인프라스트럭처 아키텍트 신현석의 블로그

마이크로소프트의 그린 컴퓨팅 전략

2008-11-07T08:44:20Z

온실가스, 탄소배출량 절감 등의 그린 IT 개념이 등장한지 벌써 꽤 많은 시간이 지난 것 같습니다. 지금까지 그린 IT하면 서버, 네트웍 장비, 스토리지 등의 저전력 하드웨어를 통해서만 가능한 것처럼 인식되었습니다. 하지만, 마이크로소프트는 소프트웨어를 활용한 그린 IT가 가능한 전략을 가지고 있고, 내부적으로 적용하여 효과를 얻고 있습니다. 이름하여, 그린 컴퓨팅 전략 입니다.

대한민국의 총 전기 생산량이 100이라고 가정하면, 화력발전을 통해 얻어지는 전기가 몇 정도 될까요? 놀랍게도 63.1 정도, 즉 63%에 육박합니다. 화력발전은 석탄, 석유, 천연가스를 태워서 물을 끊인 다음 터빈을 돌려서 전기를 생산합니다. 국내 보령화력발전소의 경우 하루 약 3만톤의 석탄을 사용하고, 24시간에 7만3천톤의 이산화탄소를 배출합니다. 이 정도의 이산화탄소를 분해하려면 하루에 잣나무 2,238만 9400그루를 심어야 한다고 하죠. 엄청나지 않습니까? 결국 나무로는 해결이 불가능 합니다. 우리가 할 수 있는 건 전기 사용을 줄이는 방법이 최선이라고 할 수 있죠. 마이크로소프트가 사용하는 전략은 크게 3가지 입니다.

줄이고, 관리하고, 다시 생각하자

1. 줄이고
    - Windows Server 2008은 Windows Server 2003에 비해 10% 에너지 효율성 ↑
    - 가상화를 통한 자원 최적화
       . 가상화 ROI 계산 도구 (무료)
    - 가이드 및 교육
       . Assessment & Planning Toolkit (무료) : 도구를 통해 전원관련 설정 가이드 제공
       . 데이터센터 베스트 프랙티스 제공

2. 관리하고
    - 에너지 낭비요인 줄이기 "측정할 수 없으면 개선할 수 없다"
    - 10~30% 서버는 아무일도 하지 않고 전원을 공급받는 상태 (미국, Uptime Institute 조사)
    - System Center Configuration Manager, Virtual Machine Manager, Operation Manager등

3. 다시 생각
- 환경 오염을 줄이고, 생산성 향상 시키는 방안을 늘 고민하고 적용하려고 해야 함

마이크로소프트가 위의 전략에 의해 실제 운영환경의 물리적인 서버, 477대를 16대의 서버로 줄여 약 2백만불 (24억)의 비용 절감 효과, 19TB의 디스크 공간을 8TB로 줄여 11TB의 절감 효과, 30개의 Rack을 단 2개로 줄였으며, 525 암페어의 전력 사용량을 8 암페어로 줄이는 효과를 직접 체험하였음

위와 같은 노력이 실제로 어느 정도의 탄소배출량을 절감하는지에 대한 수치를 산출하여 대외에 알리는 노력이 그린 활동의 중요한 실행, 집행 이라고 생각합니다.

Sun과 마이크로소프트의 가상화 동맹

2008-09-11T11:56:00Z

Sun과 마이크로소프트가 가상화 분야에서 중대한 동맹을 맺었습니다.

첫째, Sun의 새로운 xVM 가상화 플랫폼이 Windows Server 2008, 2003, 2000 운영체제 위에서 구동될 수 있게 되었습니다.
둘째, Sun의 Solaris 운영체제가 Windows 2008 Hyper-V 위에 Guest 운영체제로 운영 가능하도록 하는 호환성 관련 작업이 진행중 입니다.

특히, 두번째 발표 내용, 즉 Hyper-V에서 설치 및 지원 가능한 운영체제가 훨씬 다양해져 고객들의 선택의 폭이 넓어진다는 것이 가장 주목할 만한 대목입니다. 현재까지, 다양한 Windows 버전 외에 SUSE Linux가 Guest 운영체제로 사용될 수 있는데 RedHat에 이어 Solaris까지 추가 된것이죠. Solaris는 지금 당장 탑재 가능한 건 아니고요, Windows Server 2008 Service Pack 2, 즉 R2 버전이 나올 때 사용 가능한데 아직 정확한 날짜는 공개되지 않았습니다. 그렇지만 상호운영성 측면에서 정말 큰 진보 임에는 틀림 없습니다.
※ RedHat은 설치는 가능하지만, 지금 당장은 마이크로소프트가 기술 지원을 제공 하지는 않습니다.

가상화에 있어서 제일 중요한 것이 바로 관리 측면 입니다. Hyper-V에서는 System Center Operation Manager, Virtual Machine Manager, Configuration Manager가 핵심 인데, 올 가을에는 Sun의 xVM 운영 센터가 System Center Configuration Manager 2007과 함께 통합 운영이 가능해져 그 가치가 더욱 커지게 됩니다.

SOA (Service Oriented Architecture) vs WOA (Web Oriented Architecture) 비교

2008-09-10T16:25:00Z

SOA에 대하여 수년간 이야기되고 있고, 아직도 IT의 주요한 Trend 라고 이야기 합니다. 많은 기업들이 SOA를 구현하는 프로젝트를 수행했고, 지금도 진행하고 있습니다. 그렇지만 성공한 프로젝트는 그렇게 많지 않은 것 같습니다. 왜 그럴까요? SOA가 잘못된 개념일까요? 그렇지 않죠. SOA는 훌륭한 개념입니다.

잘 적용된다면 이라는 가정이 필수적이죠. 잘 적용됐을 때의 이점은 분명합니다.
서비스의 재사용으로 인해 비용 절감, 빠른 시장 진입, 비즈니스 유연성 등을 보장 받을 수 있죠.
문제는 개념이 아니라 실행입니다.
비즈니스 부서에서 시작되어야 하는데, IT 부서가 SOA를 Drive하는 형태로 진행된다면 정말 성공하기 어려울 겁니다. 투입되는 막대한 예산에 대한 ROI를 얻기가 정말 어렵죠.

조금 더 구체적으로 설명해보면 SOA 디자인의 핵심은 독특한 비즈니스 기능을 수행하는 서비스를 재활용 가능하도록 만드는 것이었습니다. 웹서비스를 만드는데 기본 프로토콜은 SOAP을 사용했고, WSDL, UDDI 등의 기본적인 표준이 포함됐고 기타 플랫폼과의 상호운영성을 위해 XML 스키마를 이용하여 개발되는 등 복잡하고 어려운 단점이 있습니다. 이에 반해 오늘 설명할 WOA(Web Oriented Architecture)는 데이터에 초점이 맞춰져 있습니다.
또한, 검증된 기술, 바로 WWW을 이루는 HTTP 프로토콜을 그대로 사용하고, SOAP보다 간단한 REST(Representational State Transfer) 프로토콜을 사용하여 URI(Uniform Resource Identifier) 형태로 참조되면서 웹서비스를 구현할 수 있습니다.

