남정현의 Windows Azure 블로그

요즈음 클라우드 서비스들을 이용하다보면, 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에 가면 이러한 방법을 자세히 설명한 아티클도 있습니다만 간단한 도구도 드리고, 코드 조각도 드리니 프로그램에 넣어 활용하시면 더 편리할 것입니다.

MachineKeyGenerator.zip

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 대한민국 라이선스에 따라 이용하실 수 있습니다.

이전 글: [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 대한민국 라이선스에 따라 이용하실 수 있습니다.

엔터프라이즈 클라우드를 위한 개선 사항

• 가상 컴퓨터 역할 (VM Role - http://www.microsoft.com/windowsazure/compute/#vmrole)이 추가되어, 기존의 Windows 응용프로그램은 물론 새 Windows 기반 응용프로그램도 Windows Azure에서 직접 실행할 수 있는 환경이 마련됩니다.
• 웹 역할은 IIS 7.5 전체 사양 지원을 통하여, 좀 더 완성된 웹 응용프로그램과 미들웨어를 Windows Azure에서 호스팅할 수 있게 되었습니다.
• 웹 역할과 작업자 역할의 경우, 관리자 권한 개념이 추가되어 소프트웨어 구동에 필요한 COM 서버, ActiveX 컨트롤, COM+ 서버 등을 64비트 내의 32비트 호환 모드 - 또는 - 64비트 모드에서 미리 설치하여 구성할 수 있게 되어 더욱 다양한 서버 환경을 호스팅할 수 있게 되었습니다.
• 원격 데스크톱 기능을 각각의 인스턴스에 허용하여, 실행 중인 인스턴스에서 발생하는 다양한 문제점을 Windows Azure Team의 기술 지원이 완료되기까지 기다리지 않고 직접 관리자 재량으로 수행할 수 있는 방안이 제공됩니다. 이는 웹 역할, 작업자 역할에도 동일하게 적용됩니다.
• 새로운 클라우드 기반의 네트워킹 기능이 Windows Azure 가상 네트워크 아래에서 제공되며, 첫 단계로 Windows Azure Connect가 (http://www.microsoft.com/windowsazure/virtualnetwork/default.aspx) 현재 CTP 발표 준비 중에 있습니다. Windows Azure Connect는 이전에 Codename: Sydney로 발표된 적이 있었으며, IP 기반의 네트워크를 기존의 온 프레미스 환경과 Windows Azure의 클라우드 환경 사이에 형성할 수 있도록 하여 Windows Azure의 다양한 리소스를 인터넷이 아닌 로컬 네트워크 수준에서 손쉽게 관리하고 공유할 수 있는 메카니즘을 제공하게 됩니다.

더욱 합리적인 플랫폼 접근

클라우드 컴퓨팅을 운영하면서 가장 이슈가 되는 부분은 비용에 관한 부분이며, 이에 대한 답으로 이번 PDC 2010에서는 최대한 저렴하게 개발하고 테스트할 수 있는 방안으로 기존의 소형 인스턴스 요금보다 최대 50% 이상 저렴한 Extra Small 인스턴스를 제공합니다. 그리고 Microsoft 파트너 회원사를 위하여 Cloud Essential Pack 요금제의 출시를 앞두고 있다는 소식도 있습니다. (http://www.microsoft.com/windowsazure/faq/#partners)

향상되는 서비스

• 실버라이트 기반의 새 Windows Azure 포털 서비스는 이전과는 완전히 다릅니다. 더 사용하기 쉽고, 더 직관적이며, 더욱 강력한 기능들을 제공할 것입니다.
• 현재 제공되는 진단 정보 (Diagnostic Information)에 새로운 항목이 더 추가됩니다. 역할의 종류를 확인하고, 배포된 시간과, 최근 해당 인스턴스나 역할이 다시 기동된 시점을 알아볼 수 있습니다.
• 새로운 가입 절차를 기획 중에 있으며, 이를 통하여 지금보다 더 빠르고 간편하게 Windows Azure 서비스에 가입할 수 있게 될 것이라고 합니다.
• 시나리오 기반의 Windows Azure Platform 포럼을 통하여 다양한 상황에 따라 손쉽게 대처하고 도움을 구할 수 있는 커뮤니티 및 피드백 시스템을 형성해 나갈 것이라고 합니다. (http://social.msdn.microsoft.com/Forums/en-US/category/windowsazureplatform)
• Windows Azure Marketplace가 새로 발표되었습니다. Windows Azure Marketplace에는 향후 여러 종류의 마켓이 추가될 것이며 여기에는 데이터 뿐만 아니라 소프트웨어, 서비스, 빌딩 블럭 등 클라우드 환경 구축에 필요한 다양한 제품의 판매를 목적으로 합니다. 첫 번째 마켓으로, Codename: Dallas가 정식으로 DataMarket(https://datamarket.azure.com/)으로 데뷔합니다.

2011년 중에 발표될 예정인 업데이트들

• 동적 컨텐츠 캐시: 지금은 BLOB 저장소에서 공개 권한으로 열려있는 파일에 대한 CDN 서비스만이 가능하지만, 직접 운영하는 Windows Azure 응용프로그램에서 API를 사용하여 CDN 서비스로 게시할 컨텐츠를 직접 설정할 수 있게 됩니다.
• CDN SSL 지원: 현재는 일반적인 유형의 CDN 서비스가 제공되지만, SSL/TLS 기반의 암호화된 내용을 바탕으로 데이터를 전달하는 CDN 서비스가 추가될 예정입니다.
• CDN 노드 추가 개설: 중동 국가들을 경유하는 노드가 추가될 예정에 있으며, 현행 미국과 브라질 간 연결 속도를 더 개선할 예정입니다.
• 주문형 VM 역할 제작 서비스: VM 역할이 발표된 직후에는 온 프레미스 환경의 Windows Server 2008 R2 기반의 컴퓨터만을 Physical to Virtual (P2V) 도구를 이용하여 VM 역할로 변환이 가능하지만, 새로운 인스턴스의 생성을 관리 도구 수준에서 가능하게 할 예정입니다. 이는 기존의 가상화 기반 클라우드 서비스들이 제공하는 것과 동일한 컨셉입니다.
• 2011년 중에 VM 역할로 사용할 수 있는 서버 운영 체제로 Windows Server 2003과 Windows Server 2008 SP2가 추가될 것입니다. 발표 직후에는 Windows Server 2008 R2에만 한정됩니다.
• Java 개발자를 위한 지원 향상: 현재와 같이 Visual Studio - 또는 - Visual Web Developer에 JRE나 JDK를 같이 배포하는 방식이 아닌, Java를 직접 Windows Azure 개발 환경에 사용할 수 있도록 Eclipse용 개발 도구와 라이브러리가 향상될 것이며, 2011년 중에 이에 대한 새로운 내용이 발표될 것입니다. 이로서 Windows Azure를 이용하는 사업자는 .NET 이외에도 Java를 프로그래밍 언어로 직접 선택할 수 있습니다. Microsoft는 이러한 전략에 대하여, Java를 Windows Azure의 First Citizen으로 향상시키는 것으로 표현하고 있습니다.

출처: http://blogs.msdn.com/b/windowsazure/archive/2010/10/28/you-spoke-we-listened-and-responded.aspx

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 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 위에서 사용하기 위하여 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는 Windows Server의 검증된 기술과 성능을 바탕으로 운영되는 클라우드 컴퓨팅 플랫폼입니다. 그리고, 이러한 조건을 바탕으로, 기존에 이 블로그를 읽어주시는 독자 여러분들께서 운영하시던 ASP.NET 기반의 웹 사이트들도 Windows Azure 위에서 호스팅이 가능하도록 수정하는 것도 웹 사이트의 규모나 복잡도에 따라서 다소 차이는 있을 수 있지만 비교적 손쉽게 이식할 수 있습니다.

Windows Azure로 기존의 ASP.NET 웹 사이트를 이관하면서 생각해보아야 할 이슈 사항들을 이번 개요 Chapter에서 하나씩 살펴보도록 하겠습니다.

1. 데이터베이스에 의존하는 웹 어플리케이션의 경우

대부분의 경우, ASP.NET 웹 사이트들은 Microsoft SQL Server나 기타 다른 유형의 RDBMS와 상호작용하면서 서비스를 제공합니다. 클라우드 환경 위에서 응용프로그램을 구동하기 위해서는, 데이터베이스를 어떤 형태로 이관할 것인지 구상할 필요가 있습니다.

웹 사이트에서 필요로 하는 데이터베이스는 대체로 소규모 데이터베이스이고, 단독으로 이관이 가능한 데이터베이스이므로 SQL Azure로 이관하여 클라우드 환경에 대응이 가능한 데이터베이스로 구현을 바꾸는 것이 유리합니다.

만약, 데이터베이스 도입 비용을 줄이고, 핵심적인 데이터 조회/저장 기능만을 사용하고자 한다면, Windows Azure의 Table Storage로 저장 방식을 변경하는 작업도 고려해볼 수 있습니다. 테이블 간의 외래 키 제약 조건이나, 특수한 인덱스 설정을 이용하거나, 저장 프로시저와 같은 RDBMS 전용의 기술을 사용하지 않는 경우 클라우드 서비스 비용을 줄이는데에 도움이 될 수 있습니다.

2. 설정 파일의 수정이 빈번한 웹 어플리케이션의 경우

Windows Azure 위에 게시되는 응용프로그램은 CSPKG와 CSCFG 파일의 형태를 띕니다. CSPKG 파일은 Windows Azure 위에서 사용할 수 있도록 포장된 ZIP 형식의 패키지이며, CSCFG 파일은 Windows Azure 위에서 구동될 응용프로그램의 일반적인 설정을 포함하는 XML 문서입니다. ASP.NET 웹 사이트의 경우, 관련된 클래스 라이브러리를 포함하여 모두 CSPKG 파일 안에 포장되어 들어가게 됩니다.

기존 ASP.NET 웹 사이트를 운영하면서, web.config이나 web.config에서 branch를 만들어 별도의 XML 파일을 자주 수정하였던 경우, 이러한 방식을 그대로 사용하면 설정이 바뀔 때 마다 매번 새로운 패키지를 만들어서 업데이트해야 하는 문제가 수반됩니다. 이를 피하기 위하여, Windows Azure 런타임 어셈블리를 ASP.NET 웹 사이트 프로젝트의 참조에 추가하고, Windows Azure Application의 설정을 대신 사용하도록 구성하는 것이 유리합니다.

CSCFG 파일의 정보를 읽기 위하여 아래의 도우미 코드를 활용할 수 있습니다.

public class SettingsManager
{
   private static Settings _settings = new Settings();
   public static Settings Settings
   {
      get
      {
         return _settings;
      }
   }
}

public class Settings
{
   public string this[string key]
   {
      get
      {
         if (RoleManager.IsRoleManagerRunning)
         {
            return RoleManager.GetConfigurationSetting(key);
         }
         else if (System.Web.HttpContext.Current != null)
         {
            return WebConfigurationManager.AppSettings[key];
         }
         return string.Empty;
      }
   }
}

위의 코드를 활용하는 예시는 다음과 같습니다. RoleManager.IsRoleManagerRunning 프로퍼티를 이용하여 클라우드 위에서 실행 중인 응용프로그램인지의 여부를 결정할 수 있습니다.

if (RoleManager.IsRoleManagerRunning)
{
   // we're in the cloud
   message.Text = RoleManager.GetConfigurationSetting("messageText");
}
else if (System.Web.HttpContext.Current != null)
{
   // we're NOT in the cloud, but we're still in a Web application
   message.Text = WebConfigurationManager.AppSettings["messageText"];
}
else
{
   // not in the cloud, not in the web... desktop app maybe?
   message.Text = ConfigurationManager.AppSettings["messageText"];
}

위의 샘플 코드는 http://blogs.itmentors.com/bill/2009/11/04/configuration-files-and-windows-azure 에서 발췌하였습니다.

3. IIS의 다른 기능 (SMTP, FTP)에 관한 이슈

Windows Azure의 Web Role이 IIS를 사용하기는 하지만, 있는 그대로의 기능을 모두 제공하는 것은 아닙니다. 대표적으로 SMTP와 FTP를 사용해야 하는 웹 사이트의 경우, Windows Azure로 있는 그대로의 상태를 유지하여 이관하는것은 어려울 수 있습니다. Windows Azure에서 SMTP와 FTP를 활용하기 위해서는 Worker Role을 이용해야 하며, 더 나아가서는 Windows Azure Storage를 응용해야 할 수 있습니다.

결론

이번 Chapter에서는 ASP.NET 웹 사이트를 Windows Azure로 이관하기 위하여 고려해야 할 사항들을 살펴보았습니다. 다음 Chapter에서는 ASP.NET 웹 사이트를 Windows Azure로 이관하는 과정에서 추가하는 EntryPoint 클래스에 대한 구체적인 분석을 해보도록 하겠습니다.

감사합니다.

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

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