남정현의 Windows Azure 블로그

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에서도 이용할 수 있을 것으로 보입니다.

좀 더 자세한 내용은 http://www.zdnet.com/blog/microsoft/microsoft-to-enable-linux-on-its-windows-azure-cloud-in-2012/11508 에서 보실 수 있습니다.

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

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

Windows Azure Platform의 핵심 구성 요소들 중 하나인 Windows Azure Storage가 이번 BUILD Windows 2011 행사 이튿날에 발표한 기능 중에는 Windows Azure Storage의 향상에 관한 내용이 있었는데, 그 동안 Windows Azure Storage에 대해서 바라던 많은 요구 사항들이 이번에도 성실하게 반영되었습니다. 그 중에서도 큰 맥락을 나누면 같은 지역 내의 다른 데이터센터로 Storage의 데이터를 복제할 수 있는 Geo-Replication 기능과, BLOB, Table, Queue 스토리지의 사용법 개선에 따른 성능 향상이 있습니다.

Geo-Replication

이제 Windows Azure Storage 역시 다른 Cloud Platform들과 마찬가지로 재해 복구 기능을 가질 수 있게 되었습니다. 기존에는 Geo-Replication을 전적으로 이용자의 재량으로 해야했고, 비용 투자가 필요했던 부분이지만 이 기능을 네이티브하게 지원할 수 있게 되었기 때문에 더 안전한 서비스 사용이 가능해지게 되었습니다. Geo-Replication은 Windows Azure BLOB과 Table 스토리지에 한정되는 내용으로 예를 들어 북유럽과 서유럽 사이, 동아시아와 동남아시아 사이의 데이터센터 간에 데이터 복제를 수행하여 Redundancy를 확보하는 전략입니다. 그러나 아시아와 유럽 간 복제는 수행하지 않으며, 모든 작업은 비동기적으로 수행되므로 현재 서비스에서 변경되거나 영향을 주는 부분은 없다고 합니다. 

새 BLOB, Table 및 Queue 스토리지의 기능들

2011-08-18 버전의 REST API에서는 기존에 커뮤니티로부터 많은 요청이 있었던 기능들을 제공하는데, 다음과

• Table Upsert: 한 번의 요청으로 이미 존재하는 엔터티에 대해서는 업데이트를, 존재하지 않는 엔터티에 대해서는 삽입을 조건부로 처리할 수 있는 기능입니다.
• Projection Query 지원: 엔터티의 하위 집합을 만들 수 있는 기능으로 LINQ to Table Storage 등에 직접적인 영향을 주게 될 가장 큰 기능입니다. 이전에는 Projection Query를 수행할 수 없었기 때문에 전체 엔터티 컬렉션을 서버로부터 우선 다운로드한 다음 이것을 메모리에서 정리하는 비효율적인 방식을 사용했지만 이 작업을 서버 차원에서 직접 수행할 수 있게 됨에 따라 대역폭 사용량을 줄이고 쿼리 성능을 더 업그레이드할 수 있게 되었습니다.
• 향상된 BLOB HTTP 헤더 지원: BLOB 차원의 동영상 스트리밍이 가능해지고, 다운로드 가속기 등으로 이어받는 작업이 가능해졌습니다.
• 큐 메시지 업데이트: 큐에 삽입한 메시지의 내용을 편집하거나, 유효 기한을 연장하여 큐 자체의 항목을 엔터티로 취급할 수 있게 하고 길게 소요되는 작업에 대한 이벤트 처리를 큐 스토리지를 통해서 할 수 있도록 기능을 보강했습니다.
• 큐 메시지 삽입 시 대기 시간 지정: 큐에 메시지를 삽입한 직후에 다른 큐 메시지 수신처에서 내용을 보이게 하지 않고, 지정된 기간 동안 내용을 숨기도록 삽입할 수 있습니d

그 외에 좀 더 자세한 정보는 아래 블로그 문서들을 참고하십시오.

• Windows Azure Storage BUILD talk
• Geo-replication
• New Table Features
• New Queue Features
• New Blob Features

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

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

요즈음 클라우드 서비스들을 이용하다보면, Windows 서버 운영체제를 통해서 확장성있는 클라우드를 만들고자 하는 경우가 자주 있습니다. 일반적인 웹 사이트를 구축할 때에도 마찬가지이고, 당연히 KT UCLOUD나 Amazon과 같은 환경에서도 같은 노력이 뒷받침이 되어야 하지요. 그리고 제가 주 전공으로 하고 있는 Windows Azure 역시, 첫 배포 때에는 간과하기 쉬운 점이 바로 로드 밸런싱 환경이라는 점입니다.

이러한 로드밸런싱 환경을 만들때에는, 이전에 구축해본 경험이 없는 관리자가 개발자 입장에서는 상당히 어려운 문제에 봉착하게 될 가능성이 많습니다. 특히 요즈음 웹 환경에서는 당연하게 사용하는 세션이나 쿠키에 관련된 설정들이 로드밸런싱 환경에서 기대했던 것과 다르게 동작해서 좌절하는 경험을 많이들 하실텐데요, 제가 오늘 블로그에 올리는 것은 ASP.NET에 관한, 그리고 IIS 7에 관한 내용입니다. (PHP나 JSP 개발자분들께서도 공감하실 수 있는 부분이 있을 것입니다.)

로드밸런싱 환경을 잘 알고 구축할 수 있다면, 앞으로 나오게될 어떤 종류의 클라우드 서비스이든 관계없이 문제를 정확하게 해결할 수 있을 것입니다. 사실 클라우드 기반의 웹 서비스는 달리 표현하면, 기본 골자는 로드밸런싱에 기반을 두고 있는 것이고, 그 이후의 확장성 전략을 클라우드 솔루션으로 채우는 것과 같다고 말할 수 있습니다. (어떤 뼈대를 사용할 것인지는 전적으로 여러분들의 선택에 달린 것입니다.)

로드 밸런싱 환경이란?

