디지털 Transformation, 데이터센터 & Cloud, 베트남

드디어 Windows Server 2008의 가상화 기술인 Hyper-V가 RTM되었습니다. (한국: 6월 27일)

 - 신규 고객 및 파트너: www.microsoft.com/Hyper-V 에서 다운로드 가능
 - 기존 사용고객: Windows Update를 통해 7월 8일부터 다운로드 가능

감사합니다.

IIS는 CGI(Common Gateway Interface)를 지원했죠. CGI는 IIS가 외부 어플리케이션과 의사소통할 수 있는 표준 기반의 프로토콜입니다. ISAPI도 비슷하게 사용될 수 있죠. 그러나 이 두가지 방식은 약간의 제약이 있었고 이를 해결하기 위해 FastCGI 라는 모듈이 개발되었습니다. 조금 자세하게 살펴보기로 하죠.

CGI

CGI는 IIS가 외부 어플리케이션과 인터페이스하기 위한 프로토콜 입니다. 그런데, HTTP는 stateless(상태를 가지고 있지 않음)이기 때문에 HTTP를 통해 들어오는 요청을 처리하기 위해 운영체제에서 새로운 프로세스를 구동하여 외부 어플리케이션의 인스턴스를 만들어야 합니다.
바로 이 프로세스 내부에는 stdin(스탠다드 입력)이 클라이언트의 요청 데이터를 받고, stdout(스탠다드 출력)은 해당 응답 데이터를 클라이언트로 내보내며 커맨드라인과 운영체제의 환경 변수들이 다른 서버 및 요청들을 CGI 프로세스에 보내기 위해 사용됩니다. IIS에서 CGI를 사용할 때의 단점은 윈도우 운영체제가 프로세스를 만들 때 비교적 자원 소모량이 크다는 것이죠. 모든 HTTP 요청이 새로운 프로세스를 띄우고 CGI 어플리케이션 내부에서 해당 작업을 수행하고, 작업 완료 후 프로세스를 종료하게 됩니다. 따라서, 웹에서의 응답속도가 느려질 수 밖에 없습니다. 쉽게 풀이하면 10개의 요청에 10개의 프로세스가 생성, 종료된다는 것이지요.

ISAPI

PHP를 IIS에서 구동될 수 있도록 하기 위해 다양한 시도가 이루어졌고, 그 중 나름대로 성공한 모델이 바로 ISAPI 입니다. ISAPI(Internet Server Application Programming Interface)는 CGI와는 다르게 웹서버 프로세스 내부에서 작업이 이루어집니다. 클라이언트의 요청이 있을 때 새로운 프로세스가 생성되지 않고, 웹서버 프로세스에 로딩된 DLL의 초입 포인트를 Call 하는 방식으로 이루어집니다. 만약, ISAPI 어플리케이션이 운영체제가 Thread를 어떻게 처리하는지를 고려하여 만들어져 있다면 성능이 놀라울 정도로 뛰어납니다. 수년동안 PHP는 CGI와 ISAPI 방식을 통해 구동이 되고 있지만, 두가지 방식은 단점이 있습니다.
앞에서 말했듯 CGI 방식은 속도가 느리고 ISAPI 방식은 Thread 이슈가 있습니다. 예를들면 PHP가 ISAPI 방식으로 구동될 때 웹서버 프로세스 내에서 멀티 Thread 환경에서 처리가 됩니다. PHP가 Thread-safe 방식으로 구현되었지만, 많은 인기있는 PHP 어플리케이션들은 non Thread-safe 방식으로 이루어져 있습니다. 만약 ISAPI 방식의 PHP 환경에서 non Thread-safe 방식으로 개발된 어플리케이션을 구동하면, 서버가 불안정해지는 위험이 있습니다.

FastCGI

FastCGI는 성능과 안정성 모두를 보장합니다. FastCGI 방식을 사용하면 프로세스가 해당 요청을 완료한 이후에도 종료되지 않고 그대로 살아서 다른 요청을 처리합니다. 기존 CGI 방식의 단점인 프로세스 생성 및 종료할 때의 응답 속도 지연이 사라지는 것이죠.

