요즈음 클라우드 서비스들을 이용하다보면, 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를 구축해보는 것도 의미가 있을 것입니다.

'Cloud' 카테고리의 다른 글

SQL Azure Data Sync (3) – 고려사항  (0) 2011.09.22
SQL Azure Data Sync (2) – Sync Group  (0) 2011.09.16
SQL Azure Data Sync (1) – 소개와 Agents 구성  (0) 2011.09.09
SQL Azure Sharding 소개  (0) 2011.09.08
SQL Azure Reporting (3)  (1) 2011.08.25

Hello Windows Azure / Twitter 스타일 방명록 만들기 #1

Cloud 2010. 7. 27. 09:00 Posted by 알 수 없는 사용자

꼭 읽어주세요: 이 글이 작성된 현 시점에 가장 최신 버전의 Azure Tools는 버전 1.2입니다. 이 강좌를 시작하시기 전에 Windows Azure Tools for Visual Studio를 1.2 버전으로 업그레이드하여 주십시오. 이전 버전을 설치하신 경우에는 SDK와 Tools를 모두 완전히 제거한 후 1.2 버전으로 새로 설치하여 주십시오. Windows Azure Tools for Visual Studio 1.2 한글판 다운로드는 http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=2274a0a8-5d37-4eac-b50a-e197dc340f6f 에서 가능합니다.

지난번 글 (2010/06/07 - [Cloud Development] - Hello Windows Azure / Understanding Windows Azure Development Process)에 이어서, 오늘부터는 Twitter 스타일 방명록 만들기 첫 번째 시간입니다. 이번 시간에는 Windows Azure 프로젝트를 만들고, 데이터 모델을 작성하고 파악하는 것을 실습 목표로 정의하고자 합니다.

빠르고 편리한 실습을 위하여, Visual Web Developer 2010 Express를 사용하여 실습하는 것을 기준으로 하겠습니다. Visual Studio 2010이 이미 설치되어있으신 경우 이를 이용하셔도 됩니다. 어떤 개발 도구를 사용하더라도 반드시 Windows Azure Tools for Visual Studio가 설치되어있어야 하며 설치 방법은 2010/06/03 - [Cloud Development] - Hello Windows Azure / Windows Azure 개발 환경의 구축 에서 소개하는 내용에 따라 완료하여 주시기 바랍니다.

개발 도구 시작하기 및 프로젝트 생성하기

1. Visual Web Developer 2010 Express (또는 Visual Studio 2010)를 권한 상승 시킨 상태에서 시작하도록 합니다. 아래의 그림을 참고하세요. 사용자 계정 컨트롤을 사용하고 있을 경우 별도의 경고 대화 상자가 나타날 수 있으며 실행하도록 선택하시면 됩니다.

2. Visual Web Developer 2010 Express가 실행되면 초기 화면에서 새 프로젝트 만들기 링크를 클릭합니다.

3. 아래에 표시된 대화 상자에서 왼쪽의 개발 범주를 Cloud로 선택하면 사용 가능한 프로젝트 템플릿 중에서 "Windows Azure 클라우드 서비스"가 나타납니다. 이 항목을 클릭하고, 프로젝트 이름을 원하는 이름 (여기서는 TwistBook이라고 하겠습니다.)을 지정한 후, "솔루션용 디렉터리 만들기"에 체크하고 "확인" 버튼을 클릭합니다.

특별히 솔루션용 디렉터리 만들기에 체크가 되어있는지를 확인하는 이유는, 이 옵션이 Windows Azure Tools로 생성되는 프로젝트의 특성 상 한 솔루션 안에 다수의 프로젝트가 만들어지기 때문에 이를 정확하게 분류하기 위하여 사용하는 옵션으로, 사용하도록 맞추어져있을 때 좀 더 소스 코드 관리가 편리하기 때문입니다.

4. 배포할 Windows Azure 응용프로그램 내에 배치될 Role의 종류와 유형을 설정하는 추가 프로젝트 마법사가 아래와 같이 나타납니다. (만약 아래 화면 대신 HTML 페이지로 안내 페이지가 나타나는 경우 Azure Tools가 올바르게 설치되지 않은 상태입니다.)

