아키텍트2009. 4. 9. 11:05

앞의 글에서 그린 IT 전략에서 회사 전체적인 활동을 통해 어느 정도의 CO2 가스가 절감되는지 지표화해서 관리해야 된다고 말씀드렸습니다. 기억하시죠? 아니라면 앞의 글을 한 번 훏어봐주시기 바랍니다.

10,000 Kilowatt의 전기를 절약했다면, 이 만큼의 전기가 어느 정도 CO2 가스 절감에 해당할까요?
어떤 기준으로 판단할 수 있을까요? 모든 분들이 궁금해하시는 내용입니다.
절대적인 답은 될 수 없겠지만, 미국의 EPA(Environmental Protection Agency)가 제공하는 그린하우스 가스 사용량 계산기가 도움이 될 거라고 생각합니다. 실제적으로 와닿는 개념으로 풀어서 이해가 가능합니다.

http://www.epa.gov/solar/energy-resources/calculator.html

예를들어 볼까요? 10,000 kilowatt를 절약했을 때, 546 Metric tons의 CO2 가스를 절감한 것과 동일하다는 값을 알려주는 것입니다. 그렇다면 어떤 근거로 그렇게 이야기할 수 있다는 걸까요?

Option 1:

  1. If you are starting with reductions data in units of "gallons of gasoline consumed," "kilowatt-hours of electricity," "therms of natural gas," or "passenger vehicles per year" instead of emission reductions, use this option.
  2. Enter a quantity and pick the desired unit below; and
  3. Click on the "Calculate Equivalent" button to convert your value to Carbon Dioxide Equivalent.


? Click Here for Calculations and References

Amount Unit Gas
CO2 - Carbon Dioxide
 

무슨 근거로 이렇게 이야기할 수 있을까요? eGRID(Emission & Generation Resource Integrated Database), 즉 배출 관련된 데이터를 모아놓은 데이터베이스의 통계치에 근거하고 있다는 것입니다.
계산 공식도 아래 나오는 것을 보실 수 있습니다.
재밌는 것은 전기 뿐 아니고, 휘발유 절감, 승용차 수의 운행을 줄였을 때, 가스 사용량을 줄였을 때 등의 일반적인 활동에 대한 그린하우스 가스 산출 값도 제공하고 있다는 것이죠. 이 계산기에 근거하여 이만큼의 그린하우스 가스를 절감했다고 주장할 때 그에 대해 반론을 제기할 수 있는 사람이 얼마나 있을까요?
물론 이 계산기는 미국의 사용량에 근거한 값이기 때문에 우리나라 실정에 맞는 계산기가 나와야 할 필요가 있을 것입니다. 이건 시간이 좀 걸리겠지만 진행되어야 할 내용이라고 생각합니다.

Electricity use (kilowatt-hours)

The Clean Energy Equivalencies Calculator uses the Emissions & Generation Resource Integrated Database (eGRID) U.S. annual non-baseload CO2 output emission rate when converting reductions of kilowatt-hours into avoided units of carbon dioxide emissions.

The Clean Energy Equivalencies Calculator uses an eGRID (Emissions & Generation Resource Integrated Database) non-baseload national average emissions rate when converting kilowatt-hours into avoided units of carbon dioxide emissions.

Calculation

Note: Due to rounding, performing the calculations given in the equations below may not return the exact results shown.

7.18 x 10-4 metric tons CO2 / kWh
(eGRID2007 Version 1.1, U.S. annual non-baseload CO2 output emission rate, year 2005 data)

Note: Individual subregion non-baseload emissions rates are also available on the eGRID Web site.

Sources
  • (EPA 2009) eGRID2007 Version 1.1, U.S. annual non-baseload CO2 output emission rate, year 2005 data U.S. Environmental Protection Agency, Washington, DC.
Posted by 조이트리
아키텍트2009. 4. 9. 10:43

2009년 한국정보처리학회가 주관한 "제4회 정보통신응용기술워크숍"에서 마이크로소프트의 그린IT 전략, "그린IT의 기대주, 소프트웨어"를 발표하였습니다.
그때 제가 발표한 내용의 스크립트 및 발표자료를 공개합니다. 발표자료는 첨부하겠습니다.

지구의 미래를 위해 온실가스 절감이 선택이 아닌 필수가 된 지금 신재생 에너지를 포함하여 환경에 미치는 영향을 최소화 하기 위한 다양한 활동이 진행되고 있다. IT 산업에 종사하는 사람에게는 온실가스라는 용어가 그린 IT, 그린 컴퓨팅을 쉽게 떠올린다.
Forrester Research에 의하면Green IT“ IT 공급자, 기업 고객들이 효율성을 얻고, 비용을 절감하면서 동시에 환경에 미치는 나쁜 영향을 최소화하도록 컴퓨팅 자산을 제조, 운영 및 폐기하는 방식을 변경하는 것을 의미한다.

 

그린IT하면 뭐가 떠오르시나요? 전력 사용량 절감, 즉 전기를 어떻게 하면 지금보다 더 효율적으로 사용할 것인지가 관건입니다. 전기를 만드는데 소요되는 화석연료, 예를 들면 우리나라의 보령 화력발전소, 하루 3,000 MW의 전기를 생산합니다. 하루 3만톤의 석탄을 생산하죠. 24시간 동안 73천 톤 CO2를 배출합니다. CO2를 없애기 위해 하루 2,238 9400그루의 잣나무를 심어야 한다고 하죠. 그럼, 잣나무도 심어야겠지만, 그와 맞물려서 현재 우리가 하는 일상적인 활동 중에서 그린 IT를 실천할 수 있는 것은 뭐가 있을까요?

 