로드 밸런싱 기술 자체는 상당히 오래된 것입니다. 이름에서 알 수 있듯이, 몰려오는 트래픽을 내부적으로 분산하여 특정 서버 컴퓨터로 연결이 몰려 서비스가 사용 불가 상태로 빠지는 것을 "지연"시키거나 "완화"시키는 것에 목적이 있습니다. 로드 밸런싱의 기술적 개념도는 다음과 같습니다. (이미지 출처: http://msdn.microsoft.com/en-us/library/ff650667.aspx)

다양한 상황에서 로드밸런싱이 쓰이겠지만 가장 일반적으로는 웹 환경에서 많이 쓰입니다. 연결을 오래 유지할 필요가 없으면서도, 짧은 시간 내에 빠른 연결 회전을 보이는 웹 프로토콜에서 가장 중요한 것은 바로 신속성인데, 분산 처리를 하지 않는 경우에는 필연적으로 서버 컴퓨터가 받아들일 수 있는 동시 연결 한계치에 금방 치닫게 됩니다. 그러나 로드 밸런싱을 정확히 사용하면 이러한 한계치에 치닫게 되는 속도가 로드 밸런싱에 참가하는 컴퓨터의 댓수만큼 반비례하게 됩니다. 그리고 이 때 하나의 웹 사이트를 위한 로드 밸런싱 서비스에 멤버로 참여하는 서버 컴퓨터들을 묶어서 "웹 팜"이라고 정의를 하는 것이지요. 더 일반적으로는 "서버 팜"이라고도 합니다.

잠시 다른 이야기로 넘어가자면, 요즈음 대두되는 클라우드 컴퓨팅은 관리 측면에서 봤을 때, 충분한 대역폭을 보장하는 연결과 매우 뛰어난 성능을 가진 로드 밸런서를 이용하여 연결을 분산하는 작업을 수행하는 것입니다. 그리고 웹 팜 안에 참여하는 컴퓨터의 유형에 있어서는 이전과 다른 점이 하나 있는데, 마치 구름과 같이 수축과 팽창을 자유자재로 한다는 것입니다. 물론 이런 수축과 팽창이 가능함은 내부적으로 가상화 솔루션을 이용했다거나 여기에 대응할 수 있는 알고리즘을 사용했다는 가정이 깔려있는 것입니다.

정말 완벽하고 정확하게 구축했다면, 적은 전원이나 자원 공급으로도 충분히 웹 팜이 유지가 될 수도 있고, 필요하다면 웹 팜의 크기가 엄청나게 커질 수도 있겠지요. 이걸 여러분이 관리하신다면 프라이빗 클라우드, 신뢰할 수 있는 IT 기업이 관리한다면 퍼블릭 클라우드가 된다고 보실 수 있겠습니다. 그러나, 클라우드 컴퓨팅이 만능약처럼 들릴 수 있는 부분이 있지만 정확히 알아야 할 것은 클라우드 컴퓨팅 역시 이 로드 밸런싱을 기초로 만들어지는 것이고, 여러분이 운영할 수 있는 한계에까지 트래픽이 몰리거나, 이런 일을 하는 IT 업체에게 지불할 수 있는 재정의 한계에까지 트래픽이 몰린다면 이것이 여러분이 생각할 수 있는 클라우드의 한계입니다. 무제한이라고 해서 값이 저렴하거나 무료에 수렴하는게 아님을 명확히 이해하고 있어야 합니다.

웹 로드 밸런싱을 위한 이야기

다시 본론으로 돌아와서, 웹을 로드 밸런싱할 수 있으려면 무엇을 검토해야 할까요? 가장 중요한 것은 웹 서버에 참여하는 각각의 컴퓨터 자체에는 "절대로" 컴퓨터의 고유한 정보를 가지고 있으면 안된다는 점입니다. 매우 단순한 이야기같지만 이러한 원칙을 지키지 않도록 설계되어있는 것이 지금 이 시점까지의 서버 컴퓨팅 기술들의 대다수의 원칙입니다. 간단한 예를 들어볼까요?

여러분이 일상적으로 사용하는, 웹을 통한 파일 업로드 기능을 담당하는 간단한 웹 앱이 있다고 가정해 보겠습니다. 이 웹 앱은 서버가 한 대 일때에는 참 쉽고 빠르게 설치해서 쓸 수 있었습니다. 당연히, 설치를 잘 했다면, 사용자가 웹 페이지를 방문해서 파일을 업로드하면 웹 서버가 그것을 알아보고 파일을 회수해서 하드 디스크 어딘가에 저장하겠지요. 그러나 시간이 지나서 이 웹 앱의 기능을 업그레이드하고 좀 더 많은 사용자들이 파일을 저장하고 다운로드할 수 있도록 만들어보고자 해서 로드 밸런싱 환경을 구축하여 베타 테스트를 시작했습니다. 그런데 어떤 문제들이 생겼을까요?

앞서 이야기한 기술적인 특성때문에, 사용자들은 분명히 조금전까지 파일을 업로드했었는데 페이지를 다시 와서보니 파일이 업로드되지 않은 상태로 페이지가 나와서 혼란스러워합니다. 혹은 파일을 어디로 빼돌린거냐며 분노하는 사람들도 있구요. 그래서 몇 번 F5키를 누르다보면 "어라?"하고 놀라게 됩니다. 조금 전에 업로드했던 파일이 다시 나타나니까요. 그러고나서 그 파일을 다운로드하려고 링크를 클릭하면 이번엔 또 다시 404 오류를 만납니다. 이제 사용자들은 이 서비스에 대해서 대단한 분노와 원성을 쏟아낼 것입니다. 서비스 상태에도 일관성이 없을 뿐 아니라 불안정한것 같다. 믿을 수 없다면서요.

이것이 일선 IT 현장에서 로드 밸런싱이나 클라우드를 처음 접목했을 때 겪는 "가장 흔하고 일반적인 장애"입니다. 더 안타까운 것은, 이것을 신 기술에 의한 책임으로 회피하고 문제시하는 것입니다. 문제의 본질을 정확히 알고 있다면 이렇게 말하는 것이 왜 잘못인지도 금방 알 수 있을 것입니다.

여기서 든 예제처럼, 이 웹 앱의 문제는 단순히 업로드한 파일을 자신의 컴퓨터에 저장하려고 했다는 데에 문제가 있습니다. 로드 밸런싱 멤버로 참여하는 컴퓨터가 자신의 상태를 중요하게 여기면, 다음번에 이어받는 다른 서버 컴퓨터의 입장에서는 이전에 그 컴퓨터가 무엇을 했는지 알 길이 없습니다. 그저, 찾고자 하는 내용이 없음을 이야기하는 수 밖에 없습니다. 이런 상황이 반복되면서 서비스 전체는 들어올때와 나갈때가 전혀 다른, 일관성이 없고 이상한 서비스가 되는 것입니다.

이 문제를 해결하기 위하여 어떻게 수정해야 할까요? 답은 간단합니다. 파일 저장소를 로드 밸런싱 멤버 컴퓨터 내부가 아닌, 여러 멤버 컴퓨터들이 같이 이용할 수 있는 공용 저장소로 바꾸는 것입니다. 가장 간단한 방법은 네트워크 UNC 경로로 이용할 수 있는 스토리지가 있을 수 있습니다.

여기서 궁금한 점이 하나 더 있는데, 그렇다면 로드 밸런싱에 의하여 애써 분산한 서비스가 다시 모이는 것이 아니냐고 반문할 수도 있습니다. 그런데 사실, 생각외로 사용자들이나 웹 크롤러와 같이 인터넷 상에서 발생하는 별 뜻없이 바쁘게 만드는 다양한 유형의 트래픽을 웹 팜 수준에서 한 번은 로드 밸런싱을 해주는 것 만으로도 실제 스토리지에 대한 요구 사항은 획기적으로 감소한다는 점입니다. 거기다, 역할 분담도 정확히 할 수 있으며 스토리지 자체에 대한 요구 사항이 폭증하는 것을 방지하기 위하여 기술적으로는 좀 더 복잡해질 수 있지만 캐싱 기능을 사용할 수도 있습니다. 이렇게 함으로서, 우리가 흔히 잘 아는 클라우드 서비스의 시작을 뗄 수 있게 됩니다.

기술적인 이야기 1 - 세션 처리 방법 바꾸기

그렇다면 IIS와 ASP.NET에서는 이런 이상한 상황을 예방하고 신뢰할 수 있는 서비스를 만들기 위해서 어떤 수정 사항을 반영해야 하는 것일까요? 제가 이제까지 인터넷 상으로 자료 조사를 해왔던 것은 모두 제각기 흩어져있는 정보들이었고 이것을 한 번에 취합할 수 있는 방법을 오늘 블로그 포스팅을 통하여 소개할까 합니다.

기본적으로 ASP.NET은 세션 처리를 IIS 프로세스 안에서 수행하도록 되어있습니다. 가장 동선도 짧고, 신속하게 반응하기 때문입니다. 그러나 로드 밸런싱 환경에서 이는 당연히 "채택하면 안되는" 기법입니다. 이 방법은 web.config 파일 안의 <sessionState> 요소에서 변경할 수 있는 부분으로, <configuration> 요소 아래의 <system.web> 요소 아래에서 없는 경우 새로 지정할 수 있습니다. <sessionState> 요소의 mode 속성의 값을 변경하면 됩니다. 지금 이야기한 부분은 mode 속성이 InProc으로 지정되어있거나, 아무것도 지정되어있지 않을 때 .NET Framework의 글로벌 web.config 설정을 바꾸지 않은 경우 기본으로 지정되는 설정입니다.

IIS 7에서 볼 수 있는 아래 그림과 같은 설정도 이 XML 파일의 수정을 텍스트 에디터 없이 수정하는 것입니다.

로드 밸런싱 환경에서 정상적으로 동작하는 웹 사이트를 만들기 위해서는 mode의 설정 값을 InProc 대신 StateServer나 SQLServer로 바꾸어야 하는데, 양쪽 값 모두 장단점이 있습니다. StateServer의 경우 기본적으로는 꺼져있는 ASP.NET State Service라는 NT 서비스가 제공하는 별도의 서버를 이용하는 방식이고, SQLServer는 이름에서 알 수 있듯이 실제 SQL Server를 사용하여 세션을 구현하는 방식입니다. 데이터베이스 서버의 성능이 세션을 모두 수용할 수 있을만큼 획기적으로 뛰어나거나, 세션 서버가 죽었다가 살아나도 로그아웃 처리가 안되게 한다던가, 혹은 여러 로드 밸런싱 사이트 사이에서 세션 공유를 안전하게 할 방법이 필요하다면 이 모드를 사용할 수 있습니다. 이에 비하여 StateServer는 별도의 SQL 서버 없이도 간편하게 구축할 수 있는 방법을 제공하긴 하지만, 세션 서버가 죽었다 살아날 경우 내용이 없어지는 휘발성 세션입니다.

양쪽 모드 모두 중요한 것은 멤버로 참여하는 웹 서버 컴퓨터 밖에 상태를 보관해야 한다는 것이 키 포인트로, 이것을 지키지 않고 멤버 컴퓨터 안에 이런 설정을 구축하면 전혀 나아지는 것이 없습니다. 그리고 당연한 이야기이지만 멤버 컴퓨터로 참여하는 모든 웹 서버가 같은 설정을 가지고 있어야 합니다.

StateServer와 SQLServer 모드를 구현하는 방법에 대한 자세한 내용은 아래 아티클을 참고하시면 되겠습니다.

http://msdn.microsoft.com/ko-kr/library/ms178586.aspx

기술적인 이야기 2 - ASP.NET 사이트 간에 립싱크 맞추기

세션을 공유하는 것 이외에, ASP.NET은 내부적으로 Machine Key라는 것을 사용합니다. Machine Key의 용도는 ASP.NET 안에서 참 다양한데, 가장 대표적으로는 클라이언트와 서버 사이에 쿠키 정보를 주고 받을 때 암호화하기 위한 수단으로 이용하는 것이 유명한 사례입니다. 쿠키를 이용한 취약점 공격은 웹 세계에서 너무나 당연한 공격 방식 중 하나이기 때문에 ASP.NET은 처음부터 이를 보완하기 위한 전략을 구현하고 있었습니다. 그러나 이것이 지금 와서 로드 밸런싱 환경이 되면서는 또 다른 어려운 문제로 바뀐 것입니다.

이 Machine Key라는 것 역시 서버 컴퓨터마다 고유하게 생성할 뿐 아니라, 매번 연결할 때 마다 다른 값을 생성하여 암호화에 사용합니다. 클라이언트 입장에서야, 서버가 "ABC"라는 쿠키를 주니까 "아 그렇구나. 나중에 돌려주면 서버가 날 알아보겠지?"하며 성실하게 반납합니다. 그런데 로드 밸런싱에 참여하는 A라는 서버 대신 C라는 서버가 이 쿠키를 받아들었을 때는 "이거 내것 아님" 하며 클라이언트에게 퇴짜를 놓습니다. 이것이 문제의 핵심인 것이죠.

이 문제를 해결하기 위해서는 아까전에 이야기한 주제보다 좀 더 많은 노력이 필요합니다. 생각보다, 보안을 완벽하게 유지하기 위하여 ASP.NET이 관리자들에게 요구하는 사항이 까다롭기 때문입니다. 이 Machine Key를 만들기 위해서는 별도의 생성 도구를 사용해야 합니다. 그러나 안타깝게도 이 도구를 구한다거나 만들 수 있으려면 개발자들의 조력이 좀 필요합니다. 그리고 개발자 본인들도 이런 방법을 찾아야 하기때문에 꽤나 귀찮습니다. Codeproject에 가면 이러한 방법을 자세히 설명한 아티클도 있습니다만 간단한 도구도 드리고, 코드 조각도 드리니 프로그램에 넣어 활용하시면 더 편리할 것입니다.

using System;
using System.Text;
using System.Security.Cryptography;

/* 중략 */

        public static string getRandomKey(int bytelength)
        {
            byte[] buff = new byte[bytelength];
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
            rng.GetBytes(buff);
            StringBuilder sb = new StringBuilder(bytelength * 2);
            for (int i = 0; i < buff.Length; i++)
                sb.Append(string.Format("{0:X2}", buff[i]));
            return sb.ToString();
        }

        public static string getASPNET20machinekey()
        {
            StringBuilder aspnet20machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key32byte = getRandomKey(32);
            aspnet20machinekey.Append("<machineKey\n");
            aspnet20machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet20machinekey.Append(" decryptionKey=\"" + key32byte + "\"\n");
            aspnet20machinekey.Append(" validation=\"SHA1\" decryption=\"AES\"\n");
            aspnet20machinekey.Append("/>\n");
            return aspnet20machinekey.ToString();
        }

        public static string getASPNET11machinekey()
        {
            StringBuilder aspnet11machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key24byte = getRandomKey(24);

            aspnet11machinekey.Append("<machineKey");
            aspnet11machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet11machinekey.Append(" decryptionKey=\"" + key24byte + "\"\n");
            aspnet11machinekey.Append(" validation=\"SHA1\"\n");
            aspnet11machinekey.Append("/>\n");
            return aspnet11machinekey.ToString();
        }

위의 코드를 사용하여 프로그램을 만들거나 ZIP 파일 안의 프로그램을 이용하여 값을 만들도록 하면 아래와 같은 XML 코드 조각을 얻을 수 있을 것입니다. 이 코드 조각을 각각의 서버에 들어있는 web.config에 지정하거나, 특정한 값만 인용하여 아래의 IIS 7 설정 아이콘에서 볼 수 있는 설정 도구를 통해서 직접 설정할 수도 있습니다.

<machineKey
 validationKey="FACBB6C89C44CB8BB7165FC4639BAA7267B...EF297D815E1BDD40E883E3451628CB95D34309"
 decryptionKey="4E95057676CC8DBA9AB...AACC1121B6B962E5AFA7849B0C82"
 validation="SHA1" decryption="AES"
/>

기술적인 이야기 3 - IIS에서 놓치면 안되는 것

ASP.NET을 가장 먼저 사용할 수 있게 된 웹 서버가 IIS이다보니 발생한 일종의 특성입니다만 여러 포럼에 걸쳐서 잘 언급되지 않는 문제점이 하나 있습니다. 바로 IIS에서 사용하는 사이트 ID 값을 통해서 정해지는 Application Path를 Machine Key와 같이 활용된다는 사실입니다. 웹 사이트 관리를 하다보면 로드 밸런싱에 참여하는 컴퓨터들을 다음과 같이 관리하게 되는 경우가 있습니다.

• 서버 A에서는 기본 웹 사이트를 먼저 지우고 새 웹 사이트를 만들었다.
• 서버 B에서는 새 웹 사이트를 먼저 만들고 기본 웹 사이트를 지웠다.

혹은 아래와 같은 경우도 있을 수 있습니다.

• 서버 C에서는 사이트 A를 만들고 사이트 B를 만들었다.
• 서버 D에서는 사이트 B를 만들고 사이트 A를 만들었다.

별 차이 없이 생각할 수 있지만, IIS에서는 이 경우 각각의 사이트들에 다른 ID 값을 부과하게 됩니다. 이 경우, 분명히 Machine Key를 동일하게 지정했음에도 불구하고 로드 밸런싱 환경에서 세션 상태가 일관성없게 변하는 문제를 만나게 됩니다. 제가 이번에 고민하게 된 부분도 바로 이 부분이었는데요, 이 문제를 해결하기 위해서는 IIS 7에서 전체 웹 사이트 목록에 나타나는 내용 중 다음의 ID 값이 멤버로 참여하는 웹 서버마다 차이가 있지 않은지 우선 검토해야 합니다.

위에있는 그림에서 빨간색으로 그린 부분이 서버 컴퓨터마다 차이가 있다면 이 값을 수정해주어야 합니다. 이 값을 수정하기 위해서는 수정할 사이트를 클릭하고, 고급 설정 링크를 아래 그림과 같이 클릭합니다.

이제 아래와 같은 팝업 대화 상자가 나타나면 강조 표시한 속성인 ID 값이 멤버로 참여하는 웹 서버 모두 같은 값을 가질 수 있도록 통일시켜줍니다.

확인 버튼을 누른 다음, ID 값이 바뀐 서버 컴퓨터에 한해서 IIS 전체를 재시작해주시거나 사이트 재시작을 시켜주시면 정상적으로 작동하게 될 것입니다.

Windows Azure 환경에서의 고려 사항

오늘 살펴본 내용은 IIS 7과 ASP.NET에 관한 부분이었지만, Windows Azure Platform의 경우에도 비슷한 문제가 있습니다. Windows Azure Platform에 VM Role로 웹 사이트를 게시를 하든, Web Role로 웹 사이트를 게시하든 세션을 사용하게 될 경우 비슷한 문제가 있을 수 있습니다.

다행히, Web Role을 이용한다면 내부적으로 사용하는 IIS에서 여러분이 몇 개의 웹 사이트를 추가적으로 구성하든 관계없이 같은 순서로 같은 ID를 사용하는 웹 사이트를 만들 것이므로 세 번째로 이야기한 ID 값 수정과 같은 작업은 할 필요가 없을 것입니다. 그러나 Machine Key에 대한 설정이나 세션 공유를 위한 설정은 SQL Azure를 이용한다거나, Worker Role에서 ASP.NET State Service 혹은 써드파티의 Session State Server를 이용해야 할 수 있습니다.

물론, 최근에 Windows Azure Platform의 일부로 Windows Azure AppFabric Cache가 새로 출시되기는 하였습니다만 상당히 이용 가격이 비싼 편입니다. (비싼만큼 확실한 성능을 제공합니다.) 로드 밸런싱 환경에서 특별한 문제를 일으키지 않는 일반적인 세션 공유가 필요하시다면 오늘 이야기한 주제를 응용한 Azure Project를 구축해보는 것도 의미가 있을 것입니다.

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

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

요즈음은 회사의 분야나 크기, 규모를 막론하고 누구나 자체적인 전산망을 구축하기 원하고, 자체적인 협업 사이트를 구축하기 원하며, 자체적인 통합 커뮤니케이션 시스템을 구현하기를 원합니다. 제대로만 구축된다면 참 편리하게 쓸 수 있고 회사가 빠르게 성장하는데 많은 도움을 줄 것이라는 것을 익히 보고 들어왔기 때문이죠. 하지만 생각만큼 쉬운 일이 결코 아닙니다. 경우에 따라서는, 회사가 원래 목표로 세웠던 대외적인 활동보다도 더 큰 역량이 들어가서 배보다 배꼽이 더 큰 일로 빠지는 경우도 많으니까요.

이번에 제가 다녀온 Office 365 MVP Day에서는 많은 이야기들이 있었지만 개인적으로는 Windows Azure Platform이나 기타 클라우드 컴퓨팅 플랫폼과 연결될 수 있는 Office 365만의 고유한 기능들에 대해서 가능성을 조사해보고 타진하는 것을 저만의 즐거움으로 삼을 수 있었습니다.

Exchange Web Service Managed API

다른 Microsoft 서비스들과 마찬가지로 Office 365 역시 독창적인 API를 제공합니다. EWS Managed API를 사용하여 조직 내 E-MAIL 계정 사용자의 작업을 대행하거나, 개인의 일정 정보를 검색하거나, 메일 내용을 검색하는 등의 서비스를 기존의 Windows Application에서는 물론, 여러분이 만들 고유한 웹 서비스 및 모바일 애플리케이션에서도 구현할 수 있습니다. 아래는 Epience에서 근무하시는 최정우 차장님께서 Demo로 보여주신 EWS를 이용하여 만든 Web Mail 시스템의 실행 예시입니다.

EWS Managed API 자체는 Exchange Server에서 제공하는 API를 기반으로 만들어진 것이기 때문에, 정확한 서비스 위치만 알고 있다면 XML Web Service를 처리할 수 있는 프로그래밍 언어에서는 EWS를 이용하여 필요한 작업을 수행할 수도 있습니다. http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17947 에 게시된 문서를 통하여 다양한 프로그래밍 언어와 환경에서 EWS Online API를 사용하는 예시를 살펴보실 수 있습니다. :-)