이렇게 말하면 WOA가 SOA를 대체하는 개념인가? 하고 궁금하실 겁니다. 그렇지는 않고 상호 보완 관계로 이해하시면 될 것 같습니다. SOA가 사용하는 SOAP, WSDL, UDDI 는 처음에는 스펙이 단순했지만 약 8년간 지나오면서 지원해야 하는 스펙이 타 기술과의 경쟁, 비준 등의 이유로 50개 이상으로 확대 되었습니다. 따라서, 이런 복잡한 방식말고 그냥 쉽게 웹서비스를 가져다가 쓰고 싶은 욕구가 당연히 생기겠죠? 그때 사용한 프로토콜이 바로 REST 입니다. 간단한 것이 대중화가 훨씬 쉬운 법이죠. 아마존의 웹서비스, AWS 중 S3 (Simple Storage Service), EC2(Elastic Cloud Computing) 역시 REST/WOA 방식으로 서비스 되고 있습니다. 처음 개발자들에게 SOA/SOAP, WOA/REST 방식을 선택해서 쓰라고 해봤더니 85%가 WOA/REST 방식을 선택하였기에 해당 서비스가 WOA/REST 방식으로 이루어지고 있는 거죠. 마이크로소프트도 역시 REST 방식의 프로토콜을 이용한 WOA를 지원하는데, .NET Framework 3.0 SP1에서 제공하는 WCF 서비스, ADO.NET 서비스, SQL Server Data Services 등도 모두 이 예에 속합니다.

이렇게 설명하면 WOA가 새로운 기술이라고 생각하시나요? 그렇게 보지 마시고, 기존에 모두 있던 기술, 즉 "REST, HTTP 프로토콜을 활용해 웹서비스를 생성한 것"이라고 이해하시면 되는데, 여기에 이름을 붙였다라고 보시면 될 것 같네요.

자, 이제 그럼 WOA가 어디에 쓰이고, 왜 많이 쓰일까 좀 살펴봐야겠죠. 웹2.0에서 아주 중요한 개념입니다. 웹기반 SW는 브라우저, 웹서비스로도 지원되어 새로운 형태로 메시업되어 사용될 수 있어야 합니다. 이렇게 되면 SW가 단순한 어플리케이션에서 진정한 플랫폼으로 변환 되는 것을 의미합니다. 마이크로소프트의 Virtual Earth를 가져다가 자동차 보험회사에서 사고처리 하는 웹을 구현하는 것도 하나의 예가 되고, Salesforce.com의 AppExchange를 통해 서비스를 조합하여 원하는 형태의 업무가 가능하게 하는 것도 또다른 예가 되겠죠.
즉, 어플리케이션을 웹서비스로 공유하여 내가 만든 기능과 데이터를 다른 사람이 혁신적인 방식으로 유용하게 사용하는, 이전에는 상상하기 어려운 진보를 이루어 내는 겁니다. 누구나 거대한 서비스의 공급망의 일원이 되는 거죠. 단순하고 직관적으로, "Just Work"를 이루어 내는 겁니다. 내부에서 사용하는 방식도 HTTP의 GET, POST, PUT, DELETE 등의 이미 알고 있는 형태로 조작됩니다.

짐작하셨겠지만 장점만 있을까요? 당연히 아니겠죠. Two-phase commit, 메시징에 대한 보안 등은 처리가 안됩니다. SOAP에서 가능한 WS-* 표준이 지원되지 않기 때문이죠. HTTPS를 통한 전송에 대한 보안만 제공됩니다.

WOA에 대해 조금 설명을 해보겠습니다.
1. 네트웍상에 리소스 형태, 즉 URI로 표현, 접근, 조작됩니다. (HTTP 프로토콜)
2. 네트웍상의 모든 자원은 URI 형태로 배치됩니다.
- URI는 자원임을 알 수 있는 것이 바람직합니다.
예) http://domain.com/blogs/feeds/sruby.com -> http://domain.com/resources/1234567
3. 자원은 HTTP 동사(즉, GET, POST, PUT, DELETE)로 조작됩니다. using REST
4. 자원의 형식(XHTML, XML, MP3, AVI 등)은 URI에 인코딩 되어야 합니다. .xml 일반적
5. 네트웍상의 자원에 대한 조작은 네트웍상의 컴포넌트를 통해 조작됩니다. (브라우저, 웹서버)
6. 자원에 대한 접근은 계층적으로 이루어지고, 기본 네트웍 지식으로 사용 가능합니다.
7. 보내지는 상태에 대한 전송은 각 컴포넌트가 책임져야 합니다.
8. WOA 자원은 더 큰 네트웍을 표현할 수 있도록 내장 URI를 가져갈 수 있습니다. (예, 주문 컴포넌트는 인벤토리 포함가능)
9. WOA는 Thomas Erl의 "SOA 핵심 원칙"을 따릅니다.

SOA와 WOA의 차이점 입니다.
1. SOA는 작고, 잘 정의된 Endpoint가 있는 경향이 있습니다. WOA는 매우 크고, Open된 많은 Endpoint가 있습니다.
2. 전통적으로 SOA는 SOAP을 사용한 HTTP 프로토콜 위에 메시지 Layer를 구축하는데, 유일하고 웹 개발자가 그대로 따라하도록 만들어집니다. WOA는 HTTP 및 그에 맞는 전송 메커니즘을 따르게 됩니다.
3. SOA는 벤더를 중심으로 Top Down 형태로 디자인 되고, WOA는 개발자들 중심의 Bottom Up 방식으로 나타납니다. 간단한 절차 코드와 XML 파서만 있으면 됩니다.
4. SOA는 보안 기능을 위해, 즉 메시지 암호화 등을 위해 WS-Security를 사용하는데 반해 WOA는 HTTPS를 사용합니다.
5. 웹 서비스 간의 상호 운영성을 위해 SOA는 XML 스키마를 사용해야만 합니다 WOA는 일반적으로 어떤 포맷도 가능합니다.
6. 전통적으로 SOA는 웹 브라우저 및 매시업 형태로 사용하기 어렵고 성가십니다. WOA는 어디서나 쉽게 사용 가능합니다.

즉, SOA와 WOA는 완전히 별개가 아니고 상호 보완 하는 형태로 이해하는 것이 좋습니다.

마이크로소프트 데이터센터 운영상의 에너지 효율 베스트 프랙티스

2008-09-08T10:47:00Z

과거에는 데이터센터 디자인을 할 때 물리적인 공간 비용, 즉 상면 비용이 핵심 고려사항 이었습니다. 하지만, 최근에는 전력 및 쿨링 비용의 급격한 상승으로 전력 및 쿨링의 효과적인 설계가 총 TCO를 줄일 가장 중요한 요인이라는 것이 밝혀졌죠.

