남정현의 Windows Azure 블로그

Windows Azure Platform에서 Compute 서비스가 차지하는 비중은 매우 큽니다. 그런 만큼, Compute 서비스가 어떤 방식으로 실행되고 동작하는지를 파악하는 것이 필요한데, 이에 대한 이야기를 블로그 글로 써보고자 합니다. 그 중에서도 이번 글은 웹 역할과 작업자 역할에 대한 업그레이드 메커니즘에 대한 이야기를 하고자 합니다.

1. 업그레이드 방법 #1 - VIP 교환 (VIP Swap)

가장 안전하다고 알려진 방법으로, Compute 서비스는 기본적으로 Production와 Staging이 한 벌이 됩니다. 여러분이 신청한 서비스의 실제 도메인 주소와 연결되는 것이 Production 환경이며, Staging 환경은 임의로 생성된 고유 ID 값을 식별자로 사용하는 FQDN 주소를 사용합니다. 만약 기존에 운영 중인 Production 서비스가 이미 있는 상황에서 프로젝트 파일의 구성에 큰 변화가 있을 때, 가령 SDK 버전의 변경, 최소 인스턴스 수 변경, 프로젝트 추가/제거로 인한 구성 변경 등에 해당되는 경우 VIP 교환 방식을 이용하는 것이 필요합니다.

VIP 교환 방식을 사용하면 Windows Azure는 네트워크 위치를 즉시 Production과 Staging을 서로 바꿉니다. 즉, Production에 있는 서비스 전체는 Staging으로 이동하고, Staging에 있는 서비스 전체는 Production으로 이동합니다. 스포츠 경기에서 자주 보는 선수 교체 같은 개념입니다. :-)

VIP 교체 전/후로는 서비스 자체에 결함이 없는 한, 사용자가 변경되는 시점을 알아차리지는 못합니다. 하지만 완벽하게 Seamless한 서비스 업그레이드를 구현하기 위해서는 세션 상태를 별도의 저장소에 보관하여 이전에 구동중인 서비스에서 가지고 있던 세션을 새로운 서비스에서 이어받아 서비스할 수 있도록 설계하는 것이 필요합니다.

2. 업그레이드 방법 #2 - 패키지 업그레이드

CSPKG 파일과 CSCFG 파일을 Windows Azure SDK나 Visual Studio Tools for Windows Azure를 사용하여 완성하면 이를 Azure Storage나 Management API를 경유하여 직접 업로드하는 방법입니다. 이 방법은 프로젝트에 큰 변화가 없고 소스 코드나 웹 페이지의 일부와 같이 클라우드 응용프로그램의 일부만을 변경할 때에 사용할 수 있는 방법입니다. 효율적인 서비스 관리를 위하여, Windows Azure Storage를 같이 신청하여 비공개 컨테이너를 생성하고 이곳에 여러분의 서비스 패키지를 여러벌을 올려놓고 Management API를 사용하여 필요 시 교체할 수 있습니다.

패키지 업그레이드는 VM을 새로 생성하거나, 실행 중인 VM의 OS를 다시 시작시키지 않으며, Windows Azure Fabric Controller의 지시에 따라 내부적으로 기존에 사용중이던 가상 하드 디스크를 언마운트하고, 새로운 가상 하드 디스크를 생성하여 마운트를 합니다. 이전에 올렸던 Windows Azure의 파일 시스템에 대한 글 [Windows Azure Platform/Compute] - Windows Azure VM의 파일 시스템 구조 를 잠시 인용하면, C에는 Local Storage를 위한 공간으로 할당이 되고, D에는 Windows OS가 설치된 공간이며, E부터 Z까지는 동적으로 마운트하는 가상 하드 디스크들을 위한 공간으로 활용이 된다고 하였습니다. 여기서 보통은 E로 시작하여 업그레이드 때 마다 F나 E 드라이브로 다시 마운트 되며, Windows Azure Drive는 그 이후, 보통은 G 드라이브부터 가상 하드 디스크를 마운트하는 셈입니다.

보통은 패키지 내에서 실행되던 응용프로그램은 업그레이드와 함께 종료되고 다시 시작되지만, 패키지의 권한 밖에서, 관리 목적으로 열어놓은 문서 형식의 파일에 대해 명시적으로 Lock을 걸고 있는 경우 업그레이드가 실패할 가능성도 일부 있어보입니다. 지금 언급하는 방법으로 업그레이드에 실패하는 경우 원격 데스크톱으로 열어놓은 항목을 검토할 필요가 있을 것입니다.

3. 업그레이드 방법 #3 - 완전 삭제 후 다시 배포