저전력 서버, 스토리지, 네트웍 장비를 도입하는 것, 가상화 기술을 도입하여 물리적인 서버 대수를 최소화하는 것 등이 가장 대표적인 그린 IT의 활동들이다. 여기에 조금 더 쉽게 비디오 컨퍼런싱을 도입하여 출장을 최소화하여 에너지 사용을 줄이고, 에너지 사용으로 발생하는 이산화탄소 배출을 최소화 하는 것에서부터 복사기 사용시 용지의 양면을 사용하거나 점심시간 또는 퇴근 시 컴퓨터 전원을 반드시 끄는 캠페인 등을 통해 그린 IT를 생활에서 실천하는 것이 일반적이다.

 

그린 IT분명한 목적, 이유가 있기 때문에 중요하게 회자되고 있다고 생각합니다. 그럼 도대체 범위가 어떻게 되느냐, 무엇을 하면 된다는 말이냐?” 하는 의문점이 생깁니다. 많은 투자가 필요하고, 기존에 하던 것을 완전히 들어내야 한다면 그린 IT는 지금 같은 경기 침체기에 적합한 토픽이 아닐 것 입니다. 중요한 것은 현재 일상에서 사용하고 있는, 그리고 자연스러운 업그레이드 과정을 통해 그린 IT 실천이 가능하다는 것 입니다.

 

실제로 많은 기업들이 다양한 그린 활동들을 하고 있지만, 생각나는 순서대로 무작위로 진행하는 경우가 많다. 즉 전체적인 계획 없이 수행하므로 지속적이지 못하고, 그 결과에 대한 관리가 체계적으로 이루어지지 않기 때문에 성공, 실패 여부를 가리기 어렵다. 한 번 캠페인을 진행한 것에 의미를 두고 끝나는 경우가 너무 많다. 효과를 판단할 수 있는 지표가 없기 때문에 지속적으로 진행하는 것이 불가능하다.

그린 IT는 전략과 베스트 프랙티스가 가장 중요한 요인이라고 생각한다. “과연 어떻게 적용할 것인가? 어디서부터 시작하고, 누구의 도움을 받을 수 있는가?”에 대한 가이드 없이 하나의 제품을 적용하는 방식으로는 일회성 행사에 끝날 수 밖에 없다. 따라서, 그린 IT에서는 아키텍트의 역할이 중요하다. IT에 새로운 기술이 등장하면 IT 인프라의 효율성은 증가하겠지만, 아키텍처 설계 측면, 프로세스 개선에 대한 노력이 이루어지지 않으면 그 효과는 미미해질 수 있다. 예를 들면, 가상화, 블레이드 서버가 도입되었을 때 잠재적으로 전원소비가 줄어들겠지만, 프로세스나 가이드가 제대로 이루어지지 않는다면, 가상화의 폭주 현상을 초래할 수 있고, 결과적으로 늘어나는 가상머신을 구동하기 위한 물리적인 서버의 수가 증가하여 전력소비를 높이는 결과를 낳을 수도 있는 것이다. 또한, 잘 조율된 Cooling 아키텍처가 없다면 한 랙당 장착되는 서버 대수가 늘어나면서 데이터센터에는 전력 부족으로 인한 재앙이 벌어질 수도 있는 것이다. 과거에 IT 아키텍트들이 보안에 별 관심을 두지 않았다가, 결국에는 그로 인해 큰 어려움을 겪었던 것처럼, 환경에 대한 디자인은 새로운 프로젝트가 시작될 때 반드시 고려되어야 하는 항목이다.

 

, 그럼 그린IT를 어떻게 시작해야 하는가? 정부, 소비자, 기업 등이 공동으로 동의하는 환경 지표는 탄소배출량이다. “측정할 수 없는 것을 관리할 수 없다”. 따라서, 조직은 전력 소비와 결과를 측정하고 모니터링 할 수 있는 지표 관리 시스템이 필요하다 또한, 전략이 필요하다.

 

마이크로소프트가 생각하는 그린 IT 전략은 다음과 같은 핵심적인 내용을 포함하고 있다.

1.     그린 IT가 의미하는 것에 대한 정의, 구체적 원칙 명시

2.     IT 인프라, 공급망 관리 체인상의 제품 및 서비스가 환경에 미치는 영향 지표

3.     IT의 개선 및 적용으로 최적의 비용으로 큰 영향을 줄 수 있는 영역 발굴

4.     현재 시스템의 IT 성능 분석, 전원 사용량 분석

5.     데이터센터 등의 인프라스트럭처와 서버, 네트웍, 클라이언트 장치, 프린터 등 IT 장치 등의 에너지 효율성을 향상시킬 수 있는 구체적인 계획

6.     신규로 진행되는 프로젝트, 서버 등의 환경에 미치는 영향을 최소화 하기 위한 프로세스 및 정책 정의

7.     PC 및 각종 장치의 폐기 등을 최소화하고, 관리할 수 있는 계획 수립 및 분석

8.     환경에 미치는 영향을 고려한 구매 가이드라인 수립

 

오늘 발표는 그린 IT 전략, 첫째, 줄이고, 둘째, 관리하고, 셋째, 다시 생각하자의 순서로 진행하겠습니다. 그린IT가 한 조직 내에서 잘 정착하려면 임원의 적극적인 의지, 임직원의 참여, 활동에 대한 투명한 리포팅을 통해 가능하다고 생각합니다. 그 적용 대상으로는 지금까지는 클라이언트 장치, 서버, 네트웍, 스토리지, 데이터센터과 초점에 되어 왔다면 소프트웨어를 통해서 많은 것을 이룰 수 있다고 생각합니다. 오늘의 주제를 그린 IT의 기대주, 소프트웨어로 설정한 것도 그와 같은 맥락 입니다.

 