※ 위의 그림에서 보듯 서버 숫자는 많이 늘었지만, 전체적인 전원 소비량은 그만큼 증가하지 않았음을 보실 수 있습니다.

비용 및 에너지 효율이 고려된 데이터센터 설계

마이크로소프트는 데이터센터를 24시간 구동되는 하나의 대형 컴퓨터로 보고 설계합니다. 컴퓨터는 사용자의 특정 목적에 맞게 설정되고 사용될 때 가장 잘 동작하는데, 똑같은 규칙이 데이터센터에도 그대로 적용됩니다. 데이터센터 사용자 및 특정 사이트의 조건에 가장 부합하는 리소스 효율적인 디자인이 요구되는 것인데, 마이크로소프트는 전력 배분, 쿨링 시스템, 서버 및 Rack/ 컨테이너 시스템 등 다양한 기술에 대해 분석 및 연구하고 있습니다.

여러 요소를 분석 및 평가하여 최적의 디자인 도출

최적의 환경을 만들기 위해 디자이너는 모든 비용 요소를 고려해야 합니다.
: 빌딩, 토지, 전력 장치, 쿨링 장치, 전기, 물, 네트웍 및 엔지니어 등

마이크로소프트는 데이터센터의 장소를 선정하기 위한 히트맵을 이용하기 위해 소프트웨어 를 사용합니다. 장소가 선택되면 시설의 전체 라이프사이클 동안의 총 소유비용을 낮추기 위한 빌딩 및 장치의 디자인에 대한 평가를 시작하죠. 조직의 여러 팀간에 Ownership을 분산시키기 보다는 장소 선택, 빌딩 디자인 및 운영에 대해서 하나의 단일 조직이 맡도록 합니다. 데이터 센터 및 TCO 절감에 대한 단일 책임을 부여하기 위해서 그렇습니다.

최대의 효율 및 성능을 위해 프로비저닝 최적화

잘 아시는 것처럼 대부분의 데이터센터는 처음 구축된 후 수년간 부분 가동됩니다. 데이터센터의 필요한 부분만 가동하는 것이 가능하다는 말이죠. 하지만, 정말 그렇게 되나요? Rack이 하나만 있어도 전체 데이터센터의 Cooling 시스템을 가동하고 있지는 않으신가요? 바로 이부분이 대부분의 데이터센터가 놓치고 있다고 생각합니다. 마이크로소프트는 데이터센터의 일부분만 가동이 가능하도록 데이터센터 인프라 설계를 모듈화 시켜 놨습니다. 아주 조금밖에 필요하지 않은데 100%의 인프라스트럭처를 모두 구동해야 한다면 비효율 적이겠죠?

또 다른 기술은 사용될 수 있는 지점의 전력을 다른 곳으로 보낼 수 있도록 전력 및 클링 시스템을 디자인한 것입니다. 고착된 전력은 사용되지 않고 낭비되어 결국 수십억원에 해당되는 비용이 사용되지 못하고 낭비되는 요인이 됩니다. 예를들면, 센터의 한 지점에서 특정양의 전력을 받아이도록 장치가 설치되어 있는데 그 장치가 해당 용량을 사용하지 않는 다면, 바로 이곳에서는 전기를 사용하지 않았지만, 다른 장치에서는 전기가 부족한 일이 벌어질 수 있다는 것입니다.

전기가 필요한 곳에서 사용할 수 있도록 하기 위해 마이크로소프트는 전력 및 쿨링 시스템에 재 설정되어 전력을 공유할 수 있는 유연한 디자인을 채택했습니다. 또 다른 방법은 가장 전기 및 전력 효율적인 곳에 하드웨어를 위치 시키는 것이죠. 때때로, 가장 이상적인 위치에 특정 장치를 위치하는 것이 불가능한 경우가 있지만 가능한 경우라면 물리적인 장벽을 제거하도록 설계되어 있습니다. 마이크로소프트의 비즈니스 유닛은 차지하고 있는 공간, 즉 상면 비용이 아니라 에너지(전기) 및 쿨링 비용을 포함한 운영 비용으로 과금을 합니다.

데이터 센터의 성능을 모니터링 및 제어

효율성을 높이기 위해 성능, 온도, 전력 사용량을 볼 수 있는 모니터링 시스템을 개발할 필요가 있습니다. 데이터센터 전체의 실시간 서버 온도, 쿨링 시스템의 정상 작동여부를 실시간으로 측정하는 것은 아주 중요합니다. 과도한 쿨링시스템 작동은 여러 데이터센터에서 에너지 낭비의 주요 원인입니다. 마이크로소프트는 쿨링 낭비를 줄이기 위해 아주 긴밀한 통제를 유지합니다. 게다가 데이터의 아카이브를 통해 운영 성능을 어떻게 향상 시킬것인지 포괄적인 이해를 할 수 있게 됩니다.

데이터센터 운영 Excellence를 조직 문화의 일부로 만듦

에너지 효율화 노력의 첫걸음은 Awareness(인지도)를 높이는 것이고, 모니터링, 리포팅, 데이터센터 효율화를 분석하는 것 등에 대한 책임감을 해당 팀에 부여하는 것입니다. 마이크로소프트는 데이터센터 지표를 만들어서 웹서비스를 통해 운영에 대한 값을 관련 주체들과 커뮤니케이션 하도록 되어 있습니다. 해당 의사결정권자들에게 보내져 향상 및 변화값등에 대해 공개되지 않게 에너지 효율화 및 데이터센터 성능 정보를 보내고 있습니다.

Power Usage Effectiveness(PUE)를 측정

Power usage effectiveness (PUE)는 데이터센터 효율성을 향상하기 위해 사용되는 마이크로소프트의 지표 입니다. PUE는 외부 온도, 장비 변경, 서버의 부하 등의 값에 따라 지속적으로 변하는 값입니다. 모니터링 및 계측/관리가 없다면 PUE 값 변동에 대한 원인 및 효과를 판단하는 것이 불가능 합니다. PUE는 데이터센터 운영자가 다른 데이터센의 값과 비교하여 에너지 효율화를 위해 취해야 할 필요가 있는 것을 결정하여 빠르게 데이터센터의 효율성을 평가할 수 있도록 해줍니다.

온도 조절 및 공기흐름 분배를 위핸 최고의 기술 사용

온도 조절 및 공기흐름 분배를 향상시키기 위한 기술 목록

AC(교류) units을 뜨거운 통로에 연결하여 뜨거운 공기는뜨거운 통로로 흐르게 함
0.8 ~ 1.0 미터 마루 위에 Uniform Static 공기 압력으로 디자인

뜨거운 공기와 찬 공기가 혼합되는 것 방지

뜨거운 공기와 찬 공기가 혼합되는 것은 비효율적입니다. 이런 비효율을 방지하면 쿨링 비용을 절감할 수 있게 되죠. 뜨거운 공기와 찬 공기의 혼합을 막는 기술로 구현 가능합니다.

