많은 Windows Azure Application 개발자들의 피드백을 수용한 최신 버전의 Windows Azure Tools for Visual Studio와 Windows Azure SDK가 새롭게 출시되었습니다. 이제 비로소 Visual Studio 2010의 모든 기능을 Windows Azure 개발에도 직접 활용할 수 있게 되었습니다.
Windows Azure SDK 1.2에서는 최근 발표된 .NET Framework 4.0 런타임을 내장한 Windows Azure OS 2010년 4월 버전에 대한 요구 사항을 모두 반영하고 있습니다. .NET Framework 4.0 기반의 응용프로그램을 작성 중이신 분들도 이제는 Windows Azure 환경 위에서 직접 응용프로그램을 호스팅할 수 있습니다. 그리고, Visual Studio 2010에서 새로 추가된 향상된 디버깅 기법인 IntelliTrace를 직접 지원하기 때문에 이전보다 더욱 쉬운 디버깅이 가능합니다.
다음은 Windows Azure Tools for Visual Studio 1.2의 변경 사항들입니다.
Visual Studio 2010 RTM 지원: Visual Studio 2010 RTM 버전을 지원합니다.
.NET Framework 4.0 지원: 이제는 .NET Framework 3.5와 4.0을 빌드 타겟으로 동시에 지정할 수 있습니다. 단, 4.0을 빌드 타겟으로 지정하게 되는 경우, Windows Azure OS의 이미지 중 2010년 초반의 일부 버전은 사용할 수 없습니다.
Cloud storage explorer 추가: 읽기 전용 기능이 지원되는 Windows Azure Table 및 BLOB 컨테이너 보기 프로그램이 서버 탐색기 패널을 통하여 제공됩니다. SQL Azure를 데이터베이스 목록에 추가하고 동시에 관리할 수 있어 편리합니다.
통합 배포 환경: 솔루션 탐색기에서 Windows Azure 프로젝트를 오른쪽 버튼으로 클릭하여 'Publish' 메뉴를 클릭하면 이제는 직접 배포가 가능합니다. 이전 1.0 및 1.1 버전의 경우, CSPKG 파일과 CSCFG 파일이 생성된 디렉터리의 폴더가 Windows 탐색기에서 열리고, Windows Azure Portal Web Site가 웹 브라우저로 열렸기 때문에, 브라우저에서 로그인하고 여러 단계에 걸쳐서 배포할 파일을 찾아가야했기 때문에 Deploy 절차가 복잡했습니다.
서비스 모니터링: 서비스의 상태를 웹 제어판이 아닌 "서버 탐색기"의 compute 노드에서 실시간으로 모니터링할 수 있습니다.
IntelliTrace 기능 지원: Visual Studio 2010을 사용하는 경우, IntelliTrace 기능을 Windows Azure 서비스에 배포한 이후에 "직접" 사용할 수 있습니다. 이 기능은 앞에서 설명한 통합 배포 환경의 일부로 동작하며, 배포가 끝난 이후에 자동으로 이 기능이 시작되어 서비스 모니터링과 함께 실시간으로 로그가 모니터링됩니다.
그간 Windows Azure 기반의 개발이 어려우셨다면 이제는 최신 버전의 SDK와 개발 도구를 이용하여 좀 더 편안하게 Visual Studio 2010을 통해 클라우드 기반 응용프로그램 개발을 시작해보세요. 참고로 Visual Studio 2010의 데이터베이스 탐색기는 SQL Azure 데이터베이스에 대한 탐색도 지원하므로 이전처럼 별도의 SSMSE를 필요로 하지 않습니다. 그리고 이번 버전의 SDK 역시 1.0과 1.1과 마찬 가지로 처음 설치하는 경우에는 OS와 개발 도구의 환경에 따라 패치와 핫 픽스들을 적용하셔야 합니다.
IT 업계에서, 이름만 대면 누구라도 공감하고 인정할 수 있는 업체 3곳의 클라우드 컴퓨팅 솔루션과 서비스는 현재 전세계의 모든 사람들에게 큰 신뢰를 얻고 있습니다. 바로, 마이크로소프트, 구글, 아마존입니다. 진정으로 많은 자료들과 백서들이 공개되고, 심지어는 UCC로 만든 튜토리얼까지 엄청난 자료들이 매일 쏟아지고 있습니다. 하지만 구체적으로 클라우드 컴퓨팅 플랫폼이 각 업체들마다 어떤 특징이 있는지, 어떤 방향으로 개발이 되어가고 있는지를 진단해볼 필요가 있을 것입니다.
1. 아마존의 EC2 / S3
아마존 웹 서비스 프로젝트 아래에 제공되는 클라우드 컴퓨팅 솔루션이 바로 EC2와 S3입니다. EC2는 Elastic Cloud Computing, S3는 Simple Storage Service의 줄임말입니다. EC2는 가상화 기술과 로드밸런싱 기술을 바탕으로 하여, 실시간으로 가상의 서버를 증설하거나, 제어하거나, 관리할 수 있는 클라우드 컴퓨팅 서비스를 제공합니다. 그리고 S3는 천문학적인 규모의 데이터 저장소를 역시 실시간으로 증설, 제어, 관리할 수 있는 서비스를 제공합니다.
EC2와 S3를 설명하는 많은 수의 튜토리얼에서 보여지는것처럼, 아마존의 클라우드 컴퓨팅 서비스는 "완전한 제어"를 가장 큰 장점으로 꼽습니다. 클라우드 내의 가상 머신의 자원을 계획적으로 할당하고, 정교하게 프로그래밍하기를 원하는 모든 이들에게는 최상의 선택일 것입니다. 더욱 매력적인 것은, 리눅스를 운영 체제로 사용하도록 계획된 가상 머신의 경우, 미리 템플릿으로 정의된 가상 머신을 이용할 수 있는 것은 물론, 가상 머신을 구동하기 이전이라도 필요한 패키지들을 미리 고르고 한꺼번에 빌드할 수 있는 기능까지 제공합니다. 그리고, Windows Server 2003과 2008을 OS로 지원하고, 기존에 보유하고있던 Windows Server 2003과 2008 라이선스를 EC2 기반으로 옮기는 정책 또한 지원을 하고 있습니다.
잘 생각해보면, EC2는 서버 호스팅의 그것과 상당히 닮아있습니다. 오히려, 서버 호스팅에서도 누릴 수 없는 자유도를 완전히 누릴 수 있기까지 합니다. 하지만, 클라우드 컴퓨팅을 어떤 방향으로 이용하고 계획할지를 결정해야 하는 부분이 크기 때문에, EC2와 S3 같은 클라우드 컴퓨팅 내의 자원을 활용하는 일 자체가 하나의 프로젝트가 될 수도 있습니다.
요약하면, 아마존이 제공하는 클라우드 컴퓨팅은 IaaS에 해당합니다. (Infrastructure as a Service)
2. 구글의 AppEngine (특별히 Java + Eclipse의 경우를 예로 들어봅니다.)
구글의 AppEngine은 본디 Python 기반의 Application Hosting Platform으로 처음 소개되었습니다. 하지만 최근에 Java 기반의 개발 도구와 함께 JSP 기반의 응용프로그램을 호스팅할 수 있게 되어 좀 더 소개를 해봅니다. 아래는 Eclipse 기반의 Google AppEngine 개발에 관한 튜토리얼 비디오입니다.
Windows Azure 기반의 클라우드 컴퓨팅을 먼저 보신 분이시라면, 위의 비디오에서 소개하는 내용이 Windows Azure 기반의 Web Role 개발 과정과 닮아있는 것을 보실 수 있습니다. 다만 차이가 있다면, Google AppEngine은 각 응용프로그램에 대해서 개별 VM을 할당하는 방식이 아닌, Hosting 방식으로 구성됩니다.
그리고 Google AppEngine은 BigTable이라고 하는 Google의 전매 특허격 스토리지 서비스를 기반으로 데이터 입/출력 기능을 제공합니다. (참고로 BigTable은 구글이 인덱싱하고 있는 천문학적인 수준의 데이터베이스를 구동하는 실체입니다.)
Google AppEngine은 전형적인 Platform as a Software (PaaS)를 보여주는 것으로, 개발자들이 클라우드 컴퓨팅의 세부 사양에 집중하지 않고, 응용프로그램의 핵심 부분에만 집중하여 빠른 소프트웨어 출시를 가능하게 해주는 것을 주요 골자로 하고 있습니다.
3. Windows Azure의 현재와 미래
그렇다면, 이 글을 작성하는 현 시점의 Windows Azure는 어떤 상태일까요? Windows Azure는, 내부적으로 IaaS의 성질과 PaaS의 성질을 모두 지니고 있는 것으로 이해할 수 있습니다. Windows Azure에서 응용프로그램을 배포할 때, 과금을 시작할 때에는 거의 모든 부분이 가상 머신의 실행 시간에 초점이 맞추어져 있습니다. 그리고 단순히 응용프로그램을 배포하는 것의 문제와는 별개로, 가상 머신의 실행 과정이 배포 과정에서 상당히 중요한 요소가 됩니다.
Windows Azure 안에서 실행되는 VM을 완전히 통제할 수 없다는 제약 사항은 PaaS에 초점이 맞추어진 것과도 연결되는 맥락으로 볼 수 있습니다. 실제 소프트웨어나 서비스를 구동하는데에 있어서, VM 내의 관리자 권한은 필수 요소가 아니기 때문일 것입니다. 하지만, 이런 와중에도 Windows Azure에서 Amazon EC2와 같은 완전한 제어가 가능한 서버 호스팅형 클라우드 서비스의 출시를 요청하는 사람들이 많았고, 이에 따라 관련된 서비스의 출시를 예정하는 소식도 최근에 들렸습니다. 자세한 내용은 "Windows Azure에 추가될 새로운 기능"을 참고하시면 되겠습니다.
Windows Azure에 Remote Desktop Protocol 및 VM 제어 기능이 추가된다면, Windows Azure는 클라우드 컴퓨팅을 IaaS 관점에서 활용하기를 희망하는 수요에도 대응되고, PaaS 관점에서 활용하기를 희망하는 수요에도 대응되는 매력적인 플랫폼이 될 것이라 예견해 봅니다.
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"];
}
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 클래스에 대한 구체적인 분석을 해보도록 하겠습니다.
2009년 11월 버전에 이어서, Windows Azure Tools의 최신 버전이 업데이트되었습니다. 이번 업데이트에서는 2009년 11월 버전에서 보고된 주요 문제점들 (특히 Visual Studio 2010 Beta 2에서 발견된 문제점들)이 많이 개선된 것이 눈에 띄며, 곧 출시될 Visual Studio 2010 RC (Release Candidate) 버전과 Visual Studio 2008 SP1을 대상으로 설치가 가능합니다.
이번에 배포되는 SDK에서 신규 제공하는 Windows Azure와의 연동 기능은 크게 두 가지입니다.
* Windows Azure 버전 선택: Windows Azure 자체는 하나의 완전한 운영 체제이며, Windows Azure Platform을 구성하는 가상 머신의 운영 체제입니다. 이 글을 작성하는 현 시점에서, 2009년 12월에 발표된 Windows Azure 1.0 (http://msdn.microsoft.com/en-us/library/ee956589.aspx)과 2010년 1월에 발표된 Windows Azure 1.1 (http://msdn.microsoft.com/en-us/library/ee924682.aspx) 중 택일할 수 있으며, 환경 설정 도구에서 편리하게 선택할 수 있는 옵션을 제공합니다. 그리고, 당연한 이야기이지만, 기능에 대한 변화 뿐만 아니라, 다각도에서 테스트하여 발생 가능한 보안 문제를 수정하는 노력도 더해지므로 항상 최상의 보안 상태를 유지할 수 있는 이점도 제공합니다.
그 외 다수의 버그들이 수정되었으며, 설치 방법은 2009년 11월 버전 때와 마찬가지로 일부 Hotfix들을 OS와 사용하는 개발 도구에 맞추어 추가 설치해야 합니다. (설치 방법에 대한 문서 보기: Windows Azure 개발 환경 구축 단계별 설명서)
지난 글에 이어서, 오늘 글에서는 방명록의 Web Role 어플리케이션을 만드는 부분과 함께, Blob Storage의 사용 방법, 그리고 간단한 주의 사항 하나를 살펴보도록 하겠습니다.
Blob Storage는 Blob (Binary Large Object) 즉 일반 바이너리 파일을 저장할 수 있는 공간으로, 지난 글에서 살펴본 Table Storage와 더불어서 Storage 기능 중 하나로 제공되는 부분입니다. Blob Storage를 통하여, 방명록의 사진 첨부 기능을 구현해 보고자 합니다.
그리고, 우리가 특별히 제작할 Worker Role 어플리케이션은 클라우드 컴퓨팅 서비스에 특화된 기능에 관한 예시 하나를 보여줄 것입니다. 바로, 업로드한 방명록의 사진 크기를 적절한 썸네일 이미지로 변환하는 기능입니다. 개별적인 썸네일 이미지 변환 작업 하나하나는 큰 작업이 아닐 수 있지만, 이것이 동시에 많은 사용자들에 의하여 발생하는 작업이라고 가정한다면, 웹 서비스 입장에서는 굉장한 리소스 사용이 발생하게 될 것입니다.
지난번에 만든 GuestBook_Data 프로젝트를 확인한 후, Web Role로 등록된 ASP.NET 프로젝트의 Default.aspx 페이지를 열어서, 아래와 같이 디자인 타임 상에 ASP.NET 컨트롤들을 배치합니다. (Name 옆의 입력 필드의 인스턴스 명을 'NameTextBox', Message 옆의 입력 필드의 인스턴스 명을 'MessageTextBox', Photo 옆의 입력 필드의 인스턴스 명을 'FileUpload1', 연필 모양의 이미지를 사용하는 이미지 버튼 필드의 인스턴스 명을 'SignButton'으로 하기로 합니다. 그리고, 처리 과정을 살펴보기 위하여, ASP.NET AJAX Timer 컴포넌트를 하나 추가하고, 이름을 'Timer1'으로 하기로 합니다.)
그리고 Default.aspx 페이지의 코드 비하인드를 엽니다. 그리고, 아래와 같이 네임스페이스 참조를 추가합니다.
using System.Net;
using GuestBook_Data;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.ServiceRuntime;
using Microsoft.WindowsAzure.StorageClient;
코드 비하인드와 연결된 _Default 클래스의 멤버 변수로는 다음의 항목들을 추가합니다. Blob Storage와의 상태를 동기화하고 관리하기 위한 변수들입니다. 싱글턴 패턴으로 유지하기 위하여 모두 정적 인스턴스로 선언하였으며, storageInitialized 변수에는 초기화 여부를 관리하고, gate 변수는 스레드 이벤트 동기화를 관리하며, blobStorage 변수는 실제 Windows Azure Blob Storage에 대한 서비스를 포함하는 변수입니다.
SignButton의 Click 이벤트를 구현하여 핸들러를 추가한 후 아래와 같이 코드를 작성합니다. 이 이벤트 핸들러는, Windows Azure Blob Storage에 첨부한 사진 파일을 저장하고, 이전 글에서 작성한 모델을 바탕으로 Windows Azure Table Storage에 방명록의 글을 저장하는 역할을 수행합니다.
protected void SignButton_Click(object sender, EventArgs e)
{
if (FileUpload1.HasFile)
{
InitializeStorage();
// Windows Azure Blob Storage에 이미지를 저장합니다.
CloudBlobContainer container = blobStorage.GetContainerReference("guestbookpics");
string uniqueBlobName = string.Format("image_{0}.jpg", Guid.NewGuid().ToString());
CloudBlockBlob blob = container.GetBlockBlobReference(uniqueBlobName);
blob.Properties.ContentType = FileUpload1.PostedFile.ContentType;
blob.UploadFromStream(FileUpload1.FileContent);
System.Diagnostics.Trace.TraceInformation("Uploaded image '{0}' to blob storage as '{1}'", FileUpload1.FileName, uniqueBlobName);
// Windows Azure Table Storage에 새 항목을 추가합니다.
GuestBookEntry entry = new GuestBookEntry() { GuestName = NameTextBox.Text, Message = MessageTextBox.Text, PhotoUrl = blob.Uri.ToString(), ThumbnailUrl = blob.Uri.ToString() };
GuestBookEntryDataSource ds = new GuestBookEntryDataSource();
ds.AddGuestBookEntry(entry);
System.Diagnostics.Trace.TraceInformation("Added entry {0}-{1} in table storage for guest '{2}'", entry.PartitionKey, entry.RowKey, entry.GuestName);
}
NameTextBox.Text = "";
MessageTextBox.Text = "";
DataList1.DataBind();
}
Timer1 컴포넌트의 Tick 이벤트를 아래와 같이 구현하여, 타이머가 실행되어있을 동안 주기적으로 데이터 바인딩 상태를 확인하는 동작을 서술합니다.
이제, 프로그램 내에서 중요한 Windows Azure Storage와의 연결을 초기화하는 InitializeStorage 메서드를 구현합니다. 이 메서드는, 방명록의 "쓰기" 버튼을 호출할 때 마다 불리지만, 실제로 의미를 가지고 동작하는 것은 응용프로그램이 시작된 이후 최초 한 번이 됩니다.
private void InitializeStorage()
{
if (storageInitialized)
{
return;
}
lock (gate)
{
if (storageInitialized)
{
return;
}
try
{
// read account configuration settings
var storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
// create blob container for images
blobStorage = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobStorage.GetContainerReference("guestbookpics");
container.CreateIfNotExist();
// configure container for public access
var permissions = container.GetPermissions();
permissions.PublicAccess = BlobContainerPublicAccessType.Container;
container.SetPermissions(permissions);
}
catch (WebException)
{
throw new WebException("Storage services initialization failure. "
+ "Check your storage account configuration settings. If running locally, "
+ "ensure that the Development Storage service is running.");
}
storageInitialized = true;
}
}
여기서 DataConnectionString은 응용프로그램 설정 (web.config이 아닙니다) 상의 연결 문자열로, 실제 Windows Azure Storage를 지정하거나, Windows Azure Tools의 Simulator와 연결하는 것 중 선택하여 완성해야 하는 항목입니다. 프로젝트 속성을 열어서 아래와 같이 설정할 수 있습니다.
위의 코드 상에서 DataConnectionString이라는 이름을 사용하였으므로, 같은 항목의 이름을 새로 입력하고, Type을 ConnectionString으로 설정한 후, Value 옆의 "..." 버튼 - 또는 - 도구 모음 상단의 "Add Settings" 버튼을 클릭합니다. 그러면 아래와 같은 세부 설정 창이 팝업으로 나타납니다.
"Use development storage"를 선택하면, 로컬 컴퓨터에 구축된 Storage를 사용하여 기능을 시험해볼 수 있으며, "Enter storage credentials"를 선택하면, 실제 Windows Azure Storage에 접속하는 것을 뜻하며, 입력해야 하는 항목들은 Windows Azure Portal 사이트에서 모두 확인할 수 있는 정보들입니다. 여기서는 첫 번째 항목을 선택하여 배포 전에 프로그램이 잘 동작하는지 점검하는 것으로 설정하겠습니다.
설정을 변경하고 나면 모두 저장 버튼을 눌러 프로젝트의 변경 사항을 저장합니다.
이제 마지막으로, Web Role 어플리케이션에서 화룡점정(?)이라고 할 수 있는 설정 전달 기능을, 기본으로 추가되어있는 WebRole.cs (또는 WebRole.vb) 파일 내에 코드를 추가해야 합니다. 아래와 같이 코드를 작성합니다.
public override bool OnStart()
{
DiagnosticMonitor.Start("DiagnosticsConnectionString");
// Restart the role upon all configuration changes
// Note: To customize the handling of configuration changes,
// remove this line and register custom event handlers instead.
// See the MSDN topic on “Managing Configuration Changes” for further details
// (http://go.microsoft.com/fwlink/?LinkId=166357).
RoleEnvironment.Changing += RoleEnvironmentChanging;
Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher(( configName, configSetter) =>
{
configSetter(Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(configName));
});
return base.OnStart();
}
노트: 개발 환경에서 테스트를 위하여 사용하는 DiagnosticMonitor.Start 메서드는 실제 Windows Azure 환경 위에서는 동작하지 않을 수 있습니다. 응용프로그램을 게시한 이후에 인스턴스의 상태가 Busy에서 머무르거나 Ready로 전환되지 않고 Stop으로 전환될 경우, 이 부분을 확인하여 DiagnosticMonitor 개체의 사용을 해제하거나, 정식 Windows Azure Storage 계정을 대체 지정하여야 합니다.
다음 Step에서는 방명록의 비동기 Worker Role을 작성하는 방법을 살펴보도록 하겠습니다. 감사합니다. :-)