5. .NET Framework 4 역할 그룹과 클라우드 서비스 솔루션 그룹 사이의 두 개의 버튼을 이용하여 실제로 제작할 프로젝트의 유형을 설정하고 프로젝트의 이름까지 정할 수 있습니다. 우선 ASP.NET MVC 2 웹 역할 프로젝트 한 개와 작업자 역할 프로젝트 한 개를 추가하겠습니다.

6. 이제 각 프로젝트의 정확한 이름을 설정하기 위하여, 클라우드 서비스 솔루션 그룹 안에 추가된 프로젝트 중 MvcWebRole1 프로젝트 항목을 선택하면 연필 모양의 아이콘이 이름 옆에 나타납니다. 이를 클릭하면 아래와 같이 이름을 바꿀 수 있도록 편집 영역이 나타납니다. 이 예제에서는 다음과 같이 이름을 정하였습니다.

- MvcWebRole1 => TwistBook.WebRole
- WorkerRole1 => TwistBook.LinkProcessor

이름을 편집하고 나면 아래와 같은 화면이 되어있을 것입니다. 확인 버튼을 눌러 프로젝트를 생성합니다.

7. 프로젝트의 생성을 진행하다보면 Visual Studio 2010 Professional 이상의 버전에서는 다른 ASP.NET MVC 2 프로젝트와 마찬가지로 테스트 프로젝트를 만들것인지를 물어보는 대화 상자가 나타납니다. 빠른 설명과 간결한 진행을 위하여 테스트 프로젝트를 생성하지 않는 방향으로 이 예제에서는 진행하도록 하겠습니다. (필요하신 분들께서는 생성하셔도 됩니다.) Visual Web Developer 2010 Express Edition에서는 이러한 대화 상자가 따로 나타나지 않습니다.

8. 프로젝트 생성이 끝나면 아래와 같이 솔루션 탐색기에 총 3개의 프로젝트가 열거됩니다.

TwistBook 프로젝트는 Cloud Application 전체를 총괄하는 프로젝트이며, Cloud 환경에서 하나의 Application으로 분류됩니다. 이 프로젝트 안에 Web Role과 Worker Role이 다수 연결되는 구조로 되어있으며, 나중에 Cloud Service Package 파일 (CSPKG)로 컴파일될 때 이 프로젝트가 기준이 됩니다.

TwistBook.WebRole 프로젝트는 ASP.NET MVC 2를 사용하도록 프로젝트가 구성되어있으며 여기에 기본적인 트위터 스타일의 방명록 UI를 표시하거나 인증된 사용자로부터 메시지를 입력받아 Worker Role에게 처리를 위임하는 등의 작업을 수행하도록 코드를 구성할 것입니다.

그리고 TwistBook.LinkProcessor 프로젝트는 Web Role과는 따로 실행되는 개별적인 Role 인스턴스로서, Web Role에서 받아들이는 메시지 중 이미지 파일을 twitpic.com에 게시하여 짧은 URL을 받아온다거나, 본문에 있는 긴 URL을 짧게 만들어 받아오는것과 같이 처리량이 많이 몰렸을 경우 병목 현상을 일으킬 수 있는 기능만을 전담하도록 코드를 구성할 것입니다.

자료 구조 만들기

1. 클라우드 환경 내부 및 외부에서 기준이 될 모델 자료 구조를 만들기 위하여, 별도의 클래스 라이브러리를 작성하도록 하겠습니다. 솔루션 탐색기에서 솔루션 항목을 오른쪽 버튼으로 클릭하고 아래 그림처럼 새 프로젝트 추가 메뉴를 클릭합니다.

2. 일반적인 클래스 라이브러리 프로젝트를 하나 만듭니다. 이름은 TwistBook.DataModel로 지정하고, Cloud 환경 위에서 사용하도록 현재 지정된 .NET Framework 4와 동일한 빌드 타겟이 지정되어있는지 확인한 후 프로젝트를 생성합니다.

3. TwistBook.DataModel 프로젝트에 Windows Azure Table Storage에서 사용할 Data Context 클래스를 만들도록 하겠습니다. [각주:1]