뜨거운 공기 및 찬 공기가 흐르는 통로를 각각 만듦

효과적인 절약 장치(Economizer) 사용

데이터센터의 장소 선정에 고려할 또 하나의 요소는 데이터센터를 쿨링, 즉 식히는데 절약 장치를 사용할 수 있는지 여부 입니다. 첫째는 물을 사용하는 방식, 둘째는 외부 공기를 사용하는 방식 입니다. 마이크로소프트는 2가지 방식 모두를 사용하고 있습니다.

산업계의 파트너들과 지식 공유 및 배움

마이크로소프트는 베스트프랙시트에 참여하고, 공유하고 있습니다.

The Green Grid
Climate Savers Computing
Environmental Protection Agency
Lawrence Berkeley National Labs
Society of Heating, Refrigeration, and Air-Conditioning Engineers
Association for Computer Operations Management.

위의 다양한 단체들은 산업계의 업체들이 지식을 공유하도록 촉진하고 있고, 다양한 데이터센터의 전략 및 베스트 프랙티스를 서로 교환하며 정보를 제공하고 있습니다.

에너지 효율적인 데이터센터 라이프 사이클로의 길

마이크로소프트는 산업계의 경험 및 많은 지식을 소유한 많은 분들을 통해 지식을 축적했고 이런 지식을 공유하는 것이 많은 분들에게 시간과 노력을 절감시킬 수 있다고 믿습니다.

마이크로소프트는 컴퓨터 사용자가 소프트웨어의 다양한 활용을 통해 환경을 향상시키기 위해 향상된 교육 및 가이드가 필요하다는 것을 알고 있습니다. 따라서, 정부 기관, 비 정부기관, 산업계 및 소비자등 환경에 직접, 간접으로 영향을 주는 모든 분들에게 베스트 프랙티스를 공유하는 노력을 지속하고 있습니다. 많이 활용하시기 바랍니다.

인터넷 데이터 센터(IDC)의 전원 사용량 및 Green IDC에 대하여

2008-09-05T07:32:46Z

2006년 미국의 전체 데이터센터는 약 610억 Kilowatt-hour (kwh)를 소비했고, 이것은 미국 전체 소비전력의 1.5%에 해당하는 어마어마한 양 입니다.
에너지 비용으로 따지면 4.5조원에 달하고, 미국 전체의 모든 컬러텔레비전이 사용하는 전기보다 많고 인구 5백8십만명이 사용하는 에너지의 양 입니다.
데이터센터 자체의 전력과 Cooling 인프라스트럭처를 위한 양이 50%, IT 장비 (네트웍 및 서버H/W 등)가 50%를 사용하는 것으로 조사되었습니다.
현재와 같은 추세라면 2011년에 1,

Technorati 태그: 마이크로소프트,Microsoft,IDC,데이터센터,그린IDC,그린IT,그린컴퓨팅,신현석

000억 kwh를 넘어서고, 총 에너지 비용이 7.4조에 육박할 것으로 예측되며 이를 위해서 추가로 10개 정도의 발전소가 만들어져야 할 정도 입니다.
Industry Segment로 봤을 때 데이터센터는 가장 빠르게 전력을 소비하고 있습니다.
엄청나죠? 그렇다면 데이터센터는 어떻게 만들어지고 운영되어야 할까요? 그린 컴퓨팅(Green Computing), 그린 IDC가 강조되는 이유이기도 합니다.
그렇다면 전기, 즉 전원 절감이 아주 중요한 이슈가 되는데 이것은 지구 온난화하고도 밀접하게 관련되어 있습니다. 전기를 절감, 그린하우스 Gas 절감, 결국 환경 보존에도 기여하는 논리가 성립되는 것입니다. 따라서, 데이터센터는 전원 사용에 대해 실시간으로 모니터링(온도, 성능, 전원) 하고 있어야 합니다. 서비스의 확산에 따라 인터넷 데이터센터의 중요성은 지금보다 훨씬 더 커질것으로 전망되고, 지금도 많은 IDC가 세워지고 있습니다. 마이크로소프트도 그 중의 하나인데요, 마이크로소프트는 아래의 10가지 원칙을 가지고 데이터센터를 건립하고 있습니다.

1. 비용과 에너지효율

. power distribution, cooling systems, and server rack/container systems

2. 디자인 최적화

. building, land, power equipment, cooling equipment, electricity, water, network, and staff

3. 데이터센터 부분 가동 가능

4. 데이터센터의 성능 모니터링, 컨트롤

. 성능, 온도, 파워 (실시간 모니터링)

5. 조직적으로 운영 Excellence

. 웹서비스를 통해 데이터센터 운영리포트 closed feedback

6. Power usage effectiveness (PUE) 모니터링

. 외부온도, 장비 변경, 서버에 로딩된 서버 수 (중요 Metric, 타 IDC와 비교)

7. 온도 조절 및 공기 흐름에 최고의 기술 적용

8. 뜨거운 공기와 차가운 공기 결합 차단

9. 효과적인 절약장치 사용

. Water-side: 냉각수를 식히기 위해 외부 공기 이용

. Air-side: 외부 차가운 공기를 바로 데이터센터로 진입

10. Industry Partner와 지식 공유 및 Learning

. The Green Grid 외

그린컴퓨팅, 그린IDC 이제부터 시작해야 합니다. 마이크로소프트의 www.microsoft.com/environment 사이트를 통해 어떻게 구현할 것인지에 대한 정보를 공유합니다. 참고하세요.

Hyper-V 가상화를 이용한 개발 및 테스트 서버

2008-09-05T07:26:00Z

그렇지 않나요? 많은 기업에서 위와 같은 일이 발생합니다. 개발 및 테스트 서버에
대한 수요는 많은데 이를 지원하기 위한 프로세스는 없는 경우가 대부분 입니다.
개발 및 테스트 서버를 그렇게 중요하게 생각하지 않기 때문입니다.
그러나, 개발 해본 분들은 알지만 개발 및 테스트 서버 없이 프로젝트를 진행하는 것은
불가능합니다.

가상화 및 VMM(Virtual Machine Manager)를 이용하면, 고객이 요청할 때 실시간으로
Template에서 가상머신을 생성하여 제공해줄 수 있습니다.
물론 승인 절차 및 기업내부가 아닌 고객에게 제공할 때는 품의를 진행해야 겠지만요.
정말 간단하게 고객 및 비즈니스/개발 부서의 만족도를 높이고, IT 부서는 업무 부담을
경감시키고, 심지어 매출까지 발생시킬 수 있다면 이보다 좋은 일이 또 있을까요?

클라우드 컴퓨팅, 델이 Trademark를 소유한 단어?

2008-09-02T04:24:00Z