이것은 업그레이드 메커니즘이라기보다 재설정이라고 하는 것이 정확합니다. 보통은 이 방법까지 오지 않고 VIP 교환으로 해결할 수 있고 또한 그럴 필요가 있습니다. 안타깝게도, Visual Studio Tools for Windows Azure에서 패키지를 배포하는 방법은 이 방법에 속합니다. 따라서, Visual Studio를 이용하여 배포할 때에는 도구 자체의 기능을 사용하여 Production Deploy를 수행하는 것은 위험하며, VIP 스왑을 위한 전초 단계로만 제한적으로 활용하는 것이 안전합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

알립니다: 이 블로그 게시물에서 설명하는 내용은 아직 출시되지 않은 제품과 서비스에 대한 내용을 다루는 것으로, 실제 사용 가능한 시점까지는 더 많은 기간이 소요될 수 있으나 정보 공유 차원에서 Professional Developer Conference 2010 행사에서 공개된 내용을 기반으로 내용을 말씀드립니다. 이 글의 출처 및 모든 이미지의 출처는 http://blog.toddysm.com/2010/10/remote-desktop-connection-to-windows-azure-instance.html 입니다.

Windows Azure에 대하여 가장 많은 요청이 있었고 가장 많은 관심을 받았던 업데이트들 중에서, 오늘은 Windows Azure 인스턴스를 원격으로 제어하기 위하여 앞으로 배포될 SDK와 서비스에서 어떻게 클라우드 서비스를 구성하면 될지 그 방법을 미리 살펴보는 글을 올립니다.

Windows Azure 서비스 패키지에 원격 데스크톱 연결 추가하기

1단계: 이제까지 해왔던 것처럼 Windows Azure 서비스 프로젝트를 만들고 테스트한 후 배포할 준비를 마치십시오.

위의 대화 상자를 볼 수 있는 단계까지 여러분의 클라우드 서비스가 준비되어있다면 이 글의 내용을 시험해 볼 수 있습니다. 새 버전의 SDK에서는 "Configure Remote Desktop Connections…" 링크가 "Enable IntelliTrace for .NET 4 roles" 체크 박스 바로 아래에 새로 나타날 것입니다. 링크를 클릭하면 다음과 같이 추가 대화 상자가 나타날 것입니다.

2 단계: 원격 데스크톱 연결 구성하기

이어서 나타나는 대화 상자에서, "Enable connections for all roles" 체크 박스에 체크합니다. 그리고, 보안 연결에 사용할 인증서를 선택하고, 원격 연결에 사용할 사용자 ID와 이름을 지정합니다. 해당 계정에는 반드시 계정 만료 기간을 지정하도록 되어있습니다. 한 가지 알아둘 점이 있다면, 이번에 같이 소개된 VM Role과는 다르게 웹 역할과 작업자 역할은 그 자체로 완성된 응용프로그램으로 볼 수 있으며 가능한 원격 연결을 사용하지 않더라도 완전하게 구동될 수 있는 것을 목표로 하는 것이 좋습니다. 또한, 온 프레미스 환경에서의 클라우드 운영과 다르지 않은 보안 목표를 설정할 수 있는데 바로 노출 영역의 최소화라는 관점입니다. 계정 날짜 만료는 이러한 목표를 달성할 수 있도록 돕습니다.

Windows Azure 호스팅 서비스를 통하여 배포하기

지금부터 설명할 내용은 새 버전의 실버라이트 기반 Windows Azure 호스팅 서비스 관리 도구를 기준으로 인증서와 클라우드 서비스를 배포하는 방법에 대한 내용입니다.

1단계: 화면 좌측 하단에 있는 Compute, Storage & CDN 탐색 영역을 클릭하여 화면을 이동합니다.

2단계: 새로 나타나는 트리 뷰에서 Compute Services 노드를 클릭하면 우측의 화면이 아래와 같이 바뀌게 됩니다.

3단계: 상단의 리본 메뉴의 New 섹션 안에 있는 New Hosted Service 버튼을 클릭하면 아래와 같은 대화 상자가 나타납니다. 앞 단원에서 설명한 대로 진행하기 위해서, 아직은 실제 클라우드 서비스 패키지를 배포하지 않습니다. 여기서 미리 배포를 하기 위해서는 앞 단원에서 설명한 클라우드 서비스 패키지와 매칭할 수 있는 인증서가 클라우드 서비스에 미리 등록되어있어야 합니다. Deploy 그룹 아래의 Do not deploy 버튼을 선택하고, 서비스 이름과 서비스 별칭을 지정, Affinityp Group, Region 등을 설정한 후 OK 버튼을 클릭합니다.

4단계: 이제 별도의 인스턴스가 생성되지 않은 서비스가 구독 항목 아래에 생성되는 것을 볼 수 있습니다. 우측 트리 뷰에서 Compute Services 항목을 펼칩니다.