Data Context 클래스를 만들기 위해서는 Windows Azure SDK에서 제공하는 클래스 라이브러리 파일들을 TwistBook.DataModel 프로젝트 참조에 포함시켜야 합니다. 아래 그림과 같이 솔루션 탐색기에서 TwistBook.DataModel 프로젝트 아래의 참조 항목을 오른쪽 버튼으로 클릭하고 "참조 추가" 메뉴를 클릭합니다.

4. 참조 추가 대화 상자가 나타나면, .NET 탭을 클릭합니다. 이 과정에서 비동기적으로 Visual Studio가 관리하는 디렉터리 목록 내에 있는 모든 어셈블리들을 조사하여 실시간으로 리스트 박스에 추가합니다. 이 샘플에서 필요로 하는 SDK의 라이브러리가 목록에 나타나기까지 조금 시간이 걸릴 수 있으며 시스템마다 차이가 있을 수 있지만 약 1분 이내에 나타납니다.

5. 나타난 항목들 중에서 다음의 항목들을 찾아 키보드의 Ctrl 키를 누른채로 하나씩 클릭하면, 아래 그림과 같이 여러 대상을 선택하고 참조로 추가할 수 있습니다.

* System.Data.Services.Client
* Microsoft.WindowsAzure.StorageClient

6. 아래 그림과 같이 참조 목록이 구성되어있으면 준비가 다 된것입니다. 이제 본격적으로 코드 작성을 시작해 보도록 하겠습니다. :-)

7. 기본으로 만들어진 클래스가 담겨있는 Class1.cs 파일의 내용을 아래와 같이 작성합니다. 코드에서 핵심이 되는 부분을 굵게 표시하였습니다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.WindowsAzure.StorageClient; [각주:2]

namespace TwistBook.DataModel
{
    public class TwistModel : TableServiceEntity [각주:3]
    {
        public TwistModel()
        {
            DateTime current = DateTime.Now;
            PartitionKey = current.ToString("yyyyMMdd");
            RowKey = current.ToString("hhmmss"); [각주:4]

        }

        public string WriterName { get; set; }
        public string MessageBody { get; set; }
        public DateTime WrittenDate { get; set; }
        public string ImageUrl { get; set; } [각주:5]
    }
}

8. Class1.cs 파일의 이름을 클래스 이름과 동일하게 설정합니다. Windows 탐색기를 열지 않고, 아래의 그림에서처럼 솔루션 탐색기에서 직접 이름을 바꿀 수 있으며, Class1.cs 파일을 TwistModel.cs 파일로 이름을 변경합니다.

9. TwistBook.DataModel 프로젝트에 Windows Azure Table Storage에서 사용할 Data Context 클래스를 만들도록 하겠습니다. 새 항목을 프로젝트에 추가하기 위하여 아래 그림과 같이 솔루션 탐색기에서 TwistBook.DataModel 프로젝트 항목을 오른쪽 버튼으로 클릭하면 "추가" - "새 항목 추가" 메뉴가 나타나는데 이를 클릭하시면 됩니다.

10. 새 항목 추가 대화 상자에서 설치된 템플릿 영역에서 "Visual C# 템플릿"을 선택하고, 우측 목록에서 "클래스"를 선택합니다. 그리고 이름에 새로 추가할 클래스의 이름을 지정한 후 "추가" 버튼을 클릭합니다. 9단계와 10단계를 거쳐서 다음의 파일들을 추가로 생성합니다.

* TwistDataServiceContext.cs
* TwistDataSource.cs

11. 솔루션 탐색기 내의 TwistBook.DataModel 프로젝트 항목 아래에 다음 그림과 같이 구성이 되어있으면 정상적으로 추가가 된 것입니다.

12. 이제 TwistDataServiceContext.cs 파일을 열어서 다음과 같이 코드를 작성합니다. 코드에서 중요한 부분은 굵은 글씨로 표현하였고 여기에 따른 부가적인 설명을 각주로 붙였습니다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient; [각주:6]