앞의 글에서 클라우드 컴퓨팅에 대해 설명을 드렸습니다. 조금 이해가 되셨나요?
SaaS, SOA, RIA, Web2.0, 클라우드 컴퓨팅, 이런 IT Trend 중의 중요한 개념을 한 회사가 소유한다? 어떻게 생각하세요. "클라우드 컴퓨팅" 이란 용어가 Dell이 Trademark를 소유할 뻔 한 일이 미국에서 있었네요.

미국 특허청에 요청한 "클라우드 컴퓨팅"에 대한 Trademark 요청이 "Notice of Allowance", 즉 받아들여지기 바로 전단계에서 "Returned to Examination" (조사가 필요함) 단계로 내려간 일이 최근에 있었습니다.
2007년 3월 Dell이 가지고 있는 클라우드 컴퓨팅 솔루션, 서버 및 서비스 등의 기술을 소개하면서 Trademark 신청을 했고 잘 받아들여지고 있었죠.

문제는 2008년이 되면서 클라우드 컴퓨팅이라는 말이 일반적인 고유명사 처럼 시장에서 받아들여지고, 많은 사람들의 관심을 받으면서 이슈가 되기 시작한거죠. 네티즌들이 엄청 흥분한 건 당연한 일이겠죠? 중요한 트렌드로 많이 사용하는 개념을 한 회사가 소유하게 되면 사용할 때 마다 어떤 법적인 분쟁이 일어날 지 두려워해야 될테니 개인적인 입장에서도 맞지 않다고 생각합니다.

어쨌든, 여론의 압력에 의해 "클라우드 컴퓨팅" 이란 용어는 아직은 마음대로 사용할 수 있는 단어가 됐다니 다행스러운 일입니다.

클라우드 컴퓨팅(Cloud Computing) 이란?

2008-08-22T08:11:00Z

현재의 IT 주요 트렌드가 무엇일까요? SOA(Service Oriented Architecture), Web2.0, SaaS(Software as a Service), RIA(Rich Internet Application), 그리고 클라우드 컴퓨팅 (Cloud Computing) 이라고 생각합니다.

한마디로 간단히 정의하면
SOA는 "Reuse & Agility, 재사용과 민첩합"을 목적으로 나온 개념입니다.
Web2.0은 "Network Effect, 네트웍 효과, 소셜 네트웍" 으로 설명할 수 있을 것 같구요,
SaaS는 "Flexbile Pricing & Delivery, 유연한 가격 정책과 서비스의 새로운 Delivery 방식" 이구요,
RIA는 "Experience, 사용자 경험"이 주요 개념입니다.
그렇다면, Cloud Computing은 "Service Utility, 즉 유틸리티, 수도 및 전기와 같은 컴퓨팅"이라고 설명할 수 있을 것입니다.

위와 같은 다른 용어로 시장에서는 설명을 하고 나름대로의 정의를 내리기는 하지만, 사실 SOA, SaaS, Web2.0, RIA, Cloud Computing은 어떻게 보면 다르지 않습니다. 모두 현재까지 나와있는 표준들, 다양한 기술들을 이용하여 조금씩 다른 방식으로 사용하고 있다라고 이야기할 수 있습니다.
마이크로소프트는 이러한 5가지 개념을 소프트웨어 플러스 서비스 라고 하는 Umbrella로 설명하고 있습니다. 어떤 개념을 사용하더라도 결국에는 소프트웨어, 서비스가 공존하는 환경이 펼쳐진다는 것이죠.

모든 기업은 두가지를 고려하게 됩니다. 데이터 및 어플리케이션을 통제하는데 우선순위를 둘 것인지, 아니면 규모의 경제에 우선순위를 둘 것인지를 결정해야 하는 거죠. 이러한 기준에 맞추어 시장에는 현재 4가지의 IT 모델이 존재합니다.

첫째, On-Premise. 하드웨어, 소프트웨어를 모두 관리 및 소유 하는 개념

둘째, Hosting. 호스팅 업체 및 IDC를 통해 내가 개발한 어플리케이션 및 패키지를 내가 지정한 하드웨어에서 구동하고 비용을 지불하는 방식

셋째, SaaS. 다른 누군가가 개발해 놓은 어플리케이션을 사용하고, 나는 하드웨어, 소프트웨어 등의 운영등은 전혀 고민하지 않는 방식. CRM 등의 솔루션이 요즘 많이 이용되고 있죠

넷째, 클라우드컴퓨팅. 어플리케이션이 클라우드 플랫폼에서 구동되는 것, 즉 내가 어플리케이션을 개발할 때 필요한 스토리지, 컴퓨팅 자원을 클라우드 플랫폼 제공자의 것을 사용하는 데, 접속량이 아무리 많아져도 문제없이 서비스 가용성을 보장하는 서비스 방식. (즉, Scalability, 확장성이 보장되는 것이죠) 1,2주 정도 올림픽 프로모션 사이트를 구축하려고 할 때, 대박이 나면 몇 명 정도가 접속할 지 알기 어렵죠. 1만명, 10만명, 100만명에 맞추어 서버 인프라를 구축해야 할지, 아니면 1,000명 수준으로 구축할 지 정말 판단하기 어렵고, 또 2주만 사용하는 사이트 인프라에 많은 비용을 쓰기 어렵겠죠. 한 번 쓰고 나중에 6개월 후에나 다시 쓸지 모르는데 큰 투자가 가능하겠어요? 이럴때 클라우드 컴퓨팅이 아주 적절한 개념이 되겠죠.

즉, On-Premise, Hosting, SaaS, 클라우드 컴퓨팅은 다른 것을 대체하는 개념이 아닌 서로 보완하는 개념으로 IT의 진보와 발맞추어 함께 갈 것이 분명합니다.
그렇다면, 내가 지금은 클라우드컴퓨팅 방식으로 개발해서 비용을 지불했는데, 정책이나 상황이 변해서 On-Premise 방식 또는 Hosting 방식, SaaS 방식으로 바꾸려고 할 때 어느정도 유연하게 바꿀 수 있느냐가 중요한 의사결정 포인트가 될 것인데요, 이와 같은 유연함을 제공할 수 있는 플랫폼을 고민하는 것이 필요한 시점입니다.

SSDS(SQL Server Data Services), 자세히 알아 보기

2008-08-19T08:43:00Z

SQL Server Data Services에 대해서는 앞의 글에 간략히 설명을 드렸기에 개요는 더이상 말하지 않겠습니다. 오늘은 SSDS에 대해 조금 더 자세히 설명해 보겠습니다.

SSDS의 이해

비즈니스 로직 Layer	정의	목적	예
Authority	컨테이너의 집합	계정, 보안등을 위해 컨테이너들을 조직화	"서울", "부산"
Container (컨테이너)	엔티티의 집합	컨텐츠, 쿼리의 목적으로 엔티티 조직화	"판매될 자동차들" "제공된 서비스들"
Entity (엔티티)	단위 데이터	스토리지 단위	"판매될 자동차"로 필드명, 타입, 값으로 구성됨