5단계: Compute Services 노드 아래에 인증서를 등록할 수 있도록 별도의 옵션이 나타나는 것을 볼 수 있습니다. Service Certificates 노드를 선택하고, 상단의 리본 메뉴에서 Certificates 섹션 아래의 Add Certificate 버튼을 클릭합니다.

6단계: 아래 대화 상자에서, 개인용 인증서 파일과 암호, 그리고 인증서로 증명할 대상 Hosted 서비스를 선택하고 Create 버튼을 클릭합니다.

7단계: 새 인증서가 Grid Control에 등록되는 것이 보인다면, 이제 다시 우측의 Compute Services 노드를 클릭하여 이전 화면으로 되돌아갑니다.

8단계: 4단계에서 생성한 클라우드 서비스를 선택하고, 상단의 리본 메뉴에서 New 섹션의 New Production Deployment – 또는 – New Staged Deployment 버튼을 클릭합니다. Production Deployment는 3단계에서 설명한 서비스 주소에 직접 연결되는 인스턴스를 생성할 수 있도록 하고, Staged Deployment는 임시 주소를 할당 받아 인스턴스를 생성할 수 있도록 해주지만 언제든 Production Deployment로 서비스 중단 없이 곧바로 교체할 수 있도록 준비되는 인스턴스들입니다. 아래 대화 상자에서 CSPKG 파일과 CSCFG 파일을 컴퓨터에서 찾아 지정하고, OK 버튼을 클릭합니다.

9단계: 전보다 더 보기 쉽고 안정적으로 동작하는 UI에서 실시간으로 인스턴스들의 상태가 가지런히 열거됩니다.

아래 그림처럼 모든 인스턴스들의 상태가 Ready로 바뀔 때까지 기다립니다.

이제 Ready로 표시된 인스턴스 하나를 클릭해 봅니다. 그러면 상단의 리본 메뉴에 Remote Access 섹션에 Connect 버튼이 활성화되는 것을 볼 수 있습니다. 클릭하면 브라우저의 다운로드 기능을 통하여 해당 인스턴스에 직접 접속할 수 있는 RDP 스크립트 파일의 다운로드를 허용할 것인지를 묻는 창이 나타납니다. 이렇게 생성된 RDP 파일은 USB 저장 장치나 바탕 화면 등에 보관하여 원격 데스크 톱 클라이언트와 함께 가지고 다니면서 사용할 수 있습니다.

많이 보던 시나리오인 것을 알 수 있습니다. Amazon Elastic Cloud Computing에서 호스팅되는 Windows Server와 마찬가지로 원격 제어 기능이 이제 개별 인스턴스에 대해서도 가능해졌습니다. 그리고 이러한 기능을 통하여 Windows Azure 기술 지원 팀에게 직접 설명하기 어렵고 민감한 조치 사항들을 고민하지 않고, 쉽고 빠르고 안전하게 문제를 해결하거나 진단할 수 있게 되었습니다. J

간단히 살펴본 새로운 기능과 새 관리자 도구였습니다. 올해 연말, 그리고 내년 연초에는 이러한 기능들이 모두 실제로 사용할 수 있도록, 그리고 좀 더 개선된 형태로 Windows Azure 고객들에게 제공될 예정이니 많은 기대를 하셔도 좋겠습니다.

감사합니다.

안내 - 이 글의 출처 및 모든 이미지의 출처는 http://blog.toddysm.com/2010/10/remote-desktop-connection-to-windows-azure-instance.html 입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Azure를 이용하여 Cloud Application을 개발하다보면 한 가지 불편하다고 느끼게 되는 부분이 있습니다. 특히 Web Role을 이용하여 웹 응용프로그램을 클라우드에서 호스팅하면 특히 심하게 느껴지는 부분이 있는데, 사소한 웹 컨텐츠를 바꾸기 위해서라도 실제 Cloud 환경을 완전히 업그레이드하거나 리뉴얼하는 과정이 동반된다는 점입니다. 물론 이 과정에서 서비스를 강제로 중단하지 않고 업그레이드 프로세스를 거치도록 작업하면 대외적으로 서비스가 중단되는 일은 없지만, 상당한 시간이 소요된다는 것에는 변함이 없습니다.

이러한 비효율성을 해결하고 좀 더 단 시간내에 쉽고 빠르게 웹 컨텐츠를 변경할 필요가 있다면 (마치 우리가 이전에 계속 사용해왔던 웹 호스팅이나 서버 호스팅과 마찬가지입니다.) Hosted Web Core (이하 HWC) Worker Role 템플릿을 이용해 보시는 것은 어떨런지요? 이 템플릿은 MSDN Code Gallery에 게시된 것으로 아래는 이 템플릿을 이용하여 얼마나 빨리 클라우드 상의 웹 사이트를 고칠 수 있는지를 보여주는 재미있는 동영상입니다.

