Windows Azure에서 리눅스를 게스트 OS로 2012년 중에 지원을 추가할 예정입니다.
Microsoft 전문 테크니컬 칼럼니스트인 Mary-Jo Foley의 기사에 따르면, Microsoft가 2012년 중에 리눅스를 실행할 수 있도록 Windows Azure 서비스를 업데이트할 예정이라고 합니다. 워낙에 특이하고 걸출한 토픽인지라 이 기사 자체가 잘못된 것이 아니냐는 반문을 살 정도로 뜨거운 이슈인 것 같습니다. :-)
현재 나와있는 Web Role, Worker Role은 Visual Studio를 이용하여 개발자가 Application Instance를 패키징해서 Windows Azure에 배포할 때 이것을 VM으로 변환하여 Windows Server 2008이나 Windows Server 2008 R2에서 실행할 수 있도록 바꾸고 있고, 작년에 나온 VM Role은 여기서 좀 더 나아가서 VHD 안에 Windows Server 2008 R2를 설치하고 VHD 단위로 VM을 만들 수 있도록 하는 기능을 내놓았습니다. 그러나 지금까지 나온 것은 모두 한 가지 기술적 특징이 있는데, 실행 중인 VM이 예고 없이 자동으로 재시작되거나 초기화될 수 있다는 점입니다. 그래서 Windows Azure 기반으로 서비스를 개발할 때에는 VM 안에 상태를 보관하는 방식 대신 Stateless/Remote Storage를 활용하는 전략을 택해야 했었습니다.
하지만 Linux VM에 대한 지원과 더불어 장기 실행 VM이 Windows Server에 대해서도 같이 제공되어 Amazon Web Service의 Elastic Cloud Computing 서비스와 같은 형태의 VM Hosting을 Windows Azure에서도 사용할 수 있을 것으로 보입니다. 현재 예상되는 리눅스 배포판으로는 CentOS, RHEL, Suse Linux 등 기존의 Hyper-V 스택에서 원활하게 구동 가능한 상용 리눅스 배포판 대부분이 여기에 포함될 것으로 보입니다.
지금 소개하는 기능은 CTP 버전으로 올해 봄 (2012년 봄) 시즌에 새로 런칭될 것으로 보입니다. 그리고 이 외에도 SharePoint 서버와 SQL Server를 탑재한 가상 머신 이미지의 배포도 같이 지원함으로서 SQL Azure 특유의 기술적 한계를 보완하고 Private Domain에서 사용 가능한 SQL Server를 Windows Azure에서도 이용할 수 있을 것으로 보입니다.
이번 Windows Azure SDK v1.3에서 가장 많이 좋아진 부분이 있다고 한다면 역시 StartupTask에 관한 것과 관리자 모드의 허용입니다. 이전 v1.2까지만 하더라도 네이티브 코드는 허용하면서도 관리자 권한을 허용하지 않았기 때문에 클라우드 컴퓨팅에서 원하는 소프트웨어나 컴포넌트를 자유롭게 사용할 수 없다는 큰 문제가 있었습니다만 이러한 제약이 사라진 것이지요. 아래의 XML 구문을 살펴보도록 하겠습니다.
위의 XML 구문은 클라우드 서비스 정의 파일 (CSDEF)의 내용 중 일부를 발췌한 것입니다. commandLine에 들어가는 것이 시작 과정에서 호출할 외부 응용프로그램 파일의 이름에 관한 것이고, executionContext는 권한 상승 필요 여부에 관한 것이며, taskType은 작업을 처리할 방법에 관한 설정입니다.
commandLine 속성: Worker Role의 경우 프로젝트 출력 디렉터리와 경로가 같습니다. 그러나 Web Role의 경우 프로젝트 출력 디렉터리 아래의 Bin 디렉터리를 기준으로 파일을 찾게 됩니다. Web Role의 경우 이러한 동작은 ASP.NET 응용프로그램의 보안 상 이슈와 맞물리는 것으로, Bin 디렉터리 아래의 파일 내용은 ASP.NET 차원에서 보호되고 외부로부터의 요청이 거부된다는 특성을 이용하는 것임을 숙지하시면 편리합니다.
executionContext 속성: 이 속성이 이번 SDK 업데이트에 있어서 백미라고 하는 관리자 모드에 관한 것입니다. limited로 설정하면 기존의 RoleEntry 클래스에서 사용했던 것과 마찬가지의 제한된 동작을 수행하게 되는 것이고, elevated로 설정하면 관리자 권한 위임을 받아서 동작하는 것입니다. 소프트웨어를 설치하거나, 응용프로그램 디렉터리에 추가적인 파일 액세스가 필요한 경우 elevated 속성을 지정하여 작업을 수행할 수 있습니다.
taskType 속성: 이 속성은 실행하려는 작업의 구체적인 형태를 정의하는 것입니다. 기본적으로 이 속성은 지정하지 않을 경우 자동으로 simple 값을 사용하는데, 이것은 해당 작업에 관련된 프로세스의 실행이 끝날 때까지 Agent의 실행을 중단한다는 의미입니다. 대부분 Task Type으로 지정하는 작업들은 사전 요구 사항 (Prerequisites)을 만족시키기 위한 활동들이기 때문에 이 설정이 기본값이 됩니다. 그 외에 foreground와 background는 해당 작업에 관련된 프로세스의 실행 완료 여부와는 관계없이 작업을 진행하는 것이지만, foreground는 우리가 잘 아는 대로 %comspec% 환경 변수와 연결된 명령줄 인터프리터를 Foreground Application으로 실행하고, background는 데스크 탑 윈도에 드러나지 않게 Background Application으로 실행하는 것입니다. 실제 클라우드 환경에서 foreground나 background는 큰 차이가 없습니다.
간혹 taskType을 Simple Mode와 Foreground를 놓고 잘못 이해할 수 있는데 결과가 상당히 다릅니다. 예를 들어, Simple Mode를 이용하여 어떤 파일의 압축을 풀려고 시도하면 Simple Mode는 압축이 모두 풀릴 때까지 대기 상태에 있으므로 진입점 DLL에서 압축이 풀린 디렉터리로의 접근이 완전하게 의미를 가지지만, Foreground의 경우 (Background 역시 마찬가지입니다) 한창 압축이 풀리는 시점에서 진입점 DLL의 액세스가 발생하므로 어떤 때에는 찾는 파일이 있을 수도 있고 또 어떤 때에는 찾는 파일이 없을 수도 있는 이상한 현상이 발생합니다. 이러한 문제에 빠지게 되면 설정을 다시 검토해 보기 전까지는 문제 진단이 쉽지 않을 수 있으므로 주의해야 겠습니다.
최근 열린 Professional Developer Conference 2010 (이하 PDC 2010)에서, Windows Azure Platform의 실행 환경을 담당하는 Windows Azure Compute에 획기적인 기능이 추가되었습니다. 바로 VM Role의 추가인데, 여기에는 상당히 시사하는 점이 많습니다. VM Role은 이전 글 "[Software Development/Windows Azure] - PDC 2010에서 공개된 Windows Azure 업데이트"의 내용에서 소개했던 것 처럼 Windows Server 2008 R2 기반의 서버 컴퓨터를 Physical Machine to Virtual Machine (이하 P2V) 기술을 통해 Windows Azure에서 실행 가능한 Cloud Computing Appliance로 변환할 수 있습니다.
이 덕분에 좀 더 많은 종류의 서버 응용프로그램이 Windows Azure Platform의 수혜를 얻을 수 있게 됩니다. 이 중에는 기존의 전통적인 Microsoft Back Office Server들에 대한 것은 물론이거니와, 이전에 우리에게 Service For Unix라는 이름으로 잘 알려진 Microsoft의 Unix 호환성 도구인 SFU 및 SUA의 이점을 충분히 활용할 수 있게 될 것입니다. 즉, 기존에 FreeBSD, NetBSD, Linux, POSIX용 응용프로그램을 성공적으로 Windows Server 기반의 응용프로그램으로 마이그레이션할 수 있었다면, 약간의 수정을 통하여 성공적으로 Public Cloud Computing을 위한 응용프로그램으로도 출사표를 낼 수 있음을 뜻합니다.
SFU 및 SUA가 혹시 낯설다면, Cygwin 프로젝트를 참조하셔도 좋습니다. 그리고, 당연한 이야기이지만 Cygwin 프로젝트 기반의 유닉스 응용프로그램에게도 같은 혜택이 제공될 수 있습니다.
아래는 SUA 설치 과정 및 SUA에 대한 설명 동영상입니다. SUA Community 웹 사이트 http://www.suacommunity.com/ 에 방문하시면, SUA 위에 추가 설치 가능한 주요 유틸리티 패키지들을 더 추가하실 수 있으므로 요즈음 널리 사용되는 유닉스 기반 인기 유틸리티들을 Windows에서도 사용하실 수 있습니다. 아래 동영상은 SUA Community에서 제작한 동영상이며 저작권은 해당 원 저작자에게 있음을 밝힙니다.
Jetty (http://jetty.codehaus.org/) 프로젝트는 자바 기반의 오픈 소스 웹 서버로, HTTP 서버로서의 역할과 서블릿 컨테이너의 기능을 제공합니다. 정적, 동적 컨텐츠를 모두 지원하고, 독립적으로 실행할 수도 있고, 다른 프로세스에 부착되어 실행되는 기능 또한 제공됩니다. 이러한 특성을 바탕으로, Apache Project의 ActiveMQ, Cocoon, Hadoop, Maven Project, BEA Web Logic Event Server, Eucalyptus, FioranoMQ Java Messaging Server, Google AppEngine 및 안드로이드, Eclipse용 웹 툴킷 플러그인, 레드햇 J보스, Sonic MQ, 스프링 프레임워크, 사이베이스 EA서버, 짐브라 데스크톱 등 광범위하게 Jetty가 채택되고 있습니다.
Jetty 프로젝트는 아래와 같은 기능들을 제공합니다.
비동기 HTTP 서버
표준 지향의 서블릿 컨테이너
웹 소켓 서버
비동기 HTTP 클라이언트
OSGi, JNDI, JMX, JASPI, AJP 지원
응용프로그램 컨테이너의 관점에서 보면, Jetty는 전통적인 Java 기반의 Web Application Server들 (Tomcat과 같은)을 대치하는 배포 방법으로 사용될 수 있으며, 스프링 프레임워크 및 관련된 모든 파생 프로젝트들, EJB 컨테이너 등 대부분의 일반적인 웹 기반 자바 어플리케이션을 손쉽게 제공할 수 있는 것이 특징입니다.
그러나 위에서 언급하는 Tomcat만이 Windows Azure 환경에서 사용할 수 있는 유일한 Web Application Server의 종류는 아닙니다. 사실, 위의 접근 방법들은 모두 Windows Azure Role에 함께 첨부되어 배포되는 Java 실행 환경 (JRE)를 기초로 하는 것이고, 그러므로 어떤 종류의 Java 패키지이든 관계없이 명령줄을 통하여 Classpath를 명시하는 방식으로 실행될 수 있습니다. 대개의 경우, 작업자 역할 (Worker Role) 패키지 위에서 실행되도록 디자인되고, Windows Azure 환경으로 배포될 수 있습니다. 그리고, 당연한 이야기이지만 Java와 Fast CGI를 결합하고, IIS 7.x를 기반으로 Fast CGI를 지원하는 Web Role을 이용할 수도 있습니다. 이 부분은 나중에 좀 더 자세히 소개하도록 하겠습니다.
Windows Azure 환경에서 Jetty 실행
아래는 실제 Windows Azure 환경에서 Jetty를 기반으로 실행하는 Windows Azure Worker Role의 구동 예시입니다.
위와 같이 구현하기 위한 방법을 지금부터 차례대로 따라해보기로 하겠습니다.
1. Windows Azure Worker Role 프로젝트를 만들고, Worker Role 진입점 메서드인 Run 메서드의 중심부에 다음과 같이 프로그래밍합니다.
제가 이전에 게시한 글 "[Software Development/Windows Azure] - Windows Azure 들여다보기"에서 언급한 내용들을 참조하여 위의 코드를 보시면 이해하기 쉽습니다. 몇 가지 Windows Azure 환경에서 기본으로 제공되는 환경 변수, 디렉터리 설정 등을 바탕으로 Jetty 프로세스를 Java VM (java.exe)를 통하여 실행하도록 명령어를 구성하고 실행한 다음, 표준 출력의 내용을 Windows Azure Worker Role Process로 가져오도록 만드는 것을 볼 수 있습니다.
2. Jetty 프로젝트와 Java VM의 최신 버전을 Windows Azure Worker Role 프로젝트에 추가합니다.
다음 그림과 같이 폴더를 구성하면 되겠습니다. jetty7 폴더와 jre6 폴더 아래에 직접 해당 프레임워크 및 시스템의 실제 디렉터리 구조가 오도록 맞추면 문제 없습니다. 참고로, 확실하게 동작할 수 있도록 만들기 위하여 Java VM의 경우는 특별히 Windows Platform을 기반으로하는 x64 아키텍처 버전을 다운로드하여 아래 그림과 같이 넣어두어야 합니다. (중요)
3. ServiceDefinition.csdef 파일 수정하기
1단계에서 사용한 HttpIn이라는 설정을 Worker Role에 추가해야 하므로, ServiceDefinition.csdef 파일을 찾아 "WorkerRole" 요소 아래에 다음과 같이 내용을 추가하고 저장합니다. 참고로 이 설정은 Windows Azure Worker Role이 80번 TCP 포트 통신이 필요함을 Windows Azure 환경 내의 방화벽에게 통지하기 위한 목적으로 사용됩니다.
Jetty가 사용되거나 환경 설정을 만드는 방법은 Windows Azure 환경에서 여러 가지가 있을 수 있지만, 특별히 이와 같이 Worker Role 위에서 Standalone Server로 동작하기 위하여 필요한 환경 설정이 있어서 이를 소개합니다. Windows Azure 환경에서는 Jetty가 기본으로 사용하는 NIO ChannelConnector 대신 BIO SocketConnector를 사용하도록 구성해야 합니다. NIO ChannelConnector에서는 내부적으로 루프백 연결을 기초로 하지만 Windows Azure 환경에서는 이것이 가로막혀있기 때문이라는 것이 David Chou의 설명입니다.
이러한 설정을 수정하기 위해서는 Jetty 패키지 디렉터리 아래의 etc 디렉터리의 jetty.xml 파일을 수정해야 하며, <New> 태그의 class attribute를 org.eclipse.jetty.server.nio.SelectChannelConnector 대신 org.eclipse.jetty.server.bio.SocketConnector로 변경하고, NIO ChannelConnector에만 한정되는 몇 가지 옵션을 제거하는 방법으로 변경이 가능하며 정리하면 다음과 같습니다.
그리고 좀 더 최적화된 설정을 위하여, Jetty가 자체 로그를 기록하지 않도록, etc 디렉터리의 jetty.xml 파일에서 RequestLog 핸들러 부분을 주석으로 처리하고, 확장자가 war인 패키지의 압축을 풀지 않도록 etc 디렉터리의 jetty.xml 파일에서 addBean "org.eclipse.jetty.deploy.WebAppDeployer"의 "extract" 프로퍼티의 값을 "false"로 지정하고, contexts 디렉터리의 test.xml 파일에서 <Set name="extractWAR"> 부분의 프로퍼티 값을 "false"로 지정하였다는 것이 저자의 설명입니다.
Windows Azure Platform이 Microsoft의 기술이므로 철저히 .NET Framework 기반의 응용프로그램 개발만을 지원할 것이라는 편견은 종합적으로 "잘못된 것입니다." Windows Server 2008 R2의 기술을 기반으로 하고 있기 때문에, 여러분의 응용프로그램이 Windows Server 2008 R2, 그리고 64비트 환경에서 성공적으로 수행될 수 있는 조건을 갖추고 있다면 Windows Azure Platform은 성공적으로 여러분들의 클라우드 컴퓨팅으로의 계획을 이끌어 줄 수 있을 것입니다.