Authority, Container, Entity의 체계로 데이터를 저장, 관리합니다.

1. 데이터 모델
- 특정한 스키마를 필요로 하지 않고, 유연한 데이터 모델을 지원합니다. 엔티티가 최소의 단위 입니다. 엔티티는 프로퍼티를 통해 실제 데이터 값을 가지고 있습니다. 모든 엔티티는 서비스 메타데이타 프로퍼티와 사용자 지정 프로퍼티를 함께 가지고 있습니다. 고정형 엔티티는 없습니다. 서비스 형태로 사용되어져야 하는 특성 상 엔티티와 엔티티간에의 속성은 독립적으로 서로 영향을 미치지 않습니다. 특정 프로퍼티의 값의 데이터 유형은 엔티티 별로 서로 달라집니다. 프로퍼티의 표준화 및 엔티티간의 프로퍼티 유형은 어플리케이션 개발자에 의해 결정되기 때문입니다. 프로퍼티의 데이터 타입의 종류는 스트링, 바이너리, Boolean, Number, 날짜 등입니다.

2. 데이터 조작
- Authority, 컨테이너, 엔티티에 생성/수정/삭제 등의 데이터 조작이 가능합니다. SSDS는 웹 사이트 인터페이스를 통해 SSDS의 계정 및 authority의 생성 및 삭제 기능을 지원합니다.
. 컨테이너의 생성 및 삭제 조작 가능 (수정 기능은 제공되지 않습니다)
. 엔티티의 생성, 대체 및 삭제 가능
. 직렬화 포맷의 단일 컨테이너의 검색/조회 가능
. 직렬화 포맷의 단일 엔티티 검색/조회 가능

3. Query 언어
    - SSDS는 텍스트기반의 쿼리 언어를 지원하는데, C#을 이용한 LINQ 패턴도 가능합니다. 쿼리 언어는 간단한 필터링 시나리오가 가능하도록 해주는데, 단일 authority나 컨테이너를 아래와 같은 규칙에 의해 조회 가능합니다.
    . 특정 조건을 만족하는 컨테이너 값을 가져오기 위해 authority를 조회할 수 있음
      (이 경우 쿼리의 범위는 쿼리가 적용되는 단일 authority로 한정됨)
    . 특정 조건을 만족하는 엔티티 값을 가져오기 위해 컨테이너를 조회 할 수 있음
      (이 경우 쿼리의 범위는 쿼리가 적용되는 단일 컨테이너로 한정됨)
쿼리는 Boolean(AND, OR, NOT) 및 비교 연산자(<, >, <=, >=, !=, ==)를 사용할 수 있음.
모든 비교는 특정 형태로 이루어 져야 하는데, "프로퍼티 OP(연산자) 상수/파라미터"의 형태여야 함. 예를들면, SELECT e FROM e IN 엔티티 WHERE e["도시"] == "서울";

4. 리소스 기반의 쿼리
- SSDS는 리소스 기반의 쿼리를 지원하는데, 리소스 쿼리는 엔티티, 컨테이너 등의 경로를 경유하여 값을 가져오는 것을 의미합니다. 예를들면, 다음의 REST URI는 특정 컨테이너를 의미하죠.
ChildrensBooksContainer1 beneath the authority:
mydomain.ssds.microsoft.com

만약 http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1 이라는 URI를 입력했다면 해당 컨테이너에 들어있는 모든 엔티티값이 리턴값으로 돌아올 것입니다.

또, 한단계 더 나아가서 http://http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1/SomeBook 이라는 REST URI 를 입력한다면 해당 컨테이너에서 일치하는 SomeBook, 즉 특정 엔티티가 리턴값으로 돌아오게 되는 거죠.

5. 보안
- 보안은 계정, authority, 컨테이너 레벨에 적용됩니다. 계정은 Windows Live ID를 통해 보호되고, 각 authority는 "Secret Key"를 통해 read/write 접근 권한을 부여하며, 컨테이너 역시 "Secret Key"를 통해 read/write 권한을 부여합니다. 선택적으로 컨테이너는 외부에 읽기 권한을 부여하는 것이 가능합니다.

6. API
- SSDS 서비스의 런타임은 웹서비스를 통해 이용 가능한데, 가장 중요한 방식은 RESTful 서비스 입니다. Authrity, 컨테이너, 엔티티는 모두 URI 주소를 통해 접근 가능합니다. 또한, SOAP 기반의 endpoint도 지원되는데, SOAP endpoint는 authority 까지만 지원됩니다.
현재까지는 XML이 주로 사용되는 문서 포맷인데, 이후에 AtomPub 등의 다양한 프로토콜이 추가 지원될 것으로 예정되어 있습니다. Visual C#, Visual Basic 등을 통해 LINQ Qurty 역시 사용 가능합니다.

마이크로소프트 클라우드 컴퓨팅의 시작, SQL Server Data Services (SSDS)

2008-08-19T05:52:00Z

SQL Server Data Services (이하 SSDS)는 개발자들이 데이터베이스가 필요할 때 언제든지, 얼마든지 (크기) 사용할 수 있고, 고가용성 및 보안성을 갖춘 온디맨드 데이터베이스 서비스를 의미합니다. 즉, 전기, 수도처럼 원할 때 사용하고 서비스 비용을 지불하는 형태의 유틸리티 컴퓨팅 이라고 할 수 있죠.

특징은 크기에 제한없이 무한으로 사용할 수 있고 원할 때마다 확장 및 축소 가능하다는 점, 고객이 직접 인프라(서버, DBMS 등), 운영인력을 통한 관리 및 운영비를 감당할 필요가 없다는 점, SOAP과 REST 같은 웹 프로그래밍 인터페이스를 통해 웹 어플리케이션을 빠르게 프로비저닝(실제 쓸수 있게 적용)할 수 있다는 점과 사용이 쉽고 표준 기반의 인터페이스를 이용하여 개발하기 때문에 개발자들의 업무 부담이 줄어든다는 장점이 있습니다.

다음과 같은 고객에게 유용할 것 같은데요,
첫째, 대용량 데이터베이스가 필요한데, 초기에 큰 투자 없이 업무 시스템을 개발하려고 하는 고객
둘째, 데이터 사용량이 많고, 매쉬업 유형의 어플리케이션을 최소의 인프라 투자로 보안, 가용성, 관리용이성이
필요한 개발자 및 파트너사
셋째, 규모가 크거나 공유가 필요한 협업 어플리케이션을 구축하려고 하는 고객

빠른 배포를 위한 어플리케이션 신속한 개발, 온디맨드 확장, 비즈니스에 사용가능한 정도의 SLA(Service Level Agreement) 등의 이점을 강조할 수 있겠네요. 아래 사이트를 통해 무료 베타 서비스가 가능합니다.
http://www.microsoft.com/sql/dataservices/default.mspx

이후에는 SSDS를 이용한 어플리케이션 개발에 대한 글을 적어 보겠습니다.