동영상의 내용을 간단히 요약하면, 클라우드 상에 올라와있는 페이지에 있는 Typo (오타)를 고치기 위해서 본래 취해야 할 전체 컴파일 / 업그레이드 프로세스를 거치지 않는 대신, 평소 사용하는 Windows Azure Storage Client에 새로 수정한 웹 페이지 파일을 덮어씌운 것 만으로 손쉽게 교체가 이루어진다는 것을 보여주는 것입니다.

이 템플릿은 단방향으로 Windows Azure Storage의 특정 경로 상에 있는 파일과 현재 Role 내의 파일 시스템 상의 특정 경로 상에 있는 파일들을 직접 대조하면서 Storage에서 변경이 발생하면 이를 자동으로 추적하여 Role 내의 파일 시스템을 업데이트하는 방식입니다. 대부분의 일반적인 ASP.NET 응용프로그램 시나리오에 대해 이러한 방식의 기술은 유효하며 효율적이지만, 원자적인 업데이트 관리가 발생하지 않는다는 점을 감안해야 하며, Embedded Database를 이용하게 될 경우 충돌이 발생할 가능성도 있습니다.

정보 출처: http://blog.smarx.com/posts/update-your-windows-azure-website-in-just-seconds-by-syncing-with-blob-storage

HWC Worker Role 샘플 코드 다운로드: http://code.msdn.microsoft.com/hwcworker

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 발표된 Windows Azure SDK 1.2에 추가된 Visual Studio 2010을 위한 IntelliTrace 기능은 여러모로 Windows Azure의 개발 과정과 시행 착오를 최소화할 수 있는 효과적인 도구입니다. 그렇지만 이 기능을 적용하기 위해서 필요한 요구 사양이 있는데 다음과 같습니다.

• IntelliTrace는 Visual Studio 2010 Ultimate 이상의 버전에서만 사용이 가능합니다. (이 점이 IntelliTrace에 관해서 가장 많이 놓치게 되는 부분일것 같습니다.)
• Visual Studio Tools for Windows Azure 1.2 버전에서만 가능합니다.
• 64비트 버전의 OS에서만 사용이 가능합니다. (이 부분에 대한 설명이 충분하지 않았기 때문에 많은 착오가 있을 수 있습니다.)
• IntelliTrace로 추적할 대상 Web Role - 또는 - Worker Role은 반드시 .NET Framework 4.0 기반으로 컴파일되어야 합니다.

Visual Studio 2010 Ultimate 버전을 설치하고, 최신 버전의 SDK와 Visual Studio Tools를 설치했음에도 불구하고 배포 시에 IntelliTrace 옵션이 활성화되지 않았던 경우에는 32비트 버전의 OS를 사용하고 있기 때문입니다. 이러한 경우, 아래의 Hotfix를 설치하여 문제를 해결하실 수 있습니다.

http://go.microsoft.com/fwlink/?LinkId=191542

다운로드 바로가기: http://code.msdn.microsoft.com/KB983301/Release/ProjectReleases.aspx?ReleaseId=4351

자료 출처: http://msdn.microsoft.com/en-us/library/ff683671.aspx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근에 Windows Azure의 Hosting Service Control Web Page에 유용한 기능이 하나 추가되었습니다. 이전에는 Deploy하는 Windows Azure Package의 설정 파일에 직접 기술해야 했던 Windows Azure OS 버전을 배포하기 직전이나 배포한 이후에 손쉽게 변경할 수 있는 기능이 추가되었습니다. 아래는 해당 기능에 대한 스크린샷입니다. :-)

위의 그림에서, "OS Settings..." 버튼을 클릭하면, 현재 배포된 응용프로그램에서 사용할 OS의 종류를 선택할 수 있는 옵션 페이지가 아래 그림과 같이 따로 나타납니다. 현재 사용중인 OS의 정보는 그림에서 보시는 것처럼 Windows Azure Guest OS 1.3 (Release 201004-01)로 나타나고 있습니다.

기본적으로, 모든 Role이 항상 최신의 버전을 택할 수 있도록 Automatic Upgrade Mode를 사용하는 것이 좋습니다. 그러나, 특정 Windows Azure OS에서 테스트가 필요한 경우이거나 진단을 해야 할 필요가 있을 때에는 Manual Upgrade Mode를 사용하여 직접 원하는 OS 버전을 선택할 수도 있습니다. 이에 대한 설명은 http://msdn.microsoft.com/en-us/library/ff729420.aspx 에서 자세히 제공하고 있습니다.

