지난 3월 말에 한국 마이크로소프트에서 의미있는 행사가 하나 열렸습니다. 바로 Windows Azure 기반의 클라우드 애플리케이션 경진대회가 열렸었는데요, 이 행사에서 수상한 대상 및 금상 두 작품의 발표가 오는 5월 3일 저녁 7시에 있을 예정입니다. 클라우드 응용프로그램 개발에 관심이 많으신 분들께서는 한 번 즈음 참관하시어 좋은 아이디어와 정보를 많이 얻어 가시면 좋겠습니다.
선착순으로 참석하시는 30분께는 Windows Azure 티셔츠가 무료로 제공될 예정이며, 온오프믹스 등록 페이지 (http://www.onoffmix.com/e/joongs14/1495)를 통하여 선착순 등록하시는 50분께는 4월 29일부터 일주일동안 사용 가능한 Windows Azure Platform 트라이얼 계정이 지급될 예정입니다.
최근 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 내에도 적용되어있는 상태입니다.
위에서 강조 표시한 부분이 KB971842와 KB977420을 통하여 제공되는 업데이트를 활성화하는데에 필요한 요소입니다. useRequestHeadersForMetadataAddress 요소는 Behavior 이름이 LoadBalancedBehavior라는 설정에 한정되어 유효한 태그이며, 그 이외의 경우는 잘못된 Child 요소로 분류되어 프로그램 수준에서 오류가 발생합니다. 그리고 위의 설정은 Windows Azure Simulator나 Windows Azure Host Process에서만 제대로 동작하며 직접 IIS로 호스팅하는 경우에는 설정이 반영되지 않습니다.
만약 기존에 사용하는 별도의 Behavior 설정이 있었다면 기존 Behavior 설정은 유지하시고, LoadBalancedBehavior 설정에 추가하기를 원하는 부분만 복사하여 그대로 붙여넣으면 온전하게 반영됩니다.
위에서 굵은 표시로 강조한 부분의 속성 값, 즉 behaviorConfiguration 부분만 위에서 지정한 Custom Behavior의 이름인 LoadBalancedBehavior로 변경해주면 서비스에서의 설정은 끝이 납니다.
4. 실버라이트를 고려하는 경우
실버라이트 컨텐츠를 클라이언트로 사용하는 경우, Windows Azure가 아닌 경우에도 해당이 되지만, Windows Azure에서 WCF를 호스팅할 때에도 동일하게 적용되는 부분이 있습니다. 바로 WCF 서비스의 바인딩 형태에 관한 것과 Cross Domain에 관한 부분입니다.
Windows Azure에서 실행되는 WCF 서비스의 경우, 주소 필터 불일치로 인한 문제 때문에 역시 프록시 클래스를 이용한 통신에서 실패할 수 있는데, 이를 방지하기 위한 목적으로 주소 필터의 설정을 완화하는 Attribute를 선언적으로 클래스 앞에 붙일 수 있습니다. 다음의 코드가 그 예시입니다.
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)] public class PhoneNUse : IPhoneNUse { ....
Windows Azure의 Web Role과 Worker Role은 가상 PC 인스턴스를 동적으로 생성하고 부팅시키는 방식을 통하여 서비스가 구현됩니다. SDK에서 소개하는것처럼 부팅이 끝나면 배포된 Role Application의 Entrypoint Class를 통하여 서비스의 초기화 작업이 이루어지고 서비스의 시작이 완료됩니다.
그렇다면, Windows Azure VM의 파일 시스템이나 여러가지 설정을 좀 더 상세하게 파악하고 다룰 수 있다면 서비스를 좀 더 풍성하게 꾸밀 수 있지 않을까요? 그런 취지에서 Windows Azure VM의 파일 시스템 구조를 살펴보는 글을 오늘 올려봅니다.
Note: 이 글은 Windows Azure OS 1.1을 기준으로 작성된 것이며, Windows Azure 내의 가상 PC 규격은 예고 없이 변동될 수 있음을 미리 알립니다.
Windows Azure VM의 Disk Partitioning 상태는 3개입니다. C/D/E 드라이브로 구분이 되어있는 상태로 파악할 수 있으며, 각 드라이브마다 역할이 있습니다. C 드라이브의 경우 서비스 구동과 제어에 필요한 핵심 리소스들이 주로 배치되어있습니다.
펼쳐두기..
Volume in drive C has no label. Volume Serial Number is 3A83-E377
Volume in drive C has no label. Volume Serial Number is 3A83-E377
Directory of c:\
04/21/2010 05:34 PM 2,147,483,648 dumpfile.dmp 04/21/2010 05:34 PM 4,294,967,296 pagefile.sys 04/22/2010 02:06 AM <DIR> System Volume Information 2 File(s) 6,442,450,944 bytes 1 Dir(s) 235,043,717,120 bytes free
D 드라이브에는 Windows Azure OS의 실제 시스템이 포함되어있습니다. Windows Azure OS의 기동에 필요한 Windows Server 2008 R2 x64가 설치되어있는 파티션입니다.
펼쳐두기..
Volume in drive D is Windows Volume Serial Number is F674-3730
Directory of d:\
02/13/2010 12:02 AM <DIR> inetpub 10/12/2009 09:27 PM 9,663 installVHDDriver.cmd 02/12/2010 03:02 AM 2,295,664 NDP35SP1-KB976126-v2-x64.exe 03/17/2010 12:00 PM 4,908 OnlineTargetPrep.cmd 04/22/2010 09:59 AM <DIR> OSdiagnostics 04/21/2010 05:31 PM <DIR> Packages 01/19/2008 10:11 AM <DIR> PerfLogs 02/16/2010 06:12 AM <DIR> Program Files 02/16/2010 06:12 AM <DIR> Program Files (x86) 03/03/2010 08:54 AM <DIR> rdsources 10/12/2009 09:27 PM 11,057 RolePrep_completed.txt 02/16/2010 05:45 AM 7,130 StageMe.cmd 02/16/2010 05:45 AM 11 StageMe.Pass1 10/12/2009 09:27 PM 14,797 TargetPrep_completed.txt 04/22/2010 02:06 AM <DIR> Users 03/03/2010 08:54 AM <DIR> Windows 7 File(s) 2,343,230 bytes 9 Dir(s) 7,884,308,480 bytes free
상당히 익숙한 모습의 디렉터리 레이아웃이 보입니다. inetpub, PerfLogs, Program Files, Program Files (x86), Users, Windows 디렉터리는 보통의 64비트 Windows OS에서 볼 수 있는 디렉터리 레이아웃과 같습니다. 좀 더 깊이 살펴보기 위하여, %windir%\microsoft.net\framework 디렉터리 아래에 어떤 버전의 프레임워크들이 설치되어있는지도 살펴보겠습니다.
펼쳐두기..
Volume in drive D is Windows Volume Serial Number is F674-3730
Directory of D:\windows\microsoft.net\framework
02/16/2010 06:30 AM <DIR> . 02/16/2010 06:30 AM <DIR> .. 04/11/2009 04:12 PM 79,696 NETFXSBS10.exe 09/18/2006 09:32 PM 41,392 netfxsbs12.hkf 01/05/2008 11:25 AM 16,896 sbscmp10.dll 01/05/2008 11:25 AM 16,896 sbscmp20_mscorwks.dll 01/05/2008 11:25 AM 16,896 sbscmp20_perfcounter.dll 01/05/2008 11:25 AM 14,352 sbs_diasymreader.dll 01/05/2008 11:25 AM 14,336 sbs_iehost.dll 01/05/2008 11:25 AM 14,360 sbs_microsoft.jscript.dll 01/05/2008 11:25 AM 14,904 sbs_microsoft.vsa.vb.codedomprocessor.dll
01/05/2008 11:25 AM 14,344 sbs_mscordbi.dll 01/05/2008 11:25 AM 14,344 sbs_mscorrc.dll 01/05/2008 11:25 AM 14,344 sbs_mscorsec.dll 01/05/2008 11:25 AM 14,384 sbs_system.configuration.install.dll 01/05/2008 11:25 AM 14,352 sbs_system.data.dll 01/05/2008 11:25 AM 14,376 sbs_system.enterpriseservices.dll 01/05/2008 11:25 AM 14,344 sbs_VsaVb7rt.dll 01/05/2008 11:25 AM 14,352 sbs_wminet_utils.dll 01/05/2008 11:25 AM 16,896 SharedReg12.dll 04/11/2009 04:19 PM <DIR> v1.0.3705 01/19/2008 10:11 AM <DIR> v1.1.4322 04/21/2010 05:33 PM <DIR> v2.0.50727 02/13/2010 12:02 AM <DIR> v3.0 04/21/2010 05:33 PM <DIR> v3.5 04/21/2010 05:33 PM <DIR> v4.0.30128 18 File(s) 361,464 bytes 8 Dir(s) 7,884,308,480 bytes free
.NET Framework 1.0, 1.1, 2.0, 3.0, 3.5, 4.0 디렉터리가 존재하는 것을 확인할 수 있습니다. 여기서 1.0과 1.1은 관리 도구에 관련된 파일만이 포함되어있습니다. (64비트 버전을 이용할 수 있는 것은 아닙니다.) 그리고 Windows Azure VM의 버전이 1.1이므로 4.0 버전은 설치되어있지 않고, 디렉터리만 만들어져있는 상태입니다. 좀 더 나아가서, Global Assembly Cache에는 어떤 어셈블리들이 설치되어있는지도 선택적으로 살펴보겠습니다.
펼쳐두기..
Volume in drive D is Windows Volume Serial Number is F674-3730
Directory of d:\windows\assembly\gac_msil
02/16/2010 05:42 AM <DIR> Microsoft.Build.Conversion.v3.5 02/16/2010 05:42 AM <DIR> Microsoft.Build.Engine 02/16/2010 05:42 AM <DIR> Microsoft.Build.Framework 01/19/2008 10:11 AM <DIR> Microsoft.Build.Tasks 02/16/2010 05:42 AM <DIR> Microsoft.Build.Tasks.v3.5 01/19/2008 10:11 AM <DIR> Microsoft.Build.Utilities 02/16/2010 05:42 AM <DIR> Microsoft.Build.Utilities.v3.5 01/19/2008 01:53 PM <DIR> Microsoft.GroupPolicy.Reporting 01/19/2008 02:02 PM <DIR> Microsoft.GroupPolicy.Reporting.Resources
01/19/2008 10:11 AM <DIR> Microsoft.JScript 01/19/2008 10:11 AM <DIR> Microsoft.ManagementConsole 01/19/2008 02:02 PM <DIR> Microsoft.ManagementConsole.Resources 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Commands.Management 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Commands.Management. Resources 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Commands.Utility 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Commands.Utility.Res ources 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.ConsoleHost 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.ConsoleHost.Resource s 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Security 02/13/2010 12:02 AM <DIR> Microsoft.PowerShell.Security.Resources 01/19/2008 01:53 PM <DIR> Microsoft.Storage.NfsCommon 01/19/2008 02:02 PM <DIR> Microsoft.Storage.NfsCommon.Resources 01/19/2008 01:53 PM <DIR> Microsoft.Storage.SanCommon 01/19/2008 02:02 PM <DIR> Microsoft.Storage.SanCommon.Resources 01/19/2008 01:53 PM <DIR> Microsoft.Storage.SanCommon.UI 01/19/2008 02:02 PM <DIR> Microsoft.Storage.SanCommon.UI.Resources 01/19/2008 01:53 PM <DIR> Microsoft.Storage.Vds 01/19/2008 10:11 AM <DIR> Microsoft.Tpm 01/19/2008 02:02 PM <DIR> Microsoft.Tpm.Resources 02/13/2010 12:02 AM <DIR> Microsoft.Transactions.Bridge 01/19/2008 10:11 AM <DIR> Microsoft.VisualBasic 01/19/2008 10:11 AM <DIR> Microsoft.VisualBasic.Compatibility 01/19/2008 10:11 AM <DIR> Microsoft.VisualBasic.Compatibility.Data 01/19/2008 10:11 AM <DIR> Microsoft.VisualBasic.Vsa 01/19/2008 10:11 AM <DIR> Microsoft.VisualC 02/16/2010 05:42 AM <DIR> Microsoft.VisualC.STLCLR 01/19/2008 10:11 AM <DIR> Microsoft.Vsa 01/19/2008 10:11 AM <DIR> Microsoft.Vsa.Vb.CodeDOMProcessor 02/13/2010 12:02 AM <DIR> Microsoft.Web.Administration 02/13/2010 12:02 AM <DIR> Microsoft.Web.Administration.Resources 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Aspnet 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Aspnet.Resources
02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.AspnetClient 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.AspnetClient.Res ources 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Iis 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Iis.Resources 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.IisClient 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.IisClient.Resour ces 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Remoting 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Remoting.Resourc es 02/13/2010 12:02 AM <DIR> Microsoft.Web.Management.Resources 02/16/2010 06:12 AM <DIR> Microsoft.Web.Management.Rewrite 02/16/2010 06:12 AM <DIR> Microsoft.Web.Management.Rewrite.Client 02/16/2010 06:12 AM <DIR> Microsoft.Web.Management.Rewrite.Client.r esources 02/16/2010 06:12 AM <DIR> Microsoft.Web.Management.Rewrite.resource s 01/19/2008 01:53 PM <DIR> Microsoft.Windows.ServerManager 01/19/2008 02:02 PM <DIR> Microsoft.Windows.ServerManager.Resources
04/22/2010 02:06 AM <DIR> Microsoft.WindowsAzure.ServiceRuntime 01/19/2008 10:11 AM <DIR> Microsoft_VsaVb 01/19/2008 10:11 AM <DIR> MiguiControls 01/19/2008 02:02 PM <DIR> MiguiControls.Resources 01/19/2008 10:11 AM <DIR> MMCEx 01/19/2008 02:02 PM <DIR> MMCEx.Resources 01/19/2008 10:11 AM <DIR> MMCFxCommon 01/19/2008 02:02 PM <DIR> MMCFxCommon.Resources 0 File(s) 0 bytes 66 Dir(s) 7,884,111,872 bytes free
펼쳐두기..
Volume in drive D is Windows Volume Serial Number is F674-3730
Directory of d:\windows\assembly\gac_msil
02/16/2010 05:42 AM <DIR> Sentinel.v3.5Client 01/19/2008 02:02 PM <DIR> ServerManagerCmd.Resources 02/13/2010 12:02 AM <DIR> ServiceModelReg 01/19/2008 01:53 PM <DIR> SetupNfsIdMap 02/13/2010 12:02 AM <DIR> SMDiagnostics 02/13/2010 12:02 AM <DIR> SMSvcHost 02/13/2010 12:02 AM <DIR> srmgui 02/13/2010 12:02 AM <DIR> srmgui.resources 02/13/2010 12:02 AM <DIR> srmreports 02/13/2010 12:02 AM <DIR> srmreports.resources 01/19/2008 01:53 PM <DIR> StorageMgmt 01/19/2008 02:02 PM <DIR> Storagemgmt.Resources 01/19/2008 10:11 AM <DIR> sysglobl 01/19/2008 10:11 AM <DIR> System 02/16/2010 05:42 AM <DIR> System.AddIn 02/16/2010 05:42 AM <DIR> System.AddIn.Contract 02/16/2010 05:42 AM <DIR> System.ComponentModel.DataAnnotations 01/19/2008 10:11 AM <DIR> System.Configuration 01/19/2008 10:11 AM <DIR> System.Configuration.Install 02/16/2010 05:42 AM <DIR> System.Core 02/16/2010 05:42 AM <DIR> System.Data.DataSetExtensions 02/16/2010 05:42 AM <DIR> System.Data.Entity 02/16/2010 05:42 AM <DIR> System.Data.Entity.Design 02/16/2010 05:42 AM <DIR> System.Data.Linq 04/21/2010 05:33 PM <DIR> System.Data.Services 04/21/2010 05:33 PM <DIR> System.Data.Services.Client 04/21/2010 05:33 PM <DIR> System.Data.Services.Design 01/19/2008 10:11 AM <DIR> System.Data.SqlXml 01/19/2008 10:11 AM <DIR> System.Deployment 01/19/2008 10:11 AM <DIR> System.Design 01/19/2008 10:11 AM <DIR> System.DirectoryServices 02/16/2010 05:42 AM <DIR> System.DirectoryServices.AccountManagemen t 01/19/2008 10:11 AM <DIR> System.DirectoryServices.Protocols 01/19/2008 10:11 AM <DIR> System.Drawing 01/19/2008 10:11 AM <DIR> System.Drawing.Design 02/13/2010 12:02 AM <DIR> System.IdentityModel 02/13/2010 12:02 AM <DIR> System.IdentityModel.Selectors 02/13/2010 12:02 AM <DIR> System.IO.Log 01/19/2008 10:11 AM <DIR> System.Management 02/13/2010 12:02 AM <DIR> System.Management.Automation 02/13/2010 12:02 AM <DIR> System.Management.Automation.Resources 02/16/2010 05:42 AM <DIR> System.Management.Instrumentation 01/19/2008 10:11 AM <DIR> System.Messaging 02/16/2010 05:42 AM <DIR> System.Net 01/19/2008 10:11 AM <DIR> System.Runtime.Remoting 02/13/2010 12:02 AM <DIR> System.Runtime.Serialization 01/19/2008 10:11 AM <DIR> System.Runtime.Serialization.Formatters.S oap 01/19/2008 10:11 AM <DIR> System.Security 02/13/2010 12:02 AM <DIR> System.ServiceModel 02/13/2010 12:02 AM <DIR> System.ServiceModel.Install 02/13/2010 12:02 AM <DIR> System.ServiceModel.WasHosting 02/16/2010 05:42 AM <DIR> System.ServiceModel.Web 01/19/2008 10:11 AM <DIR> System.ServiceProcess 02/13/2010 12:02 AM <DIR> System.Speech 02/16/2010 05:42 AM <DIR> System.Web.Abstractions 02/16/2010 05:43 AM <DIR> System.Web.DynamicData 02/16/2010 05:42 AM <DIR> System.Web.DynamicData.Design 02/16/2010 05:43 AM <DIR> System.Web.Entity 02/16/2010 05:42 AM <DIR> System.Web.Entity.Design 02/16/2010 05:43 AM <DIR> System.Web.Extensions 02/16/2010 05:42 AM <DIR> System.Web.Extensions.Design 01/19/2008 10:11 AM <DIR> System.Web.Mobile 01/19/2008 10:11 AM <DIR> System.Web.RegularExpressions 02/16/2010 05:42 AM <DIR> System.Web.Routing 01/19/2008 10:11 AM <DIR> System.Web.Services 01/19/2008 10:11 AM <DIR> System.Windows.Forms 02/16/2010 05:42 AM <DIR> System.Windows.Presentation 02/13/2010 12:02 AM <DIR> System.Workflow.Activities 02/13/2010 12:02 AM <DIR> System.Workflow.ComponentModel 02/13/2010 12:02 AM <DIR> System.Workflow.Runtime 02/16/2010 05:42 AM <DIR> System.WorkflowServices 01/19/2008 10:11 AM <DIR> System.Xml 02/16/2010 05:42 AM <DIR> System.Xml.Linq 0 File(s) 0 bytes 73 Dir(s) 7,884,111,872 bytes free
그리고, 마지막으로 E 드라이브의 구조를 살펴보겠습니다. E 드라이브는 개발자가 업로드한 Web Role이나 Worker Role이 저장되는 파티션입니다. 보통 Windows Azure 응용프로그램이 실행되면 VM 내에서의 기본 디렉터리 위치는 E:\ (E 드라이브의 루트 디렉터리)가 됩니다.
펼쳐두기..
Volume in drive E has no label. Volume Serial Number is 5447-4618
Directory of E:\
04/22/2010 02:05 AM 0 244e457eeae84f5cb30862f26fec3b7c.0.cssx.t ag 04/22/2010 02:29 AM 9,954 7894b527-88ba-42f2-be12-eedc4e224778.csma n 04/22/2010 02:05 AM <DIR> approot 04/22/2010 02:05 AM <DIR> base 01/31/2010 10:04 AM 18,015 Cloud.uar.csman 04/22/2010 02:05 AM <DIR> diagnostics 04/21/2010 05:28 PM 532 RuntimeSetup.Manifest 04/22/2010 02:05 AM <DIR> storage 04/22/2010 02:29 AM 944 [Content_Types].xml 04/22/2010 02:05 AM <DIR> _rels 04/21/2010 05:28 PM 16 __entrypoint.txt 6 File(s) 29,461 bytes 5 Dir(s) 1,034,371,072 bytes free
위의 항목들 중에서 approot 디렉터리에는 우리가 개발한 Web Role이나 Worker Role 프로젝트 파일들의 사본이 배포됩니다. 그리고 Windows Azure VM 내에서는 __entrypoint.txt 파일에 서술된 DLL 파일을 찾아 해당 항목을 Loading하는 것으로 이해할 수 있겠습니다.
펼쳐두기..
Volume in drive E has no label. Volume Serial Number is 5447-4618
Directory of e:\approot
04/22/2010 02:05 AM <DIR> . 04/22/2010 02:05 AM <DIR> .. 04/22/2010 02:05 AM <DIR> bin 04/21/2010 05:22 PM 110 CommandDelegate.asmx 04/18/2010 11:37 AM 446 Default.aspx 04/22/2010 02:05 AM <DIR> Scripts 04/21/2010 05:28 PM 8,075 Web.config 3 File(s) 8,631 bytes 4 Dir(s) 1,034,371,072 bytes free
그 외에 base에는 Windows Azure 구동에 관한 핵심 DLL들이, storage에는 Windows Azure Drive 관련 API를 제공하는 DLL들이, diagnostics에는 진단 도구 및 ETW 관련 API들이 포함된 DLL 및 응용프로그램들이 포함되어있습니다.
그 외에, Windows Azure의 상세한 디스크 정보를 파악하기 위하여 diskpart 같은 명령어를 테스트해보기도 하였지만 COM 관련 기능의 부재로 아래와 같은 오류 메시지가 나타나는 것도 확인하였습니다.
펼쳐두기..
Microsoft DiskPart version 6.0.6002 Copyright (C) 1999-2007 Microsoft Corporation. On computer: RD00155D3127B6
DiskPart encountered an error starting the COM services.
Windows Azure OS의 내부 빌드는 ver 명령을 통하여 확인할 수 있었습니다.
Microsoft Windows [Version 6.0.6002]
whoami를 이용하여 현재 Role을 실행하는 사용자의 이름도 확인할 수 있었습니다.
cis\ab279a57-70bb-4dd5-a4ba-fe7f60abfca2
그리고, Standard User Account로 실행 중이기 때문에, netstat -nab 같은 명령어나 fsutil 같은 명령어는 각각 아래와 같은 권한 상승 필요 메시지가 나타남을 확인할 수 있었습니다.
펼쳐두기..
The FSUTIL utility requires that you have administrative privileges.
The requested operation requires elevation.
대신, netstat 명령만을 실행하였을 때는 아래와 같이 간단한 네트워크 현황을 볼 수 있습니다.
프로그램 작성에 좋은 지침이 되는 환경 변수들 몇 가지를 살펴보면, SystemDrive, RdRoleRoot, RoleRoot, PATH 같은 환경 변수들이 있겠습니다. 그리고 USERDOMAIN, COMPUTERNAME, COMSPEC 및 프로세서 관련 환경 변수들도 시스템을 분석하는데에는 역시 도움이 되는 정보들이 되겠습니다.
Windows Azure OS 내의 파일 시스템 구성은 오늘 소개한 내용이 대략적인 내용이 될 것 같습니다. Windows Azure 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 OS는 어떤 구성을 사용하고 어떤 설정을 바탕으로 움직이는것일까요? 물론, 충분한 양의 문서와 SDK와 API로 모든 이론적인 설명은 가능합니다. 하지만 좀 더 깊이 들어가서 알아볼 필요가 있을 때도 있습니다. 인터넷 서핑 중에 찾은 흥미로운 블로그 아티클 하나를 소개하고자 합니다.
엄밀하게 말해서, Windows Azure OS를 실행하는 VM의 상황은 사실 블랙박스나 다름없습니다. 정상적으로 프로그래밍하고 테스트했다면 반 정도의 확률은 정상적으로 실행되지 않을 가능성도 있는 셈입니다. (기동에 실패하는 일보다는, 원하는 대로 서비스가 동작하지 않을 가능성을 의미합니다.) 특히, Worker Role의 경우 Web Role과는 달리 Custom Configuration에 강한 의존을 할 수 밖에 없는데요, 네트워크 서비스 등이 예상대로 동작하지 않으면 굉장히 큰 고민속에 빠지게 됩니다. 이런 곤란한 상황을 빠져나가려면 어떻게 하면 좋을까요?
배포할 Windows Azure 프로젝트의 .CSDEF 파일에 enableNativeCodeExecution 어트리뷰트의 값을 "true"로 명시적으로 설정하는 것으로부터 솔루션을 시작할 수 있습니다. (최근의 SDK와 OS의 경우, 이 설정은 기본적으로 'true'이지만 명시적으로 설정하는 것도 좋을것 같습니다.)
위의 코드가 하는 역할은 단순합니다. Windows 명령줄 인터프리터를 대신 실행해주고 대신 결과를 출력해주는 것입니다. 그리고, Native Code의 실행을 허용했으므로 거의 대부분의 명령이 정상적으로 실행될 수 있을 것입니다. (관리자 권한 아래에서 실행되지는 않습니다.)
아래의 스크린 샷들은 실제 명령의 수행 결과들을 보여주는 것입니다. 그리고 이 블로그 아티클의 저자는 NETSTAT 명령을 원격에서 실행해보고, Tomcat Instance가 필요로하는 8080포트가 이미 점유된 상태이기 때문에 원하는대로 작동하지 않음을 확인할 수 있었다고 합니다.
ps. 이와 같은 도구는 확실히 디버깅이나 문제 진단에는 유용할 수 있지만, 아무리 클라우드 환경이라고 할지라도 이와 같은 도구가 개방되어있을 경우, 악용될 소지가 크기 때문에, 실제 배포 단계에서는 이러한 도구가 포함되지 않도록 유의할 필요가 있겠습니다.
.NET Framework 4.0과 Visual Studio 2010 RTM이 긴 테스트 과정과 수렴 과정 끝에 이번달에 성공적으로 전 세계에 런칭하였습니다. 생산성을 극적으로 업그레이드할 수 있는 다양한 기술과 API 들을 중무장하고, ASP.NET MVC2나 MEF (Managed Extensibility Framework) 등의 새로운 기술들도 다채롭게 선보였습니다.
그런데 한 가지 궁금증이 생깁니다. Windows Azure OS 자체는 아직도 .NET Framework 3.5 SP1을 기반으로 하는데 언제 .NET Framework 4.0으로 업데이트하는걸까요? 이에 대한 포럼 내의 답이 있어서 블로그에 소개합니다.
MIX2010에서, Windows Azure에서의 .NET Framework 4.0 지원은, RTM 버전이 공개된 이후 약 90일 이내에 업데이트된다고 합니다. 개발 과정 상의 변수 (Visual Studio용 SDK 개발, Windows Azure VM 이미지 업데이트) 등을 모두 감안한 기간으로 보입니다만, 늦어도 올해 초여름에는 .NET Framework 4.0을 기반으로 실행되는 Windows Azure 서비스를 사용할 수 있는 셈이 됩니다.
그렇지만, 좀 더 빠르게 .NET Framework 4.0 기반의 클라우드 응용프로그램을 개발하고 테스트하기를 희망하신다면, 배포하실 Windows Azure 환경 설정 파일에 실제로 채택할 운영 체제의 버전을 정확히 기술하여 .NET Framework 4.0 RC 버전을 채택한 VM을 기반으로 구동하도록 선택하실 수도 있습니다. 해당 버전은 Windows Azure Geust OS 1.2 중 2010년 3월 1일 버전의 이미지입니다. (http://msdn.microsoft.com/en-us/library/ff436045.aspx)
.NET Framework 4.0과 Windows Azure가 결합한다면, 이전보다 더 확장성이 뛰어나고 강력한 클라우드 기반 응용프로그램을 작성할 수 있는 토대가 마련될 것입니다. 여러모로 기대가 많이 되는 소식이고, 새로운 소식이 들어오는대로 정보를 공유할 수 있도록 하겠습니다. 감사합니다. :-)
Windows Live Labs에서 개발중이던 여러 기술들은 이미 세간의 입소문에 자주 회자되곤 했었습니다. 그런데 최근에 이들 기술들이 Bing Map에 보기좋게 통합되어 TED 2010에서 멋지게 선보이게 되어 이 동영상을 가져와보았습니다. 이 글의 출처는 http://neters.inha.ac.kr/Article/7573 입니다.
편리한 시청을 위하여, 한국어 자막도 제공됩니다. View Subtitles를 클릭하시면 사용 가능한 언어가 나열되며, 한국어 자막 (Korean)도 포함되어있습니다. :-)
ps. bing.com의 한국어 사이트는 Daum에서 제공하는 검색 서비스로 대치되어있는 상태입니다. 아래의 서비스를 체험하시려면 언어 설정을 영어로 변경하셔야 합니다. 문맥 상 기계 번역이 가능한 부분에 한하여, 영어 버전의 사이트에서도 한국어로 표시되는 문자열이 있습니다.