namespace TwistBook.DataModel
{
    internal class TwistDataServiceContext : TableServiceContext [각주:7]
    {
        internal TwistDataServiceContext(CloudStorageAccount account)
            : base(account.TableEndpoint.AbsoluteUri, account.Credentials) [각주:8]
        {
        }

        internal const string TwistModelName = "TwistModel";

        public IQueryable<TwistModel> TwistModel [각주:9]
        {
            get { return this.CreateQuery<TwistModel>(TwistModelName); } [각주:10]
        }

    }
}

13. 이어서 TwistDataSource.cs 파일을 열어서 다음과 같이 코드를 작성합니다. 코드에서 중요한 부분은 굵은 글씨로 표현하였고 이에 따른 부가적인 설명을 각주로 붙였습니다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.WindowsAzure;
using System.Data.Services.Client;
using Microsoft.WindowsAzure.StorageClient; [각주:11]

namespace TwistBook.DataModel
{
    public class TwistDataSource
    {
        private static CloudStorageAccount storageAccount;
        private TwistDataServiceContext serviceContext;

        static TwistDataSource()
        {
            // 중요: 실제로 응용프로그램을 Cloud 환경에 배포할 때에는
            // Cloud Project 내의 다른 환경 설정 문자열을 이용하도록
            // 호출을 변경해야 합니다.
           storageAccount = CloudStorageAccount.DevelopmentStorageAccount; [각주:12]

           CloudTableClient.CreateTablesFromModel(
                typeof(TwistDataServiceContext),
                storageAccount.TableEndpoint.AbsoluteUri,
                storageAccount.Credentials); [각주:13]

        }

        public TwistDataSource()
        {
            this.serviceContext = new TwistDataServiceContext(storageAccount); [각주:14]
            this.serviceContext.RetryPolicy = RetryPolicies.Retry(
                3, TimeSpan.FromSeconds(1)); [각주:15]

        }

        public DataServiceResponse Insert(TwistModel model)
        {
            this.serviceContext.AddObject(
                TwistDataServiceContext.TwistModelName,
                model); [각주:16]

            return this.serviceContext.SaveChanges(); [각주:17]
        }

        public IEnumerable<TwistModel> Select()
        {
            var results = from eachTwist in this.serviceContext.TwistTable
                          select eachTwist; [각주:18]

            var query = new CloudTableQuery<TwistModel>(
                results as DataServiceQuery<TwistModel>,
                RetryPolicies.Retry(3, TimeSpan.FromSeconds(1))); [각주:19]

            return query.Execute(); [각주:20]
        }

        public DataServiceResponse Delete(TwistModel model)
        {
            this.serviceContext.AttachTo(
                TwistDataServiceContext.TwistModelName,
                model, "*"); [각주:21]

            this.serviceContext.DeleteObject(model);
            return this.serviceContext.SaveChanges();
        }
    }
}

Preface: ASP.NET MVC 2 Web Role에 대한 이해

다음 Article의 내용을 올리기 전에, ASP.NET MVC 2에 대한 이해를 돕기 위하여 간단한 단락 하나를 구성하였습니다. ASP.NET MVC 2는 Microsoft의 최신 웹 기술이 적용된 프레임워크로 Windows Azure 개발 환경에서 뿐만 아니라 일반적인 웹 사이트 개발에도 얼마든지 활용될 수 있는 유용한 프레임워크입니다.

TwistBook.WebRole 프로젝트의 노드를 솔루션 탐색기에서 살펴보면 아래와 같은 구성이 나타납니다. 이 구성은 전형적인 ASP.NET MVC 응용프로그램이며, 고전적인 웹 프로그래밍 모델에서와는 달리 직접 aspx 페이지를 부르지 않고 알기 쉬운 주소를 기반으로하는 것이 특징입니다. ASP.NET MVC 응용프로그램을 처음 접하시는 분들을 위하여 디렉터리 구조에 대한 설명을 잠시 말씀드립니다.