OS 업그레이드는 위와 같이 포털 사이트에서 진행할 수도 있고, 작업 시간을 단축하기 위하여 프로젝트와 함께 생성되는 설정 파일 상에서도 미리 구성할 수 있습니다. 앞으로 Windows Azure OS는 최신 보안 패치들과 사용 빈도나 요청이 많은 닷넷 어셈블리들을 포함하여 매달 정기적으로 업데이트가 이루어질 예정이라고 합니다. 웹 포털에 자주 방문하셔서 최신 OS로 업그레이드하는 작업도 꾸준히 하시는 것이 Windows Azure 기반의 서비스를 최상의 상태로 유지하는데에 도움이 되실 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 Windows Azure 위에서 사용하기 위하여 WCF 서비스를 테스트하던 중, 이전에 Windows Azure SDK에서 소개했던 문제점을 발견하게되었습니다. IIS에 의하여 호스팅되는 WCF 서비스를 클라우드 밖의 환경에서 참조하기 위하여 프록시 클래스를 생성할 때, Windows Azure의 외부 호스트 주소가 아닌 VM의 로컬 주소를 기준으로 프록시 클래스가 생성되는 현상으로, On-Premise 환경과 달리 Windows Azure Platform의 네트워크 인프라가 로드밸런서에 의하여 동적으로 관리된다는 데에 문제의 핵심이 있습니다.

이미 지난 2월에 Windows Azure SDK를 발표하면서 이에 관한 패치 (KB971842 / KB977420)가 같이 소개되었습니다만 이를 실제로 Windows Azure Application에 적용하는 방법에 대한 문서를 써볼 필요가 있어서 늦게나마 이를 올려봅니다. 이 패치는 개발자 컴퓨터에 직접 설치하는 패치로, 이 패치를 통하여 변경되는 사항은 Windows Azure VM 내에도 적용되어있는 상태입니다.

1. 패치 설치하기

Windows Vista 및 Windows Server 2008에서 Windows Azure SDK를 이용하여 개발하실 경우, http://code.msdn.microsoft.com/KB971842 에서 패치를 다운로드하여 설치하여 주시고, Windows 7 및 Windows Server 2008 R2에서 Windows Azure SDK를 이용하여 개발하실 경우 http://code.msdn.microsoft.com/KB977420 에서 패치를 다운로드하여 설치하여 주시기 바랍니다. (기술 지원 문서는 각각 http://support.microsoft.com/kb/971842 와 http://support.microsoft.com/kb/977420 의 내용을 참조하여 주십시오.)

2. Windows Azure Web Role / Worker Role에 Custom Behavior 추가하기

기존의 Windows Azure Web Role이나 Worker Role의 WCF 설정 섹션 (system.serviceModel 요소) 아래에 다음과 같은 설정을 추가합니다.

    <behaviors>
      <serviceBehaviors>
        <behavior name="LoadBalancedBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <useRequestHeadersForMetadataAddress>
            <defaultPorts>
              <add scheme="http" port="81" />
              <add scheme="https" port="444" />
            </defaultPorts>
          </useRequestHeadersForMetadataAddress>
        </behavior>
      </serviceBehaviors>
    </behaviors>

위에서 강조 표시한 부분이 KB971842와 KB977420을 통하여 제공되는 업데이트를 활성화하는데에 필요한 요소입니다. useRequestHeadersForMetadataAddress 요소는 Behavior 이름이 LoadBalancedBehavior라는 설정에 한정되어 유효한 태그이며, 그 이외의 경우는 잘못된 Child 요소로 분류되어 프로그램 수준에서 오류가 발생합니다. 그리고 위의 설정은 Windows Azure Simulator나 Windows Azure Host Process에서만 제대로 동작하며 직접 IIS로 호스팅하는 경우에는 설정이 반영되지 않습니다.

만약 기존에 사용하는 별도의 Behavior 설정이 있었다면 기존 Behavior 설정은 유지하시고, LoadBalancedBehavior 설정에 추가하기를 원하는 부분만 복사하여 그대로 붙여넣으면 온전하게 반영됩니다.

3. WCF 서비스에 Behavior 연결하기

    <services>
      <service behaviorConfiguration="LoadBalancedBehavior" name="PhoneNUse.WebRole.PhoneNUse">
        <endpoint address="" binding="basicHttpBinding" contract="PhoneNUse.WebRole.IPhoneNUse" bindingConfiguration="PhoneNUse.WebRole.IPhoneNUse">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>

위에서 굵은 표시로 강조한 부분의 속성 값, 즉 behaviorConfiguration 부분만 위에서 지정한 Custom Behavior의 이름인 LoadBalancedBehavior로 변경해주면 서비스에서의 설정은 끝이 납니다.