서버가상화 아키텍처 비교

2008-08-18T14:11:00Z

인프라스트럭처 아키텍트 신현석 입니다. 서버가상화에 대한 시장의 관심은 대단히 뜨거운데요,
각 기술의 아키텍처 측면에서 설명을 해보려고 합니다.
1. VMWare ESX
2. Microsoft Hyper-V
3. Xen

위의 3가지가 바로 삼국지의 주인공 들입니다. 오늘은 그 중 ESX와 Hyper-V에 대해서만 언급하려고 합니다.

그렇다면 어느 회사의 어떤 기술을 사용하는 것이 훨씬 효과적일까요? TCO, Feature 등 다양한 각도에서 이유를
찾아볼 수 있겠지만 저는 순수하게 아키텍처 측면으로 살펴보는 것임을 다시한 번 강조합니다.
주로 2가지의 내용이 주로 많이 언급됩니다.

1. 하이퍼바이저의 아키텍처 구현 방식
- 우리 회사의 방식이 더 선진화된 방식이고, 사이즈가 작고 가볍다

2. 하드웨어 지원 방식 vs 소프트웨어 방식, 내가 더 빠르다

첫번째 내용을 먼저 살펴볼까요?
1. 하이퍼바이저의 아키텍처 구현 방식

1) VMWare ESX

2) 마이크로소프트 Hyper-V

VMWare의 ESX에서는 VMKernel이 핵심적인 역할을 하는데, 하드웨어를 지원하기 위한
Device Driver들과 함께 번들링 되어 있습니다. 약 200,000 라인 정도의 코드로 개발되었고
VMWare Console OS가 바로 그 윗단을 구성하고 있고, VMKernel, http, Virtual Center Service
등을 포함한 관리 업무를 수행하는데, 가상 머신의 업무들을 지원하는 역할을 VMKernel이 대부분 처리합니다.
(약 32M Byte)

마이크로소프트의 Hyper-V(Viridian)은 조금 다르게 만들어졌는데, Console OS의 역할을 Parent Partion이 수행합니다.
하이퍼바이저의 크기가 훨씬 더 작게 만들어져 있고 실제로 약 800K Byte 밖에 되지 않습니다.
VMWare에 비해 훨씬 더 크기가 작기에 오류 코드가 포함될 확률이 작고, 큰 특징중의 하나가 Device Driver가
하이퍼바이저가 아닌 Parent Partition에 올라가 있다는 것입니다.

하드웨어 드라이버에 문제가 생겼을 시 VMWare 아키텍처는 전체 가상화에 문제가 발생하지만 Hyper-V
아키텍처에서는 문제가 있는 드라이버를 사용하는 가상머신에만 문제가 발생하기에 위험요인이 더 적습니다.

두번째 내용을 살펴보겠습니다. 인텔에서는 Intel-VT, AMD V x64 비트 칩을 개발했죠.
마이크로소프트는 바로 이 하드웨어, 즉 칩이 지원하는 가상화 아키텍처를 이용하고 VMWare는 "바이너리 변환",
즉 가상머신이 발생시킨 명령어를 하이퍼바이저가 받아서 재작업을 하여 가상환경에서 잘 구동되도록 변환하는 방식을 사용합니다.
이런 소프트웨어 변환 방식을 사용하면 "가상화환경에서 구동되도록 수정되지 않는 게스트 OS"가 가상머신에서 잘 동작하도록
할 수 있게되기에 실제로 큰 의미가 있습니다. Xen에서도 이런 유사한 형태를 구현하기 위해 Paravirtualization을 구현했습니다.
Paravirtualization은 하이퍼바이저가 표준 게스트 OS의 명령어를 처리하도록 하는 방식이 아니고, 게스트 OS가 가상 환경에서
잘 동작하도록 변경 (Paravirtualized)되는 방식을 의미합니다. 결국 게스트 OS의 커널을 변경할 필요하여 Xen 기반의 하이퍼바이저에서는
Linux 기반의 OS만 동작가능할 수 밖에 없었던 이유이기도 합니다. (즉, 다른 운영체제 커널의 코드에 접근할 수 없었기 때문이죠)
그런데, 앞에 언급한 Intel-VT, AMD-V 칩의 등장으로 큰 변화가 이루어집니다. 이제는 하이퍼바이저가 "가상머신이 발생한 명령어를
소프트웨어적으로 에뮬레이션 하지 않고 최적화" 해주는 역할을 하게 된거죠.

이제는 VMWare는 기존과 동일하게 "바이너리 변환"하는 방식을 취하고 마이크로소프트와 Xen은 하드웨어,
즉 칩이 지원하는 하이퍼바이저 방식을 취하게 된 것입니다. VMWare는 소프트웨어 방식이 빠르다고 주장하고,
마이크로소프트와 Xen은 하드웨어 지원 방식이 빠르다고 주장을 하고 있는 것이죠.
해당 상황에 따라 벤치마크 결과가 조금씩 다르지만, 거의 차이가 없다는 것이 시장의 설득력을 얻고 있습니다.
하지만, 여기서 VMWare는 Intel-VT, AMD V x64비트 칩을 장착한 하드웨어가 없어도 가상화를 구현할 수 있다는 장점을 갖게 되는 것은 분명하죠.

위와 같은 장,단점이 아키텍처 상에 내재하고 있음을 이해할 필요가 있다고 생각합니다.

Microsoft 서버가상화, Hyper-V의 장점

2008-08-14T08:54:00Z

성능 최적화는 여러 부분에서 다루어질 수 있겠지만 운영체제, 드라이버 최적화가 가장 큰 영향을 주게 되는데, 마이크로소프트의 Hyper-V는 바로 이곳에 초점을 맞추어서 개발되었습니다. 또한 64 bit 아키텍처로 Host, Guest 머신에 64 bit 운영체제 설치가 가능하고 Guest(가상)머신에 최대 4개 까지의 CPU를 사용 가능하며, 메모리 역시 Enterprise, Data Center Edition은 64G, Standard는 32G 까지 지원 가능하게 설계가 되어 있습니다. 또한, synthetic IO (즉, 가상 머신이 Input/Output 채널에 이전 같은 에뮬레이션 방식이 아닌, Windows 드라이버에 대해 Native하게 빠르게 접근할 수 있도록 구성된) 방식을 통한 빠른 성능이 가능해 졌습니다.
- Synthetic I/O 구조에서 Hyper-V는 클라이언트 서버 방식의 아키텍처를 사용하는데, Kernel Level에서 Root 영역에서는 Virtual Service Provider의 역할, 클라이언트
영역에서는 Virtual Service Client가 I/O를 주고 받으므로 훨씬 효과적인 I/O가 가능해졌습니다.