이 중 데이터센터는 가장 많은 전력을 소비하는 곳으로 알려져 있다. 왜냐하면, IT 시스템들은 점점 더 많은 솔루션들을 통해 에너지 수요량이 늘어나고 있고, 아키텍트들은 훨씬 더 복잡하게 시스템을 설계하고 있다. 또한, 물리적인 서버들이 사용하는 에너지 소비량이 급격히 증가했다. 가장 중요한 이유 중 하나는 도입되었다 사라지는 솔루션보다 훨씬 더 많은 수의 엔터프라이즈 IT 솔루션이 신규로 생겨나고 있기 때문이다. 이와 같이 에너지 소비는 그린 하우스 배출에 직접적인 영향을 미친다.

이렇게 볼 때, 아래와 같은 등식이 가능해진다.

 

에너지 소비를 줄인다 = 그린하우스 가스 배출 감소 = 데이터센터 및 비즈니스 운영 비용 절감

 

마이크로소프트의 그린 IT 전략은 크게 3가지 분야로 나누어 생각해볼 수 있다.

첫째, 줄이고

둘째, 관리하고

셋째, 다시 생각하자

 

줄이고

아키텍처는 적은 수의 서버로 에너지 효율이 좋은 시스템을 도입하고, 애플리케이션이 물리적인 자원을 최적화하도록 하여 적은 코드, 시스템으로 더 많은 일을 하도록 하는 것이다.

 

빌트인 에너지 효율을 고려해야 한다. Windows Vista, Windows 7, Windows Server 2008 운영체제에만 전력 관리 기능이 36개가 내장되어 있다. 또한, Windows Server 2008의 경우 이전 버전의 운영체제에 비해 동일한 하드웨어를 사용하여 테스트한 결과 10% 정도의 에너지를 절감하는 것으로 나타났고, 그룹정책을 적용하고 관리하는 등의 활동으로 효율성을 높일 수 있다.

 

통합을 통한 최적화도 적용 가능하다. 서버 가상화를 통해 10대의 물리적인 서버를 1대의 물리적인 서버 위에 구동되는 10개의 가상머신으로 통합함으로써 약 9대의 서버가 소비하는 전력을 절감할 수 있게 되고 이는 큰 비용절감, 환경영향 최소화로 수치화될 수 있다. 또한, 컴퓨터 효율화를 모니터링 하여 낭비를 줄일 수 있다.

 

서버의 전원 정책의 설정을 확인, 조정하도록 가이드하는 Assessment and Planning Toolkit을 통해 업무 수행에 대한 도움을 받을 수 있다.

 

전력 절감 모드 선택으로 기본적인 전력 사용량을 절감 가능하다. 새로운 CPU에는 프로세서의 상태에 따라 전원 사용량을 다르게 책정 가능하다. CPU 사용량이 100%일 때와 50%일 때는 Frequency에 차이가 발생하는 것을 볼 수 있고, 그 때 사용하는 전력량도 95w, 32w로 약 3배 정도 절감되는 것을 확인할 수 있다. 결국 p-state를 적용하는 것과 적용하지 않는 것이 이러한 차이로 나타나는 것이다. 이로 인해, Windows Server 2008의 에너지 효율성은 이전 버전 서버에 비해 동일 하드웨어를 사용했을 때 약 10% 정도 뛰어난 것으로 BMT 결과 확인되었다.

 

두 번째로 가능한 것이 가상화를 통한 절감인데, 오른쪽 막대의 경우 물리적인 서버수의 증가에 비례하여 전력사용량이 늘어나는 것을 볼 수 있다. 하지만, 가상화된 환경에서는 거의 차이가 없는 것을 확인할 수 있다. 실제로 10대의 물리적인 서버를 구동하는 것과, 한대의 물리적인 서버에 10개의 가상 머신을 구동하는 것의 차이는 약 1/10 수준인 것을 수치로 확인 가능하다. 마이크로소프트의 개발 및 테스트 환경을 가상환경으로 변경을 통해 비용, 하드드라이브 공간, Rack 및 전력사용량의 절감을 통해 가시적인 효과를 본 것을 알 수 있다.

 

 

관리하고

2006년 조사에 의하면 미국 전체 전력 소비량의 1.5%를 데이터센터가 사용하는 것으로 조사됐고 클라우드 컴퓨팅 등의 비즈니스가 활성화되며, 데이터센터 설립이 경쟁적으로 추진되면서 그 비율이 계속 늘어나는 추세다. 에너지 효율화가 필요한 주요 영역인 데이터센터는 4가지 영역에서 에너지를 소비한다.

1.     컴퓨팅 시스템 (서버, 네트웍, 스토리지)

2.     쿨링

3.     전원 변환, PDU(Power Distribution Unit)

4.     Hoteling (전기 장치 등)

쿨링 및 전원 변환 등의 시설이 어떻게 디자인되어 있는지에 따라 전원 효율화가 큰 차이를 보인다. 실제로 데이터센터의 존재 이유는 컴퓨팅 시스템을 구동하기 위한 것이므로 전원 변환 및 쿨링, Hoteling에 소모되는 전원의 양을 최소화하여 최대의 양을 컴퓨팅 시스템이 사용하도록 하는 것이 바람직할 것이다. 데이터센터에 들어오는 총 전력량 중 컴퓨팅 시스템(서버,스토리지,네트웍장비)이 사용하는 전력으로 나는 것이 바로 PUE(Power Usage Effectiveness) 이다. 미국의 “The Green Grid” 컨소시엄에 의해 제안된 이 지표는 실제로 AMD, Dell, Intel, IBM, 마이크로소프트, EMC 등의 글로벌 벤더들이 참여하고 있고, 적용하고 있다.

이때, PUE를 포함하여 탄소배출량 등의 지표까지 함께 관리하여 그린 활동을 통한 큰 개선이 가능하다.

 

다시 생각하자

