the_man.jpg

David Chappell의 Windows Azure Platform 강연회에 초대합니다.

 


데이비드 챠펠(David Chappell) 씨가 10월 22일(월) 저녁 7시, 한국 Microsoft 5층 WIN 세미나 룸에서 윈도우 애저(Windows Azure) 유저 그룹에서 클라우드 플랫폼에 대한 관련한 강연을 합니다.


데이비드 챠펠씨는 Chappell & Associates (http://www.davidchappell.com)의 대표로서 다양한 강연, 저술, 컨설팅을 통해 세계의 많은 IT리더들께서 새로운 기술을 잘 이해하고, 더 나은 결정을 내릴 수 있게 도와 드리고 있습니다. 데이비드는 5개 대륙에 수만명의 IT리더, 아키텍트, 개발자들이 참석하는 수백개의 회의 및 행사에서 기조 연사로 활동하고 있으며, 그의 저술은 다양한 언어로 번역 출판 되어 MIT, ETH 취리히 및 와튼스쿨 등 여러 대학의 과정에서 사용되고 있습니다. 또한 HP, IBM, Microsoft 등 IT 기업의 고객 및 파트너와 내부직원을 대상으로 IT 전반의 컨설팅을 수행하고 있으며, 스탠포드 대학 등에서의 강연 및 유수하고 다양한  IT 관련 출판물에 유명 칼럼리스트로도 활동하고 있습니다.


행사에 참석하기 희망하시는 분들께서는 온오프믹스 행사 홈 페이지 (http://onoffmix.com/event/9962) 에서 접수하여 주시기 바랍니다.


서울 행사 접수하러 가기


ps. 서울에서 진행되는 행사 이외에 기타 예정되어있는 각 국가별/도시별 세미나 일정은 다음과 같습니다. (아래 시간은 미국 시간 기준입니다.)




  • 10월 25일: 싱가폴



  • 10월 29일: 바르샤바 (Microsoft Technology Summit)



  • 10월 30일 ~ 31일: 프라하



  • 11월 5일 ~ 6일: 파리



  • 11월 8일: 런던



  • 11월 9일: 뮌헨



  • 11월 13일: 토론토



  • 11월 15일: 뉴욕


 

AppFabric 브랜드 네임의 전면적인 수정

최근 개편된 Windows Azure 웹 사이트에서 한 가지 재미있는 내용을 발견하였는데, 이전에는 Windows Azure AppFabric의 일부로 Service Bus, Access Control가 제공되는 것으로 언급되었지만 이번에는 Windows Azure라는 단일 브랜드의 서비스 구성 요소로 통합되었습니다. 이를 두고 여러 가지 이야기가 있었지만 결론은 Windows Azure Platform 아래에 모든 서비스를 하나로 통합시키겠다는 의도 아래에 이루어진 정리 작업이었습니다.

개편된 웹 사이트: http://www.windowsazure.com/en-us/home/tour/overview/

서비스 브랜드 네임의 조정이 있었지만 서비스 다운 타임이 생겼다던지 혹은 다른 문제점이 있었던 것은 전혀 아닙니다. 하지만 앞으로는 Azure AppFabric와 Server AppFabric을 혼동할 이유가 없을 것입니다. Azure AppFabric의 구성 요소들은 모두 Windows Azure Platform의 서비스들이고, Server AppFabric의 구성 요소들은 지금까지와 마찬가지로 독립적인 노선을 유지하게 될 것 같습니다.

IC116419.gif

ASP.NET과 IIS 7을 위한 로드 밸런싱 전략과 기초적인 이야기, 그리고 Azure Platform

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


cfile23.uf.127986354E6E12A427F866.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를 구축해보는 것도 의미가 있을 것입니다.

banner.png

Windows Azure Cafe Boot Camp #2

행사 등록: http://onoffmix.com/event/3146


Windows Azure Cafe Boot Camp #2

 
Windows Azure Cafe (http://cafe.naver.com/wazure)에서는 지난해에 이어 올해부터는 매월 다양한 주제를 통하여 개발자, IT 전문가들에게 Windows Azure 기반의 실전 개발에 대한 이야기를 전할 수 있또록 Boot Camp 세미나를 준비하였습니다. 클라우드 컴퓨팅에 관심이 있는 분들을 모시고, 세미나 전/후로는 클라우드 컴퓨팅과 최신 기술 동향에 대한 자유로운 토론도 같이 진행할 수 있도록 하겠습니다.
 
제목: 기존 소프트웨어에서 Windows Azure를 활용하는 방법
일시: 2011년 7월 2일 토요일 / 오후 2시
장소: 포스코센터 서관 5층 한국 마이크로소프트 GROW룸
대상: 소프트웨어, 웹 개발자
 
세션 소개
 
(1) Windows Azure Storage 활용 전략
Windows Azure Storage는 익히 알려진대로 세 가지의 대표적인 저장소 (테이블, BLOB, 큐)를 이용하여 개발할 수 있는 것이 특징입니다. 그러나 이들 저장소는 우리가 기존에 알고 있던 파일 시스템이나 관계형 데이터베이스와는 전혀 다른 시스템들입니다. 이러한 시스템들을 어떻게 효과적으로 사용할 수 있는지에 대해 알아보도록 하겠습니다.
- Windows Azure Storage 및 주요 기능 소개
- Storage를 중심으로 활용하는 몇 가지 유용한 모델에 대한 소개
 
(2) .NET 클라이언트 및 웹 개발자들을 위한 활용 전략
Windows Azure Storage를 .NET 클라이언트 개발 환경에서는 어떻게 활용할 수 있는지 클라이언트 및 웹 개발자들의 관점에서 유용한 정보를 알려드리도록 하겠습니다.
- Windows Azure Storage 라이브러리를 활용하는 방법
- 관계형 데이터베이스가 아니라는 것이 끼칠수 있는 문제점들
- LINQ to Table Storage에 대한 몇 가지 이슈
 
아젠다
14:00 ~ 14:50 (1) Windows Azure Storage 활용 전략
14:50 ~ 15:00 휴식
15:00 ~ 15:50 (2) .NET 클라이언트 및 웹 개발자들을 위한 활용 전략
15:50 ~ 16:00 질문/답변
 
시간, 장소, 날짜
일시: 2011년 6월 25일 토요일 / 오후 2시
장소: 포스코센터 서관 5층 한국 마이크로소프트 (ROOM은 추후 확정 후 다시 공지하겠습니다.)
 
알립니다: 본 세미나는 커뮤니티가 주최하는 비영리 세미나이며, 주차권은 별도로 제공되지 않으니 가급적 대중 교통을 이용하여 주시면 감사하겠습니다.

Windows Azure Platform Training Kit 2010년 12월 버전 출시!

Windows Azure Platform Training Kit의 2010년 12월 버전이 새로 출시되었습니다. 다운로드는 카페 대문에 걸려있는 링크 – 또는 - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=413E88F8-5966-4A83-B309-53B7B77EDF78&amp;displaylang=en 에서 다운로드하실 수 있습니다.


[Updated] All demos were updated to the Azure SDK 1.3 / 모든 DEMO들이 SDK 1.3 버전에 맞추어졌습니다.

  • [New demo script] Deploying and Managing SQL Azure Databases with Visual Studio 2010 Data-tier Applications / Visual Studio 2010 데이터 계층 응용프로그램에서 SQL Azure 데이터베이스를 배포하고 관리하는 프레젠테이션이 추가 되었습니다.

  • [New presentation] Identity and Access Control in the Cloud / 클라우드 환경에서의 아이덴티티와 액세스 제어에 관한 프레젠테이션이 추가되었습니다.

  • [New presentation] Introduction to SQL Azure Reporting / SQL Azure 레포팅에 대한 프레젠테이션이 추가되었습니다.

  • [New presentation] Advanced SQL Azure / SQL Azure의 고급 기능 및 상세 정보에 대한 프레젠테이션이 추가되었습니다.

  • [New presentation] Windows Azure Marketplace DataMarket / 이전 버전인 Codename: Dallas의 정식 버전인 Windows Azure Marketplace DataMarket에 대한 프레젠테이션이 추가되었습니다.

  • [New presentation] Managing, Debugging, and Monitoring Windows Azure: Windows Azure 응용프로그램을 관리, 디버깅, 모니터링하는 방법을 소개하는 프레젠테이션이 추가되었습니다.

  • [New presentation] Building Low Latency Web Applications: 빠른 응답 속도를 구현하기 위하여 웹 응용프로그램에서 취해야 할 가이드라인을 소개하는 프레젠테이션이 추가되었습니다.

  • [New presentation] Windows Azure AppFabric Service Bus: AppFabric Service Bus에 대한 새 프레젠테이션이 추가되었습니다.

  • [New presentation] Windows Azure Connect: 이전 버전인 Codename: Sydney의 정식 버전인 Windows Azure Connect에 대한 새 프레젠테이션이 추가되었습니다.

  • [New presentation] Moving Applications to the Cloud with VM Role: 기존의 응용프로그램을 VM Role 환경으로 이식하는 방법에 대한 새 프레젠테이션이 추가되었습니다.

이 내용들 중 VM Role에 관한 것은 이전에 제가 같이 게시하였던 VM Role 관련 Step-by-step 문서와 더불어서 보실 것을 권합니다. 감사합니다. :-)

Windows Azure SDK 1.3 발표


PDC 2010에서 언급된 대로 이번 Windows Azure 업데이트에는 많은 수의 업그레이드가 있었습니다. 이러한 업그레이드들의 공통적인 목표는 단 한가지, 좀 더 높은 수준의 서비스를 좀 더 손쉽고 빠르게 개발할 수 있도록 개발자들을 지원하기 위함이었습니다. 그리고 12월 1일, 드디어 새 버전의 SDK와 함께 윈도 애저 서비스 포털이 새 단장을 합니다.


새 버전의 Windows Azure SDK의 버전은 1.3이며, Windows Azure Management Portal은 이제 정식으로 사용할 수 있도록 서비스됩니다. 다음은 Windows Azure SDK 버전 1.3에서 바뀐 사항들을 정리한 것입니다.



  • 권한 상승과 전체 IIS 기능 사용을 통하여 좀 더 완성도 높은 응용프로그램의 개발이 가능하게 됩니다. 이제 웹 역할과 작업자 역할에서 관리자 권한을 이용한 실행을 지원하므로 고유한 소프트웨어의 설치가 가능하게 되었고, 특히 웹 역할의 경우 IIS 전체 기능을 지원하도록 개선되어 IIS 7 전용 모듈을 설치하는 등의 작업이 가능하게 되었습니다.

  • 원격 데스크톱 기능을 켜고 끌 수 있도록 웹 역할이나 작업자 역할의 출판 속성이 추가되었습니다. 이에 대한 자세한 내용은 제 블로그의 글 ([Software Development/Windows Azure] – Windows Azure 인스턴스를 원격 제어하기)을 참조하십시오.

  • 윈도 서버 2008 R2 기반의 역할 지원: Windows Azure는 이제 Windows Server 2008 R2를 OS로 사용할 수 있도록 웹 역할, 작업자 역할, 그리고 가상 머신 역할이 개선되었습니다. 여기에는 IIS 7.5, AppLocker를 비롯하여 고급 명령줄 도구와 PowerShell 버전 2.0과 같은 자동화 기능까지 지원되며, 이전에 제 블로그 글 ([Software Development/Windows Azure] – 이제 UNIX 기반 프로그램도 Windows Azure의 First Citizen이 됩니다.)에서 언급했던 것과 마찬가지로 SUA 등의 리소스를 사용하여 UNIX, LINUX, POSIX 기반 응용프로그램을 윈도 애저 플랫폼으로 이식하는 작업도 가능하게 됩니다.

  • 다중 서비스 관리자 지원: 이제 Windows Azure는 다수의 윈도 라이브 ID를 관리자로 인정하여 서비스에 대한 제어를 수행할 수 있도록 기능이 개선되었습니다. 팀 단위 작업에 대한 지원을 고려하여 추가된 기능으로 더 효율적이고 편리한 작업을 수행할 수 있습니다. 특히 이 기능은 작업 시간대가 서로 다르고 위치가 떨어져있는 팀원들 사이에 관리 작업을 공유할 때 매우 효율적입니다.

  • 실버라이트 기반의 Windows Azure Portal 런칭: 기존의 AJAX 기반 Windows Azure Portal보다 더 사용하기 쉽고 빠르며, 새로운 기능들에 대한 완벽한 인터페이스를 제공하는 실버라이트 UI를 Windows Azure Portal에서 사용할 수 있습니다.

  • 향상된 진단 정보: 1차원적인 진단 정보가 아닌 좀 더 상세한 진단 정보를 통하여 관리하는 역할 인스턴스들의 종류, 배포된 시간, 마지막으로 다시 부팅한 시간등을 확인할 수 있습니다.

  • 새로운 회원 가입 프로세스: 이전보다 더욱 편리하고 쉽게 Windows Azure 서비스에 가입하여 곧바로 클라우드 컴퓨팅 서비스를 이용할 수 있게 됩니다.

  • 시나리오 기반의 Windows Azure Platform 포럼 런칭: 상황 별 대처 방안에 따라 빠르게 답을 구할 수 있는 Windows Azure Platform 포럼이 런칭됩니다. (http://social.msdn.microsoft.com/Forums/en-US/category/windowsazureplatform)

다음의 기능들은 베타 버전으로 제공됩니다.



  • Windows Azure 가상 머신 역할: 새로운 – 또는 – 기존의 윈도 서버 기반 응용프로그램을 VM Role을 이용하여 손쉽게 클라우드로 이관할 수 있습니다. 이에 대한 자세한 정보는 http://www.microsoft.com/windowsazure/compute/#vmrole 의 내용을 참조하십시오.

  • 극소형 인스턴스 레벨: 런타임 시간당 0.05$, 원화로 환산하면 한달 약 4~5만원 선으로 새로운 Windows Azure Platform의 기능을 경험해볼 수 있습니다. 극소형 인스턴스를 통하여 여러분이 원하는 클라우드 솔루션을 비용 걱정없이 자유롭게 테스트하며 개발할 수 있습니다. 자세한 내용은 http://www.microsoft.com/windowsazure/compute/#computeinstancesize 의 내용을 참조하십시오.

이제 개발자와 IT 전문가들은 Windows Azure Management Portal을 통하여 다음의 베타 서비스에 액세스할 수 있습니다.



  • Windows Azure 마켓플레이스: Windows Azure 마켓플레이스는 여러분의 빌딩 블록 구성 요소를 공유하거나, 판매하거나, 구입할 수 있도록 도우며, 고급 데이터를 거래할 수 있도록 도와주는 온라인 마켓플레이스입니다. 현재는 DataMarket (구 Codename: Dallas)이 런칭된 상태이며, 이번에는 Application Market Section이 오픈되었습니다. 40개 파트너사와 50여개의 응용프로그램과 서비스가 현재 게시되어있습니다.

다음의 기능은 CTP (Community Technology Preview)로 제공됩니다.



  • Windows Azure Connect (구 Project Sydney): 더욱 단순하고 관리하기 쉬운, 클라우드와 온 프레미스 사이의 IP 기반의 네트워크를 형성할 수 있도록 도움을 주는 서비스가 CTP로 런칭되었습니다. 현재는 별도의 비용을 받지 않는 CTP 버전으로 제공되며 Windows Azure Management Portal을 통하여 서비스를 신청하고 미리 테스트해보실 수 있습니다.

미국 시간 기준으로 2010년 12월 1일 오전 9시 (한국 시간은 2010년 12월 2일 오전 2시)에 Windows Azure Management Portal을 통하여 Overview 웹 캐스트 (http://go.microsoft.com/fwlink/?LinkID=207019)가 게시될 예정이니 관심있으신 분들께서는 꼭 살펴보시기 바랍니다. :-)


PDC10에서 발표된 Windows Azure 업데이트들을 다시 보시려면 http://www.microsoft.com/windowsazure/pdcannouncements/ 의 내용도 같이 확인하십시오.


출처: http://blogs.msdn.com/b/windowsazure/archive/2010/11/29/just-released-windows-azure-sdk-1-3-and-the-new-windows-azure-management-portal.aspx

Windows Live 2011의 새로운 기능: 향상된 Photo Gallery

요즈음 개그콘서트에서 한창 인기를 누리고 있는 “남하당 여당당”의 두 주인공이 직접 촬영한 Windows 7 Personal Cloud Life 캠페인 동영상, 보셨나요? 이 글을 쓰고 있는 현 시점에서 두 편의 동영상이 선 공개되었고 조만간 새로운 동영상들이 유익한 내용과 함께 여러분을 찾아가게 될 예정입니다. 나른하고 졸린 식곤증을 재미있는 개그 동영상과 함께, 그리고 유익한 정보를 함께 배우며 재미있게 보내보신다면 좋겠습니다. :-D


캠페인 홈페이지에서 이벤트 응모도 가능합니다. http://www.win7pc.co.kr/ 를 방문하시면 됩니다. :-)

2010 대한민국 SW 개발자 컨퍼런스


이번주 토요일 오전 9시 30분부터 오후 5시 30분까지, 2010 대한민국 SW 개발자 컨퍼런스가 열립니다. 이번 컨퍼런스에서는 “개발자가 꼭 알아야 할 4대 IT 트렌드, 기술 이슈 및 미래 전망”이라는 주제로 모바일, 클라우드, 소셜, 웹에 대한 내용을 다루게 됩니다. 좋은 내용들이 많이 다루어질 예정이니 많은 관심과 참여 부탁드립니다. 유료 세미나입니다.





















company_img_3.jpg

Amazon Elastic Cloud 기반 Social App – LinkupWith 런칭!

오늘 오전 10시부터 네이트 앱 스토어에서 Amazon Elastic Cloud 기반 Social App을 런칭하였습니다. 주식회사 SHESTORY의 서비스이며, QR 코드에 독창적인 컨텐츠를 부여하고 자신의 메시지를 남들에게 전달하거나 공유하고, 댓글 등을 통하여 의견을 받을 수도 있는 LinkupWith라는 App이며, Microsoft Silverlight 4를 사용하였고, 조만간 iPhone과 Android용 전용 QR Code Reader Application이 추가 공개될 예정입니다.



위의 이미지는 Silverlight 기반 Client UI로 주요 실행 화면들을 스크린 샷으로 촬영한 것입니다. App의 자세한 사용법은 http://club.cyworld.com/5451477817/43245835 에서 소개하고 있습니다. 이번에 사용한 클라우드 플랫폼은 Amazon EC2로, Windows Server 2008 x86 및 IIS 7에서 ASP.NET과 WCF를 사용하여 구현된 서비스입니다.


서비스 체험 바로가기: http://bit.ly/aOBxEI

110510_1637_WindowsAzur2.png

Windows Azure 인스턴스를 원격 제어하기

알립니다: 이 블로그 게시물에서 설명하는 내용은 아직 출시되지 않은 제품과 서비스에 대한 내용을 다루는 것으로, 실제 사용 가능한 시점까지는 더 많은 기간이 소요될 수 있으나 정보 공유 차원에서 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 입니다.