App_Data: ASP.NET 응용프로그램이 데이터베이스에 연결하기 위하여 필요한 각종 코드 및 데이터베이스 연결 설정 파일들을 보관하는 디렉터리이며, ASP.NET 2.0부터 존재해왔던 디렉터리입니다. 예외적으로 이 디렉터리에는 Microsoft Access 파일 (*.mdb 또는 *.accdb)이나 소규모 웹 사이트를 위한 Embedding 가능한 SQL 데이터베이스 파일 (*.mdf 및 *.ldf)이 배치되기도 합니다.

Content: ASP.NET MVC 응용프로그램 전반에 걸쳐서 사용되는 공통적인 클라이언트측 구성 요소 (가령 CSS 스타일 시트, XSLT 스타일 시트, 이미지 파일, 오디오 파일 등)가 이 디렉터리에 저장됩니다. 이 디렉터리에 저장된 파일들은 중간 처리기에 의하여 해석되지 않는 고유한 경로를 유지할 수 있습니다.

[중요] Controllers: ASP.NET MVC 응용프로그램에서 "C"를 대표하는 구성 요소가 저장되는 디렉터리이며 백그라운드에서 웹 페이지를 그리거나, 웹 브라우저로부터 받아온 정보를 해석하거나, 가공하거나, 처리하는 제어 코드를 이곳에 배치합니다.

[중요] Models: ASP.NET MVC 응용프로그램에서 "M"을 대표하는 구성 요소가 저장되는 디렉터리이며 주로 Controller 간의 통신, 데이터베이스와의 통신, 클라이언트로의 통신 등에서 기본 단위가 되는 데이터나 모델을 표현하는 클래스 코드를 이곳에 배치합니다. 이곳에 배치되는 코드에는 로직이 포함되지 않는 것을 원칙으로하며, 이곳에 배치되는 클래스들의 성격을 일반적으로는 POCO [각주:22] - 또는 - PONO [각주:23] (http://en.wikipedia.org/wiki/Plain_Old_CLR_Object)로 이해하면 쉽습니다.

Scripts: Content 디렉터리와 유사한 성격의 디렉터리이지만 특별히 JavaScript 라이브러리들을 위하여 할당된 디렉터리로, ASP.NET MVC 2는 오픈 소스 기반의 JavaScript Framework인 jQuery를 기본으로 제공합니다. 만약 jQuery Plugin을 개발하였거나 사용하고자 하는 다른 Plugin이 있을 경우 - 또는 - jQuery 이외의 다른 JavaScript 라이브러리 (예: 네이버 jindo, script.aculo.us, Moo Tools, Google Web Toolkit, extJS, Dojo Toolkit, prototype, Yahoo! UI 등)를 이곳에 추가하면 됩니다.

[중요] Views: ASP.NET MVC 응용프로그램에서 "V"를 대표하는 구성 요소가 저장되는 디렉터리이며 주로 Controller에 어떤 데이터를 전달할 것인지를 사용자에게 대화형으로 묻거나, Controller에 의하여 발생한 출력 결과를 사용자에게 대화형으로 전달할 때 사용하는 컨텐츠 파일들이 여기에 저장됩니다. ASP.NET MVC 2에서는 Web Forms와 Script Tag Expression을 기반으로 하는 뷰 엔진을 기초로 합니다. [각주:24]

[중요] Global.asax: ASP.NET MVC에서 매우 중요한 구성 요소로 지금 작업하는 ASP.NET 응용프로그램이 ASP.NET MVC 엔진에 의하여 처리되어야 함을 지정하고 초기 설정을 구성하는 코드가 여기에 포함되어있습니다. 이 파일이 누락되거나 내용이 잘못되어있을 경우 ASP.NET MVC 응용프로그램으로서 동작하지 않음을 유의해야 합니다. 추가적으로 사이트 내에 다른 영역을 구성하거나, 다른 주소 패턴을 확장해야 할 경우에도 이 파일에 내용을 추가해야 설정이 적용됩니다.

[중요] Web.config: ASP.NET 응용프로그램의 환경 설정 파일로 역시 이 파일의 내용에 문제가 있거나 누락되어있을 경우 ASP.NET MVC 응용프로그램이 올바르게 동작하지 않을 수 있음을 주의해야 합니다.

[중요] WebRole.cs: ASP.NET 응용프로그램과는 무관하나, Windows Azure 환경에서 Web Role이 초기에 기동될 때 필요한 설정을 포함하고 있으며, 클라우드 컴퓨팅 환경에서의 실질적인 진입점이 됩니다. 이 클래스가 없을 경우 응용프로그램 실행에 문제가 있을 수 있습니다.

다음 시간에는

다음 시간에는 ASP.NET MVC 2 기반의 Web Role을 작성하고, 테이블 스토리지에서 실제로 데이터를 조회하거나 추가, 변경, 삭제하는 예시를 들어보도록 하겠습니다. 긴 강좌 읽어주셔서 감사하며, 즐거운 여름 휴가 되십시오. 감사합니다. :-)