SharePoint Portal Development with Office 365

SharePoint는 기본적으로 협업을 위한 위키 페이지 작성, 문서 공유 등의 작업을 수행할 수 있도록 디자인된 기업용 맞춤형 포털 서비스를 제공합니다. 그렇지만 클라우드 버전의 SharePoint Online에서는 이 외에도 클라우드 기반 시스템으로 갖추어야 할 기본적인 소양으로 많이 꼽히는 Claim-based Authentication이나 Data Conversion/Migration 등의 기능도 제공하고 있습니다.

그리고 종전의 Standalone 버전의 SharePoint와는 달리, 클라우드 환경에서는 타 고객들에게 금전적, 시간적 손해를 끼칠 가능성을 사전에 차단하기 위하여 클라우드 서비스에 대해서 영향을 주지 않을것이라고 확신할 수 있는 컨텐츠만을 제작할 수 있는 SharePoint Designer 이외의 모든 코드들이 샌드박스 환경 안에서 수행됩니다.

전적으로 개발자의 재량에 따른 것이지만 간단한 전자결재 시스템 역시 SharePoint를 통하여 구축하는 것이 가능합니다. 좀 더 자세한 내용은 http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx 에서 확인해보실 것을 권합니다.

Microsoft표 온라인 서비스의 이점