그린IT를 통해 매출 증가, 비용 절감 등의 비즈니스에 영향을 주는 효과가 발생하지 않으면 지속하기 어려운 것이 사실이다. 비용절감을 통한 ROI 개선 등의 비용과 직접 영향 있는 분야부터, 브랜드 이미지 개선 및 임직원 만족도 증가 등의 보이지 않지만 중요한 부분까지 고려하여 그린 IT는 추진되어야 한다. 또한, “녹색성장포럼등의 다양한 단체와 연계하여 추진하는 것도 중요하다. “Green Grid” 같은 컨소시엄이 제공하는 베스트 프랙티스 (http://www.thegreengrid.org) , 마이크로소프트가 제공하는 베스트 프랙티스(http://www.microsoft.com/environment) 등을 참고하는 것도 좋은 방법이 될 것 같다.

 

앞에서 언급했듯 측정할 수 없는 것은 관리할 수 없는 것처럼, 처음 전략을 수립할 때 정했던 지표를 추적하고 관리할 수 있는 그린IT 관리 시스템의 도입이 중요할 것으로 보이고, 이때는 비용절감, 이산화탄소 배출량 절감치 등에 대해서도 이력 관리가 이루어질 수 있고, 사내뿐 아니라 외부에도 정보를 공개하는 적극적인 대응이 중요할 것이라고 생각된다.

 

마지막으로 지금까지는 데이터센터, 서버 등의 하드웨어를 통한 그린을 생각했다면 아직은 태동기지만, 그린 소프트웨어가 주요한 역할을 수행하게 될 것이라고 생각한다.

1.     비즈니스 Travel 최소화

- 비디오 컨퍼런싱 (원격지 협업 및 의사 결정 방식 개선)
- ROI:
출장비용 절감, 탄소 배출량 절감

2.     Supply Chain 효율성 강화
-
운송 수단 및 패키징 등의 결정 시 환경 영향 최소화

3.     환경 친화적인 제품 디자인

   - 제품 디자인, 전사적 자원 관리 소프트웨어에 환경 관련 원칙 적용

4. 탄소 배출량을 관리, 리포팅

 

앞에서도 강조했듯 IT 자원의 에너지 사용량을 조절하는 것은 중요하고, 큰 의미가 있지만 건물 관리, 출퇴근 및 비즈니스 출장 같은 비즈니스 업무 등과 함께 고려하고, 그 활동을 통한 비용 및 환경적 영향에 대해 지표로 관리할 수 있어야 효과를 볼 수 있고 지속할 수 있다. 물론, 아직은 어떤 지표를 기준으로 삼을 것인지에 대해서도 각 주체간의 동의가 이루어진 상태가 아니기에 갈 길이 멀지만 정부 주도로 짧은 시간 안에 가이드가 제공되어야 할 것으로 생각된다. 결국, 어떤 형태로든 CO2 배출량이 회사의 대차대조표에 앞으로 10년 안에 부채로 기입될 가능성이 높고, 어느 기업도 피해갈 수 없을 것으로 보여지므로 성공적인 그린 IT 전략을 수립하고 이행하는 노력이 시급할 것으로 보인다.

Posted by 조이트리
아키텍트2009. 4. 7. 17:44

클라우드 컴퓨팅은 클라우드 사업자가 모든 인프라, 플랫폼을 제공하는 공용 클라우드와 기업이 자체 클라우드 환경을 구축하는 사설 클라우드의 두 가지 유형이 존재합니다.

그 중에서 사설 클라우드는 데이터센터를 자체 운영하는 엔터프라이즈 및 IDC들이 구축할 것으로 예상된다고 말씀드렸는데요, 마이크로소프트 서버 및 툴 총책임자인 President Bog Muglia께서 사설 클라우드 구축에 관해 아래와 같이 밝혔습니다.


"We will move more and more into managing pools of resources," Muglia said. Traditional data centers, and even most virtualized data centers, require administrators to manage servers as discrete entities and to move applications manually. Private clouds will take a much more flexible, scalable, automated approach and draw computing power from pools of resources, rather than discrete servers, and will adopt many of the best practices of public cloud vendors.

요약해보면 이렇습니다. 전통적인 데이터센터, 가상화를 적용한 데이터센터의 경우 관리자가 각 서버 자원들을 직접 관리하면서 그 위에 구동되는 애플리케이션을 수동으로 배포하고 있는데, 사설 클라우드 환경을 적용한 경우 개별 서버에 대한 관리가 아닌 모든 자원들을 Pool 개념으로 묶어서 훨씬 더 유연하고, 확장 가능하며 자동화된 접근 방식을 사용할 수 있다는 거죠.

IT 운영관점의 변화라고 볼 수 있을 것 같은데요 지금까지는 서버 워크로드를 어디에, 어떻게 배치하여 구동할 것인가에 집중하고 있었다면 앞으로는 이러한 일들을 컴퓨터가 대행하게 될 거라는 겁니다. 예를들면, 현재 버전의 가상 머신 관리자(VMM)은 가상서버를 어디에 배치할 것인지를 배치 마법사(Placement Wizard)가 추천하면 관리자가 적용하는 방식으로 이루어지지만, 향후 버전에서는 마법사가 없어지고 프로세스가 자동화될 것으로 보여집니다. 데이터센터 관리자가 자원 풀에 물리적 서버를 추가해놓으면 관리 소프트웨어가 이러한 자원을 가장 최적화하여 사용하는 개념입니다.

시스템 센터는 윈도우, 리눅스 서버등 이기종 환경을 관리할 수 있어야 겠죠. 물론, 현재 시스템 센터도 크로스 플랫폼 확장 add-on을 통해 리눅스 환경을 관리할 수 있습니다.
물론 Windows Server 2008 R2, 새로운 시스템센터 만으로 사설 클라우드를 바로 현실로 만들기는 어렵다고 설명했는데, 그 이유는 애플리케이션이 확장, 병렬 프로세싱을 사용하도록 설계되지 않으면 원하는 형태로 구축이 안될 거라는 거죠. 마이크로소프트 역시 병렬 프로그래밍 패러다임, Oslo 모델링 플랫폼, .Net 프레임웍 등을 통해 애플리케이션이 여러 서버를 가로지르면 구동 가능하도록 개발할 수 있도록 하는데 많은 노력을 기울이고 있습니다.

언제 사설 클라우드 구축이 가능한 Windows  Server R2, System Center가 준비될 것인지에 대해서는 아직 정확한 일정은 없지만, 가까운 미래에 사설 클라우드 구축 역시 하나의 주요한 움직임이 될 것이라고 생각됩니다.

Posted by 조이트리
아키텍트2009. 4. 6. 20:04
2009년 4월 6일자 전자신문 34면에 전면 기사로 나왔습니다. 클라우드 컴퓨팅 시나리오, 각 업체의 전략, 서비스 도입시 고려해야 하는 사항 등에 대해 기술했습니다.
한 번 읽어보시고 도움이 되셨으면 좋겠습니다.

http://www.etnews.co.kr/news/detail.html?id=200903310318

감사합니다.
Posted by 조이트리
아키텍트2009. 4. 2. 17:21
스캔한 자료를 올리면 문제가 될 것 같아서 그냥 알려만 드려요.
'클라우드 컴퓨팅을 말한다' 인터뷰 기사 입니다.
제목은 '클라우드 컴퓨팅' 조만간 '대세' 될 것 입니다.

기회 되시면 한 번 읽어 보세요. 4월이 끝나면 제가 원문을 올려보도록 하겠습니다.
Posted by 조이트리
아키텍트2009. 4. 1. 15:31

REST 아키텍처 스타일에 대해서는 앞의 글에서도 소개했었는데, 오늘은 WCF 서비스를 활용한 방법에 대해 이야기하려고 합니다. REST(Representational State Transfer)에 대해서는 많은 분들이 도대체 뭐야? 라는 반응을 보이십니다.
하지만, 앞으로 정말 많이, 여러번 듣게 되실 개념이기 때문에 꼭 이해가 필요합니다.

WOA(Web Oriented Architecture)가 결국은 RESTful 아키텍처를 의미합니다.

REST란?
아키텍처 스타일이란 말은 어떤 무엇인가를 구축할 때 적용되는 규약들의 집합이라고 이야기할 수 있습니다. 즉, 소프트웨어 시스템을 구현할 때 사용되는 가이드 정도로 이해하면 되겠습니다.

클라이언트가 서비스(Endpoint)를 요청할 때 사용되는 클라이언트 – 서버 아키텍처 스타일 중의 하나입니다.
HTTP 스펙을 만든 사람 중의 한 명인 Roy Fielding 교수가 박사학위 논문에서 사용한 개념 입니다.
Architectural Styles and the Design of Network-based Software Architectures

Web이 바로 REST 아키텍처 스타일을 그대로 따르고 있는 시스템 입니다. 원칙을 한 번 살펴보도록 하죠.

  • 사용자 에이전트가 자원과 상호작용하는데, 자원은 URI로 표현될 수 있는 모든 것들이 대상입니다.
  • 자원과의 상호작용은 HTTP의 표준 동사(GET, POST, PUT, and DELETE)를 사용하여 이루어집니다. 또한, 상호작용을 위해 자원의 미디어타입이 결정되는데 HTTP 컨텐츠 타입의 헤더를 사용합니다.
    (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
  • 자원은 필요한 모든 정보를 다 포함하고 있습니다. (서비스가 stateless 형태로 존재)
  • 자원은 다른 자원과의 링크를 포함합니다. (하이퍼미디어)

하나의 간단한 예제로 이해를 해보도록 하죠.

MSDN 매거진의 데이터을 처리하는 서비스를 만든다고 가정해보죠.
- 해당 서비스는 지금까지 발행된 모든 MSDN 매거진에 대한 정보를 알려줍니다.
  매거진의 편집자가 이 서비스를 쓸 것이고 새로 발행되는 매거진에 대한 정보를 추가하고, 관리하는 등의 작업을 할
   예정 입니다.

RESTful 서비스를 구축할 때 서비스 디자인 단계를 살펴보죠

  1. 자원은 어떤 것들이 될 것인지?
  2. 자원을 표현하는데 사용할 URI로 어떤 값을 쓸 것인지?
  3. 단일 인터페이스 (HTTP 동사) 중 어떤 것을 쓸 것인지?

RESTful endpoint를 만드는 기본적인 블럭들입니다. 자원, 그리고 표현 방법

자원: MSDN 잡지가 출간된 모든 년도, 매년 발행된 이슈, 매거진에 게재된 기사
해당 자원을 표현하기 위해 XML을 사용하기로 하죠, 하지만 RESTful서비스는 XML에 한정된 것은 아니고 여러 유형으로 표현 가능합니다.

이제 URI를 결정해보죠. 절대경로는 이 endpoint를 어떤 호스트에 배치할 것인지에 달라지기 때문에, 여기서는 상대경로로 표현하도록 하겠습니다.
모든 년도들의 리스트, 즉 서비스의 루트 URI로 / 를 사용합니다.
이 구문을 활용하면, /{year} 는 해당 년도에 발행된 모든 잡지들에 대한 정보를 리턴합니다.
/{year}/{issue}는 해당 년도에 발행된 특정한 이슈에 대한 값을 리턴하겠죠.
/{year}/{issue}/{article}은 해당 이슈의 기사에 대한 정보값을 리턴하는데, 각 기사는 1 .. n까지 번호가 매겨졌다고 가정하죠

자, 이제 해당 URI를 단일인터페이스 (HTTP 동사)와 연결해보죠. 해당 잡지의 히스토리는 읽기 전용이어야 하므로, 해당 root 자원은 GET 동사만 사용되어야 합니다. 새로운 년도는 추가될 수 있으므로 PUT을 통해 /{year}가 추가되고, PUT을 통해 수정도 이루어질 수 있습니다. POST 연산을 통해서는 해당 자원을 신규로 생성할 때 사용되는데 해당 이슈를 만드는, /{year}/{issue} 등으로 사용합니다.

예를들어, 2006년 1월 이슈의 모든 기사를 원한다면 HTTP GET /2006/January 라고 가져올 수 있을 것이고 2009년 3월 이슈를 만들려면 POST /2008/december라고 쓸 수 있다는 것이죠.

그렇다면 왜 REST에 대해 이야기를 할까요?
서비스를 사용하는 방법이 REST 밖에 없을까요? 그렇지 않습니다.

클라이언트 서버 스타링의 애플리케이션을 구현하는데 있어서 다른 아키텍처 스타일을 사용할 수 있습니다. .NET의 특화된 RPC(Remote Procedure Call), 즉 DCOM 및 .NET 리모팅 등을 사용하거나 상호운용성이 제공되는 ASMX를 사용하는 SOAP, WCF 등의 RPC 기술을 사용할 수 있었죠.
그런데, REST를 사용하면 첫째, 훨씬 간편하고 쉽게 서비스를 구현할 수 있고 둘째, 마이크로소프트가 RPC 기술(SOAP 포함)에 비해 REST 아키텍처 스타일을 훨씬 더 선호하고 있기 때문인데, 그 이유가 있다는 거죠. 마이크로소프트의 클라우드 컴퓨팅, 애저 서비스 플랫폼과 윈도 애저에서도 REST 스타일을 채택하고 있습니다.

장점
Caching HTTP 동사를 통해 RESTfu endpoint가 불리워 질 때, HTTP 동사 GET을 사용합니다. GET으로 불리워진 자원들은 여러 다양한 방법으로 캐싱이 가능합니다. 결국 속도와 확장성이 향상됩니다.

Scale-Out REST는 각 자원이 특정 요청에 필요한 모든 상태 값을 다 가지고 있기 때문에, 즉 stateless기 때문에 확장이 훨씬 용이합니다.

Idempotent GET을 이용해 자원을 요청할 때 추가적인 부작용이 벌어지지 않습니다 (즉, 다시 한 번 GET, DELETE 등을 불러도 두번 중복작업이 이루어지지 않음)

Interoperability SOAP이 클라이언트 서버 프로그램을 통해 상호운용성이 뛰어나다고 하지만, 몇 몇 언어 및 환경은 여전히 SOAP 툴킷을 갖고 있지 못하고, 툴킷을 가지고 있는 언어의 경우에도 최신 표중르 가진 다른 툴킷과 통신할 수 없는 경우가 종종 발생합니다. REST는 HTTP 동사만을 사용하기 때문에 어떤 언어, 플랫폼과도 상호운용이 가능합니다.

Simplicity 너무 단순하게 구현이 가능합니다. URI와 HTTP 동사는 모든 웹개발자들이 다 알고 있는 내용입니다.

가능한 경우에 REST를 많이 사용하시기 바라고, 엔터프라이즈에서도 고려하고 있는 중입니다.

WCF and REST

WCF는 스타일, 프로토콜에 무관하게 통신이 가능한 분산 컴퓨팅 환경의 애플리케이션을 구축하는데 사용되는 마이크로소프트의 프레임웍 입니다. WCF 개념은 개발자가 한 프로그래밍 언어를 통해 다른 많은 분산 시스템을 사용 가능하도록 돕는 기술 입니다.

이전 버전의 WCF는 RPC(SOAP 등)를 이용하도록 사용되었는데, .NET Framwork 3.0부터는 REST 서비스를 사용할 수 있도록 지원하고 있었는데 REST 기반 서비스 프로그래밍이 가능한 모델 및 인프라 지원이 부족했는데, .NET Framwork 3.5 SP1에 프로그래밍 모델 및 기타 많은 부분이 개선되었습니다. 저도 조금 살펴봤는데 잘 만들어졌습니다.

프로그래밍 모델 중 두가지 속성, WebGetAttribute 과 WebInvokeAttribute, URI template 메커니즘이 주목할 만합니다.
URI, 메쏘드에 적용될 동사를 정의할 수 있도록 해주는 거죠. 인프라 영역에서는 WebHttpBinding 바인딩과 REST가 적절한 네트웍 스택을 사용할 수 있도록 WebHttp­Behavior가 지원됩니다. 또한, 커스톰 Service­Host (WebServiceHost) 와 ServiceHostFactory (WebServiceHostFactory)가 포함되어 있습니다.

WebGetAttribute 와 WebInvokeAttribute

WCF는 연결된 시스템 구축을 간단하게 해주는데, 네트웍 메시지를 여러분이 서비스를 구현하기 위해 정의한 클래스의 인스턴스로 라우팅해버린다. 결국, 네트웍 트랙픽을 처리하기 위한 인프라에 신경쓰지 않고, 코드의 로직에 집중할 수 있게 해주는 거죠. WCF와 인프라를 함께 사용할 때 기본 디스패처는 요청에서 사용하는 URI를 기준으로 라우팅을 진행합니다. 즉, 이 라우팅 방식을 사용하면 RESTful endpoint를 아주 쉽게 구현할 수 있고, 실제로 WebHttpDispatchOperationSelector를 사용합니다. 

이것이 가능하도록 하는 핵심은 WebHttpDispatch­OperationSelector는 서로 다른 URI와 동사를 여러분이 만든 메쏘드에 어떻게 매핑할 것인지를 아는 거죠. WebGetAttribute 와 WebInvokeAttribute는 WCF ServiceContract Type의 메쏘드에 반드시 포함되어야 합니다. WebGetAttribute는 디스패처에게 해당 HTTP GET 요청에 응답해야 한다고 알려주고, WebInvokeAttribute는 디폴트로 HTTP POST에 매핑됩니다. 메쏘드 속성은 다른 HTTP 동사를 지원하기 위해 설정 가능합니다. (PUT 과 DELETE ). 디폴트로 URI는 메쏘드에 이름으로 결정됩니다.
UriTemplate 과 UriTemplateTable

WCF는 각 자원의 URI를 정의할 수 있습니다.
이 경우에 AddArticle 메쏘드에 Method="POST"를 가독성을 위해 추가했습니다. (디폴트: WebInvokeAttribute POST). GET 과 POST 메쏘드는 uriTemplate을 통해 URI 커스토마이제이션 가능합니다.

WebHttpBinding 와 WebHttpBehavior

WCF에서 바인딩이 WCF가 어떻게 통신할 것인지를 결정합니다. RESTful endpoint를 위해 WebHttpBinding을 사용합니다. 다른 바인딩과 다르게 WebHttpBinding는 굉장히 간단합니다. 두 개의 컴포넌트 (HTTP transport 와 text message encoder)

WebHttpBehavior는 URI와 동사 디스패처를 위해 사용됩니다. WebHttpBinding과 항상 함께 사용된다고 보면 되죠.

ServiceHost sh =
  new ServiceHost(typeof(MSDNMagazineServiceType));
string baseUri = "http://localhost/MagazineService";
ServiceEndpoint se =
  sh.AddServiceEndpoint(typeof(IMSDNMagazineService),
  new WebHttpBinding(), baseUri);
se.Behaviors.Add(new WebHttpBehavior());
sh.Open();
WebHttpBinding을 지정해야할 뿐 아니라, ServiceHost의 endpoint도 추가해야 합니다. 또한, 명시적으로 WebHttpBehavior를 추가하여 endpoint에 URI와 동사 디스패칭 시스템이 동작하도록 하는 작업이 추가되어야 합니다.
물론, 설정으로도 위와 동일한 작업을 할 수 있죠.
WebServiceHost 와 WebServiceHostFactory

WCF에 대한 불만 중 하나가 설정에 관해 때때로 너무 복잡하다는 것입니다. RESTful endpoint의 이러한 불만을 줄이기 위해, 마이크로소프트는 WebServiceHost 와 WebServiceHostFactory를 .NET Framework 3.5에 추가하였습니다.
WebServiceHost 는 RESTful endpoint의 자체 호스팅 시나리오를 간단히 하기 해 추가된 유형입니다.

string baseUri = "http://localhost/MagazineService";
WebServiceHost sh =
  new WebServiceHost(typeof(MSDNMagazineServiceType),
  new Uri(baseUri));
sh.Open();

바로 이 코드를 사용하면 WebHttpBinding, WebHttpBehavior를 수작업으로 매번 추가하는 번거로움을 덜 수 있습니다. WebServiceHost 클래스가 자동으로 endpoint을 만들고, WebHttpBinding, WebHttpBehavior가 하는 설정을 대신해주기 때문이죠. IIS 웹서버에서 WCF 매니지드 호스팅 시나리오에서 WCF는 보통 서비스 타입을 가리키기 위해 .svc 파일이필요하고, WCF에게 endpoint에 대한 정보를 알려주기 위해 web.config 파일에 entry 를 추가합니다.
즉, 매니지드 호스팅 시나리오를 단순화 하기 위해 마이크로소프트는 WebServiceHostFactory를 추가했는데, 여러 RESTful 서비스의 설정 관련 부분을 덜어주기 위해 확장 point를 개방합니다.

<%@ ServiceHost Factory=
  "System.ServiceModel.Activation.WebServiceHostFactory"  
  Service="MSDNMagazine.MSDNMagazineServiceType" %>
WebServiceHostFactory는  WebServiceHost의 인스턴스를 생성하고, WebServiceHost는 WebHttpBinding과 WebHttpBehavior를 이용해 endpoint를 자동설정 합니다. 물론 바인딩에 대한 정보가 변경될 때는 설정 파일에 적절한 entries 값을 추가해야 겠죠.

Figure 1 서비스 endpoint에 HTTP 기본 인증을 설정하는 파일
Figure 1 HTTP Basic Authentication

예제 코드 사용하기

서비스를 만들고 구동하고 있다면, 어떤 클라이언트를 통해서도 root URI를 입력할 수 있습니다. 브라우저를 이용한 RESTful endpoint 테스트를 위해 아래와 같이 한 번 해보시죠.

Figure 2

Figure 2 Root Resource URI
이 경우에 나는 Visual Studio 2008 웹 개발 서버에 해당 코드를 호스팅하고 있습니다. Issues.svc 파일은 WCF 매니지드 호스팅 시나리오에서 필요한 파일 입니다. 특정 년도 값을 보기 위해서는 아래와 같이 입력합니다. Figure 3
Figure 3 2007년도를 나타내는 자원
만약 2008년 10월을 요청하려고 한다면, URI는 localhost:1355/Issues.svc/2008/October가 될 것이다. (현재 10월 값이 없다고 하자) 추가하려면 HTTP POST로 해당 기사를 요청해보자.
 
 
Figure 4 기사 자원 생성
 
URI 자원을 알고, 원하는 동작을 안다면 서비스로 활용이 충분히 가능함을 느낄 수 있으시죠?
바로 이 REST 아키텍처 스타일을 활용하면 Web Feeds (RSS, Atom), JSON 등을 AJAX와 연동하여 활용가능함이 느껴지나요?

MSDN Jon Flanders의 글을 번역하였습니다.

Posted by 조이트리
아키텍트2009. 3. 23. 19:33

지난 주 마이크로소프트의 Mix09 행사에서 Windows Azure 클라우드 플랫폼 관련하여 의미 있는 발표가 있었습니다.
첫째, PHP 애플리케이션 개발 지원
둘째, Native 코드와 Full Trust 기능 추가

Windows Azure는 클라우드 상의 운영체제라고 말씀 드렸었죠? 처음 발표 때는 .NET만 가능했지만, 이번에 PHP, 다음에는 Ruby, Java 등이 추가될 것으로 예상됩니다.
IIS7의 FastCGI 기능을 통해 PHP on Windows가 최적화 된 것처럼 Azure위의 PHP도 FastCGI가 지원되고, 스트레스 테스트가 완료된 상태입니다. 현재 보유하고 계신 PHP 기술과 애플리케이션을 Windows Azure위에 올려보시는 것 어떠세요? 나중에 글로벌 서비스가 가능해지면 막대한 비용을 버실 수도 있습니다. 우리나라 뿐 아닌 이웃 나라, 아니 먼 나라에 있는 고객에게 까지 다 서비스가 가능해지기 때문이죠.

Posted by 조이트리
아키텍트2009. 3. 19. 11:45

종종 듣는 질문입니다. SQL Server 2005, SQL Server 2008이 Windows Server 2008 Hyper-V에서 정상적으로 구동되나요? 네, 당연히 지원됩니다. 그에 대한 해답은 아래 사이트에서 확인하실 수 있습니다.
http://www.microsoft.com/sqlserver/2005/en/us/support-options.aspx

“SQL Server 2005 is now supported on Hyper-V”라고 쓰여있죠?
“SQL Server 2005는 Hyper-V 가상머신에서 지원됩니다”

Posted by 조이트리
아키텍트2009. 3. 17. 11:35

Windows Server 2008 R2에서는 호스트 서버, 가상 머신 배포가 정말로 간단해집니다.

1. 호스트 서버에 운영체제를 설치하는 것
2. 가상 머신에 운영체제를 설치하는 것

두 경우 다 경험해 보셨죠? 설치 방법이 똑 같은가요? 설치하는데 몇 분 정도 걸리시나요?
가상 머신의 경우 운영체제 이미지를 미리 다 만들어서 Library에 넣어 놓고, 관리도구를 통해 필요할 때 Provision 하는 방식을 선택하셨는데, 이것도 방법을 아는 분, 모르는 분에 따라 전혀 다르게 사용하시더군요

아시는 것처럼 가상머신의 파일 포맷은 VHD가 사용되고, de facto standard가 된 것 같습니다. Windows Server 2008 Hyper-V에서도 역시 VHD 형식을 사용했는데, R2 버전에서는 2가지 중요한 업데이트가 있습니다.

첫째, 관리자가 서버를 리부팅하지 않고 구동중인 VM의 SCSI Controller에 붙어 있는 pass-through disk를 추가 및 삭제 가능합니다. 스토리지가 급격히 증가하는 경우에 추가적인 다운타임 없이 관리할 수 있고 데이터센터 백업등의 시나리오에도 유연하게 대응할 수 있음을 의미합니다.

둘째, 로컬하드디스크에 저장된 .vhd 파일을 가지고 컴퓨터를 부팅할 수 있습니다. 미리 설정된 .vhd 파일을 가지고 호스트 서버, 가상머신을 배포할 수 있다는 것을 의미하죠. 실제 운영환경에 배포하기 전에 테스트환경에 쉽게 올려 놓고 검증 한 후 운영환경으로 간다면 관리의 패러다임이 많이 바뀌게 되는 거죠

Posted by 조이트리
아키텍트2009. 3. 17. 11:22

Windows Server 2008 R2에서 더욱 강력해진 기능을 꼽으라면 Hyper-V라고 이야기하고 싶습니다.

Live Migration의 기능을 설명 드리겠습니다.
두 대의 호스트서버 A,B가 있습니다. 각 호스트서버에 가상머신 1,2가 구동중인데, 호스트 A에 구동중인 가상머신 1을 서비스 중단 없이 호스트 B로 보내는 것을 의미하죠. 가상머신 1에 연결된 사용자는 반응속도가 약간 떨어지는 것은 느낄지 모르지만, 물리적인 서버가 옮겨졌다는 것은 알지 못합니다.

 
그림1. Cluster Shared Volumes

Live Migration은 Windows Server 2008 R2에 포함된 Cluster Shared Volumes을 사용합니다. CSV는 같은 Failover Cluster안에 있는 여러 노드 들이 같은 LUN(Logical Unit Number)를 접근하도록 설계되어 있습니다. VM(가상머신) 관점에서는 각 VM이 자신만의 LUN을 가진 것처럼 보이지만 각 VM들은 같은 CSV Volume에 저장되어 있는 거죠. 
CSV안에 있는 각 노드들은 같은 이름과 경로를 갖게 됩니다.


그림2. CSV안의 같은 네임스페이스를 사용하는 예

CSV Volumes (Volume1, Volume2, Volume3)은 ClusterStorage 폴더에 저장되어 있습니다. ClusterStorage가 E: 드라이브에 위치하고 있다면 각 CSV Volume은 아래와 같이 접근 가능합니다.
E:\ClusterStorage\Volume1\Root, …

별도의 툴을 사용할 필요도 없죠? 아주 간단합니다.

또한 장점은 위의 노드 간에 단절이 발생할 때 Redirection을 통해 장애를 극복 가능합니다. 예를들면 Cluster Node2가 SAN 접근하는 경로에 장애가 발생하면 Cluster Node1으로 연결이 이루어져 SAN 접근이 가능해지는 것이죠.

괜찮죠?

Posted by 조이트리