강좌에 대한 고칠 부분, 의견, 제안 등은 남정현의 클라우드 & 닷넷 블로그 (http://www.rkttu.com/), 트위터 (@rkttu), 전자 메일 (rkttu nospam rkttu dot com)을 통하여 항상 받고 있습니다. 언제든 의견 주시면 감사하겠습니다. :-)

  1. 이 샘플에서 Windows Azure Storage를 이용하는 방향으로 설명이 되어있지만, 실제로 여러분이 개발할 Windows Azure 서비스에서는 SQL Azure나 다른 곳에 배치되어있을 고가용성의 관계형 데이터베이스 시스템 (예: SQL Server 2008 R2)을 이용하는 것이 더 좋을 수 있습니다. [본문으로]
  2. Windows Azure SDK와 함께 제공되는 Table Storage를 위한 API가 포함되어있는 네임스페이스입니다. [본문으로]
  3. TableServiceEntity 클래스를 상속받도록 자료 구조를 만들어야 SDK를 이용하여 Table Storage에 데이터를 저장하거나 가져올 수 있습니다. [본문으로]
  4. TableServiceEntity 클래스의 기능을 적용하기 위하여 동일한 시그니처를 가진 생성자를 하나 만듭니다. Table Storage의 접근 효율성을 위하여, 테이블은 여러 개의 파티션으로 구분됩니다. 이 샘플에서 파티션의 분리 단위로 "날짜"를 사용하였습니다. 그리고 파티션 내에서 각각의 Entity가 고유한 의미를 가질 수 있게 하기 위하여 Row Key를 사용하여 구분합니다. Partiton Key와 Row Key가 더해져서 테이블 내에서는 이 Entity가 "유일할 수 있다"는 특성을 보장합니다. [본문으로]
  5. WriterName Property는 작성자의 이름, MessageBody Property는 메시지 본문, WrittenDate Property는 작성한 날짜와 시간을, ImageUrl Property는 같이 첨부하는 사진의 URL을 보관하는 목적으로 사용됩니다. C# 3.0 이후로 지원되는 단축 Property Getter/Setter 선언으로 별도의 private 멤버 변수를 배치하지 않고 이와 같이 단순한 코드를 만들 수 있습니다. [본문으로]
  6. Windows Azure SDK와 함께 제공되는 Table Storage를 위한 API가 포함되어있는 네임스페이스입니다. [본문으로]
  7. LINQ를 이용하여 손쉽게 데이터를 가져오거나 설정할 수 있도록 LINQ의 설정을 확장해주는 기본 추상 클래스입니다. [본문으로]
  8. CSCFG 파일 상의 정보를 표현하는 객체인 CloudStorageAccount를 생성자에서 인자로 받아 이 객체를 초기화하고, Windows Azure Storage와의 연결을 초기화합니다. [본문으로]
  9. 지연 실행을 목적으로 하는 질의 객체를 생성합니다. 지연 실행이란, 각각의 요소를 다룰 필요가 있을 때 식을 계산하고 평가하는 방식으로, 전체의 내용을 미리 메모리에 읽어들여서 처리하는 것과는 차이가 있습니다. 이 객체는 앞서 우리가 정의한 TwistModel 클래스를 트랜잭션의 단위로 사용하도록 SDK 내의 프레임워크에서 생성됩니다. [본문으로]
  10. 주의: 엔티티 클래스의 이름, ServiceContext에서 노출하는 프로퍼티의 이름, CreateQuery 메서드에 전달하는 테이블 명의 이름이 모두 같아야 혼선없이 올바르게 동작할 수 있음을 보증할 수 있습니다. [본문으로]
  11. LINQ to Azure Table Storage를 활용하는데에 필요한 클래스 및 원격 데이터 액세스에 필요한 클래스들이 굵게 강조 표시한 3개의 네임스페이스 안에 모두 포함되어있습니다. [본문으로]
  12. 현재는 실제 Windows Azure Storage 계정을 지정하지 않고 Local Development Storage 계정을 대신 지정합니다. [본문으로]
  13. 테이블 모델을 생성할 때 사용할 기준이 될 DataContext 클래스를 선택하고, 생성을 요청합니다. 이 때 접속할 대상 스토리지의 HTTP 주소와 자격 증명 정보도 한꺼번에 지정합니다. 또한, 이 작업은 TwistDataSource 클래스를 프레임워크에서 로드할 때 한 번만 발생할 수 있도록 유도하기 위하여 정적 생성자에 정의하였습니다. 테이블의 초기 구조를 할당하는 작업은 자주 일어날 필요가 없는 작업이기 때문에 성능 상의 이득을 위하여 이와 같이 작성합니다. [본문으로]
  14. 서비스 객체를 초기화합니다. 앞에서 가져온 계정 정보를 사용하여 복원된 계정 정보 객체를 사용하여 초기화하고 있다는 점을 확인하십시오. [본문으로]
  15. 혹시 있을지 모르는 장애에 대해 좀 더 완벽한 대비를 위하여, 재시도 정책을 설정할 수 있습니다. (이 부분은 매우 중요한 개념입니다.) 첫 번째 인자에는 재시도 횟수, 그리고 두 번째 인자에는 재시도 간격을 TimeSpan 객체를 이용하여 지정할 수 있습니다. 여기서는 처음 실패가 발생한 시점을 기준으로 3회 더 시도하며 각 시도 간격은 1초로 정합니다. [본문으로]
  16. 전형적인 LINQ to Entity 서비스와 마찬가지로 AddObject를 이용하여 객체의 참조를 기반으로 새로운 데이터를 추가할 수 있습니다. [본문으로]
  17. 트랜잭션 개념을 기본적으로 사용하므로 SaveChanges 메서드는 삽입, 변경, 삭제 작업이 있은 직후에는 반드시 병행되어야 합니다. [본문으로]
  18. Windows Azure Table Storage에 전송할 Query를 지연된 실행을 위한 객체로 초기화합니다. 이 문장이 실행되었다고해서 곧바로 데이터가 수집되는 것은 아닙니다. [본문으로]
  19. Windows Azure Table Storage에 실제로 Query를 전송할 클라이언트 객체를 초기화하고, 이 객체의 재시도 정책도 추가로 정의할 수 있습니다. 여기서도 3회 재시도, 매 시도마다 1초 간격을 두기로 설정합니다. [본문으로]
  20. 비로소 이 부분에서야 실제 전송과 데이터 수집이 발생하게 됩니다. [본문으로]
  21. Table Storage에서 객체를 삭제할 때에는 삭제를 위하여 검색할 대상을 지정해야 하며 이 때 사용하는 것이 AttachTo 메서드입니다. 이 메서드를 이용하여 어떤 테이블에서 어떠한 유형의 데이터를 검색할 것인지를 서비스 객체에 지정합니다. [본문으로]
  22. Plain Old CLR Object (Plain Old Java Object; POJO를 응용한 줄임말) [본문으로]
  23. Plain Old .NET Framework Object (Plain Old Java Object; POJO를 응용한 줄임말, POCO와 동일한 의미의 다른말) [본문으로]
  24. 이 글을 작성하는 시점에서 ASP.NET MVC 3에서 기본으로 채택될 예정인 Razor View Engine이 새로 발표되었습니다. Razor View Engine은 Web Form을 대체하는 ASP.NET MVC 전용의 View Engine 시스템을 뜻합니다. [본문으로]