클라우드 서비스를 제공하겠다고 나서는 업체들은 매우 많습니다. 그렇지만 이러한 클라우드 서비스를 단순히 제공한다는 사실만을 너무 강조한 나머지 기본에 충실하지 못한 경우를 자주 보게 되는데, 이는 달리 표현하면, "바퀴를 붙여 잘 굴러가게 만들었으니 자동차로서의 기능을 지원한다"고 설명하는 것과 같은 오류가 될 수 있습니다. Microsoft가 제공하는 온라인 서비스들은 이러한 오류에 빠지지 않도록 지속적으로 기능을 개선하고, 기본에 충실하면서도, 신뢰성이 높은 서비스들로 구성되어있다는 점에서 이번 Office 365의 런칭은 개인적으로 Windows Azure Platform이 런칭될 때 못지 않은 기대감을 가지게 합니다.

조만간 국내에서도 KT를 통하여 Office 365 서비스를 신청할 수 있게 될 것으로 보입니다. Office 365의 기본 기능들만 사용해도 훌륭하지만 이제 클라우드 시대에 맞추어 여러분도 다른 업체에 여러분의 시스템을 맡기는 일 없이 여러분의 입맛에 맞게 회사 내 인트라넷 시스템과 인프라를 DIY할 수 있습니다. :-)

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

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