CGI 방식과 FastCGI 방식의 기술적인 차이는 FastCGI는 stdin, stdout과 CGI 사용하던 자원들에 매핑하는 작업을 수행하는 Layer가 존재한다는 것입니다. 현재 사용되고 있는 CGI 소스코드들은 아주 적은 수정만으로도 FastCGI에서 사용될 수 있습니다. 웹서버가 여러개의 동시 요청을 처리하기 때문에 가용한 프로세스 풀을 가져야 하고, 들어오는 요청들을 처리할 준비를 하고 있어야 합니다. FastCGI 처리기에서는 이 프로세스 풀을 application이라고 부릅니다. (일명 "프로세스 풀") 프로세스 풀의 프로세스의 갯수, 하나의 프로세스가 처리할 요청의 수 등을 설정할 수 있습니다.
FastCGI 처리기는 여러개의 프로세스 풀을 지원합니다. 하나의 웹서버에서 여러 종류의 FastCGI를 구동할 수 있기 때문이지요. PHP와 Ruby를 동시에 지원하기 원할 경우가 해당 될 것입니다.

PHP

PHP에 관해 몇 가지 설명을 해보겠습니다. PHP는 두가지 버전이 있죠, Thred-safe와 non Thread-safe가 바로 그것입니다. Thread-safe 버전은 thread 들이 서로 경쟁하지 않도록 하는 작업이 이루어지므로 반응속도가 느린 반면, non Thread-safe 버전은 응답속도가 빠른 것이 특징입니다. non Thread-safe PHP를 사용하는 경우 php5ts.dll을 디렉토리에서 보실 수 있고, Thread-safe PHP를 사용하신다면 php5.dll을 찾으실 수 있을 겁니다. Apache의 mod_php 또는 IIS 웹서버로 ISAPI를 사용하시려면 thread-safe PHP 버전을 사용하셔야 합니다.

IIS 웹서버에서 PHP를 사용하시려면 non Thread-safe 방식을 사용하시는 것이 가장 최적의 성능을 제공합니다. www.php.net/download 사이트에 가셔서 PHP5.2.X 버전의 non-Thread safe 바이너리를 다운받으셔서 사용하시면 최적의 환경에서 PHP를 구동하실 수 있습니다.

이전 글을 보시면 FastCGI 설정에 대해 확인하실 수 있지만, 몇 가지 추가된 내용을 포함하여 다시 글을 써보도록 하겠습니다.

SoftGrid (소프트그리드) Application 가상화라고 알려져왔던 바로 그 솔루션이 새로운 이름을 갖게 되었습니다. 바로 마이크로소프트 어플리케이션 가상화 4.5죠. 지금까지 소프트웨어의 단점이라고 여겨져왔던 로컬컴퓨터에 설치를 함으로 해당 어플리케이션이 레지스트리, DLL 등과 밀접하게 연결되어 있었습니다. 버전이 올라가면 업그레이드 해야하고, 보안 패치해야 하고. 또 동일회사의 제품을 2개 동시에 설치하는 것도 불가능했죠. 예를들면, 오피스 2003을 사용하고 있는데 오피스 2007 시스템을 설치하려면 DLL 등의 충돌로 인해 이전 버전을 삭제하고 설치해야 되었던 불편함이 있었죠.

어플리케이션 가상화의 장점 입니다.
첫째, 컴퓨터에 네트웍을 연결하면 가상화된 어플리케이션을 직접 설치된 것처럼 바로 쓸 수 있습니다.
둘째, 라이선스를 획득한 노트북, 데스크탑등 어느 장치에서든 어플리케이션을 쓸 수 있고, 또한 오프라인 상태에서도 이용할 수 있습니다.
셋째, 어플리케이션 관리가 중앙에서 이루어지기 때문에, 사용자가 권한을 가진 어플리케이션만 사용하도록 할 수 있습니다.
넷째, 호환성 테스트, 일반 사용자들의 관리 비용이 거의 발생하지 않습니다. 어플리케이션 관련된 문제들을 처리하는 전화, 요청을 획기적으로 줄일 수 있고 장애시 복구하는 능력이 빨라져 기존 다운타임의 80% 정도를 절감할 수 있습니다.