4. 실버라이트를 고려하는 경우

실버라이트 컨텐츠를 클라이언트로 사용하는 경우, Windows Azure가 아닌 경우에도 해당이 되지만, Windows Azure에서 WCF를 호스팅할 때에도 동일하게 적용되는 부분이 있습니다. 바로 WCF 서비스의 바인딩 형태에 관한 것과 Cross Domain에 관한 부분입니다.

    <services>
      <service behaviorConfiguration="LoadBalancedBehavior" name="PhoneNUse.WebRole.PhoneNUse">
        <endpoint address="" binding="basicHttpBinding" contract="PhoneNUse.WebRole.IPhoneNUse" bindingConfiguration="PhoneNUse.WebRole.IPhoneNUse">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>

    <bindings>
      <basicHttpBinding>
        <binding name="PhoneNUse.WebRole.IPhoneNUse">
          <security mode="None" />
        </binding>
      </basicHttpBinding>
    </bindings>

위에서 강조 표시한 부분이 실버라이트와의 통신을 고려한 BasicHttpBinding에 대한 설정이 되겠습니다. 그리고 아래의 XML 파일이 clientaccesspolicy.xml 파일이며 보통 Windows Azure Web Role Root에 배치됩니다.

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

5. 주소 필터 불일치로 인한 문제 해결하기