또한, Hyper-V는 Bare Metal (즉, 순수 하드웨어 장비) 위에서 구동이 되는데 최적의 속도와 확장성을 가지는 아주 가벼운 소프트웨어 Layer로 이루어져 있습니다. 실제 크기가 800K 바이트 밖에 되지 않죠. 경쟁사 제품이 32M 바이트인 것에 비하면 훨씬 가볍고, 또한 Windows Server 2008 Server Core 버전에서 구동될 경우 훨씬 더 적은 자원을 사용하며 운영될 수 있습니다. (Server Core 버전은 그래픽 인터페이스를 사용하지 않는 커맨드라인으로 제어가 가능한 아주 가벼운 운영체제 입니다)

MSSQL Server 2005를 Hyper-V 기반 가상머신(VM)에서 구동하기

2008-08-12T11:27:00Z

Hyper-V 기반 가상머신에서의 MSSQL 2005 정상 구동 여부는 아직 테스트가 완료 되지는 않았지만,

SQL Server 2005를 가상머신에 구동할 수는 있습니다.

만약, 문제가 발생할 경우 경우 MSSQL Server 2005의 코드 수정이 필요하지 않는 정도는 Microsoft의 CSS 서비스를 받으실 수 있습니다.

가상머신으로 구동하는 동안 문제가 발생하면 일단은 CSS를 통해 문제 해결을 시도하고, 가상머신이 아닌 물리적 서버로 이전해 본 후
동일한 문제가 발생하는지 여부를 확인하여, 가상머신과 물리적 서버 환경에서 똑같은 오류가 발생하면 SQL Server 프로덕트 그룹에

이슈를 제기하여 버그를 해결할 수 있습니다.

지속적으로 MSSQL Server 2005가 가상머신에서 구동될 수 있도록 테스트가 진행중이고,

향후 완전히 지원될 SQL 버전은 아래와 같습니다. 최종 테스트가 완료되면 다시 글을 올리도록 하겠습니다.

-	Microsoft SQL Server 2005 Workgroup Edition
-	Microsoft SQL Server 2005 Standard Edition
-	Microsoft SQL Server 2005 Developer Edition
-	Microsoft SQL Server 2005 Enterprise Edition

참고하세요.

David Chappell 세미나 이후 사진 한장, 좋네요

2008-08-11T05:09:00Z

David Chappell, 평소에 꼭 만나보고 싶었던 분 입니다. 강연 및 글을 통해 전세계의 IT Pro를 대상으로 IT, 아키텍처에 대한 이해를 돕는 역할을 하고 있죠. 대형 IT 세미나의 키노트를 전담하듯 담당하고 있기도 합니다. 그분의 강연을 듣고 있자면 빨려 들어가는 느낌이 들어요, 청중의 집중을 유도하며 자연스럽에 이끌어 가는 기술의 비밀이 궁금했는데, "Giving Technical Presentation" 이라는 주제를 통해 나름대로 그 비법을 깨달았습니다.

가장 중요한 비밀은 청중에 대한 이해였습니다. 모든 PT는 청중이 있고, 그 청중의 규모, 해당 주제에 대한 이해도를 사전에 파악하고 준비하는 것이 성공, 실패의 가장 중요한 요인이라는 것이죠. 제 영문 이름이 David 인데, 저와 같은 이름이라 더 좋네요. 함께 찍은 사진 첨부합니다.

Windows에서 PHP를 구동하기 위한 FastCgi 베스트 프랙티스

2008-08-05T16:06:00Z

몇 가지 고려사항이 있습니다.

첫째, PHP 웹사이트의 보안을 위해 다른 사이트와 격리 시켜야 합니다.
. 웹사이트 마다 어플리케이션 풀을 각자 할당
. 어플리케이션 풀 아이덴티티에 사용자 계정 사용
. 어플리케이션 풀 아이덴티티를 사용하기 위해 Anonymous 사용자 설정
. FastCGI의 impersonation 설정 확인 (fastcgi.impersonate = 1)

둘째, PHP 프로세스를 재활용 하세요 .
네이티브 PHP 리사이클링이 시작되기 전에, php-cgi.exe가 항상 리사이클 되도록 하는 것이 좋습니다. FastCGI의 프로세스 리사이클링은 instanceMaxRequests라는 파라미터에 의해 결정됩니다. 리사이클 되기 전에 몇개의 FastCGI 프로세스를 처리할 것인지를 설정하는 역할을 하죠. 이 파라미터 이외에도 PHP 자체적으로 프로세스 리사이클링을 담당하는 파라미터가 있는데, PHP_FCGI_MAX_REQUESTS가 바로 그거죠. instanceMaxRequest 값을 PHP_FCGI_MAX_REQUESTS 값보다 작거나 같게 하면 PHP의 네이티브 리사이클링은 절대 발생하지 않겠죠? 아래와 같이 설정하면 됩니다.
C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000

C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /+[fullPath='c:\{php_folder}\php-cgi.exe'].environmentVariables.[name=’PHP_FCGI_MAX_REQUESTS’, value='10000']
※ 미리 값을 설정하지 않으면 기본 설정값은 instanceMaxRequest=200, PHP_FCGI_MAX_REQUESTS=500 으로 할당됩니다.

셋째, PHP의 버전
. PHP 어플리케이션은 주로 특정 버전의 PHP의 기능 및 특징을 이용하여 개발되죠. 웹호스팅 환경에서, 또는 기업에서 사용하는 PHP 어플리케이션이 다양한 버전의 PHP를 사용한다면, 한대의 서버에서 여러개의 PHP를 지원하는 것은 필수겠지요. IIS7의 FastCGI 핸들러는 여러 버전의 PHP를 지원합니다. PHP4.4.8, PHP5.2.1, PHP5.2.5 non thread-safe 버전이 모두 필요하다면 PHP컴파일러를 파일 시스템에 각각 다운 받아야 합니다. (c:\php4.4.8, c:\php5.2.1, c:\php525nts)를 설치한 후 각 버전의 어플리케이션 풀을 생성합니다.
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php448\php.exe']
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php521\php-cgi.exe']
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php525nts\php-cgi.exe'] site1, site2, site3의 3개의 웹사이트가 있고 각 사이트가 별도의 버전 PHP를 사용한다면 아래와 같이 설정할 수 있을 겁니다.
C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]

넷째, PHP 보안강화를 위한 추천 항목

Disable remote URL's for file handling functions:
. Set allow_url_fopen=Off
. Set allow_url_include=Off
Disable register_globals:
. register_globals=Off
Restrict where PHP can read and write on a file system, e.g.:
. open_basedir="c:\inetpub\"
sable safe mode:
. safe_mode=Off
. safe_mode_gid=Off
Limit script execution time:
. max_execution_time=30
. max_input_time=60
Limit memory usage and file sizes:
. memory_limit=16M
. upload_max_filesize=2M
. post_max_size=8M
. max_input_nesting_levels=64
Configure error messages and logging:
. display_errors=Off
. log_errors=On
. error_log="C:\path\of\your\choice"
Hide presence of PHP:
. expose_php=Off

감사합니다.