어떤 메커니즘 인지 간단히 설명드리겠습니다. 최종 사용자 입장에서 설명을 해보죠.
Application Virtualization for Desktop의 경우 데스크탑 사용자가 오피스를 사용하려고 한다면 오피스가 데스크탑에 설치되는 것이 아니고, Virtualization Application Server(VAS)에 설치가 됩니다. 데스크탑 사용자가 엑셀을 사용하려고 해당 아이콘을 클릭하면 그때 VAS에서 해당 어플리케이션이 전송이 되는 것이지요. 사용자에게 화면이 보이는데 이건 SoftGrid에서 보여주는 가상의 화면이고, 이 화면과 데스크탑의 운영체제 사이에 SystemGuard라고 하는 Layer가 존재하게 됩니다. 바로 이 Layer에 해당 어플리케이션을 구동하는데 필요한 DLL, 패키지 정보들이 로딩되어 정상적으로 로컬 컴퓨터에 어플리케이션이 설치된 것처럼 동작하도록 도와주게 되는 것입니다.

사용을 종료하면 해당 어플리케이션 사용에 대한 기본적인 내용이 데스크탑의 캐시에 위치하게 됩니다. 향후 사용시 더 빠르게 동작하도록 하기 위해서지만, 이것 역시 설치 등의 개념과는 전혀 다르지요.
바로 이것이 동작원리 입니다.

그렇다면 모든 윈도우 어플리케이션은 어플리케이션 가상화 형태로 사용될 수 있을까요? 정답은 대부분은 가능하다 입니다. 위의 그림에서 보면 Sequencer라고 보이시죠? 바로 이 Sequencer가 윈도우 어플리케이션이 사용자와 SystemGuard, 운영체제와의 커뮤니케이션 프로세스를 저장하여 VAS로 보내주어 향후 사용자의 요청에 정상적으로 동작하도록 도와주는 프로그램 입니다.

또하나 가능한 사용법이 Terminal Server와 연계하는 방법입니다. 터미널서버에 해당 어플리케이션을 설치해놓고 클라이언트에서는 그냥 프리젠테이션 가상화를 이용하여 사용하는 것이지요. 위의 데스크탑을 활용한 시나리오에서는 로컬컴퓨터의 파워를 그대로 이용하여 소프트웨어를 설치하여 사용하는 것과 동일한 효과를 볼 수 있는 반면 터미널서버와 연계하면 서버의 자원을 사용하게 되는 것입니다. 일반적인 서비스의 장점 및 단점을 그대로 갖게 되겠죠.

많은 IT 관리자 분들로부터 자주 듣는 이야기 입니다.

1. 새로운 플랫폼의 기능이 마음에 드는데, 업그레이드가 귀찮고 스킬도 없다
2. 플랫폼을 운영할 IT 인력을 유지하기가 힘들고, 아까운 인재를 전략적인 프로젝트에 투입하고 싶다.
3. 비용 절감을 떠나 IT 비용을 예측 가능했으면 좋겠다
4. 보안, 안정성 보장에 충분한 투자를 하기 어렵다
5. 임직원 생산성 향상을 위한 솔루션을 보유하지 못했고, 도입에 시간을 투자하기도 어렵다

이럴때 적합한 해답이 바로 서비스 아닐까요? 일반적인 소비자의 경우에는 SaaS 기반의 서비스를 쓰면 되겠지만 엔터프라이즈 고객 및 보안성이 보장된 서비스를 원하는 고객의 경우는 고민되실 겁니다.

마이크로소프트 온라인 서비스를 소개합니다.

e-Week를 종종 보곤 합니다. 오늘 Cameron Sturdevant에 의해 Windows Server 2008, Hyper-V에 가상 머신을 추가하는 Lab 테스트 결과가 올라왔네요. 한 번 Summary 해보겠습니다.

2008년 5월 20일자로 RC1(Release Candadate 1)이 배포되었죠. Windows 2000 Server Service Pack 4, x86/x64 버전의 SUSE Linux Enterprise 10 SP1의 지원이 추가되었습니다. Red Hat Enterprise Linux 5 역시 향후 업데이트 때 반영될 것 입니다. Lab 테스트 때 Windows 2000, SUSE Linux 등의 설치 및 정상 작동 여부 및 새로운 기능 리뷰가 이루어졌습니다. Host 머신은 HP ProLiant ML 115, Intel 칩을 사용하고 있습니다.


보시는 것처럼, 단계가 아주 간단하죠. 메모리 설정, 네트웍 카드 지정, VHD(Virtual Hard Disk) 지정하면 끝입니다.


Windows 2000 서버가 잘 돌아가네요. 에뮬레이션 모드에서 동작합니다.


SUSE Linux 역시 잘 돌아가죠?

상호운영성의 시대, 플랫폼간의 호환이 정말 현실로 다가왔습니다.