Windows Azure에서 실행되는 WCF 서비스의 경우, 주소 필터 불일치로 인한 문제 때문에 역시 프록시 클래스를 이용한 통신에서 실패할 수 있는데, 이를 방지하기 위한 목적으로 주소 필터의 설정을 완화하는 Attribute를 선언적으로 클래스 앞에 붙일 수 있습니다. 다음의 코드가 그 예시입니다.

    [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
    public class PhoneNUse : IPhoneNUse
    {
        ....

    }

그 외에 좀 더 자세한 내용, 상세한 설정 방법 등은 http://code.msdn.microsoft.com/wcfazure/Wiki/View.aspx?title=KnownIssues 에 게시되어있는 글을 참조하시면 많은 도움이 될 것입니다.

감사합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Azure의 Web Role과 Worker Role은 가상 PC 인스턴스를 동적으로 생성하고 부팅시키는 방식을 통하여 서비스가 구현됩니다. SDK에서 소개하는것처럼 부팅이 끝나면 배포된 Role Application의 Entrypoint Class를 통하여 서비스의 초기화 작업이 이루어지고 서비스의 시작이 완료됩니다.

그렇다면, Windows Azure VM의 파일 시스템이나 여러가지 설정을 좀 더 상세하게 파악하고 다룰 수 있다면 서비스를 좀 더 풍성하게 꾸밀 수 있지 않을까요? 그런 취지에서 Windows Azure VM의 파일 시스템 구조를 살펴보는 글을 오늘 올려봅니다.

Note: 이 글은 Windows Azure OS 1.1을 기준으로 작성된 것이며, Windows Azure 내의 가상 PC 규격은 예고 없이 변동될 수 있음을 미리 알립니다.

Windows Azure VM의 Disk Partitioning 상태는 3개입니다. C/D/E 드라이브로 구분이 되어있는 상태로 파악할 수 있으며, 각 드라이브마다 역할이 있습니다. C 드라이브의 경우 서비스 구동과 제어에 필요한 핵심 리소스들이 주로 배치되어있습니다.

펼쳐두기..

그리고 시스템 덤프 파일과 메모리 페이징 파일도 C 드라이브에 들어있습니다.

펼쳐두기..

D 드라이브에는 Windows Azure OS의 실제 시스템이 포함되어있습니다. Windows Azure OS의 기동에 필요한 Windows Server 2008 R2 x64가 설치되어있는 파티션입니다.

펼쳐두기..

상당히 익숙한 모습의 디렉터리 레이아웃이 보입니다. inetpub, PerfLogs, Program Files, Program Files (x86), Users, Windows 디렉터리는 보통의 64비트 Windows OS에서 볼 수 있는 디렉터리 레이아웃과 같습니다. 좀 더 깊이 살펴보기 위하여, %windir%\microsoft.net\framework 디렉터리 아래에 어떤 버전의 프레임워크들이 설치되어있는지도 살펴보겠습니다.

펼쳐두기..

.NET Framework 1.0, 1.1, 2.0, 3.0, 3.5, 4.0 디렉터리가 존재하는 것을 확인할 수 있습니다. 여기서 1.0과 1.1은 관리 도구에 관련된 파일만이 포함되어있습니다. (64비트 버전을 이용할 수 있는 것은 아닙니다.) 그리고 Windows Azure VM의 버전이 1.1이므로 4.0 버전은 설치되어있지 않고, 디렉터리만 만들어져있는 상태입니다. 좀 더 나아가서, Global Assembly Cache에는 어떤 어셈블리들이 설치되어있는지도 선택적으로 살펴보겠습니다.

펼쳐두기..

펼쳐두기..

그리고, 마지막으로 E 드라이브의 구조를 살펴보겠습니다. E 드라이브는 개발자가 업로드한 Web Role이나 Worker Role이 저장되는 파티션입니다. 보통 Windows Azure 응용프로그램이 실행되면 VM 내에서의 기본 디렉터리 위치는 E:\ (E 드라이브의 루트 디렉터리)가 됩니다.

펼쳐두기..

위의 항목들 중에서 approot 디렉터리에는 우리가 개발한 Web Role이나 Worker Role 프로젝트 파일들의 사본이 배포됩니다. 그리고 Windows Azure VM 내에서는 __entrypoint.txt 파일에 서술된 DLL 파일을 찾아 해당 항목을 Loading하는 것으로 이해할 수 있겠습니다.

펼쳐두기..

그 외에 base에는 Windows Azure 구동에 관한 핵심 DLL들이, storage에는 Windows Azure Drive 관련 API를 제공하는 DLL들이, diagnostics에는 진단 도구 및 ETW 관련 API들이 포함된 DLL 및 응용프로그램들이 포함되어있습니다.

그 외에, Windows Azure의 상세한 디스크 정보를 파악하기 위하여 diskpart 같은 명령어를 테스트해보기도 하였지만 COM 관련 기능의 부재로 아래와 같은 오류 메시지가 나타나는 것도 확인하였습니다.

펼쳐두기..

Windows Azure OS의 내부 빌드는 ver 명령을 통하여 확인할 수 있었습니다.

Microsoft Windows [Version 6.0.6002]

whoami를 이용하여 현재 Role을 실행하는 사용자의 이름도 확인할 수 있었습니다.

cis\ab279a57-70bb-4dd5-a4ba-fe7f60abfca2

그리고, Standard User Account로 실행 중이기 때문에, netstat -nab 같은 명령어나 fsutil 같은 명령어는 각각 아래와 같은 권한 상승 필요 메시지가 나타남을 확인할 수 있었습니다.

펼쳐두기..

대신, netstat 명령만을 실행하였을 때는 아래와 같이 간단한 네트워크 현황을 볼 수 있습니다.

펼쳐두기..

프로그램을 실제로 작성할 때 도움이 되는 환경 변수에 관한 사항들은 어떨까요? set 명령을 이용하여 설정된 환경 변수들의 목록도 살펴보았습니다.

펼쳐두기..

프로그램 작성에 좋은 지침이 되는 환경 변수들 몇 가지를 살펴보면, SystemDrive, RdRoleRoot, RoleRoot, PATH 같은 환경 변수들이 있겠습니다. 그리고 USERDOMAIN, COMPUTERNAME, COMSPEC 및 프로세서 관련 환경 변수들도 시스템을 분석하는데에는 역시 도움이 되는 정보들이 되겠습니다.

Windows Azure OS 내의 파일 시스템 구성은 오늘 소개한 내용이 대략적인 내용이 될 것 같습니다. Windows Azure OS의 파일 시스템과 설정을 좀 더 상세히 살펴볼 수 방법은 앞으로도 지속적으로 업데이트하겠습니다. 긴 글 읽어주셔서 감사합니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

실제 Windows Azure OS는 어떤 구성을 사용하고 어떤 설정을 바탕으로 움직이는것일까요? 물론, 충분한 양의 문서와 SDK와 API로 모든 이론적인 설명은 가능합니다. 하지만 좀 더 깊이 들어가서 알아볼 필요가 있을 때도 있습니다. 인터넷 서핑 중에 찾은 흥미로운 블로그 아티클 하나를 소개하고자 합니다.

출처: Windows Azure Team에서 Senior Program Manager로 근무 중인 David Lemphers의 블로그 (http://blogs.msdn.com/davidlem)에서 찾은 아티클 (http://blogs.msdn.com/davidlem/archive/2009/07/06/looking-inside-windows-azure.aspx) 입니다.

엄밀하게 말해서, Windows Azure OS를 실행하는 VM의 상황은 사실 블랙박스나 다름없습니다. 정상적으로 프로그래밍하고 테스트했다면 반 정도의 확률은 정상적으로 실행되지 않을 가능성도 있는 셈입니다. (기동에 실패하는 일보다는, 원하는 대로 서비스가 동작하지 않을 가능성을 의미합니다.) 특히, Worker Role의 경우 Web Role과는 달리 Custom Configuration에 강한 의존을 할 수 밖에 없는데요, 네트워크 서비스 등이 예상대로 동작하지 않으면 굉장히 큰 고민속에 빠지게 됩니다. 이런 곤란한 상황을 빠져나가려면 어떻게 하면 좋을까요?

배포할 Windows Azure 프로젝트의 .CSDEF 파일에 enableNativeCodeExecution 어트리뷰트의 값을 "true"로 명시적으로 설정하는 것으로부터 솔루션을 시작할 수 있습니다. (최근의 SDK와 OS의 경우, 이 설정은 기본적으로 'true'이지만 명시적으로 설정하는 것도 좋을것 같습니다.)

그리고 아래와 같이 간단한 asp.net 페이지에 사용할 코드 비하인드를 만듭니다.

newProc.StartInfo.UseShellExecute = false;
newProc.StartInfo.RedirectStandardOutput = true;
newProc.StartInfo.FileName = "cmd";
newProc.StartInfo.Arguments = "/c " + txtCommand.Text;

newProc.EnableRaisingEvents = false;
newProc.Start();

sr = newProc.StandardOutput;

txtStatus.Text += String.Format("{0}\r\n", sr.ReadToEnd());

newProc.Close();

위의 코드가 하는 역할은 단순합니다. Windows 명령줄 인터프리터를 대신 실행해주고 대신 결과를 출력해주는 것입니다. 그리고, Native Code의 실행을 허용했으므로 거의 대부분의 명령이 정상적으로 실행될 수 있을 것입니다. (관리자 권한 아래에서 실행되지는 않습니다.)

아래의 스크린 샷들은 실제 명령의 수행 결과들을 보여주는 것입니다. 그리고 이 블로그 아티클의 저자는 NETSTAT 명령을 원격에서 실행해보고, Tomcat Instance가 필요로하는 8080포트가 이미 점유된 상태이기 때문에 원하는대로 작동하지 않음을 확인할 수 있었다고 합니다.

ps. 이와 같은 도구는 확실히 디버깅이나 문제 진단에는 유용할 수 있지만, 아무리 클라우드 환경이라고 할지라도 이와 같은 도구가 개방되어있을 경우, 악용될 소지가 크기 때문에, 실제 배포 단계에서는 이러한 도구가 포함되지 않도록 유의할 필요가 있겠습니다.

샘플 페이지의 예시

NETSTAT 명령 실행 결과

TASKLIST 명령 실행 결과

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

.NET Framework 4.0과 Visual Studio 2010 RTM이 긴 테스트 과정과 수렴 과정 끝에 이번달에 성공적으로 전 세계에 런칭하였습니다. 생산성을 극적으로 업그레이드할 수 있는 다양한 기술과 API 들을 중무장하고, ASP.NET MVC2나 MEF (Managed Extensibility Framework) 등의 새로운 기술들도 다채롭게 선보였습니다.

그런데 한 가지 궁금증이 생깁니다. Windows Azure OS 자체는 아직도 .NET Framework 3.5 SP1을 기반으로 하는데 언제 .NET Framework 4.0으로 업데이트하는걸까요? 이에 대한 포럼 내의 답이 있어서 블로그에 소개합니다.

출처: http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/395925-create-a-beta-environment-for-net-4-0-tests-and?ref=title

MIX2010에서, Windows Azure에서의 .NET Framework 4.0 지원은, RTM 버전이 공개된 이후 약 90일 이내에 업데이트된다고 합니다. 개발 과정 상의 변수 (Visual Studio용 SDK 개발, Windows Azure VM 이미지 업데이트) 등을 모두 감안한 기간으로 보입니다만, 늦어도 올해 초여름에는 .NET Framework 4.0을 기반으로 실행되는 Windows Azure 서비스를 사용할 수 있는 셈이 됩니다.

그렇지만, 좀 더 빠르게 .NET Framework 4.0 기반의 클라우드 응용프로그램을 개발하고 테스트하기를 희망하신다면, 배포하실 Windows Azure 환경 설정 파일에 실제로 채택할 운영 체제의 버전을 정확히 기술하여 .NET Framework 4.0 RC 버전을 채택한 VM을 기반으로 구동하도록 선택하실 수도 있습니다. 해당 버전은 Windows Azure Geust OS 1.2 중 2010년 3월 1일 버전의 이미지입니다. (http://msdn.microsoft.com/en-us/library/ff436045.aspx)

.NET Framework 4.0과 Windows Azure가 결합한다면, 이전보다 더 확장성이 뛰어나고 강력한 클라우드 기반 응용프로그램을 작성할 수 있는 토대가 마련될 것입니다. 여러모로 기대가 많이 되는 소식이고, 새로운 소식이 들어오는대로 정보를 공유할 수 있도록 하겠습니다. 감사합니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.