세미나 신청은 http://onoffmix.com/event/3671 에서 부탁드립니다.

Windows Azure Cafe (http://cafe.naver.com/wazure)에서는 지난해에 이어 올해부터는 매월 다양한 주제를 통하여 개발자, IT 전문가들에게 Windows Azure 기반의 실전 개발에 대한 이야기를 전할 수 있또록 Boot Camp 세미나를 준비하였습니다. 클라우드 컴퓨팅에 관심이 있는 분들을 모시고, 세미나 전/후로는 클라우드 컴퓨팅과 최신 기술 동향에 대한 자유로운 토론도 같이 진행할 수 있도록 하겠습니다. 이번달에는 SQL Azure에 대한 내용을 다루어봅니다.

카페 방문하기: http://cafe.naver.com/wazure

제목: SQL Azure 실무에 도입하기
일시: 2011년 9월 7일 수요일 / 오후 7시
장소: 포스코센터 서관 5층 한국 마이크로소프트 SYNERGY 룸
대상: 소프트웨어 개발자 및 웹 개발자
발표: 남정현 (Windows Azure MVP 2011)

세션 소개

(1) SQL Azure가 SQL Server와 다른 점
SQL Azure는 Microsoft SQL Server를 클라우드 환경에서 사용할 수 있도록 서비스화하여 제공하고 있는 클라우드 서비스로, 기본 기능들은 Microsoft SQL Server와의 호환성을 유지하기 위하여 작성되었지만, 실제 동작 환경이나 여러 가지 제약 사항들이 또 한편으로는 존재합니다. SQL Azure를 이용하여 데이터베이스 프로그래밍을 어떻게 시작할 수 있고, SQL Server와의 차이점이 어떤 것들이 있는지 첫 세션에서 살펴보고자 합니다. 그리고 각 프로그래밍 언어별로 SQL Azure를 활용하는 방법도 살펴봅니다.
- 30일 Trial로 SQL Azure 계정 신청하기
- SQL Azure의 구조 살펴보고 이해하기
- Desktop 및 Server에서 SQL Azure 활용하기
- PHP나 Java에서 SQL Azure 활용하기
- Visual C++과 OLE DB를 이용하여 SQL Azure 활용하기

(2) SQL Azure 좌절방지위원회
SQL Azure는 공유 환경에서 실행되는 클라우드 데이터베이스로, 흔히 생각하는 이상적인 클라우드 컴퓨팅 서비스보다 사실 더 엄격하고 정책적입니다. 이러한 차이점을 숙지하지 못하고 이용했을 때 벌어질 수 있는 문제점들을 진단해보고 프로그래밍 코드 상에서 개선할 점은 없는지 검토해봅니다.
- 백업을 해야할 만큼 중요한 데이터라면...
- Connection Throttling (연결 차단)에 대한 정확한 이해
- 지원되지 않는 몇 가지 옛날 기술들과 그 솔루션
- 방화벽 설정에 대한 정확한 이해
- 문자열, 시간대에 관한 주의 사항

진행 순서
- 19:00 ~ 19:50 (1) SQL Azure가 SQL Server와 다른점
- 19:50 ~ 20:00 휴식
- 20:00 ~ 20:50 (2) SQL Azure 좌절방지위원회
- 20:50 ~ 21:00 질문/답변

경품 안내

당일 추첨을 통하여 "Pro SQL Azure 입문" 도서 3권과 Microsoft Arc Wireless Keyboard 1대를 나누어드릴 예정입니다.

알립니다: 본 세미나는 커뮤니티가 주최하는 비영리 세미나이며, 당일 주차권은 별도로 제공되지 않으니 가급적 대중 교통을 이용하여 주시면 감사하겠습니다.

세미나 신청은 http://onoffmix.com/event/3671 에서 부탁드립니다.

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

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

자신의 PC를 가져와서 같이 앱을 개발 해보는 방식의 앱 캠프가 시작 됩니다. 관심 있는 많은 개발자 분들과 만날 수 있었으면 합니다. 
‘첫 클래우드 앱 개발하기’ 세션에서 필요한 것은 본인의 PC에 여기 링크에서 Get Tools & SDK를 클릭하시면 나오는 WPI를 통해서 윈도우 애저 개발에 필요한 도구를 모두 설치하신 후에 참석하셔야 합니다.

<첫번째 App Camp 진행 일정>

일시 : 2011년 7월 20일(수)
시간 : 오후 7시~10시
장소 : 대치동 포스코센터 서관 5층 회의실
**주의사항 : 앱 캠프는 무료로 진행되며 별도로 노트북을 제공해 드리지 않습니다. 참석하시는 분들은 필요한 소프트웨어를 설치한 노트북을 지참해 주십시오.

참가 신청하기 : http://blogs.msdn.com/b/eva/

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

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

이전 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around cloud computing – 지금이 여러분의 이력서를 새로 쓸 시간 

뜬금없이 근두운 이야기가 무엇인가 하고 놀라는 분들이 있으리라 생각한다. 이해가 빠른 분들이 계실 것이므로 단도직입적으로 말하면, 필자가 의도한 그대로, Cloud Computing 이야기를 하고자 했던 것이다. 우리의 머릿속 한 구석에 큰 존재감을 과시하며 차지하고 있는 전설 속 원숭이 손오공의 근두운을 IT 세상에서는 누구나 하나씩 다 가지고 있는 것이다.

여러분이 사용하고 싶어하는 근두운의 종류 또한 다양하다. 그래서 앞서 설명했던 Windows Live, Windows Server 기반 Private Cloud, Office 365가 있었고, 오늘은 마지막으로 개발자와 IT 전문가들의 관점에서 적극적으로 검토해 볼 가치가 있고 든든한 파트너 역을 맡아줄 Windows Azure Platform이라는 근두운을 이야기해볼 생각이다.

IT 관리자의 관점에서 보는 Windows Azure Platform

PDC08에서 처음 소개된 Windows Azure Platform은 전적으로 개발자의 역할을 중시했던 플랫폼이었다. 이는 PDC09, 그리고 PDC 2010 직전까지도 지속되었고 꾸준히 그 색을 더해 나가고 있던 과정이었다. 하지만 PDC 2010에서 처음으로 세간에 루머로만 떠돌던 VM Role이 공식적으로 사용 가능하게 베타 서비스로 출시되었고 이에 따라 IT 관리자들의 관점에서도 Windows Azure Platform을 활용할 수 있는 기회가 대폭 늘어나게 되었다.

Windows Azure Platform이 IT 관리자들에게 제공하는 주요 이점은 한 마디로 정리하면 기존의 IT 자산과 맞물려 사용할 수 있는 다양한 기회를 제공한다는 점이다. Microsoft의 Public Cloud는 모든 것을 Cloud로 올려야 한다고 말하지 않는다. 대신, 네트워크 수준에서의 통합부터 시작하여 Cloud 내부 및 외부에서 발생할 수 있는 문제를 다양한 방법으로 해결할 수 있도록 도와준다.

Windows Azure의 VM Role은 On-Premise 시스템을 분리 해체하는 작업을 거치지 않고 곧바로 Windows Azure 데이터센터에 서버를 올려놓는 방법이다. 기존에 먼저 소개된 Web Role 및 Worker Role과 달리 Windows Server 2008 R2 운영 체제 전체를 하나의 완전한 Role로 채택하여 사용할 수 있는 기법으로, 여러분이 기존에 어떤 라이선스를 가지고 있던지 관계없이 Windows Azure VM Role 라이선스로 전환할 수 있도록 해준다.

매우 이상적인 이야기처럼 들릴 수도 있지만 사실 중요한 문제가 두 가지가 있다. 라이선스에 관한 것이 있고, 또 다른 하나는 기술적인 구성 상의 문제이다. 다음의 표에 대략적인 내용을 언급해두었다.

 

라이선스에 관한 문제의 본질은 다음과 같다. Windows Azure Compute를 통해서 서비스가 실행되면, Service Level Agreement (SLA) 계약 이행을 위하여 기본적으로 VM을 1대 이상 사용하는 것을 전제로 한다. 최소 1대만을 유지하도록 설정해도 상관은 없지만, 필연적으로 사용량이 증가하고 서비스를 위하여 배치된 VM들의 상태가 바빠지는 것이 감지되면 자동적으로 Fabric Controller가 원본 VM 이미지를 복제하여 새로운 VM을 복제하기 시작한다. 이것이 의미하는 바는 단순하다. 물리적인 Instance의 수가 자동으로 늘어나므로 그 안에 포함된 3^rd Party 소프트웨어에 대한 라이선스도 같이 계산되어야 하고, 그것이 CPU 기반 라이선스이든 연결 개수 기반 라이선스이든 상관이 없는 것이다. 양쪽 라이선스 모두 있는 그대로 (as-is) 해석을 한다면 Public Cloud 내에서는 상식을 넘는 금액을 요구할 수 밖에 없다.

이를 해결하기 위해서는 해당 소프트웨어 공급자가 Public Cloud에 대응되는 사용량 – 또는 – 사용 시간 기반 라이선스를 지원해야 하며, 대다수의 경우 이를 지원하지 않을 것이므로 이러한 소프트웨어를 포함하는 서버를 On-Premise 환경에 배치하고, 이들 서버에 대한 종속성을 지니는 별도의 VM Role, Web Role, Worker Role 만을 Windows Azure에 게시한 후 Windows Azure Connect로 상호 연동을 가능하게 만드는 것이 최선이다.

기술적인 문제의 본질은 다음과 같다. 주로 데이터베이스에 대한 부분과 관련이 깊은데, Windows Azure가 SLA 이행을 위하여 VM을 복제하고, 복제된 VM들의 목록을 기준으로 Load Balancer를 구현하는 것은 매우 바람직한 일이다. 그러나 기존의 서버 모델은 개별 서버가 데이터베이스까지 서버 내에 같이 포함하고 있는 경우가 많은데 여기에 대한 적당한 조치를 취하지 않고 그대로 VM Role로 전환하는 경우 우스꽝스러운 문제가 발생한다. 접속할 때 마다 데이터베이스의 내용이 달라지는 일이 발생하는 것이다. 이를 해결하기 위해서는 사용 중인 데이터베이스의 종류를 파악하는 것이 중요한데, SQL Server로 이관이 가능한 범주 안에 있는 데이터베이스들은 우선 SQL Server로 이관한 후, 이를 SQL Azure로 다시 이관하는 작업이 필요하다. 그리고 기존 응용프로그램들도 SQL Azure를 데이터 소스로 사용할 수 있도록 일부 수정이 필요하다.

SQL Azure로 이관하는 것을 누구나 쉽게 검토해볼 수는 있다. 그러나 생각 외로 만만찮은 문제들이 쌓여있다. 기존에 사용하던 자료 형식 중 CHAR, VARCHAR, TEXT와 같이 유니코드와 호환되지 않는 문자열 자료 형식들은 이관 후 CJK 문자 세트로 구성된 데이터가 소실되므로 NCHAR, NVARCHAR, NTEXT로 업그레이드해야 한다는 부분이 있다. 날짜와 시간의 경우 이관 이전과 이관 이후의 시간대 설정 차이가 있으므로 데이터 일관성에 문제가 있을 수 있다는 점이다. 드문 경우이지만, .NET 어셈블리는 SQL Azure에 설치할 수 없으므로 이와 관련된 기능을 사용하는 경우 SQL Azure로 이관하기 전 적당한 Wrapper나 Agent를 따로 개발해야 한다. 또, 기존의 응용프로그램이 데이터베이스 연결을 헤프게 사용하는 경향이 있다면 SQL Azure 입장에서는 예고 없이 연결을 차단시킬 수 있다는 점도 숙지해야 한다. SQL Azure 서비스 자체는 공유 환경에서 실행되므로 SQL Server 인프라와는 비교할 수 없이 엄격한 정책 준수를 요구하는데, 사실 이 때문에 낭패를 보는 경우가 많다. 이런 모든 문제들을 극복하기 위해서, 데이터베이스 역시 특별한 이슈가 없다면 Windows Azure Connect를 사용하여 기존 On-Premise 환경과 구분선 없이 밀착시키는 것이 좋을 수 있다.

사실 지금 언급한 내용들만 이야기해도 Cloud로 이관하는 것보다는 이관하지 않는 것이 더 좋은 것처럼 들린다. 그래서, IT 관리자 입장에서는 무리해서 기존의 인프라를 Cloud로 이관하기 보다, 기존의 인프라나 IT 자산으로는 충당할 수 없는 새로운 영역을 Cloud를 통해 개발하고 확보하는 방법을 새로 익히는 것이 좋다. 그런 맥락에서, IT 관리자들은 Cloud 환경에 최적화된 VM-Role을 개발하는 방법을 익히고, VM-Role이 Windows Azure Connect를 통하여 기존의 Active Directory Domain Controller에 참가하도록 시스템을 구성하거나, 웹 상에서의 클레임 기반 인증을 구현할 목적으로 Active Directory Federation Services (AD FS)와 Windows Azure AppFabric Access Control을 같이 활용하는 방안을 모색하는 것이 바람직하다.

응용프로그램 개발자 관점에서 보는 Windows Azure

원래부터 그러했지만 Windows Azure는 개발자들을 위한 Cloud 플랫폼이었다. 여러 서비스들이 있지만 각각의 역할을 하나씩 소개하려 한다.

Windows Azure Compute: Windows Azure 데이터센터에서 여러분의 응용프로그램을 Hosting할 수 있도록 해주며, IIS를 활용하여 웹 응용프로그램을 실행할 수 있도록 해주는 Web Role, WCF, Socket, C, C++, Python 등 Win32 기반 시스템에서 사용 가능한 모든 종류의 응용프로그램을 실행할 수 있도록 해주는 Worker Role, 그리고 VHD 기반 이미지를 이용하여 Windows Server 2008 R2 OS를 실행할 수 있도록 해주는 VM Role을 하나의 서비스 안에서 다양한 방법으로 조합하여 실행할 수 있는 서비스이다. Windows Azure SDK에서는 VM Role을 제외한 Web Role과 Worker Role 에뮬레이터가 기본 제공된다.

Windows Azure Storage: 대용량의 데이터를 고속으로 처리할 수 있도록 해주는 특별한 저장소로, HTTP 및 HTTPS 프로토콜을 기반으로 상호 작용할 수 있기 때문에 플랫폼이나 위치에 제약이 없다. 저장소의 유형으로는, 단순 파일 저장 및 대용량 파일의 Paging 연산을 지원하는 BLOB 저장소, 행과 열의 대규모 집합 및 고속 인덱싱을 지원하는 테이블 저장소, 고속 메시지 입력 및 출력을 지원하는 큐 저장소로 구분된다. 저장소의 범주에 속하지는 않으나, Windows Azure Compute 상의 Role들이 Win32 API를 사용하여 파일 입력과 출력 연산을 수행할 수 있도록 해주는 Cloud Drive API가 Windows Azure Storage Emulator와 함께 제공된다.

Windows Azure CDN: 대한민국 및 아시아 권역에서 빠른 속도를 자랑하는 새로운 CDN 서비스 역시 Windows Azure Platform 안에 있다. 기본적으로는 Windows Azure Blob Storage에서 공개 권한으로 설정한 Block BLOB에 대해 CDN 서비스를 사용할 경우 자동으로 Mirroring이 된다. 최근 업데이트에서는 Windows Azure Storage가 아닌, 동적으로 API를 사용하여 특정 Contents를 CDN 서비스를 통해 Mirroring할 수 있게 업데이트되었고, 더불어 HTTPS도 지원하기 시작하였다.

Windows Azure AppFabric: 대규모 서비스 운영에 필요한 주요 서비스 컴포넌트 5가지를 제공하는 온라인 서비스로, Windows Server AppFabric의 기술을 바탕으로 하지만 외부에 드러나는 모습은 많이 다르다.

Windows Azure 초창기부터 지속적으로 제공되어왔던 Service Bus는 Point-to-Point 연결을 구현하는 Tunneling Mechanism을 제공한다. WCF 기술을 기반으로 하며, 서버 역할을 수행하는 WCF 호스트가 Service Bus와 연결을 맺은 뒤, WCF 클라이언트는 직접 WCF 호스트에 접근하지 않는 대신, 암호화된 연결을 사용하는 Service Bus로 방향을 바꾸어 접속을 시도하는 방식이다. 이러한 방식이 유용한 이유는, 방화벽의 존재 여부와 관계없이 네트워크 계층에 일관성이 없는 서로 다른 환경 사이를 완벽하게 연결시켜주기 때문이다.

Access Control 서비스는 또 한 번 업데이트를 준비 중에 있다. 처음 발표된 Access Control은 특정 도메인이나 기관이 운영하는 Active Directory 인프라를 기반으로 인터넷 상에서 클레임 기반 인증을 구현하기 위한 목적으로 처음 소개되었다. 인터넷 서비스를 상대로 클레임 기반 인증을 수행하는 것이기 때문에, 인트라넷 환경과는 달리 수시로 Traffic이 발생하며, 뿐만 아니라 신뢰성도 매우 중요하기 때문에 Azure AppFabric Access Control이 유용하다. 그리고 조만간 대대적인 업데이트를 통하여 Windows Live ID, Yahoo, Google, Facebook 등의 Social Networking Platform을 인증 수단으로 사용할 수 있게 되어 한층 더 폭넓은 활용 가능성을 제공한다.

Cache 서비스는 Server 버전의 AppFabric Cache를 Cloud 버전으로 제공하는 것으로, Cache를 위한 인프라를 직접 구축하지 않으면서, 같은 API, 같은 기술을 사용할 수 있는 것이 장점이다. Windows Azure Storage와 SQL Azure를 AppFabric Cache 원본으로 지정하여 사용할 경우 시간과 비용을 획기적으로 절약할 수 있다. 그리고 올해 연중으로 BizTalk Server와의 연계를 고려한 AppFabric Integration 서비스와 함께 Cloud Computing 전반을 통솔하고 제어할 수 있는 AppFabric Composite App 역시 출시될 예정에 있다.

물론 아직 부족한 서비스들도 있다. 그렇지만 이 정도 수준의 서비스라고 한다면 누구나 원하는 서비스를 제약 없이 구현해 볼 수 있지 않을까? 프로그래밍 언어나 개발 도구에 관계없이, 그리고 여러분이 실행하는 프로그램의 위치와 무관하게 말이다. 다시 강조하지만, Microsoft의 Public Cloud는 다른 Cloud Platform들처럼 강제 이주를 논하지 않는다. 모든 것은 여러분의 결정에 따라 움직이며, 매번 적절한 솔루션은 Microsoft에 의해서이든 오픈 소스 커뮤니티에 의해서이든 쓰여지고 업그레이드되어 나가고 있다. Microsoft가 말하는 Cloud Power의 진가를 확인하고 싶다면 지금 곧 Windows Azure Platform으로 떠나보자.

더 많은 정보가 필요하다면 Windows Azure 홈페이지 (http://www.windowsazure.com/)와 더불어 Windows Azure Café (http://cafe.naver.com/wazure), 그리고 .NET 기반 소프트웨어 개발을 위하여 Visual Studio 2010 한국 공식 팀 블로그 (http://www.vsts2010.net/)을 자주 찾아주기 바란다.

글쓴이 이력

• Blog: http://www.rkttu.com / E-MAIL: rkttu@rkttu.com / Twitter: @rkttu
• Windows Azure MVP (2011) / Visual C# MVP (2009-2010)
• ㈜코아뱅크 코아기술연구소 (http://www.corebank.net) 연구원 재직 중
• Windows Azure Café SYSOP (http://cafe.naver.com/wazure)
• Visual Studio 2010 Team Blog (http://www.vsts2010.net) 집필진 활동 중

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

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

올해에도 어김없이 Microsoft TechDays가 찾아왔습니다. 올해 봄 시즌에는 "N 스크린 시대의 IT 전문가들을 위한 온라인 컨퍼런스"라는 주제로 여러 Microsoft MVP들의 온라인 세션이 준비되어있습니다. 그리고, 지금 한창 진행 중인 Imagine Cup 2011 한국 대표 선발전과 더불어서, IT 기술을 통하여 실력을 업그레이드하기도 하고, 전 세계의 수많은 대학생들과 아이디어로 경진해볼 수 있는 Imagine Cup에 대한 상세한 소개도 온라인 세션으로 같이 준비되어있습니다.

이번에도 여러 세션들이 있지만 오늘 제가 소개해드리려고 하는 세션은 개발 - 또는 - Microsoft N 스크린 개발에 처음 입문하시는 분들을 위한 내용, 그리고 모바일, 클라우드, 이매진컵에 대한 내용들을 따로 발췌하여 찾아보시기 편하도록 블로그 포스팅을 재구성해 보았습니다.

개발에 처음 입문하시는 분들께 추천해드립니다.
* Visual Studio 2010 How To Start : 개발자를 꿈꾸는 분들을 위한 입문서 - (주)코아뱅크 연구원 남정현 / Windows Azure MVP
* N-스크린 시대의 필수 Agile 개발 : 1부 모바일 - 강보람 Visual C# MVP
* N-스크린 시대의 필수 Agile 개발 : 2부 WEB - 유니위스 박세식 대리
* N-스크린 시대의 필수 Agile 개발 : 3부 클라이언트 - 엄준일 Visual Studio ALM MVP

Windows Phone 7 개발에 입문하시는 분들께 추천해드립니다.
* 모다의 Windows Phone 뚝딱 팩토리 1. 헬로우 Windows Phone - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 2. 실버라이트, Windows Phone 을 만드는 기술! - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 3. Windows Phone 의 얼굴 만들기, UI - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 4. 인터넷, Windows Phone 과손을 잡다 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 5. 데이터 바인딩의 기초 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 6. 우리 하드디스크가 달라졌어요, 격리된 저장소 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 7. 메뉴? 아니죠, 어플리케이션 바? 맞습니다 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 8. 어플리케이션 속으로 들어간 인터넷 익스플로러 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 9. Where am I? - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 10. 레이싱 게임의 핸들을 구현하는 기술, 가속도계 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 11. 꼭꼭 숨어라 데이터가 보인다 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 12. 잠시 대출(?)이 가능한 기술들, 카메라/주소록/이메일.. - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 13. 다양한 상황에 따라 모양이 변하는 터치 키보드 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 14. LINQ를 이용한 간단한 실전 예제! 블로그 보기 - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 15. 손가락이 하나 더 늘어나면? 멀티터치! - 한국 Microsoft 홍준모 Evangelist Intern
* 모다의 Windows Phone 뚝딱 팩토리 16. 앱 속의 미디어 플레이어 - 한국 Microsoft 홍준모 Evangelist Intern

Windows Azure 개발에 입문하시는 분들께 추천해드립니다.
* 클라우드 응용 프로그램 개발 - Ty Anderson VSTO MVP
* Windows Azure에서 클라우드 응용 프로그램 개발 시작하기 - Hilton Giesenow MVP
* Windows Azure에서 클라우드 응용 프로그램 처음 만들기 - Hilton Giesenow MVP
* SQL Azure : SQL Azure를 사용하여 데이터 액세스를 포함한 클라우드 응용 프로그램 만들기 - Hilton Giesenow MVP
* Windows Azure 현재와 미래 - 한국마이크로소프트 박중석 개발자 에반젤리스트
* Windows Azure 보안 - 한국마이크로소프트 박중석 개발자 에반젤리스트
* Windows Azure 비용 - 한국마이크로소프트 박중석 개발자 에반젤리스트
* Windows Azure 성능 - 한국마이크로소프트 박중석 개발자 에반젤리스트
* 해외 실제 사례로 살펴보는 마이크로소프트 클라우드 개발 - 한국마이크로소프트 박중석 개발자 에반젤리스트
* 마이크로소프트 클라우드 기술 방향성 - 한국마이크로소프트 박중석 개발자 에반젤리스트

Imagine Cup을 준비하시는 분들께, 그리고 대학생 여러분들께 추천해드립니다.
* Imagine Cup : 세상의 난제를 IT기술로 해결하라! - 홍익대학교 황채영 MSP,한국마이크로소프트 최은지 DPE Intern
* Windows Live Mesh 2011 : 동기화 되는 삶  - 프리랜서 박광수 MSP&MVP
* Microsoft Expression Studio 4 : 협력 툴의 결정체 - 프리랜서 노희상 MSP
* Web Matrix : 나만의 블로그를 쉽게 만드는 방법 - 한국기술교육대학교 허찬 MSP, 성신여자대학교 이서연 MSP

더 많은 내용을 보시려면 http://www.techdays.co.kr/2011Spring/ 페이지를 방문해주세요. :-)

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

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

Windows Azure SDK v1.4가 새로 출시되었습니다. 이번에 업데이트된 내용에는 v1.3 이후로 Windows Azure 고객들 사이에서 수집된 다양한 요구 사항들을 반영하고, 한층 더 실용적인 기능을 포함하고 있습니다. 이번 업데이트에서 변경된 주요 사항은 다음과 같습니다.

* web.config 파일이 읽기 전용으로 설저오디었을 때 전체 IIS 기능이 실패하는 문제를 수정
* 전체 IIS 기능을 사용하는 web role 패키지의 크기가 두 배가 되는 문제를 수정
* 진단 로그 저장소가 꽉 찬 경우 전체 IIS 기능을 사용하는 web role의 재생에 발생하는 문제 수정
* Windows Azure 저장소로 IIS 로그 파일을 이관할 때 로그 파일에 대한 권한 문제 수정
* x86 플랫폼에서 csupload 도구를 사용하는 것에 관련된 이슈 수정
* web.config 파일 상의 사용자 오류에 대한 진단이 더 쉽도록 수정
* Windows Azure의 Role에 대한 원격 데스크 톱 연결 관련 기능 안정성 및 성능 향상

그 외에 이번 업데이트와 더불어서 변경되는 서비스 및 신 기술은 다음과 같습니다.

* Windows Azure Connect
   - 다중 관리자를 지원하도록 UI 수정
   - 상태 알림과 진단 기능을 개선한 새로운 클라이언트 UI
   - 비 영어권 Windows 운영 체제에서 Windows Azure Connect 클라이언트를 설치할 수 있도록 수정

* Windows Azure CDN
   - Windows Azure Web과 VM Role에서 직접 CDN 원본 컨텐츠를 구성하고 배포할 수 있도록 만듦
   - CDN에서 HTTPS 프로토콜을 지원; 관리자 포털에서 HTTPS 사용 여부를 제어 가능

새 버전의 SDK를 다운로드 받으시려면 다음 웹 사이트로 이동하시면 됩니다. 한국어 SDK v1.4는 조만간 출시될 것으로 보입니다.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7a1089b6-4050-4307-86c4-9dadaa5ed018&displaylang=en

정보 출처: http://blogs.msdn.com/b/windowsazure/archive/2011/03/09/now-available-updated-windows-azure-sdk-and-windows-azure-management-portal.aspx

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

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

지난번에 소개드렸었던 QRCODE 소셜 앱에 이어, 이번에는 좀 더 다양하고 편리한 기능들을 바탕으로, 그리고 Windows Azure Platform을 기반으로 소셜 앱을 새롭게 업그레이드 런칭하였습니다. 이번 버전에서는 좀 더 다양한 QRCODE 리더 응용프로그램과 상호작용하고, iPhone과 Android 버전 CASEQRCODE Reader App을 설치하시면 일정 관리 등의 기능도 QRCODE를 이용하여 관리하실 수 있습니다.

체험하러 바로 가기 (싸이월드/네이트온 로그인이 필요합니다.)
http://appstore.nate.com/Main/View?apps_no=1376

이번 버전에서 제일 많은 비중을 두고 사용된 것은 Windows Azure Platform의 상호 운용성 기술에 대한 부분으로, Compute의 경우 내부 역할이 2개의 역할로 구성되어있습니다. 앱 스토어에 올라갈 실버라이트 애플리케이션이 호출할 백그라운드 서비스와 더불어, iPhone과 Android 버전 CASEQRCODE Reader App과 상호작용할 REST 기반 API를 호스팅하는 Web Role이 있으며, Java JSP를 기반으로 작성된 QRCODE Image Rendering을 위한 Apache Tomcat 기반의 Worker Role이 있습니다. 그리고 이 둘 사이를 중계하기 위하여 사용자가 직접 업로드하는 이미지들은 물론, 생성되는 QR 코드를 보관하기 위한 Windows Azure Storage가 있으며, SQL Azure를 Web Role과 Worker Role에서 모두 사용합니다. 그리고 실버라이트의 경우, 빠른 다운로드 속도를 제공할 수 있도록 Windows Azure Storage에 현재 게시하였으며 필요한 경우 CDN으로 전환하는 것을 검토 중에 있습니다.

이번 Social App을 런칭하기까지 많은 분들의 기술적 도움과 자문을 바탕으로 성공적으로 Cloud Application을 런칭할 수 있었습니다. 이번에 쌓인 노하우를 다양한 자리에서 다양한 방법으로 전달하고, 또한 많은 발전을 할 수 있도록 노력하고자 합니다. 이번 런칭에 많은 격려와 조언을 아낌없이 해주신 SHESTORY의 김의준 사장님께도 깊은 감사를 드립니다.

감사합니다. :-)

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

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