'PaaS'에 해당되는 글 71건

  1. 2014.09.15 ubuntu 14.04에서 asp.net vnext 설치하고 사용하기, mono 3.8 업데이트
  2. 2014.08.24 Project.json 파일
  3. 2014.08.10 ASP.NET Custom Loader의 원리
  4. 2014.08.03 OWIN과 함께 춤을 – Hello, World
  5. 2014.07.15 OWIN과 함께 춤을 – 시작하기
  6. 2013.10.12 ASP.NET을 이용한 이식성 높은 클라우드 서비스 개발하기
  7. 2013.10.05 SendGrid E-MAIL 서비스로 E-MAIL 보내기
  8. 2013.03.31 Windows Azure를 통한 클라우드 서비스 확장성 포스터
  9. 2013.03.07 Cloud Service 레시피 - Windows Azure Cloud Service 프로젝트 안에서 실행 환경을 구분하는 방법
  10. 2013.02.26 Windows Azure Worker Role에 여러 진입점 클래스가 있는 경우
  11. 2012.11.21 Management Portal에서 미디어 서비스 관리하기
  12. 2012.08.06 클라우드 시대의 피아식별: Access Control #3
  13. 2012.08.05 클라우드 시대의 피아식별: Access Control #2
  14. 2012.07.13 Windows Azure Media Service 활용하기
  15. 2012.06.25 Windows Azure에서 XE 설치하고 실행하기 (2)
  16. 2012.06.10 Windows Azure Web Site로 블로그 만들기 (2)
  17. 2012.05.14 VM Role 생성을 위한 가상 하드 디스크 템플릿 파일
  18. 2011.12.15 AppFabric 브랜드 네임의 전면적인 수정
  19. 2011.09.12 ASP.NET과 IIS 7을 위한 로드 밸런싱 전략과 기초적인 이야기, 그리고 Azure Platform
  20. 2011.07.25 Real-World Windows Azure Development Guide – 원격 데스크톱
  21. 2011.07.23 Real-World Windows Azure Development - Windows Azure 호스팅 환경에서의 인증서 관리
  22. 2011.05.09 Real-World Windows Azure Development Guide – Windows Azure에 대한 생각 뒤집기
  23. 2011.03.29 A Lap around cloud computing – 1인 1근두운 시대
  24. 2011.02.27 A Lap around cloud computing – 지금이 여러분의 이력서를 새로 쓸 시간
  25. 2011.02.25 Windows Azure Virtual Lab으로 쉽고 빠르게 클라우드 개발 실습하기
  26. 2011.02.17 DevForce 프레임워크의 Windows Azure 마이그레이션 DEMO 동영상
  27. 2011.02.14 A Lap around Cloud Computing – 당신이 어디에 있든 관계없는 세상
  28. 2011.02.01 Windows Azure Consumption Rate 자동 계산 Excel 워크시트
  29. 2011.01.30 클라우드 시대의 피아식별: Access Control #1
  30. 2011.01.22 A Lap around Cloud Computing - “Everything as a Service”
PaaS2014. 9. 15. 09:38

NOTE: 지난 번에 올렸던 글 이후로 mono 3.8이 빠르게 추석 연휴를 사이로 업데이트가 되었는데, mono의 최신 버전을 설치하는 과정이 무척 복잡하고 까다로웠던 점이었던게 상당히 아쉬웠습니다. 그런데 이 부분이 잘 해결된 듯 하여 업데이트된 내용을 더해 글을 더 보강하여 다시 게시합니다.

 

 

다시 말씀드리면, 이 블로그 포스트는 MS Azure Virtual Machine과 Ubuntu Server 14.04 버전을 최초 설치했을 때의 상태를 기준으로 작성된 것이며, 이 블로그 글을 작성하는 2014년 9월 현재 ASP.NET vNext가 정식 출시 전임을 말씀드립니다.

주의: 실제 배포 환경에서 이 블로그 포스트의 내용을 활용하시는 것은 매우 위험합니다.

사전 준비 작업

중요: 이 아티클에서 소개하는 내용은 Ubuntu 14.04에서 작동하며, Ubuntu 12 버전에서는 패키지 버전 불일치 등으로 인하여 mono 3.8이 정상적으로 설치가 되지 않아 실행할 수 없습니다.

최근들어 변경된 사항으로, Mono의 최신 버전 릴리즈는 Xamarin이 독자적으로 운영하는 패키지 리포지터리를 통하여 좀 더 빠르게 받아보실 수 있습니다. 하지만 2014년 9월 현재 모든 배포판에 대해 완전하게 설치를 보장하는 것이 아닌 것으로 보입니다.

Mono 3.8 및 그 이후 버전을 설치하기 위하여 우선 해야 할 일은 Xamarin 리포지터리를 시스템에 추가하는 일입니다.

단순한 설명을 위하여, 현재 로그인한 사용자의 홈 디렉터리로 일단 디렉터리 변경을 하겠습니다.


cd ~

Xamarin 리포지터리의 GPG Key를 내려받도록 합니다.


wget http://download.mono-project.com/repo/xamarin.gpg

그리고 내려받은 GPG 키를 저장합니다.


sudo apt-key add xamarin.gpg

/etc/apt/sources.list 파일을 편리한 텍스트 편집기로 열고, 가장 마지막에 다음의 줄을 추가한 후 저장하고 닫습니다.


deb http://origin-download.mono-project.com/repo/debian/ wheezy main

패키지 캐시를 업데이트하기 위하여 아래 명령어를 실행합니다.


sudo apt-get update

이제 Mono 3.8을 설치할 준비가 다 되었습니다. 아래 명령어만 실행하면 됩니다.


sudo apt-get -y install mono-complete

설치가 다 끝나면 mono의 버전을 확인해봅니다.


mono –version

K Runtime과 ASP.NET vNext 설치하기

Mono 3.8이 9월에 릴리즈하고 나서 K Runtime과 ASP.NET vNext를 테스트하는 방법에도 조금 변화가 생겨서 그 내용을 같이 말씀드립니다.

HTTPS/SSL 인증서들을 추가하고 Mono에서 사용할 수 있도록 동기화하는 작업을 반드시 실행합니다.


sudo certmgr -ssl -m https://go.microsoft.com
 sudo certmgr -ssl -m https://nugetgallery.blob.core.windows.net
 sudo certmgr -ssl -m https://nuget.org
 sudo certmgr -ssl -m https://myget.org
 mozroots –import –sync

ASP.NET vNext를 실행하기 위해서는 unzip 패키지가 필요합니다.


sudo apt-get install unzip

그리고 ASP.NET vNext 설치 스크립트를 내려 받습니다.


curl https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.sh | sh && source ~/.kre/kvm/kvm.sh

source 명령을 사용하여 K runtime을 쉽게 실행할 수 있도록 설정합니다.


source ~/.kre/kvm/kvm.sh

2014년 9월 23일 현재 최신 버전은 1.0.0-alpha4-10353입니다. 이 버전을 내려 받기 위하여 KRE_FEED 환경 변수에 Feed URL을 설정하고 해당 버전을 설치합니다.


export KRE_FEED=https://www.myget.org/F/aspnetvnext/api/v2
 kvm install 1.0.0-alpha4-10353

예제 소스 받아서 테스트해보기

이전 아티클에서 이야기했던 내용을 좀 더 보강하면, 현재 ASP.NET vNext의 k web 명령은 아직 Windows 환경에서만 실행이 가능한 상태입니다. Mono를 통하여 웹 서버를 시작하고 ASP.NET vNext를 호스팅할 수 있게 하려면 project.json에 별도의 명령어를 추가해주어야 합니다. 물론 이는 추후에 정식 버전이 릴리즈가 될 때 당연히 해결될 문제이므로 걱정하지 않으셔도 됩니다.

git 패키지를 설치하도록 합니다.


sudo apt-get install git

ASP.NET vNext Home 리포지터리에서 예제 소스를 체크아웃합니다.


git clone https://github.com/aspnet/Home.git

늘 그렇듯이, 콘솔 프로젝트를 시작점으로 잡아봅니다. :-)


cd ~/Home/samples/ConsoleApp/
 kpm restore
 k run

그리고 현재 알파 버전의 ASP.NET vNext 기준으로 리눅스에서 웹 서비스를 실행해보기 위해서는 NOWIN 팩토리 패키지를 구성해야 할 필요가 있습니다.


cd ~/Home/samples/
 mkdir Nowin.vNext
 cd Nowin.vNext
 wget https://github.com/davidfowl/HelloWorldVNext/raw/master/src/Nowin.vNext/NowinServerFactory.cs
 wget https://github.com/davidfowl/HelloWorldVNext/raw/master/src/Nowin.vNext/project.json

위와 같이 준비되면, HelloWeb 프로젝트의 project.json에 들어있는 dependencies 섹션과 commands 섹션을 편집기로 조금 수정하여 앞서 만든 NOWIN 팩토리로 서버를 띄울 수 있게 해야 합니다. project.json에 대한 자세한 내용은 Project.json 파일 을 참고하십시오.


cd ~/Home/samples/HelloWeb/

project.json 파일을 편집기로 열고 각각 다음의 사항을 반영하도록 합니다.
•dependencies에 다음을 추가합니다.
“Nowin.vNext”: “”,
•commands에 다음을 추가합니다.
“nowin”: “Microsoft.AspNet.Hosting –server Nowin.vNext”,

project.json 파일을 저장하고, 다음의 명령어를 실행합니다.


kpm restore
 k nowin

앞에서 다운로드 한 Nowin Factory 프로젝트의 코드를 보면 TCP/5000 포트를 웹 리스너 포트로 사용하고 있습니다. 밖에서 호스트 이름과 함께 5000번 포트로 접속하면 웹 페이지가 나타나는 것을 볼 수 있습니다. 그리고 서버를 종료하려면 콘솔에서 아무 키나 누르면 종료가 됩니다.

만약에 원격에서 좀 더 지속적으로 서버의 성능을 측정해보고 싶으시다면 screen 유틸리티를 사용하여 세션을 분리하신 상태에서 위의 명령어를 입력하고, 서버가 떠 있을 때 Ctrl 키를 누른 상태에서 빠르게 a, a, d 키를 누르면 세션이 분리되어 계속 살아있는 서버가 만들어집니다. 이 상태에서 Apache Bench (AB)등의 유틸리티를 사용하여 부하 테스트 등을 해보시는 것도 의미가 있을 것입니다.

참고로, NAT 환경이나 퍼블릭 클라우드 환경에서는 대표 IP 주소에 대한 외부 방화벽 설정을 열어주셔야 밖에서도 접속이 가능합니다.

마무리

ASP.NET vNext는 계속 업데이트가 이루어지고 있는 상태이며, Mono 런타임의 개선에 따라 리눅스와 맥 OS X에서 ASP.NET vNext를 사용하는 것이 좀 더 쉬워지고 간편해질 전망입니다. 더 많은 기대를 해도 좋지 않을까 생각합니다. :-)

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 8. 24. 09:37

번역: 남정현


날짜: 2014-08-24


이 문서에 대하여

이 문서는 2014년 8월 19일에 작성된 https://github.com/aspnet/Home/wiki/Project.json-file 의 내용을 한국어로 번역한 것으로, 원본 문서 작성자는 ASP.NET vNext 팀입니다. 오역, 어색한 부분, 매끄럽지 않은 부분이 있을 경우 알려주시면 적극적으로 반영하도록 하겠습니다.

스키마

http://json.schemastore.org/project

의존성

 

 

의존성 섹션은 여러분의 애플리케이션이 사용하는 모든 의존성들을 열거합니다. 이름과 버전으로 정의할 수 있으며, 런타임 로더가 어떤 것을 반드시 로드해야 할지 결정합니다. NuGet 패키지, 소스 코드 등이 될 수 있습니다.

[json]
 {

“dependencies”: {

“Microsoft.AspNet.ConfigurationModel”: “0.1-alpha-*”,

“SomeProject”: “”

}

}
 [/json]

여기서 사용할 수 있는 또 다른 기능으로 아래와 같이 더 구체적으로 의존성 설정을 지정하는 것이 가능합니다.

[json]
 {

“dependencies”: {

“Microsoft.AspNet.ConfigurationModel”: { “version”: “0.1-alpha-*”, “options”: “private” },

“FakeToolingPackage” : {“version”: “0.1”, “options”: “dev”},

“SomeProject”: “”

}

}
 [/json]

참조에는 여러 가지 다른 종류들이 있을 수 있습니다.

•Private – 의존성을 인텔리센스나 혹은 컴필레이션에 노출하지 않도록 할 수 있습니다.

 

•Bago (Build and go away) – 이 참조를 컴파일한 후에 대상 프로젝트 안으로 같이 컴파일됩니다.

 

어떻게 의존성 버전이 선택되는지에 대한 더 상세한 정보는 https://github.com/aspnet/Home/wiki/Dependency-Resolution 에서 자세히 확인할 수 있습니다.

Configurations 섹션

Configurations는 컴필레이션 설정에 대한 이름이 붙여진 그룹 항목들입니다. 실행 시점에는 기본으로 주어지는 설정 두 가지가 있는데, 바로 Debug와 Release입니다. 이들 설정을 project.json에 필요에 따라 다시 설정하거나 새로운 설정을 더 추가하는 것도 가능합니다.

[json]
 {

“configurations”: {

“Debug”: {

“compilationOptions”: {

“define”: ["DEBUG", "TRACE"],

“debugSymbols”: “full”

}

},

“Release”: {

“compilationOptions”: {

“define”: ["RELEASE", "TRACE"],

“optimize”: true,

“debugSymbols”: “pdbOnly”

}

}

}

}
 [/json]

Frameworks 섹션

어느 프레임워크를 대상으로 개발된 프로그램인지 정의하고, 해당 구성에서 참조하는 의존성들을 dependencies에서 정의할 수 있습니다. 아래 코드 조각에서는 데스크톱 (net45) 또는 Core CLR (k10) 중 하나를 사용할 것입니다. Core CLR은 BCL을 만들기 위해서 더 많은 참조들에 대한 의존성을 가집니다.

[json]
 {

“frameworks”: {

“net45″: {},

“k10″: {

“dependencies”: {

“System.Collections”: “4.0.0.0”,

“System.Collections.Concurrent”: “4.0.0.0”,

“System.ComponentModel”: “4.0.0.0”,

“System.Linq”: “4.0.0.0”,

“System.Reflection”: “4.0.10.0”,

“System.Runtime”: “4.0.20.0”,

“System.Runtime.InteropServices”: “4.0.10.0”,

“System.Threading”: “4.0.0.0”,

“System.Threading.Tasks”: “4.0.0.0”

}

}

}

}
 [/json]

Sources 섹션

sources 섹션은 컴파일해야 할 소스 코드들을 지정합니다.

[json]
 {

“code”: “*.cs”,

“exclude”: “buggy/**/*.cs”,

“resources”: “embed/**/*.*”

}
 [/json]

공유 파일 섹션

여러 프로젝트에서 의존하는 코드를 공유할 수 있습니다. 공유 어셈블리 정보 같은 내용을 담고 있는 코드를 공유하기 위해서, 공통 프로젝트를 만들고, 이 프로젝트에서 공유 파일 섹션을 포함하도록 공유할 코드를 참조하게 하면 됩니다. 그 후에는 새로 만든 공통 프로젝트를 참조하는 프로젝트라면 항상 프로젝트에 해당 파일들이 같이 포함되어 컴파일이 이루어지게 됩니다.

[json]
 {

“shared”: “*.cs”

}
 [/json]

컴파일 옵션

컴파일 옵션에서는 Roslyn으로 전달할 설정을 지정할 수 있습니다. 여기서 언어의 버전을 선택할 수 있습니다.

[json]
 {

“compilationOptions”: {

“define”: ["SOMETHING"],

“allowUnsafe”: true,

“warningsAsErrors” : true,

“languageVersion”: “experimental”

}

}
 [/json]

명령

K.cmd를 실행할 때에는 실행하려는 명령의 이름을 지정할 수 있습니다. 아래 코드 조각은 K web이라는 명령어를 실행할 때 셀프 호스트를 시작하도록 하고 있고, K test라는 명령어를 실행할 때에는 모든 단위 테스트를 실행하도록 하고 있습니다.

[json]
 {

“commands”: {

“web”: “Microsoft.AspNet.Hosting server.name=Microsoft.AspNet.Server.WebListener server.urls=http://localhost:5001″,

“test”: “Xunit.KRunner”

}

}
 [/json]

스크립트

KPM에서 어떤 일을 수행하기 전과 후에 발생하는 이벤트에 간섭하여 추가 작업을 지시할 수 있습니다.

[json]
 {

“scripts”: {

“prebuild”: “echo before building”,

“postbuild”: “echo after building”,

“prepack”: “echo before packing”,

“postpack”: “echo after packing”,

“prerestore”: “echo before restoring packages”,

“postrestore”: “echo after restoring packages”

}

}
 [/json]

그리고 사용 가능한 변수들은 다음과 같습니다.
</p><p>%project:Directory% - 프로젝트 디렉터리 경로
</p><p>%project:Name% - 프로젝트 이름
</p><p>%project:Version% - 프로젝트 버전<br />

메타데이터

프로젝트에 대한 메타데이터를 기록할 수 있습니다.

[json]
 {

“version”: “0.1-alpha”,

“authors”: ["John Doe"],

“description”: “A wonderful library that does nice stuff”

}
 [/json]

Entity Framework 프로젝트에서 가져온 project.json 파일의 한 예시

[json]
 {

“version”: “0.1-alpha-*”,

“compilationOptions”: {

“warningsAsErrors”: true

},

“dependencies”: {

“Microsoft.Bcl.Immutable”: “1.1.18-beta-*”,

“Microsoft.AspNet.ConfigurationModel”: “0.1-alpha-*”,

“Microsoft.AspNet.DependencyInjection”: “0.1-alpha-*”,

“Microsoft.AspNet.Logging”: “0.1-alpha-*”,

“System.Data.Common”: “0.1-alpha-*”

},

“code”: “**\\*.cs;..\\Shared\\*.cs”,

“frameworks”: {

“net45″: {

“dependencies”: {

“System.Runtime”: “”,

“System.Collections”: “”

}

},

“k10″: {

“dependencies”: {

“System.Collections”: “4.0.0.0”,

“System.Collections.Concurrent”: “4.0.0.0”,

“System.ComponentModel”: “4.0.0.0”,

“System.Console”: “4.0.0.0”,

“System.Diagnostics.Contracts”: “4.0.0.0”,

“System.Diagnostics.Debug”: “4.0.10.0”,

“System.Globalization”: “4.0.10.0”,

“System.Linq”: “4.0.0.0”,

“System.Linq.Expressions”: “4.0.0.0”,

“System.Linq.Queryable”: “4.0.0.0”,

“System.Reflection”: “4.0.10.0”,

“System.Reflection.Extensions”: “4.0.0.0”,

“System.Resources.ResourceManager”: “4.0.0.0”,

“System.Runtime”: “4.0.20.0”,

“System.Runtime.Extensions”: “4.0.10.0”,

“System.Threading”: “4.0.0.0”,

“System.Threading.Tasks”: “4.0.10.0”

}

}

}

}
 [/json]

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 8. 10. 09:34

ASP.NET Custom Loader (코드 네임 Helios)는 기존의 System.Web 기반의 전통적인 ASP.NET 프레임워크를 대체하는 기술로, IIS 파이프라인에 직접 관여하여 System.Web에 의존적이지 않은 최신 ASP.NET 개발 프레임워크들 (OWIN, Nancy, FubuMVC 같은)의 실행에 필요하지 않은 System.Web 및 관련 파이프라인을 생략하고 직접 이들 프레임워크를 중개할 수 있도록 도와주는 도우미입니다.

 

 

이 글을 작성 중인 2014년 8월 현재 최신 버전은 1.0 알파 버전으로, 조만간 출시될 ASP.NET vNext와 함께 릴리즈가 될 것으로 예상되는 기술입니다. 현재는 Windows Server 2008 R2 및 Windows 7 이상의 운영 체제를 정식으로 지원하며, IIS 및 IIS Express의 경우 7.5 버전 이상을 지원합니다. 정식 출시에 맞추어, Windows Server 2008과 Windows Vista, 그리고 IIS 7도 지원 대상에 포함될 것으로 예상됩니다.

ASP.NET Custom Loader의 실행 성능 개선 효과에 대해서는 여러 블로그 아티클이 있지만, http://blogs.msdn.com/b/webdev/archive/2014/02/18/introducing-asp-net-project-helios.aspx 의 내용을 살펴보실 것을 권합니다.

이 글에서는 ASP.NET Custom Loader의 동작 원리에 대해서 간단하게 설명을 하려고 합니다.

ASP.NET Custom Loader의 구성 파일 내역

ASP.NET Custom Loader는 다음과 같이 구성됩니다.
•AspNet.Loader.dll
•Microsoft.AspNet.Loader.IIS.dll
•Microsoft.AspNet.Loader.IIS.xml
•x86\Microsoft.AspNet.Loader.IIS.Interop.dll
•amd64\Microsoft.AspNet.Loader.IIS.Interop.dll

일단 위의 파일들이 bin 폴더에 복사되면, 특별히 web.config에서 수정하는 내용 없이 곧바로 기능이 활성화됩니다. 또한 이름에서도 알 수 있듯이, 지원 가능한 아키텍처는 x86과 amd64 아키텍처만 가능하며, 아이태니엄 및 ARM 아키텍처는 지원되지 않습니다.

실제 웹 프레임워크와의 연결

이제 중요한 것은 위의 Loader가 그 다음으로 주선할 웹 프레임워크를 지정하는 과정인데, 각 웹 프레임워크 별로 HttpApplicationAttribute를 어셈블리 수준에 적용하여 자신들의 웹 프레임워크 기술을 사용하는 개발자들을 위한 부트스트랩을 제공합니다. ASP.NET Web Loader는 이 정보를 찾아 연결을 시도하게 됩니다.

대강 아래와 같은 모양새를 가진 부트스트랩이 있어야 합니다. (물론 필요하다면 직접 만들 수도 있습니다.)

[assembly: HttpApplication(typeof(YourClass))]
 public class YourClass : HttpApplicationBase
 {
 }

이런 목적에 부합하는 기능과 관련된 종속 기능들을 OWIN에서는 아래 어셈블리들에 나누어 제공하고 있습니다.
•Microsoft.Owin.Host.IIS.dll
•Microsoft.Owin.Host.IIS.xml
•Microsoft.Owin.Host.IIS.Security.dll
•Microsoft.Owin.Host.IIS.Security.xml
•Microsoft.Owin.Hosting.dll
•Microsoft.Owin.Hosting.xml

기존에 OWIN 기반으로 배포한 응용프로그램이 있다면 ASP.NET Custom Loader를 배포한 다음 위의 어셈블리 파일들을 추가로 복사해야 ASP.NET Loader가 OWIN 시작 클래스를 연결해줄 수 있습니다.

주의 사항

이 글을 작성하는 현 시점에서 ASP.NET Custom Loader는 알파 버전을 릴리즈한 상태입니다. 그리고 이에 관하여 다음의 제약 사항들이 있습니다.
•Windows Server 2008과 Windows Vista, 즉 IIS 7의 경우 로더 실행 시 보안 알고리즘 관련 알 수 없는 HRESULT가 발생했다는 예외가 나타나면서 초기화가 이루어지지 않습니다. 공식 개발팀의 언급에 따르면, 정식 버전에서 해결할 예정이라고 합니다.
•Web.config에 configSource 애트리뷰트를 사용하여 나누어놓은 구성 파일이 있을 경우, 잘못된 경로 문자열이라면서 역시 Helios 초기화 도중 예외가 발생합니다. 불편하더라도 알파 버전의 테스트를 위해서는 구성 파일을 web.config 하나로 통합하셔야 테스트할 수 있습니다.

위와 같은 문제점에도 불구하고, 상당한 수준의 성능 개선은 개인적으로 만족스러웠습니다. :-)

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 8. 3. 09:33

OWIN과 미들웨어

OWIN은 .NET Framework를 이용하여 코드를 실행할 수 있는 서버 환경이면 어디서든 사용이 가능한 이식이 편리한 코어 웹 프레임워크입니다. 기본적으로 OWIN은 웹 요청을 받아들이면 주어진 순서대로 구성된 미들웨어 체인을 따라 응답을 만들어내게 됩니다.

.NET Framework를 이용한 웹 응용프로그램 개발도 요즈음에는 다양한 프레임워크를 결합하여 개발하는 것이 요구 사항으로 자리잡고 있으며, 초창기의 .NET과는 달리 더 이상 System.Web 기반의 기술만으로 모든 것을 구현하지는 않습니다.

 

 

대표적으로, 최근 소개된 비동기 양방향 웹 소켓 호환 통신을 지원하는 SignalR의 경우 버전 2.0부터는 System.Web과 독립적으로 움직일 수 있도록 OWIN 위에서 실행되는 구조를 취하게 되었습니다. SignalR을 도입하는데 뜬금없이 OWIN Startup이라던지 하는 코드를 보면서 생소하다는 느낌을 받으셨다면 그게 바로 이것입니다.

재미있는 것은 OWIN 스택 전체는 기존에 ASP.NET을 실행하던 환경과 독립적인 관계를 가집니다. 기존 ASP.NET 환경 위에서 호스팅하는 경우 ASP.NET 환경보다 가장 먼저 앞서서 실행되는 형태로 되어있습니다. 이전처럼 Visual Studio 도구에 종속적인 방식으로 프로그래밍하는 것이 아니라, 내가 어떤 웹 기술을 사용할 것인지 Startup 클래스에서 정하여 선택적으로 사용할 수 있게 됩니다.

OWIN 기반의 응용프로그램 처음 만들어보기

앞에서 잠시 이야기한 것처럼 OWIN은 흔히 콘솔이나 클라이언트 응용프로그램처럼 시작점이 존재합니다. ASP.NET 기반의 응용프로그램으로 말할 것 같으면 Global.asax 같은 역할을 담당한다고 할 수 있습니다. 이것을 OWIN Startup 클래스라고 하며, OWIN Startup 클래스에서 내가 어떤 미들웨어를 사용하여 웹 요청을 처리할 것인지 프로그래밍할 수 있습니다.

빠르게 예제를 만들어보기 위하여, Visual Studio에서 비어있는 ASP.NET 프로젝트를 하나 만들어보도록 하겠습니다. (MVC나 Web Form 등은 일절 필요하지 않습니다.)

참고로, 이번 아티클에서 사용하는 Visual Studio 버전은 2013 버전이지만 2012로도 큰 차이 없이 작업할 수 있습니다.

새 웹 프로젝트를 만들면서 아래와 같이 One ASP.NET 프로젝트 대화 상자가 나타나는데, 빈 템플릿으로 하나 만들도록 합니다.

 

그러면 아래와 같이 최소 수준으로 구성된 웹 프로젝트가 만들어지게 됩니다.

 

프로젝트 항목 (위 그림 기준으로 OwinExample)을 마우스 오른쪽 버튼으로 클릭하고 NUGET 패키지 관리 메뉴를 클릭하면 아래와 같이 패키지 설치 대화 상자가 나타납니다. 우측 항목들 중 온라인 항목을 선택하고, 검색어에 “system.web owin”이라고 입력하여 검색합니다.

만약 이 기능을 찾을 수 없는 경우 Visual Studio에 NuGet 패키지 관리자가 설치되어있지 않은 것이므로, http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c 에서 익스텐션을 내려 받아 설치하시면 됩니다.

 

나타나는 검색 결과 항목들 중 Microsoft.Owin.Host.SystemWeb 항목을 클릭하고 Install 버튼을 클릭하면, 종속성 관계에 따라 추가 설치가 필요한 패키지에 대한 정보나 라이선스 동의 등의 추가 확인 대화 상자가 나타날 수 있고, 여기에 모두 승인하시면 ASP.NET 프로젝트에서 OWIN을 사용할 수 있게 준비가 완료됩니다.

설치가 마무리되면 새 클래스를 만듭니다. 아래와 같이 클래스의 내용을 작성하도록 합니다. 혹은 Visual Studio 2013을 사용하는 경우 새 파일 템플릿 중에 OWIN 시작 클래스라는 항목도 있는데 이 항목을 대신 사용해도 됩니다.
using System;
using System.Threading.Tasks;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(OwinExample.Startup1))]

namespace OwinExample
{
    public class Startup1
    {
        public void Configuration(IAppBuilder app)
        {
        }
    }
}


위에 보시는 것이 처음 OWIN 프로그램을 시작할 때 사용되는 시작 클래스입니다. 여기서 Configuration 부분에 OWIN에서 사용할 미들웨어 등에 대한 구성을 추가하면 됩니다.

OWIN 패키지로 설치되는 라이브러리에 대한 이해

엄격하게 말해서 OWIN 어셈블리는 IAppBuilder라고 불리는 인터페이스 하나만을 가지고 있습니다.

 

보시는 것처럼 정말 IAppBuilder라는 인터페이스를 하나만 가지고 있을 뿐입니다. 그런데 이 인터페이스가 OWIN 기반의 응용프로그램을 만들기 위한 여러 가지 기본 사항들을 정의하고 있습니다. 각 멤버들에 대해서 간단히 살펴보면 다음과 같습니다.

•Build(System.Type): 이 인터페이스를 구현하는 클래스의 재량이며, 주어진 Type 형식에 대응되는 객체의 참조를 반환합니다. Microsoft OWIN 구현체의 경우, Map과 MapWhen 관련 기능을 소화하기 위한 목적으로 이 메서드를 활용합니다.

 

•New(): 역시 인터페이스를 구현하는 클래스의 재량이며, 또 다른 IAppBuilder 인터페이스 형식의 객체의 참조를 반환합니다. Microsoft OWIN 구현체의 경우, Map과 MapWhen 관련 기능을 소화하기 위한 목적으로 이 메서드를 활용합니다.

 

•Use(object, params object[]): OWIN 초기 구성에 있어서 가장 중요한 메서드입니다. 요청을 처리하고자 하는 미들웨어를 필요한 만큼 추가할 수 있으며, Use 메서드를 구성 과정에서 부른 순서대로 내부적으로 배열이나 리스트 안에 Use 메서드를 통해 전달받은 미들웨어 진입점들을 보관하고 순서대로 호출이 이루어질 수 있게 합니다.

 

OWIN 기반으로 프로그램을 만드는 과정에서 가장 첫 단추는 바로 이 IAppBuilder의 Use 메서드를 적절하게 활용하는 것입니다.

하지만 이 인터페이스 만으로 프로그래밍을 한다는 것은 정말 최소한의 수준을 만족하는 프로그래밍 기법을 사용하는 것으로, 실제 우리가 관심을 가져야 할 부분과는 거리가 상당히 멀리 떨어져 있습니다. 호스팅 환경이나 웹 프로그래밍에서 응당 필요한 요청과 응답 과정에서의 파이프라인 처리 등 필요한 것이 많습니다. 이런 부분들을 적절히 제공하는 것이 바로 Microsoft가 제안하는 Katana 프로젝트를 통한 프로그래밍입니다. Microsoft.Owin 이라는 이름으로 시작하는 어셈블리들의 시리즈이며, 이것을 사용하여 좀 더 웹 프로그래밍 다운 웹 프로그래밍을 할 수 있게 됩니다.

지금 여러분이 만든 ASP.NET 프로젝트에서 OWIN을 실행할 수 있도록 해준다는 것은 Katana 프로젝트의 일부인 System.Web Loader 프로젝트의 기능입니다. 어떻게 해서 이 클래스가 별다른 설정도 없이 자동으로 모든 요청을 받아들일 수 있는 시작점이 되는가에 대해서는 지금은 자세히 알지 못해도 괜찮습니다.

Hello World 미들웨어 작성

이제 본격적으로 Hello World 메시지를 출력하는 간단한 미들웨어를 하나 작성해보도록 하겠습니다.

Configuration 메서드 안에 다음과 같이 코드를 작성합니다.
app.Run(async (context) =&gt;
{
    await context.Response.WriteAsync("Hello, World!");
});

앞에서 살펴본 Use 메서드를 응용하는 도우미 메서드로 Run 메서드를 Katana에서 제공하고 있습니다. 이 메서드를 사용하면 다른 미들웨어를 실행하지 않고 자기 선에서 요청에 대한 응답을 끝낼 수 있는 미들웨어를 간단한 코드로 쉽게 작성할 수 있게 해줍니다. 여기서는 Hello World라는 문자열을 HTTP 응답으로 내보내도록 하는 코드를 작성해보았습니다.

이 코드를 실행하면 다음과 같이 웹 브라우저에 Hello, World! 라는 문구가 나타날 것입니다.

 

HTTP Query String 받아서 처리하기

Response 속성을 통해 응답을 내보내는 것 말고, 조금 더 나가보기로 하겠습니다. 이번에는 Query String을 입력으로 받아들여 이름을 출력하는 코드를 조금 더 작성해보기로 하겠습니다.

문자열을 다루는 코드를 조금 추가할 것이므로 네임스페이스에 대한 참조가 다음과 같이 추가되어야 합니다.


using Microsoft.Owin;
using Owin;
using System;
using System.Globalization;

 


그리고 앞에서 작성한 Hello, World! 메시지를 내보내는 미들웨어의 코드를 다음과 같이 변경하겠습니다.


var query = context.Request.Query;
var name = query.Get("name");

if (name == null)
    name = "Stranger";

var message = String.Format(
    CultureInfo.InvariantCulture,
    "Hello, {0}!",
    name);

await context.Response.WriteAsync(message);

 


Query 속성의 Get 메서드를 사용하여 Query String 형태로 전달되는 매개 변수의 값을 가져오도록 할 수 있는데, 만약 값을 가져오지 못한다면 NULL 참조를 대신 반환합니다. 이 경우 기본값으로 Stranger로 설정하도록 코드를 작성하였습니다. 그 다음은 익히 잘 아시는 String.Format 메서드를 사용하여 문구를 완성하는 것이고, 응답에 이를 사용하게 됩니다.

그럼 이제 다시 한 번 코드를 실행해보겠습니다. 이름을 지정하지 않은 상태에서는 다음과 같이 실행될 것입니다.

 

그리고 주소 뒤에 ?name=David 라고 입력해봅니다.

 

그런데 여기서 한 가지 궁금한 점이 생깁니다. 보통 웹 프로그래밍을 할 때 흔히 어떤 파일에 대해서 작업을 하고 그 파일을 열어보면 실행된다는 식인데 지금 이 화면을 띄우기까지 어떤 파일 위에서 작업한 것이 아니라 그냥 프로그래밍을 했을 뿐입니다. 다시 말해, 어떤 URL을 경유해서 들어오든 지금 보는 화면과 동작이 적용됨을 뜻합니다. 임의로 아무렇게나 주소를 한 번 넣어보시면 어떤 의미인지 금방 알 수 있습니다. 예를 들어, http://localhost:37339/askbvkkewr?name=David 라고 없는 주소를 임의로 써봅니다.

 

그렇습니다. 어디서 어떻게 들어오든 모든 웹 요청을 전부 방금 만든 미들웨어가 소화를 하도록 되어있는 것입니다. 전통적인 ASP.NET 또는 웹 프로그래밍 환경과는 다르게, OWIN 안에서는 HTTP 서비스 전체를 자유자재로 통제할 수 있습니다.

HTTP POST URL Encoded Form 다루기

마지막으로 한 가지 더 살펴보도록 하겠습니다. Query String도 쉽게 처리할 수 있었는데, 그렇다면 POST로 보내는 요청들도 Katana에서 쉽게 처리할 수 있을까요?

간단하게 요약하면, Katana가 제공하는 Request에 대한 처리는 Request Body를 실시간으로 읽을 수 있는 System.IO.Stream 구현체를 사용하거나, ReadFormAsync() 메서드를 사용하여 URL Encoded Form을 받아들이는 정도를 우선 활용할 수 있습니다. 그러나 흔히 사용하는 Multipart 데이터는 자체적으로 소화할 수 있는 방법은 따로 없고, ASP.NET MVC Web API v2의 도우미 클래스를 사용하여 처리하는 방법을 사용할 수 있습니다. 일단 여기서는 URL Encoded Form의 형태로 받아서 처리할 수 있는 예를 한 번 다루어보도록 하겠습니다.

URL Encoded Form으로 들어오는 요청을 손쉽게 만들기 위하여, 아래와 같이 간단한 웹 페이지를 하나 만들어보도록 하겠습니다. <FORM> 태그의 ACTION 속성 값에 들어갈 URL은 현재 여러분이 만든 OWIN 응용프로그램의 웹 주소로 적절하게 치환하셔야 정상적으로 전송이 됩니다. 이 주소를 확인하는 방법은 방금 만든 프로젝트의 속성을 연 다음, 웹 탭을 클릭하는 것입니다. 참고로 이 주소는 프로젝트 생성 시점에 동적으로 할당되어 프로젝트 설정으로 저장되는 값으로, 개발 과정 중에는 계속 같은 포트 값을 유지할 수 있습니다.

 

위의 주소를 확인하여 아래와 같이 HTML 페이지를 작성하도록 합니다.

<!DOCTYPE html>

<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8" />
    <title>Hello, World!</title>
</head>
<body>
    <form action="http://localhost:37339/" method="post"
          enctype="text/plain">
        <label for="name">Your Name: </label>
        <input type="text" name="name" id="name" />
        <input type="submit" value="Hello?" />
    </form>
</body>
</html>

 

여기서 중요한 것은 <FORM> 태그의 METHOD 속성의 값이 POST라는 것과 ENCTYPE 속성이 “application/x-www-form-urlencoded”로 지정된 것입니다. 이렇게 지정해야 OWIN에서 데이터를 가져올 수 있습니다.

그리고 Form 데이터를 받아서 처리할 수 있도록 아래와 같이 수정합니다.

//var query = context.Request.Query;
var form = await context.Request.ReadFormAsync();
var name = form.Get("name");

 


특별히 바뀐 것은 없습니다. context.Request.Query 속성 대신 context.Request.ReadFormAsync() 비동기 메서드를 호출하여 얻은 결과로 나오는 객체를 활용하도록 하는 것이고 그 이후는 동일한 로직을 사용합니다.

테스트를 위해서 앞에서 만든 HTML 페이지를 브라우저로 열어봅니다. 텍스트 상자 안에 임의의 이름을 넣고 Hello? 버튼을 클릭하면 다음과 같이 입력한 문자열이 반영된 응답이 나오게 됩니다.

 

만약 HTML 폼에서 “application/x-www-form-urlencoded” 대신 “multipart/form-data”를 지정할 경우 ReadFormAsync() 비동기 메서드는 비어있는 컬렉션을 반환합니다.

다음 아티클에서는

다음 아티클에서는 이 특성을 사용하여 좀 더 세밀하고 다양한 미들웨어 프로그래밍을 다루어보도록 하겠습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 7. 15. 09:32

OWIN 개요

요즈음 .NET 기반 웹 개발에서 주목을 받고 있는 것은 ASP.NET MVC나 ASP.NET Web API가 아니라 사실 OWIN이 아닐까 생각합니다. OWIN은 Open Web Interface for .NET을 줄여서 쓴 말로 .NET Framework 기반의 웹 개발 프레임워크들을 더 다양하게 고르고 조합할 수 있도록 도와주는 표준화된 인터페이스를 말합니다. (http://owin.org/ 에서 자세한 정보를 볼 수 있습니다.)

왜 OWIN인가?

OWIN이 주목을 받는 이유는, 이전에 다루던 웹 응용프로그램 개발 환경과는 달리, 목적과 상황에 맞게 더 정밀하고 더 세세한 웹 프로그래밍이 가능하기 때문입니다. 이전의 ASP.NET 만을 사용하던 개발 환경에서 가장 큰 문제가 되었던 것은 의외로 단순한 부분들로부터 나타나는 것들이 많았는데, 예를 들어 파일 업로드에 대한 것이 가장 큰 문제였습니다.

 

 

인터넷 속도가 빠르지 않은 지역에서의 사용을 기준으로 잡혀있는 파일 업로드 제한과 공간 할당 정책이 기본값이었기 때문에, 대용량 파일 업로드가 필요한 때에는 이것을 처리하기 위해 ASP.NET의 파일 업로드 제한을 다시 정의할 수 밖에 없었고, 사실 이것은 면밀하지 못한 설정이 되어서 보안 리스크가 될 수 밖에 없었습니다. 그리고 .NET Framework 2.0 서비스팩 적용 이전까지는 놀랍게도 파일 업로드를 임시 저장소가 아닌 메모리 공간에 저장하는 방식이어서 대용량 파일 업로드를 할 경우 서버 자원이 고갈되는 (!) 문제까지 있었습니다.

지금은 임시 디스크에 저장한 후에 파일 업로드가 다 되었음을 알려주는 식이 되었지만, 여전히 세밀한 파일 업로드 제어는 하기 어려운 상태입니다. 그리고 제일 큰 문제는, 환경 설정에서 지원하는 최대 파일 업로드 크기가 여전히 부호있는 32비트 정수값 (.NET의 표준은 부호있는 정수 사용을 권합니다.)의 범위에 있어서 최대 업로드가 2GB 밖에 가능하지 않습니다. 이를 해소하기 위해서 청크 방식의 업로드 등을 이용해야 하지만 웹 브라우저가 지원하지 않으면 별도 클라이언트를 이용할 수 밖에 없는 상태입니다. 다시 말해, 간단한 파일 업로드를 필요로 한다면 ASP.NET이 여전히 편리하지만, 복잡해진 요구 사항을 맞추기 위해서는 턱없이 커스터마이징 변수가 부족한 것입니다.

비단 이 문제 뿐 아니라 ASP.NET이 편의를 위하여 제공하는 기능이 요즈음에 들어서는 오히려 복잡한 요구 사항 개발에 방해 요소가 되는 일이 많습니다. 그리고 이러한 요구 사항을 만족하기 위해 ASP.NET의 기본 설정을 변경하는 것 자체가 보안 리스크가 됨은 물론, ASP.NET 자체에 대한 강력한 커플링이 발생하여 유지 보수에 큰 문제가 되곤 합니다. 왜냐하면 커플링이 강력해질수록 ASP.NET에 사소한 업데이트나 패치 하나가 전체 프로그램에 큰 영향을 줄 개연성이나 확률이 더 높아지기 때문입니다. 그래서 기존 ASP.NET의 영역을 유지하면서, 안전하고 더 편리하게 복잡한 요구 사항을 쉽게 맞출 수 있는 방법이 필요해지게 되는데, OWIN이 여기에 대한 확실한 답이 됩니다.

OWIN의 기본 개념

OWIN 그 자체는 HTTP 요청을 받아들이고, 응답을 결정하는 행위를 규정하는 스펙을 .NET 4.0을 기반으로 제공하는 것이 전부이며, 모든 처리 과정은 미들웨어를 통해 이루어지는데, 미들웨어 간의 호출에 사용되는 것은 아주 단순한 Dictionary 자료 구조입니다. (http://owin.org/spec/owin-1.0.0.html)

OWIN-5

OWIN이 하는 일 자체는 위의 그림 (클릭하면 크게 볼 수 있습니다.)이 전부입니다. 여러 개의 미들웨어 구성 요소를 OWIN 프로그램을 시작할 때 등록하고, 미들웨어의 입장에서는 자신이 처리할 수 있는 요청인 경우에만 요청을 가로채고, 그 외에는 다음 미들웨어로 호출을 넘겨주는 것이 전부입니다. 만약 모든 미들웨어를 지나 끝까지 도착했음에도 불구하고 처리할 수 있는 미들웨어가 없다면, OWIN을 어떤 환경에서 사용하는지에 따라 다음 동작이 결정됩니다.
•만약 OWIN 그 자체를 바로 호스팅하는 베어본 서버 환경이라면 익히 알려진대로 404 오류 코드를 내보내거나 빈 응답을 반환할 수 있습니다.
•만약 ASP.NET 환경에서 OWIN을 얹어서 사용하는 형태라면, OWIN 환경 자체가 다른 ASP.NET 모듈보다 먼저 실행되는 ASP.NET 모듈이기 때문에, 다음 ASP.NET 모듈로 넘어가게 됩니다. 기존에 개발한 ASP.NET 웹 프로젝트 위에 OWIN을 추가 장착하게 되면 이런 형태가 됩니다.
•만약 ASP.NET Native Loader 위에서 OWIN을 얹어서 사용하는 형태라면, OWIN 환경 자체를 완전히 분리된 환경에서 실행하는 것을 의미합니다.

각각의 경우를 따로 설명하는 데에는 이유가 있습니다. 이어서 말씀드리면 다음과 같습니다.

세 가지 실행 환경과 가능성

첫 번째는 OWIN과 미들웨어들을 묶어서 어디에서든 웹 서비스를 시작할 수 있음을 말씀드리고 싶어서입니다. 즉, 정상적인 .NET Framework 실행 환경을 갖추고 클라이언트와 서버 사이의 연결을 정확하게 처리하도록 만들어주기만 한다면 서버 OS가 윈도우이든 리눅스이든 맥이든 상관이 없으며 (리눅스와 맥은 Mono 덕분이라고 할 수 있겠습니다.), 전혀 다른 형태로 구현된 웹 서버일지라도 OWIN으로 정확하게 연결을 전달할 수 있다면 이론상으로 .NET 기반이 아닌 서버 플랫폼 환경에서도 얼마든지 .NET 서버 응용프로그램을 호스팅할 수 있는 상태가 됩니다.

두 번째는 기존에 가지고 있던 ASP.NET 웹 프로젝트에 얼마든지 OWIN 응용프로그램을 추가 장착할 수 있음을 의미합니다. System.Web이라고 불리는 레거시 ASP.NET 웹 프레임워크의 종속성에서 완전히 벗어나지는 못하지만, 그 규칙 안에서라면 기존 ASP.NET의 기술과 완전히 무관하게 독자적인 미들웨어를 개발하고 수행하는 것이 가능하므로, 전송 프로토콜 수준에서 HTTP 응답을 재정의하는 것도 가능하고, 실시간으로 파일 업로드에 개입할 수도 있습니다. 기존 ASP.NET 웹 프로젝트를 해치지 않고 얼마든지 복잡한 기능을 쉽게 추가할 수 있음을 뜻합니다.

마지막 세 번째 방법은 기존의 ASP.NET 실행 환경을 사용하지 않고, IIS에 최소 버전의 .NET 실행 환경을 직접 주입하여 실행 속도를 획기적으로 개선하고, 기존의 System.Web 관련 설정을 모두 무시하는 방식입니다. 이것은 Project Helios라고 불리던 것을 제품화한 것으로, 실행 속도와 메모리 점유율을 획기적으로 개선하여 응답 성능을 비약적으로 개선시킬 수 있습니다. 기존 ASP.NET 프로젝트와 독립된 형태로 웹 프로젝트를 개발하면서 IIS 위에서 OWIN 프로그램을 실행하려는 경우 이 방식을 이용하여 성능을 극대화할 수 있습니다.

다음 아티클에서는 OWIN의 내부 구조와 미들웨어를 프로그래밍하는 방법을 몇 가지 살펴보도록 하겠습니다.

이미지 출처: http://byterot.blogspot.kr/2013_08_01_archive.html

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2013. 10. 12. 21:00

요즈음은 Infrastructure as a Service를 이용하여 VM의 Mobility를 통한 클라우드 서비스 사업자 간 이동 및 이전이 요즈음 주목 받고 있습니다. 익히 잘 알려진대로, Windows Azure의 경우 사설 혹은 기업 데이터센터 구축을 위하여 사용하는 Hyper-V 환경의 가상 PC를 Windows Azure로 진출시키거나 역으로 가져오는 등의 기능은 상당히 잘 알려져 있어서 많이들 이용하고 계실 것 같습니다.

그런데 Platform as a Service는 이런 부분에서 확실한 이동성을 보장하기 많이 어렵다는 것이 문제가 됩니다. 특히 비즈니스 로직을 내부에 많이 포함하고 있는 클라우드 응용프로그램일 수록 해당 클라우드 서비스에 종속적이기 때문에 클라우드 사업자간 이동이 훨씬 더 어렵습니다. 물론, 이를 극복하기 위하여 Dependency Injection이나 Inversion of Control을 이용하여 클라우드 사업자들이 제공하는 SDK의 공통 분모를 추출하여 그 대상으로 삼는 것도 가능한 전략이기는 하겠습니다만 사실 쉽지 않습니다.

좀 더 현실적이고 직관적인 방법이 없을까 많이들 고민하시는 데에 어느정도 도움이 될까 하여 한 가지 방안을 제시해 보겠습니다. 바로 ASP.NET과 Web Deploy를 이용한 개발입니다.

왜 ASP.NET과 Web Deploy를 사용하는가 - ASP.NET을 사용할 수 있는 환경의 다양성

PHP, Node.js, Ruby on Rails 등 웹 세계에서 유명한 프레임워크나 개발 환경이 많이 있습니다만 상대적으로 ASP.NET은 늘 저평가되어있습니다. 특히 ASP.NET을 버전 1.0~2.0 시절의 Web Form과 연결하여 선입견을 가지는 경우가 무척 많습니다. 그렇지만 이전부터 필자가 계속 강조해왔던 NuGet, Web Developer Express 등 다양한 OSS에 친화적인 기술들과의 결합과 ASP.NET MVC의 등장은 이 선입견에 묻혀서 거의 알려지지 않은 경우가 많습니다. (특히 국내에서는 더욱 그렇지요.)

그러나 이런 와중에 생각보다 ASP.NET의 입지는 넓습니다. Microsoft 기술과 가장 친화적이지 않을 것 같은 Amazon의 BeansTalk가 ASP.NET Web Deploy 패키지를 사용한 PaaS 배포 기법을 전면에서 지원하고 있으며, 사용 중인 환경이 Linux인 경우 다양한 방법으로 Mono ASP.NET 런타임과 결합하여 ASP.NET 웹 사이트를 호스팅할 수 있습니다. 그리고 Windows Azure는 Web Site와 Cloud Service를 이용하여 각각 웹 사이트를 호스팅할 수 있는 방법을 제공합니다. 멀리 가지 않아도 시중에 나와있는 웹 호스팅 서비스는 모두 FTP를 통한 ASP.NET 웹 사이트 배포까지 지원합니다. 수단은 얼마든지 많고, 남는 것은 전략의 수립에 관한 부분만이 남는 셈입니다.

왜 ASP.NET과 Web Deploy를 사용하는가 - 단일 코드 베이스 유지

ASP.NET을 이용하여 독립적으로 실행할 수 있는 Web Application Project를 만들어두면, Public Cloud만을 이용해서 서비스를 구축하였을 때 간간히 문제가 발생하는 특정 데이터센터, 혹은 특정 클라우드 서비스의 장애로 인해서 전체 서비스가 중단되는 사고로부터 좀 더 자유로워질 수 있습니다.

여러 위치에 분산된 응용프로그램을 배포하는 것은 기본적으로 매우 어려운 작업입니다. 그리고 이 어려운 작업의 난해함을 지수승으로 더 복잡하게 만드는 것은 바로 클라우드 서비스 사업자 간의 고유한 기능 집합 때문입니다. 이 문제를 해결하기 위해서는 사업자 간 이해 관계가 비교적 덜 연결되어있으면서도 구성의 차이가 거의 없는 기술을 택하는 것이 바람직한데, 여기에 들 수 있는 후보로는 ASP.NET을 포함하여 다수의 기술들이 있습니다. 그 중에서도 오늘 소개하려는 ASP.NET은 수준 높은 IDE 지원과 다양한 OSS 프로젝트와의 연계가 가능하기 때문에 유용한 점이 많습니다.

왜 ASP.NET과 Web Deploy를 사용하는가 - 배포 시의 문제점을 최소화

기능 상의 유용함 이외에도, 스스로 스케줄링을 해야 하는 Daemon Type의 서비스 프로세스가 아닌 RPC나 REST 형태의 시스템일 경우 ASP.NET을 사용하여 프로그래밍하고 Visual Studio의 지원을 받을 때의 큰 이점이 하나 더 있습니다. 바로 배포 시의 문제점을 최소화할 수 있다는 것입니다.

ASP.NET Web Deploy 및 관련 프로세스들은 패키지로 만들 때, 종속성에 관련된 모든 문제를 예방할 수 있도록, 웹 프로젝트와 연관성이 있는 모든 종속성 관계 상의 파일을 자동으로 복사하여 패키지에 포함시키는 정책을 사용합니다. 이러한 특징 때문에, ASP.NET MVC나 Razor의 최신 버전이 처음 .NET Framework가 배포된 이후에 바뀌더라도 최신 기능을 사용하면서도 배포 상의 DLL 버전 차로 인한 문제가 발생할 가능성이 높지 않습니다.

클라우드 서비스 별 배포 방법 - Amazon BeansTalk

우선 Amazon BeansTalk의 경우를 예로 들어보도록 하겠습니다. Amazon BeansTalk는 Visual Studio에 추가 기능으로 설치할 수 있는 Toolkit을 통한 배포/모니터링과 Management Console (Web)를 통한 패키지 파일 업로드 방식의 배포를 모두 지원합니다.

웹 프로젝트를 만들고, 아래 화면과 같이 배포 프로필을 Web Deploy 패키지로 만드는 것으로 설정한 다음, 지정된 위치에 패키지 파일을 만들도록 합니다. 패키지 파일은 ZIP 파일입니다.

만들어진 파일을 AWS Management Console로 이동하여 다음과 같이 업로드를 시작합니다.

업로드 완료 후 배포 프로세스가 시작되면 다음과 같이 진행 상황이 표시됩니다.

잠시 기다리면 다음과 같이 정상 배포가 완료되었음을 알리는 화면이 표시됩니다.

그리고 로드 밸런서 앞으로 부여된 FQDN 앞으로 접속하면 다음과 같이 로컬 개발 환경에서 개발할 때와 비슷한 응용프로그램이 실제 클라우드 서비스에서 실행 중인 것을 볼 수 있습니다.

BeansTalk의 멤버 노드로 참여하는 VM 인스턴스들이 있다면 여느 PaaS 플랫폼들과 마찬가지로 모든 배포를 자동화하여 처리하므로 배포 프로세스의 상당 부분을 쉽게 완료할 수 있습니다.

클라우드 서비스 별 배포 방법 - Azure Web Site

이번에는 Azure Web Site를 위한 배포 방법을 살펴보도록 하겠습니다. Visual Studio에서 앞의 경우와 마찬가지로 웹 게시 대화 상자를 띄운 다음, 가져오기 버튼을 클릭합니다.

 

처음 이 기능을 실행하면 배포 프로필을 한 번도 사용한 적이 없으므로 아래와 같이 빈 목록이 나타나게 됩니다. Windows Azure 구독 추가 링크 (드롭 다운 상자 아래)를 클릭합니다.

 

Windows Azure 구독 가져오기 대화 상자가 나타나면 구독 파일 다운로드 링크를 클릭합니다.

 

로그인 페이지에서 로그인을 완료하면 로그인한 Microsoft ID와 연결된 모든 Windows Azure Web Site 프로필 정보를 취합한 통합 프로필 파일의 다운로드를 시작하게 됩니다.

 

앞의 대화 상자로 되돌아와서, publishsettings 파일을 다시 지정하고, 가져오기 버튼을 클릭합니다. 잠시 기다리면 지정한 Live ID로 만든 여러 가입 상의 여러 Azure Web Site에 대한 정보가 한번에 나타납니다. 관리자 권한만을 가지고 있었다고 할지라도 여기에 한번에 나타나므로 손쉽게 배포를 진행할 수 있고, 이 과정 이후에 따로 웹 사이트를 새로 만들더라도 다시 이 대화 상자만 띄우면 목록이 새로 업데이트됩니다.

 

이와 같이 설정을 마무리하고 연결에 이상이 없는지 유효성 검사 버튼을 클릭하여 녹색 체크 마크가 나타나면 배포를 위한 연결이 성립된 것으로, 계속 진행해도 좋습니다.

 

클라우드 서비스 별 배포 방법 - Azure Cloud Service / Web Role

기존에 만들어진 ASP.NET 웹 사이트 프로젝트를 Web Role로 변환하여 내보내는 작업은 생각보다 어렵지 않습니다. 기술적인 고려 사항을 제외하면, Web Role용 프로젝트는 Beans Talk의 경우와 마찬가지로 Azure Cloud Service만을 위해서 무언가 꼭 추가해야 하거나 심각하게 변경해야 할 것이 전혀 없습니다.

Windows Azure Tools 최신 버전을 설치한 다음, 클라우드 서비스 프로젝트를 생성할 때 아래와 같이 아무것도 추가하지 않은 상태로 확인 버튼을 클릭합니다. 기존 프로젝트를 가져오기 위해서입니다.

 

그러면 멤버 역할이 없는 상태의 빈 클라우드 서비스 프로젝트가 만들어지게 됩니다. 이제 솔루션 탐색기의 역할 폴더를 오른쪽 버튼으로 클릭하고 아래 그림과 같은 순서로 팝업 메뉴를 접근합니다.

 

그러면 아직 지금 클라우드 서비스와 연결된 적이 없는 프로젝트의 목록이 나타나게 됩니다. 항목을 선택하여 클라우드 서비스 프로젝트로 가져옵니다.

 

정상적으로 가져오게 되면 다음과 같이 솔루션 탐색기의 클라우드 서비스 프로젝트 아래의 역할 폴더에 프로젝트 이름이 나타나면서 클라우드 서비스의 웹 역할로 등록됩니다.

 

이제 Azure Cloud Service로 배포하기 위하여 패키지를 만들 차례입니다. 패키지를 만들어서 Azure Management Portal을 이용하여 업로드를 해도 좋고, 사전에 인증서 및 계정 연동을 미리 구성하여 Visual Studio에서 진행해도 상관 없습니다. 여기서는 패키지 만들기 기능으로 배포를 해보겠습니다. 클라우드 서비스 프로젝트를 오른쪽 버튼으로 클릭한 다음 패키지 메뉴를 클릭합니다.

 

그러면 배포 대화 상자가 나타나게 됩니다. 각각의 드롭 다운 상자의 의미는 어렵지 않습니다. 서비스 구성이란 클라우드 서비스의 구성을 의미하는 것이고, 빌드 구성은 각 역할과 연결된 C#이나 VB.NET 프로젝트들의 빌드 구성을 의미하는 것으로 양쪽은 서로 독립적인 관계이므로 적절한 옵션을 선택합니다. 설정을 확인한 다음 패키지 버튼을 클릭합니다.

 

빌드 상의 오류가 없으면 탐색기 창이 열리면서 .CSCFG 파일과 .CSPKG 파일이 표시됩니다. 이 파일을 다루기 쉬운 위치로 이동시켜 Windows Azure Management Portal에서 클라우드 서비스를 만든 다음 게시합니다.

 

 

고려할 사항들

전통적인 웹 응용프로그램들과는 달리 클라우드 서비스들은 단일 인스턴스에서 실행하는 것 보다는 로드 밸런싱을 전제로 여러 인스턴스에서 실행하는 것을 기준으로 생각합니다. 그렇기 때문에, 전통적인 웹 기반 응용프로그램을 그대로 전환하는 것은 생각보다 쉽지 않습니다. 특히, 컴퓨터 자체적으로 업로드한 파일을 보관하거나, 서버 컴퓨터의 상태에 의존적인 웹 응용프로그램은 클라우드 기반의 서비스로 이동하기 전에 적절한 보완이 반드시 필요합니다.

그리고 여러 위치에 클라우드 서비스를 배포하고 관리하기 위해서는 자동화된 빌드, 배포, 모니터링 도구가 필요합니다. 각각의 개별 클라우드 서비스들이 제공하는 REST API를 이용하는 도구를 직접 만들 수도 있지만, 재미있는 것은 대다수의 클라우드 서비스 공급자들이 Windows에서는 PowerShell에 대응하는 모듈을 개발하여 배포하고 있다는 것이고, Unix나 Linux에서는 node.js의 클라이언트 기반 런타임을 개발하여 배포하는 일이 많다는 점입니다.

이러한 특징들을 이용하여, 여러 클라우드 서비스를 손쉽게 관리할 수 있는 노하우를 개발하여 여러분의 개발 및 운영 프로세스에 자연스럽게 통합시킬 수 있을 것으로 기대합니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2013. 10. 5. 15:02

이 글을 읽기 전에 주의 사항 - 이 강좌는 기술적인 내용을 다루기 위하여 작성된 것으로, 여기서 소개하는 내용을 이용하여 스팸 메일을 대량 발송하는데 악용해서는 안됩니다. 또한 필자는 불법적인 소프트웨어 개발 의뢰로 오는 연락에는 회신하지 않습니다. 이 점 주의하여 주십시오.

소셜 네트워크 서비스나 다른 여러가지 의사소통 채널들이 많이 늘어났지만, 오랜 시간동안 변함없이, 그리고 지금까지도 널리 사용되고 꾸준히 활용되는 광범위한 메시징 서비스로 여전히 E-MAIL은 그 값어치를 인정받고 있고 중요성이 유지되고 있습니다.

그런데 요즈음은 원치 않는 메일 수신이 늘어나면서 메일이 정상적으로 도착하게 될 것인지 아닌지 불분명한 메시지 송신을 담보로 해야 하는 경우가 많습니다. 이는 스팸 메일 필터링 규칙이 까다로워진 것에 큰 원인이 있을 것입니다.

대규모로 메일을 보내면서도 안정적인 송신이 가능한 방법으로 요즈음은 대량 E-MAIL 발송 서비스를 많이 이용하곤 합니다. 여러가지 서비스들이 있을 수 있지만, 만약 Windows Azure를 사용 중인 경우, Windows Azure Add-on과 연동되는 SendGrid E-MAIL 서비스를 사용하면 간편하게 SMTP 발송 서비스를 사용할 수 있습니다. 특히 초기 개발을 위하여 사용할 경우 무료로 약 5만여통의 E-MAIL 발송을 테스트해볼 수 있습니다.

SendGrid 신청 방법은 쉽습니다. Windows Azure Management Portal에 접속하여, 신규 Addon 서비스 신청 (2013년 10월 현재 한국어 메뉴에서는 저장소라고 나타나는 부분) 메뉴를 클릭하여 다음과 같이 SendGrid 서비스 신청을 진행하면 됩니다. 무료 서비스를 택하여 계정을 생성할 수 있습니다.

서비스 신청이 완료된 후, SendGrid 서비스 항목에 대한 상세 페이지로 들어가면 다음과 같이 대시보드 화면이 나타납니다. 기본적인 서비스 연결 정보 확인 및 계약 관리를 이곳에서 할 수 있으며, 실제 서비스에 대한 속성은 SendGrid 측의 관리자 페이지로 이동하여 진행할 수 있고, 이 관리자 페이지는 현재 Windows Azure 계정과 1:1 관계로 대응되는 SendGrid 측에서 자동으로 생성한 사용자 계정과 연결되어 Single Sign On으로 연동됩니다.

하단의 도구 모음에서 관리 버튼을 클릭하면 다음과 같이 SendGrid 측의 관리자 페이지로 이동합니다. 

이 관리자 페이지에 등록된 개인 정보는 수동으로 다시 입력해주어야 합니다. 프로필 변경을 통해서 수동으로 변경 가능하며 정확한 정보를 입력해야 나중에 유료 계정으로 업그레이드할 때 문제가 발생하지 않습니다. 그 외에는 메일의 발신 상태, 발신 시 표시할 문구 및 부가 기능 설정 등을 관리할 수 있으므로 서비스 자체에 대한 속성은 여기서 설정하시면 됩니다.

연결 정보 버튼을 클릭하면 위와 같이 SMTP 서버 접속 정보가 나타납니다. 위 정보를 메모하시고 다른 곳에 유출되지 않도록 관리해야 합니다. 이제 C# 프로그램 코드를 이용하여 메일을 보내는 예제 코드를 한 번 만들어보도록 하겠습니다.

string connString = CloudConfigurationManager.GetSetting("DefaultStorage");
var account = CloudStorageAccount.Parse(connString);
var blobClient = account.CreateCloudBlobClient();

var getBlobReferenceFromServer = Task<ICloudBlob>.Factory.FromAsync<Uri>(
    blobClient.BeginGetBlobReferenceFromServer,
    blobClient.EndGetBlobReferenceFromServer,
    new Uri(o as string), null);
var blob = await getBlobReferenceFromServer;

try
{
    using (SmtpClient client = new SmtpClient("smtp.sendgrid.net", 587))
    using (MailMessage message = new MailMessage(
        new MailAddress("rkttu@somewhere.com", "보내는 사람 이름"),
        new MailAddress("someone@abc.com")))
    {
        string[] nameParts = blob.Name.Split(new char[] { '/' }, StringSplitOptions.None);
        string siteIdPart = nameParts[0];
        string userIdPart = nameParts[1];

        message.Subject = String.Format("[Xinics Commons - {0}] {1} has uploaded the content.", siteIdPart, userIdPart);

        message.AlternateViews.Add(AlternateView.CreateAlternateViewFromString(
            String.Format(@"
New content has arrived.

* Site ID: {0}
* User ID: {1}
* Media URL: {2}

", siteIdPart, userIdPart, o), null, MediaTypeNames.Text.Plain));
        message.AlternateViews.Add(AlternateView.CreateAlternateViewFromString(

            String.Format(@"
<p>New file has arrived.</p>
<ul>
<li>Site ID: {0}</li>
<li>User ID: {1}</li>
<li>Media URL: {2}</li>
</ul>

", siteIdPart, userIdPart, o), null, MediaTypeNames.Text.Html));

        client.Credentials = new NetworkCredential(
            "<SENDGRID 사용자 ID>",
            "<비밀 번호>");

        await client.SendMailAsync(message);
    }
}
catch (Exception ex)
{
    Trace.TraceWarning(ex.ToString(), "Exception");
}

클라우드 서비스를 통하여 수신한 BLOB 파일에 대한 정보를 특정 사용자에게 메일로 보내기 위하여 위와 같이 코드를 작성하였습니다. 여기서 굵게 강조표시한 항목들이 바로 연결 정보에서 나타난 부분으로 교체해야 하는 부분입니다.

SendGrid를 통하여 E-MAIL을 보내면 수신 거부 링크를 자동으로 첨부하여 보내줍니다. 수신 거부한 사용자들은 제외하고 메일 발송을 계속 할 수 있으며, 수신 거부 내역은 관리자 페이지를 통하여 쉽게 확인할 수 있습니다. 관리 목적으로 보내는 E-MAIL 말고도 마케팅 관련 메일을 보낼 때도 SendGrid를 사용하면 법률을 준수할 수 있습니다.

주의 사항 - 이 강좌는 기술적인 내용을 다루기 위하여 작성된 것으로, 여기서 소개하는 내용을 이용하여 스팸 메일을 대량 발송하는데 악용해서는 안됩니다. 또한 필자는 불법적인 소프트웨어 개발 의뢰로 오는 연락에는 회신하지 않습니다. 이 점 주의하여 주십시오.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2013. 3. 31. 12:58

안녕하세요. Windows Azure MVP 남정현입니다.

Windows Azure를 사용하면서 여러가지 서비스들을 많이 활용할 수 있지만, 역시 Windows Azure Platform을 제일 잘 설명할 수 있는 것은 확장성에 충분히 대응할 수 있는 유연한 아키텍처가 아닐까 싶습니다. 하지만 이러한 아키텍처를 어떻게 디자인하고 설계하고 수정해야 할지 개념을 잡기가 쉽지 않을 수 있는데요, 이러한 개념을 알기 쉽게 설명해주는 유용한 포스터를 하나 공유합니다.

아래 링크를 클릭하시면 포스터 PDF 파일을 내려받으실 수 있습니다. 포스터를 내려받아서 필요한 부분만을 읽어보시거나, 포스터 인쇄를 주문하셔서 잘 보이는 곳에 붙여놓고 활용하시면 좋을 것 같습니다. :-)

Windows Azure Scalability.pdf

감사합니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2013. 3. 7. 15:52

안녕하세요. Windows Azure MVP 남정현입니다.

Windows Azure Cloud Service에서 실행되는 응용프로그램을 개발하는 과정에서 자주 필요성을 느끼게 되는 기능 중 하나는 지금 코드가 호스팅되는 위치가 실제 Windows Azure 데이터 센터 내인지, 에뮬레이터 내인지, 아니면 일반적인 서버 환경인지를 알고자하는 경우입니다. 이러한 위치 구분이 필요한 이유는 바로 코드 재사용성을 위해서인데, 정확하게 구분하기가 쉽지 않은 점이 있습니다.

여기에 대한 다양한 방법과 Workaround가 존재하지만 추천할만한 코드 Snippet이 있어서 글로 정리하여 올려봅니다.

RoleEnvironment.IsAvailable 속성

실제 Windows Azure Cloud Service 환경이거나 에뮬레이터 환경에서 실행되는 경우를 알아낼 수 있는 방법입니다. 이 방법은 Windows Azure 런타임을 사용할 수 있는지 없는지에 대한 구분으로 활용할 수 있고, 에뮬레이터인지 아닌지는 구분할 수 없습니다.

사용 예시

public static bool EnsureRunningInAzureOrDevFabric()
{
    return RoleEnvironment.IsAvailable;
}

RoleEnvironment.DeploymentId 속성

실제 Windows Azure Cloud Service 상에 패키지를 Deploy해서 실행 중인 경우 이 속성에 Guid 값이 부여되므로 .NET Framework FCL이 제공하는 System.Guid.Parse 정적 메서드를 사용하여 Guid로 파싱할 수 있습니다. 파싱에 성공한다면 실제 환경, 그렇지 않다면 에뮬레이터 환경으로 구분할 수 있습니다.

사용 예시

public static bool EnsureRunningInAzure()
{
    Guid guidId;
    return (RoleEnvironment.IsAvailable &&
        Guid.TryParse(RoleEnvironment.DeploymentId, out guidId));
}

한 번만 조회하기

최대한의 효율성을 기하기 위하여, 단순 작업이지만 같은 작업을 여러번 수행할 필요가 없겠지요. 논리적으로 생각해보면, 이와 같은 사항이 코드를 실행하는 실행 시점에서 변경될 일은 2013년 현재의 Windows Azure 플랫폼 스펙으로 볼 때에는 없습니다. 클라우드 서비스가 아닌 환경으로 실행 중인 가상 컴퓨터가 별도 VM으로 분리 이동하는 기능은 제공되지 않으며, 일반적으로 개발자 환경과 실제 데이터센터 환경 사이에 실시간으로 VM을 주고 받을 일 또한 없습니다. 따라서 위의 메서드에 대한 호출 결과를 정적 생성자를 호출하는 시점에만 부르거나 Lazy Initialization으로 다루더라도 전혀 기능에 이상이 없을 것입니다.

유틸리티 클래스로 만들기

아래의 소스 코드는 http://stackoverflow.com/questions/6160947/how-can-i-determine-if-i-am-running-locally-on-my-pc-or-on-the-cloud 에서 발췌한 것임을 밝혀둡니다.

using Microsoft.WindowsAzure.ServiceRuntime;

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;


namespace Sample

{

    public static class CloudEnvironment

    {

        private static bool m_IsRunningAzure = GetIsRunningInAzure();


        private static bool GetIsRunningInAzure()

        {

            Guid guidId;

            if (RoleEnvironment.IsAvailable &&

                Guid.TryParse(RoleEnvironment.DeploymentId, out guidId))

                return true;

            return false;

        }


        public static bool IsRunningInAzure()

        {

            return m_IsRunningAzure;

        }


        private static bool m_IsRunningAzureOrDevFabric = GetIsRunningInAzureOrDevFabric();


        private static bool GetIsRunningInAzureOrDevFabric()

        {

            return RoleEnvironment.IsAvailable;

        }


        public static bool IsRunningInAzureOrDevFabric()

        {

            return m_IsRunningAzureOrDevFabric;

        }

    }

}



Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2013. 2. 26. 01:01

안녕하세요. Windows Azure MVP 남정현입니다.

간단하지만 간과하기 쉬운 팁을 하나 공유하려고 합니다. Windows Azure Cloud Service를 .NET Framework 기반으로 개발할 때 있을 수 있는 일에 대해 이야기하려고 합니다. Cloud Service에 Worker Role을 추가할 때, Worker Role의 진입점에 관련된 팁을 알려드리기 위하여 글을 씁니다.

Worker Role은 전통적인 .NET 기반 응용프로그램들과는 다르게, 클래스 라이브러리 형식의 어셈블리를 만들고, 그 어셈블리가 클라우드 서비스 패키지 파일에 들어가게 됩니다. Windows Azure Fabric Controller는 관리자가 제출한 클라우드 서비스 패키지 파일을 열어서 그 안에 들어있는 진입점 어셈블리를 찾아서, 해당 어셈블리 내에 존재하는 진입 클래스를 선택하여 서비스 기동을 시작하게 됩니다. 이 과정에서 사용하게 되는 것이 .NET Framework의 핵심 기능들 중 하나인 Reflection입니다.

만약 Worker Role로 만든 어셈블리 안에서 RoleEntryPoint를 기본 클래스로 정의한 클래스가 하나 이상 들어있다면 어떤 일이 벌어질까요? 오름차순으로 정렬했을 때 가장 먼저 열거될 수 있는 클래스만이 진입점으로 선택됩니다.

이러한 문제를 해결하기 위한 방법은 정리하면 다음과 같습니다.

  • 실제로 사용할 Entry Point 클래스 하나만을 Worker Role 어셈블리 안에 배치합니다.
  • 나머지 모든 RoleEntryPoint를 상속받는 클래스들은 다른 클래스 라이브러리에 만들어서 이동시킵니다.
  • Worker Role 어셈블리에서 새로 만든 클래스 라이브러리를 참조합니다.
  • 컴파일이나 런타임 오류가 발생하지 않도록 코드를 정리합니다.

그리고 이 문제가 더 부각되는 것은 Worker Role 어셈블리 안에서 상속 등의 기능을 사용하여 여러 Entry Point를 구현하게 될 경우입니다. 실제로 사용하고픈 Entry Point는 따로 있지만 이름의 순서 상 다른 진입점이 먼저 나오면 이상하게 동작하는 것 처럼 보이게 됩니다. 여기에, 만약 먼저 검색되는 Worker Role EntryPoint 클래스가 추상 클래스이거나 인수 없이 호출하는 기본 생성자를 제외시킨 경우 서비스가 전혀 실행되지 않을 수도 있습니다. 이런 경우 이 글의 내용을 참고하여 문제 해결을 시도해보기 바랍니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2012. 11. 21. 02:05

안녕하세요. Windows Azure MVP 남정현입니다.

오늘 소개해드리려고 하는 내용은 이전에 소개해드렸던 Windows Azure Media Service SDK와 연결되는 웹 서비스를 관리자 포털 (manage.windowsazure.com)에서 쉽게 사용할 수 있도록 만든 기능에 대한 내용입니다. 웹 상에서 최대 200MB까지의 단일 미디어 파일을 업로드할 수 있고, 업로드한 미디어 파일의 공개 URL 및 클라우드 기반 인코딩 작업 생성과 관리에 대한 내용을 소개해드리려고 합니다.

NOTE: 2012년 11월 현재 프리뷰 버전으로 제공되는 기능으로 향후 기능이 바뀌거나 변동되는 내용이 있을 수 있습니다.

Windows Azure Media Service는 기본적으로 프리뷰 서비스이며 별도의 Sign-up Process를 거쳐야 사용이 가능한 서비스이므로 account.windowsazure.com에 방문해서 개별적으로 Windows Azure 계정을 신청해야 합니다.

동영상 파일 업로드하기

Windows Azure Management Portal에 접속한 다음, Media Service에 대한 서비스를 신청한 상태에서 아래 그림과 같이 하단의 UPLOAD 버튼을 클릭합니다.

UPLOAD 버튼을 클릭하면 아래 그림과 같이 로컬에서 업로드할 동영상 파일을 찾고 업로드 후 사용할 BLOB의 이름을 지정하는 입력 상자가 나타납니다. 파일을 선택하면 보통 이름이 자동으로 완성되고 이 이름을 URL에 사용할 수 있으므로 기본 값으로 설정해도 대개는 무방합니다.

테스트 할 동영상으로 에반게리온 신극장판 Q의 예고편 클립을 선택해보았습니다. :-)

동영상 업로드까지 시간이 많이 소요됩니다. 일단 업로드하고 난 다음에는 위의 그림과 같이 동영상 파일의 크기가 조회 내역에 나타납니다. 만약 업로드에 문제가 있어 완료되지 않은 경우 SIZE 컬럼의 값이 0 Byte로 나타나므로 문제 판단을 쉽게 할 수 있습니다. 이 경우 기존 항목을 삭제하고 다시 업로드하여 문제를 해결할 수 있습니다.

업로드가 끝난 동영상에 대해서는 아래 그림과 같이 커맨드 바에 Encode, Play, Publish 버튼이 나타납니다. Encode 버튼을 클릭하면 현재 선택한 미디어를 기준으로 다른 형식으로 변환할 수 있는 Job을 호출하는 것이고, Play 버튼은 현재 선택한 동영상을 브라우저에서 재생하도록 페이지를 여는 기능, 그리고 Publish 버튼은 다른 사람에게 미디어를 표시할 수 있도록 공개 URL을 Windows Azure Storage에서 할당받는 작업입니다. Publish 버튼을 눌러 공개한 상태에서만 Play 버튼이 작동합니다.

Encode 버튼을 누르면 위의 그림과 같이 팝업이 나타납니다. Preset에서 원하는 미디어 인코딩 형식을 선택하고 인코딩 된 새 파일의 이름을 지정하여 확인 버튼을 클릭하면 작업이 시작됩니다. 이 작업은 비동기적으로 이루어지므로 브라우저를 작업 호출 이후에 그냥 닫아도 무방합니다. 단, 작업이 완료되기 전까지 작업 중인 파일의 크기가 0 Byte로 표시되더라도 덮어쓰거나 삭제할 수 없는 상태로 보호됩니다.

Publish 버튼을 누른 다음에는 위의 그림과 같이 공개 URL이 나타나며, 이 URL을 더블 클릭하여 텍스트를 선택하고 복사할 수 있습니다.

Windows Media Player에서 URL 열기 (Ctrl+U) 기능으로 MP4 미디어 파일을 열어 재생하였을 때 위와 같이 동영상이 원활하게 Progressive Download로 재생이 되고 있습니다.

기능의 제한 사항

현재 포털을 통해서 공개된 부분은 Windows Azure Media Service의 일부 기능에 대한 것으로 PlayReady나 다른 여러 부가 기능들에 대해서는 아직 계속 개발 단계에 있습니다. 지속적으로 업데이트되는 내용을 참고하시어 실제 서비스 도입에 활용하면 유용한 부분이 많을 것으로 예상됩니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2012. 8. 6. 08:00

지난번 글에 이어서 Access Control을 실제 ASP.NET 응용프로그램에 연동하는 방법을 살펴보도록 하겠습니다. Access Control을 연동하기 위해서는 .NET의 경우 Windows Identity Foundation이라는 새로운 기술을 필요로 합니다. Windows Identity Foundation은 여러 버전의 런타임으로 나누어져 있으며, Windows Server 2003부터 Windows Server 2012까지 지원되지만, 보통은 Windows Server 2008 이후의 OS를 사용하는 것이 구성이나 배포가 단순합니다.

이 글에서는 Visual Studio 2010과 WIF 3.5를 사용하는 것을 기준으로 가이드를 쓰려고 합니다. 역시 나중에 기회가 되면 Visual Studio 2012와 WIF 4.5기준의 업데이트를 한 번 더 소개하겠습니다.

글에 있는 내용을 따라서 시작하기 전에 ACS를 이용하는 웹 사이트를 배포할 서버와 개발자 컴퓨터에 다음의 런타임을 버전에 맞추어 선택적으로 미리 설치하여 구성하셔야 합니다.

운영 체제 버전 별 런타임 설치하기

개발 도구 (SDK) 설치하기

개발 도구의 경우 한국 Microsoft 홈페이지에는 3.5 버전의 SDK만 게시되어있는데, .NET Framework 3.5가 아닌 4.0을 타겟으로 하는 경우에는 영어 홈페이지로 이동해서 직접 다운로드해야 합니다. 아래는 패키지 파일 다운로드 경로를 직접 걸어놓은 것으로 필요한 패키지를 골라 설치하면 됩니다.

SDK 또한 Windows Server 2003 SP2 부터 설치가 가능합니다.

Windows 8 및 Windows Server 2012에서 WIF 3.5 런타임 설치하기

Windows Identity Foundation 4.5 대신 3.5 버전을 사용해야 할 경우 아래 절차를 거쳐 설치할 수 있습니다.

제어판의 프로그램 및 기능 - 또는 - 프로그램 빠른 검색이나 Windows + R 단축키로 사용 가능한 실행 대화 상자에서 appwiz.cpl 제어판 애플릿을 시작합니다.

그 다음 Windows 기능 켜기/끄기 마법사를 시작합니다.

여러 항목들 중에서 Windows Identity Foundation 3.5 항목을 체크하고 확인 버튼을 클릭합니다.

잠시 기다리면 아래와 같이 완료 대화 상자가 나타납니다.

이제 여기에 WIF SDK 3.5 - 또는 - 4.0 버전을 설치하면 됩니다.

Visual Studio 2008 및 Visual Studio 2010의 경우 - FEDUTIL.EXE 사용하기

런타임의 경우 Windows Identity Foundation의 실행을 위한 클래스 라이브러리 및 네이티브 구성 요소들을 배포하기 위한 목적으로 사용하는 것이고, 기존에 만든 응용프로그램의 환경 설정 파일을 변경하거나 클래스 라이브러리 도움말 등을 포함하는 것이 SDK의 구성입니다. 그리고 부가적으로 SDK의 경우에는 Visual Studio와 연동하는 기능도 제공합니다만 이 기능은 제대로 설치가 될 수도 있고 그렇지 않을 수도 있어서 신경쓸 필요는 없는 부분입니다. SDK에서 진짜 중요한 부분은 FEDUTIL.EXE 라는 마법사형 프로그램으로 이 프로그램을 사용하여 여러분의 asp.net 응용프로그램을 WIF, ACS와 연결시킬 때 필요한 복잡한 설정을 자동화할 수 있습니다.

시스템 사용 환경에 따라 FedUtil.exe 파일의 설치 위치에 다소 차이가 있지만 아래와 같이 요약할 수 있습니다.

  • 32비트 버전 설치 시: %programfiles%\Windows Identity Foundation SDK\v4.0\FedUtil.exe
  • 64비트 버전 설치 시: %programfiles(x86)%\Windows Identity Foundation SDK\v4.0\FedUtil.exe

FedUtil.exe 프로그램을 실행시키고 잠시 기다리면 아래와 같이 마법사가 시작됩니다.

UI 언어는 환경에 따라 한국어가 나올 수도, 영어가 나올 수도 있습니다. 응용프로그램 설정 파일의 위치를 묻는 부분에는 여러분이 WIF를 적용하려는 ASP.NET 웹 프로젝트의 기본 web.config 파일 경로를 지정하는 곳이며, Visual Studio로 해당 프로젝트를 편집 중에 있더라도 안전하게 적용할 수 있습니다.

노트: Visual Studio와 연동된다는 것은 이 유틸리티를 프로젝트 실행 도중 즉시 호출할 수 있도록 "STS 추가 마법사"라는 이름으로 솔루션 탐색기 컨텍스트 메뉴에 추가하는 정도의 편의 제공이기 때문에 이 유틸리티를 직접 호출해도 무방합니다.

그리고 Application URI에는 지난번 글에서 소개했던 것과 같이 Ad-hoc 서버의 포트 번호를 확인하여 얻을 수 있는 localhost 주소를 이곳에 기재해야 합니다. 프로덕션 환경에서 적용하려면 당연히 이 부분이 실제 프로덕션 웹 사이트의 주소가 되어야 합니다.

Application URI에 HTTPS대신 HTTP 주소를 지정할 경우 아래와 같은 경고 메시지가 나타나지만, Access Control 테스트를 위한 것이므로 지금은 무시하고 넘어갑니다.

계속 진행하면 보안 토큰 서비스의 주소를 물어보는 단계가 나타납니다. 이 단계에서 실제로 Azure Access Control Service의 웹 서비스 주소를 지정하여 WIF와 ACS간에 연동을 이루게 됩니다.

여기에 어떤 주소를 넣어야 할까요? 다시 Azure Access Control 관리자 웹 서비스로 되돌아가봅니다. 관리자 웹 서비스 페이지 좌측 제일 하단의 응용프로그램 통합 링크를 클릭하면 페이지 하단에 STS 서비스를 위한 WS-Federation Metadata Endpoint URL이 보이는데 이 주소를 그대로 Copy & Paste합니다.

다음 단계로 진행하면 ACS 서비스가 제시한 인증서가 올바른 인증서가 아니라는 오류를 표시합니다. 이전에 언급한대로 Azure ACS가 프로덕션 환경에서 제대로 작동하려면 정식 서버 인증서를 필요로 합니다. 여기서는 마법사가 기본으로 제안하는 인증서 체인 검사 비활성화를 선택하고 진행하겠습니다.

토큰 암호화에 대한 설정을 지정하는 페이지가 나타납니다. ACS 설정에서 토큰 암호화에 대한 부분을 구성하였다면 이 단계에서도 호환 가능한 설정을 같이 지정해야 합니다.

웹 서비스가 던져줄 수 있는 클레임의 종류에 대한 설명이 열거됩니다. 다음 버튼을 클릭합니다.

이제 마침 버튼을 눌러 web.config 파일을 업데이트합니다.

별다른 이상이 없다면 아래와 같이 성공 메시지 상자가 나타나고 FedUtil.exe 프로그램이 종료될 것입니다.

NOTE: Visual Studio를 실행 중이었다면 web.config 파일을 열어둔 상태였을 경우 파일이 변경되었음을 감지하고 다시 읽어들일 것인지 물어볼 수 있습니다. 이 경우 꼭 바뀐 파일 내용을 다시 읽도록 해주어야 하며, 편집기 버퍼에 남아있는 컨텐츠를 저장하면 FedUtil.exe로 변경한 내용이 소실되므로 유의해야 합니다. 편집기 버퍼에서 바꾼 내용이 FedUtil.exe 실행 전에 많이 존재한다면 변경된 web.config 파일을 별도로 백업받아놓고 두 파일을 적절하게 병합해야 합니다.

변경된 web.config 파일 내용 살펴보기

이제 FedUtil.exe 프로그램에서 어떤 일을 해주었는지 살펴볼 차례입니다. 우선 여러분의 웹 프로젝트 디렉터리에 새로운 디렉터리와 파일들이 나타나는데, 아래와 같습니다. 

FederationMetadata 폴더에 ACS 서비스와 상호대조를 위한, ACS로부터 복제한 메타데이터 파일이 들어있습니다. 실제 서비스가 제대로 작동하기 위해서는 이 파일이 개발자 환경이나 프로덕션 서버로 정확하게 배포되어야 합니다. 버전 관리 시스템을 사용하는 경우 이 파일이 버전 관리 대상에 포함될 수 있도록 해야 합니다.

그리고 web.config 파일이 변경된 것과 더불어 이전 파일에 대한 백업도 들어있습니다. 백업 파일은 확인 후 필요없으면 삭제해도 무방합니다.

그렇다면 web.config 파일은 어떻게 바뀌었는지 한 번 살펴보도록 할까요?우선 파일을 열었을 때 가장 먼저 눈에 띄는 것은 새로운 Configuration Handler를 추가한 부분인데, 아래와 같습니다.

  <configSections>
    <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </configSections>

새로운 Configuration Handler를 지정하고 있으므로 설정 파일 어딘가에 새로운 설정 섹션이 하나 더 추가되어있겠군요. 그리고 appSettings 태그 아래에는 메타데이터 원본 경로에 대한 설정이 들어있습니다.

  <appSettings>
...
    <add key="FederationMetadataLocation" value=https://<네임스페이스>.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml />
...
  </appSettings>

그리고 직전에 살펴본 FederationMetadata 폴더를 위한 특권이 하나 들어있습니다. 인증 세션을 거치지 않았어도 누구나 FederationMetadata 폴더는 접근할 수 있도록 열어놓았군요.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

반면에 웹 응용프로그램의 모든 영역에 대해서는 보호가 걸리게 됩니다.

  <system.web>
...
    <authorization>
      <deny users="?" />
    </authorization>
    <authentication mode="None" />
...
    <!--Commented out by FedUtil-->
    <!--<authentication mode="Forms"><forms loginUrl="~/Account/LogOn" timeout="2880" /></authentication>-->
  </system.web>

달리 표현하면 web.config이 관할하는 모든 영역에 대해서는 ACS를 통한 로그인을 거치지 않을 경우 자동으로 ACS측 로그인 페이지로 리디렉션됨을 의미합니다. 이 부분에 대한 조율이 필요하다면 ASP.NET MVC의 경우 영역으로 별도 영역을 파티셔닝하거나, Location 태그를 적극 활용해야 합니다. 그리고 중요한 차이점이 하나 더 보이는데 WIF의 인증 체계는 기존의 ASP.NET이 제공하던 Form 인증, AD 인증, Windows 인증 및 Passport 인증 어디에도 속하지 않는다는 것입니다.

그리고 당연한 이야기이지만 어셈블리 참조가 걸려있습니다. web.config 파일 및 동적 컴파일 호출 시 유효한 대상으로 걸려있는 것이고, Visual Studio 프로젝트나 별도 컴파일 호출 시 WIF를 사용하려면 프로젝트 참조에서 Microsoft.IdentityModel 어셈블리를 직접 추가해야 합니다.

  <system.web>
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
...
        <add assembly="Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
...
      </assemblies>
    </compilation>
...
  </system.web>

ASP.NET 차원에서는 마지막으로 HTTP 모듈이 대체되는 부분이 있습니다. WIF가 기존 ASP.NET 인증 체계를 완전히 재정의해야 하므로 아래의 모듈이 새로 추가됩니다.

    <httpModules>
      <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </httpModules>

같은 설정이지만 IIS 7 이후의 서버들을 위해서는 <system.webServer> 태그 설정도 동일하게 추가됩니다.

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true">
      <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
    </modules>
  </system.webServer>

이제 끝으로 제일 서두에 언급된 새로운 설정 핸들러가 web.config 끝자락에 보입니다.

  <microsoft.identityModel>
    <service>
      <audienceUris>
        <add value="http://localhost:50086/" />
      </audienceUris>
      <federatedAuthentication>
        <wsFederation passiveRedirectEnabled="true" issuer="https://rkttuacs.accesscontrol.windows.net/v2/wsfederation" realm="http://localhost:50086/ " requireHttps="false" />
        <cookieHandler requireSsl="false" />

      </federatedAuthentication>
      <applicationService>
        <claimTypeRequired>
          <!--Following are the claims offered by STS 'https://rkttuacs.accesscontrol.windows.net/'. Add or uncomment claims that you require by your application and then update the federation metadata of this application.-->
          <claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" optional="true" />
          <claimType type="
http://schemas.microsoft.com/ws/2008/06/identity/claims/role" optional="true" />
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" optional="true" />-->
          <!--<claimType type="
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider" optional="true" />-->
        </claimTypeRequired>
      </applicationService>
      <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <trustedIssuers>
          <add thumbprint="CE5BF1CE19528FEDA7FA9F3ECF87A85E3B1B6AED" name="https://rkttuacs.accesscontrol.windows.net/" />
        </trustedIssuers>
      </issuerNameRegistry>
      <certificateValidation certificateValidationMode="None" />
    </service>
  </microsoft.identityModel>

위의 내용들 가운데에서 굵게 강조 표시한 항목들이 변경의 여지가 있고 제어가 가능한 부분들입니다. 지금으로서는 테스트를 목적으로 하는 것이므로 따로 변경할 것은 없겠습니다.

잘 작동할까요?

워낙에 중요하고 어려운 부분들만 수정해놓은 것이라 불안하게 보입니다. 잘 작동할까요? 한 번 실행해보겠습니다. 

설정 파일에서 변경한대로 사이트에 접속하자마자 ACS 로그인 페이지로 이동합니다. 이후에 다시 살펴보겠지만 이 페이지의 디자인은 얼마든지 재정의 가능합니다. 여기서 Google ID를 시험삼아 로그인에 사용하도록 해보겠습니다.

로그인을 거치고나니 이런 오류 메시지가 나타납니다. 이 문제를 어떻게 해결해야 할까요?

WIF 3.5의 호환성 문제 해결하기

전통적인 로그인 및 사용자 인증 모델에서는 고려할 수 없었던 동작을 수행해야 하는데 안타깝게도 ASP.NET은 이러한 부분에 대해서 다소 부정적인 면모를 보입니다. 이 문제를 해결하는 방법 자체는 단순합니다. 입력 폼으로 들어오는 XML 데이터를 무시하도록 설정을 완화시키면 가능합니다. 그렇지만 그냥 그렇게 프로덕션 환경에 설정을 풀어놓은채로 올리기에는 너무 안일합니다. 뭔가 좋은 방법이 없을까요?

유효성 검사를 풀지 않으면서도 안전하게 WIF와 ACS 사이의 통신을 인정할 수 있는 방법으로 Custom Validation Handler를 추가하는 방법이 있습니다. 이 코드는 아래의 웹 페이지의 코드를 인용한 것입니다.

http://social.technet.microsoft.com/wiki/contents/articles/1725.windows-identity-foundation-wif-a-potentially-dangerous-request-form-value-was-detected-from-the-client-wresult-t-requestsecurityto.aspx

C# 소스 코드

//-----------------------------------------------------------------------------
//
// THIS CODE AND INFORMATION IS PROVIDED 'AS IS' WITHOUT WARRANTY OF
// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
// PARTICULAR PURPOSE.
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
//
//-----------------------------------------------------------------------------

using System;
using System.Collections.Specialized;
using System.Web;
using System.Web.Helpers;
using System.Web.Util;
using Microsoft.IdentityModel.Protocols.WSFederation;

/// <summary>
/// This SampleRequestValidator validates the wresult parameter of the
/// WS-Federation passive protocol by checking for a SignInResponse message
/// in the form post. The SignInResponse message contents are verified later by
/// the WSFederationPassiveAuthenticationModule or the WIF signin controls.
/// </summary>
public class SampleRequestValidator : RequestValidator
{
    protected override bool IsValidRequestString(
        HttpContext context, string value, RequestValidationSource requestValidationSource,
        string collectionKey, out int validationFailureIndex)
    {
        validationFailureIndex = 0;

        if (requestValidationSource == RequestValidationSource.Form &&
            !String.IsNullOrEmpty(collectionKey) &&
            collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
        {
            NameValueCollection unvalidatedFormValues = Validation.Unvalidated(context.Request).Form;
            SignInResponseMessage message = WSFederationMessage.CreateFromNameValueCollection(
                WSFederationMessage.GetBaseUrl(context.Request.Url),
                unvalidatedFormValues) as SignInResponseMessage;

            if (message != null)
                return true;
        }

        return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
    }
}

Visual Basic .NET 코드

'-----------------------------------------------------------------------------
'
' THIS CODE AND INFORMATION IS PROVIDED 'AS IS' WITHOUT WARRANTY OF
' ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
' THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
' PARTICULAR PURPOSE.
'
' Copyright (c) Microsoft Corporation. All rights reserved.
'
'
'-----------------------------------------------------------------------------

Imports System
Imports System.Collections.Specialized
Imports System.Web
Imports System.Web.Helpers
Imports System.Web.Util
Imports Microsoft.IdentityModel.Protocols.WSFederation

''' <summary>
''' This SampleRequestValidator validates the wresult parameter of the
''' WS-Federation passive protocol by checking for a SignInResponse message
''' in the form post. The SignInResponse message contents are verified later by
''' the WSFederationPassiveAuthenticationModule or the WIF signin controls.
''' </summary>
Public Class SampleRequestValidator
    Inherits RequestValidator

    Protected Overrides Function IsValidRequestString( _
        context As HttpContext, value As String, requestValidationSource As RequestValidationSource, _
        collectionKey As String, ByRef validationFailureIndex As Integer) As Boolean

        validationFailureIndex = 0

        If requestValidationSource = Util.RequestValidationSource.Form AndAlso _
            String.IsNullOrEmpty(collectionKey) = False AndAlso _
            collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal) Then

            Dim unvalidatedFormValues As NameValueCollection = Validation.Unvalidated(context.Request).Form
            Dim message As SignInResponseMessage = TryCast(WSFederationMessage.CreateFromNameValueCollection( _
                WSFederationMessage.GetBaseUrl(context.Request.Url), _
                unvalidatedFormValues), SignInResponseMessage)

            If message IsNot Nothing Then
                Return True
            End If
        End If
        Return MyBase.IsValidRequestString(context, value, requestValidationSource, collectionKey, validationFailureIndex)
    End Function
End Class

위의 코드가 이상 없이 컴파일이 잘 되는지 프로젝트에 클래스를 새로 하나 추가하여 확인하고, web.config으로 이동하여 아래와 같이 설정을 수정합니다.

C#의 경우

<system.web>
  ...
  <httpRuntime requestValidationType="SampleRequestValidator" />
  ...
</system.web>

VB.NET의 경우

<system.web>
  ...
  <httpRuntime requestValidationType="[프로젝트 이름].SampleRequestValidator" />
  ...
</system.web>

VB.NET의 경우 네임스페이스의 경로가 상대성을 가지기 때문에 정확한 것은 개체 탐색기 등을 이용하여 확인해보는 것이 필요합니다. 대개는 위와 같이 기술했을 때 문제가 없습니다.

이제 다시 로그인을 시도하면 아래 그림과 같이 인증이 통과되는 것을 볼 수 있습니다. 

한 가지 더 - 로드 밸런싱에 대응하기

아직 모든 것이 완벽하게 마무리 되지 않았는데, 로드 밸런싱에 대한 부분이 해결되지 않았습니다. 기본적으로 ASP.NET과 마찬가지로 컴퓨터 상태에 의존하여 난수를 생성하는 DPAPI (Data Protection API)를 기반으로 하므로 로드 밸런싱 환경에서는 아래와 같은 유형의 오류 메시지가 나타납니다.

Key not valid for use in specified state

위의 오류를 해결하기 위해서는 DPAPI 기반의 암호화 대신 로드 밸런싱이나 웹 팜에 참여하는 노드들 간의 키를 일치시켜야 합니다. Global.asax 파일이 없을 경우 하나 추가하여 Application_Start 메서드 혹은 이벤트 처리기에 아래의 코드 조각을 추가합니다.

C# 코드

FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;

VB.NET 코드

AddHandler FederatedAuthentication.ServiceConfigurationCreated, OnServiceConfigurationCreated()

이어서 추가된 이벤트 처리기의 코드 내용을 아래와 같이 프로그래밍합니다.

C# 코드

using System.Collections.Generic;
using Microsoft.IdentityModel.Tokens;
using Microsoft.IdentityModel.Web;
using Microsoft.IdentityModel.Web.Configuration;
...
    private void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
    {
       List<CookieTransform> sessionTransforms = new List<CookieTransform>(
           new CookieTransform[] {
               new DeflateCookieTransform(),
               new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
               new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate) 
           });
       SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(
          sessionTransforms.AsReadOnly());
       e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
    }

VB.NET 코드

Imports System.Collections.Generic
Imports Microsoft.IdentityModel.Tokens
Imports Microsoft.IdentityModel.Web
Imports Microsoft.IdentityModel.Web.Configuration
...
    Private Sub OnServiceConfigurationCreated(sender As Object, e As ServiceConfigurationCreatedEventArgs)
        Dim sessionTransforms As New List(Of CookieTransform)(New CookieTransform() { _
            New DeflateCookieTransform(), _
            New RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate), _
            New RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)
            })
        Dim sessionHandler As New SessionSecurityTokenHandler( _
            sessionTransforms.AsReadOnly)
        e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace( _
            sessionHandler)
    End Sub

마지막으로 Azure Cloud Service나 VM, 혹은 여러분의 웹 팜 환경에서 실행되는 컴퓨터에 동일한 인증서를 사용하도록 배포하면 로드밸런싱 환경에서도 안전하게 ACS 기반 인증을 처리할 수 있게 됩니다.

좀 더 많은 자료들과 글 작성에 도움이 된 자료들

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2012. 8. 5. 20:18

지난번 글에 이어서 Access Control을 실제로 ASP.NET 웹 사이트에 사용하기 위한 방법을 살펴보도록 하겠습니다. Access Control은 이제 독립적인 Building Block 중 하나로 언급되고, AppFabric이라는 브랜드 네임은 더 이상 붙지 않습니다.

주: 글 작성의 편의상 ACS 혹은 액세스 제어 서비스라는 말을 혼용해서 사용하려고 합니다.

Access Control 서비스 신청하기

Access Control 서비스는 2012년 여름 현재 아직 새 포털 사이트 (manage.windowsazure.com)에서 프로비져닝하거나 관리할 수 있는 UI가 없습니다. 그러나 빠른 시일 내에 추가가 될 것으로 예상되며, 현재는 실버라이트 기반의 포털 사이트 (windows.azure.com)에서 프로비져닝하고 관리할 수 있습니다.

로그인하고 난 다음에 화면 좌측 하단의 "서비스 버스, 액세스 제어 및 캐시" 탭을 클릭합니다. 사용중인 서비스가 있다면 아래와 같이 나타날 수 있으며, 다른 서비스가 없다면 상단 리본 메뉴에서 "새로 만들기" 버튼을 클릭합니다.

이름에서 알 수 있듯이 네임스페이스 아래에 다수의 서비스가 연결되어있습니다. 관련성이 떨어져보이긴 하지만 캐시도 네임스페이스 아래에 배치하여 프로비져닝할 수 있도록 하고 있습니다. 여기서 한 가지 유의하실 것이 하나 있는데, 실제로 사용하려는 서비스에만 체크해야 불필요한 지출이 발생하지 않습니다. 그리고 이곳의 캐시는 최근 소개된 Dedicated Cache와는 다른 것으로 고성능을 전제로 하지만 상대적으로 작은 용량, 높은 비용이 특징입니다.

서비스 버스 신청 후에는 내부 활성화 및 프로비져닝 절차가 복잡한 것으로 추정되고, 이 때문인지 다른 클라우드 서비스보다 다소 시간이 많이 걸립니다. 완전히 사용할 수 있는 상태가 되면 아래 그림과 같이 항목이 나타나며, 특별히 액세스 제어를 신청했다면 상단 리본 메뉴의 액세스 제어 서비스 버튼이 활성화됩니다.

NOTE: 아마 더 이상 그런 일은 없겠지만 ACSV1으로 신청해서 사용 중인 계정을 아직도 가지고 계시다면, ACSV2로 업그레이드를 따로 요청하셔야 합니다. (아마 지금즈음이면 어떤 형태로든 ACSV2 기반으로 마이그레이션되었을 것으로 봅니다.)

ACS 관리하기

ACS 포털은 각 서비스 노드마다 따로 제공되는 것으로 위의 그림에서 액세스 제어 서비스 버튼을 클릭하면 아래 그림과 같이 새 웹 페이지가 나타날 것입니다. 접속 주소의 패턴은 https://[네임스페이스 이름].accesscontrol.windows.net/v2/mgmt/web 과 같습니다. 

그런데 실버라이트 포털에서 그냥 나와버려서 당황하셨을 수도 있는데, 걱정하지 않으셔도 됩니다. 로그인 상태는 지금 보시는 포털과 실버라이트 포털 사이에 모두 세션이 일치된 상태로 계속 유지가 되기 때문에 (즉 SSO를 구현하고 있기 때문에) 사용에 전혀 지장이 없습니다.

ACS는 여러분이 어떻게 설정하는가에 따라 전적으로 동작이 달라지게 되겠지만 보통은 (1) ID 공급자를 지정하여 ACS 서비스가 여러분의 응용프로그램을 위하여 어떤 ID 공급자와 계약을 맺을 것인지 정의하고, (2) ACS에 여러분의 응용프로그램의 속성을 등록하여 상호 작용에 필요한 정보를 사전에 관리하고, (3) ID 공급자와 응용프로그램 사이에 주고 받을 데이터의 내용을 관리하는 것으로 설정을 다룹니다. 그리고 지금 이야기한 단계 모두 ACS 사이트의 자동 생성 기능을 사용하면 어렵지 않게 초기화할 수 있습니다. 이번 블로그 글에서는 ACS 첫 설정에 대한 내용을 살펴보려고 합니다.

ID 공급자 추가하기

당연한 이야기이지만 Windows Azure는 Windows Live ID (혹은 앞으로는 Microsoft ID라고 불리겠군요)를 기반으로 모든 서비스 프로비저닝이 이루어지므로 기본적, 종속적, 필수적으로 ACS의 기본 ID 공급자로 자동 구성되어있으며 동시에 뺄 수 없도록 보호되어있습니다.

Windows Live ID 공급자를 제외하면 웹 관리 UI 상으로는 아래 그림과 같은 종류의 ID 공급자들을 지원합니다.

별 다른 노력 없이 쉽게 추가할 수 있는 공급자 종류로 Google과 Yahoo!가 있고, 기존의 인프라가 선행되어야 하는 공급자 종류로 Facebook와 WS-Federation ID 체계를 지원하는 공급자를 택할 수 있게 되어있습니다. 만약 여러분이 작성하려는 웹 서비스가 소셜 네트워크와 친화적일 필요가 있다면 ACS를 사용해서 한 번에 Facebook과 Google, Yahoo!를 인증 공급자로 택하여 SSO를 자동으로 구현할 수 있는 것입니다.

저는 여기서 간단하게 Google을 ID 공급자로 등록해보도록 하겠습니다. 기회가 되면 Facebook을 활용하는 것도 글로 다루어보도록 하겠습니다.

로그인 페이지 상에 표시할 상세 정보를 지정할 수 있는 페이지가 보입니다. 특별한 설정 없이 저장 버튼을 눌러도 무방하므로 계속 진행합니다.

새 ID 공급자와 ACS 간의 연동이 완료되었습니다. 계속해서 신뢰 당사자 응용프로그램 등록 절차를 진행합니다.

응용프로그램 정보 등록하기

ACS를 실제로 사용하려는 웹 사이트의 정보를 등록해야 합니다. 위의 화면 상 왼쪽 메뉴에서 "신뢰 당사자 응용프로그램" 메뉴를 클릭하고 추가 링크를 클릭하면 아래 그림과 같이 등록 절차가 시작됩니다.

요구하는 항목의 수가 많아 부담스러운 페이지이긴 하나 모두 의미가 있는 항목들이므로 하나씩 찬찬히 살펴보면서 진행해야 합니다.

  • 이름: 관리 도구나 기타 메타데이터 상에서 표시할 알아보기 쉬운 이름을 입력하며, 보통은 도메인 이름 약칭을 적어주면 유용합니다.
  • 모드: 수동으로 설정 입력에 체크합니다.
  • 영역: ACS로 인증을 거친 이후에 실제로 전달받은 토큰이 쓰일 수 있는 URL 경로를 지정합니다. 사이트 전체를 ACS 인증 체제로 확정하려면 그냥 도메인을 포함하여 루트 URL을 지정하고, 그렇지 않은 경우에는 웹 서버 설정과 맞추어 지정해야 합니다. 동일 도메인이라 할지라도 이 영역을 벗어나면 먼저 인증하여 받은 토큰은 자동으로 무력화됩니다.
  • 반환 URL: XML 형태로 넘어오는 보안 토큰값을 실제로 받아서 처리할 URL을 지정합니다. 이 URL을 정확히 지정하여 로그인해서 넘어오는 어떤 임의의 사용자가 실제 여러분이 가지고 있는 사용자 DB와 일치하는 동일 사용자인지 피아식별하고 판정할 수 있습니다.
  • 오류 URL: 옵션 항목이며, 오류가 발생했을 때 사용자가 당황하지 않도록 안내문구를 표시해줄 URL을 지정하여 서비스에 대한 클레임을 최소화하는데 활용할 수 있습니다.
  • (계속)

  • 토큰 형식: 토큰 데이터를 ACS에서 응용프로그램으로 넘길 때 어떤 형태로 패키징해서 보낼 것인지를 결정하는 부분으로, 이번 강좌에서 사용하려는 프레임워크인 Windows Identity Foundation을 고려하여 SAML 2.0으로 지정합니다. 만약 다른 프레임워크를 사용하려는 경우 적절한 포맷을 선택합니다.
  • 토큰 암호화 정책: ACS에서 토큰을 넘겨받을 때 인증서와 키 값을 이용하여 토큰을 암호화해서 넘겨받아야 하는 경우가 있을 때 암호화 사용을 선택합니다. 여기서는 암호화를 필수적으로 사용해야 하는 경우가 아니므로 암호화 정책을 기본값으로 설정하겠습니다.
  • 토큰 수명: 토큰이 발행되고 난 뒤에 만료되기까지의 기간을 설정합니다. 초 단위의 값이며 기본값은 10분입니다.
  • ID 공급자: 앞 단계에서 등록한 공급자들 중에서 지금 등록하려는 응용프로그램과 연결하려는 ID 공급자를 따로 지정할 수 있습니다. 보통은 네임스페이스와 연결된 모든 ID 공급자를 선택할 수 있지만 편의에 따라 설정을 바꿀 수 있습니다.
  • 규칙 그룹: ID 공급자와 이 응용프로그램 사이에 어떤 정보를 주고 받을 것인지에 대한 구체적인 설정을 보관하는 규칙 그룹을 선택할 수 있습니다. 이미 만들어진 규칙 그룹을 고르거나 새로운 규칙 그룹을 만들어 독립적인 설정을 구성할 수 있습니다.
  • 토큰 서명: 토큰 서명 시 사용하려는 인증서를 고를 수 있는데, 자체 제공되는 ACS용 인증서를 이용하거나 여러분이 기존에 소유하고 있는 인증서를 대신 지정할 수 있습니다. 선택 옵션에 따라 하단에 새 옵션 필드가 하나 더 늘어날 수 있습니다.
  • 인증서: 토큰 서명에 사용할 인증서를 직접 지정하도록 옵션을 변경하면 나타나는 옵션 필드로 X.509 인증서와 연결되어있는, 비밀 키를 포함하는 PFX 파일과 비밀 키 값을 지정해야 합니다.

ACS의 인증은 사이트 도메인 경계를 넘나드는 형태로 진행되기 때문에, 위의 옵션에서 잠시 나왔던 것 처럼 localhost 주소가 등록하려는 Application의 실제 주소가 될 수 있습니다. 달리 표현하면, VPN 환경과 같이 외부와 격리되어있으면서 실제 VPN 네트워크 안에 참가해야만 유효한 특별한 형태의 네트워크일지라도 ACS나 실제 ID 공급자와 통신하는데 문제가 없다면 좀 더 견고한 인트라넷-인터넷 간 상호 인증을 구현하는 것도 얼마든지 가능합니다. 그리고 localhost 주소를 지원하므로 당연히 Visual Studio나 Eclipse 등의 개발 도구 등으로 만든 Ad-hoc 서버의 주소를 넣어서 ACS 기능을 테스트하는 것도 당연히 가능합니다.

저의 경우에는 테스트를 위하여 Visual Web Developer 2010 Express Edition을 이용하여 ASP.NET MVC 프로젝트를 만들고 이 주소를 Application으로 등록하기로 하였습니다. Visual Studio 개발 서버나 IIS Express 모두 Ad-hoc 서버이므로 정확한 포트 번호의 확인을 위해서 만든 웹 프로젝트의 속성에서 포트 번호를 확인해야 합니다.

제가 테스트를 위해서 확정해야 하는 주소는 http://localhost:50086 이군요. 이 주소를 바탕으로 신뢰 응용프로그램 정보에 다음과 같이 정보를 등록하려고 합니다.

  • 이름: MyApp
  • 수동으로 설정 입력
  • 영역, 반환 URL, 오류 페이지 주소: http://localhost:50086/
  • ID 공급자: Google 및 Windows Live ID
  • 기타 항목은 모두 기본값으로 설정합니다.

저장 버튼을 누른 다음에는 아래와 같이 응용프로그램 정보가 새로 등록된 것을 볼 수 있습니다.

이제 규칙 그룹의 세부 설정을 완성해야 합니다.

규칙 그룹 구성하기

규칙 그룹 링크를 화면 왼쪽에서 클릭하면 아래 그림과 같이 응용프로그램 등록 과정에서 자동으로 추가된 항목이 나타날 것입니다. 규칙 그룹 이름을 클릭하여 상세 정보를 확인합니다.

규칙 그룹의 상세 내역을 확인해보면 처음 만들어진 그룹이기 때문에 아무것도 등록되어있지 않은 것을 볼 수 있습니다. 규칙 그룹의 이름 같은 부분들은 역시 이곳에서 편집이 가능하고, 어떤 규칙 그룹과 앱이 연결되어있는지도 한 번에 파악할 수 있습니다.

하단의 생성 링크를 클릭하여 자동으로 ID 공급자와 응용프로그램들 사이에 필요한 모든 규칙을 한 번에 만들도록 구성할 수 있습니다. ID 공급자들이 ACS에 제안하는 기본적인 옵션들을 한번에 만들어주므로 일반적인 연동을 위해서는 보통 이 작업 한 번으로 필요한 모든 기능을 자동으로 구성할 수 있게 되어있습니다.

규칙들이 아래 그림과 같이 등록된 것을 볼 수 있습니다. ID 공급자별로 제공할 수 있는 클레임과 클레임의 출처, 그리고 간단한 설명이 열거되어있습니다.

Google의 경우 사용자의 Google 계정과 연결된 메일 주소, 사용자 이름, 그리고 고유 식별자를 제공하며, Windows Live ID의 경우에는 다른 정보 없이 최소한의 식별자만을 제공하고 있습니다. 이후에 다시 살펴보겠지만 사실 모든 ID 공급자들이 친절하게 e-mail 주소를 공개한다는 보장은 할 수 없습니다. 그렇기 때문에 파악이 쉬운 e-mail 주소와 같은 클레임을 직접 사용하려고 하기 보다는 고유 ID 값을 근거로 새로운 프로필을 만들도록 권하는 방식이 ACS 사용 시에는 더 좋은 방법이라고 할 수 있습니다.

마무리

이제 기본적인 구성이 모두 완료되었습니다. 실제 응용프로그램에서 ACS와 연동하여 SSO를 어떻게 구현할 수 있는지 그 내용을 다음번 강좌때 올리도록 하겠습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2012. 7. 13. 18:07

안녕하세요. Windows Azure MVP 남정현입니다.

이전에 신청한적이 있었던 Windows Azure Media Service Preview 프로그램에 대한 테스트 계정을 오늘 얻을 수 있었습니다. 이에 맞추어 간단한 기능을 테스트해보고 처음으로 블로그 포스트를 남겨봅니다. Windows Azure Media Service는 Windows Azure Platform에 근래에 새로 추가된 클라우스 서비스의 한 종류로, 여러분이 가지고 있는 동영상 컨텐츠를 클라우드 컴퓨팅 상의 자원을 활용하여 인코딩하고 그 내용을 곧바로 저장소와 CDN에 게시할 수 있도록 도와주는 서비스입니다. 현재는 프리뷰 버전으로 나온 상태이므로 기능이나 API에 많은 변동이 있을 수 있습니다. 그러나 서비스의 기본 방향이나 목적은 지금 설명 드린 내용이 주된 내용이 되므로 국내외에서 미디어 관련 서비스를 활용하고자 하는 많은 고객들의 관심을 얻을 수 있을 것으로 봅니다.

Windows Azure Media Service를 신청하려면?

Windows Azure Media Service는 현재 신청을 별도로 받아서 계정을 할당하는 방식으로 사용해 볼 수 있습니다. 이를 위해서는 우선 Windows Azure 계정을 하나 만드셔야 하며, http://www.windowsazure.com/ 에서 신청하실 수 있습니다. 국내에 서비스가 정식으로 시작되었기 때문에, 이제는 해외 거주지 정보가 필요하지 않고 쉽게 신청을 마무리하실 수 있습니다.

Windows Azure 계정 관리 홈페이지 (account.windowsazure.com)에 접속하신 후에, "미리 보기 기능"을 클릭하면 현재 신청 가능한 프리뷰 프로그램들이 열거됩니다. 이 중에서 Media Services 항목을 신청하시면 대기열에 예약이 됩니다. 승인이 완료되면 아래 그림과 같이 관리 홈페이지 (manage.windowsazure.com)에 접속하였을 때 Media Service에 대한 메뉴가 새로 나타납니다.

 

미디어 서비스를 만든 후에는 새로운 미디어 서비스를 신청해야 하며, 이 때 미디어 서비스와 연결할 스토리지 계정을 하나 지정하게 됩니다. 미디어 서비스 API로 동영상을 업로드하고 인코딩 후 결과물을 받아보는 것이 모두 연결된 스토리지 계정을 통해 이루어지고, 미디어 서비스 자체는 현재 프리뷰 프로그램 상태에 있기 때문에 미디어 서비스를 통해서 실행되는 비용은 발생하지 않지만 스토리지에 파일을 보관하고 트랜잭션이 발생하는 것에 대해서는 비용이 따로 계산이 됩니다.

.NET Framework 기반 미디어 서비스 API 개발 환경 구성하기

.NET Framework로 미디어 서비스 API를 호출하기 위해서는 제공되는 SDK를 사용하는 방법이 가장 유용하고 편리합니다. 이를 위해서는 몇 가지 소프트웨어 패키지를 설치해야 하며, 다음의 패키지를 다운로드하여 설치하시면 됩니다.

미디어 서비스 API 자체가 REST API이므로 .NET 이외의 언어에서도 얼마든지 호출이 가능합니다. 기타 언어에 대한 SDK 및 지원 내용, 구성 방법은 아래의 각 링크를 참고하시면 됩니다.

테스트 프로젝트 구성하기

이 예제에서는 Windows 데스크톱 응용프로그램 환경에서 코드를 작성하는 것을 기준으로 예를 들어보겠습니다. Visual Web Developer 2010 SP1이나 Visual Studio 2012 for Web RC를 설치한 경우, Windows 클래스 라이브러리 프로젝트를 만들고 프로젝트 속성에서 프로젝트의 출력 유형을 클래스 라이브러리에서 콘솔이나 Windows로 변경하면 직접 실행 가능한 EXE 파일로 빌드 결과물을 만들 수 있습니다.

콘솔 프로그램을 하나 만들고, 프로젝트 참조에 필요한 라이브러리들을 모두 추가해야합니다.

우선 WCF Data Service 5.0 for OData v3 어셈블리들을 추가해야 합니다. 64비트 컴퓨터를 사용 중인 경우 %programfiles(x86)%\Microsoft WCF Data Services\5.0\bin\.NETFramework 폴더를, 32비트 컴퓨터를 사용 중인 경우 %programfiles%\Microsoft WCF Data Services\5.0\bin\.NETFramework 폴더에 있는 아래의 5개 DLL을 참조로 추가합니다.

  • Microsoft.Data.Edm.dll
  • Microsoft.Data.OData.dll
  • Microsoft.Data.Services.Client.dll
  • Microsoft.Data.Services.dll
  • System.Spatial.dll

이어서 Windows Azure Storage Client 어셈블리를 추가해야 합니다. %programfiles%\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\bin 폴더로 이동하여 아래의 DLL을 참조로 추가합니다.

  • Microsoft.WindowsAzure.StorageClient.dll

이어서 Windows Azure Media Service SDK 어셈블리를 추가해야 합니다. 64비트 컴퓨터를 사용 중인 경우 %programfiles(x86)%\Microsoft SDKs\Windows Azure Media Services\Services\v1.0 폴더를, 32비트 컴퓨터를 사용 중인 경우 %programfiles%\Microsoft SDKs\Windows Azure Media Services\Services\v1.0 폴더에 있는 아래의 DLL을 참조로 추가합니다.

  • Microsoft.WindowsAzure.MediaServices.Client.dll

마지막으로, Windows Azure Media Service SDK가 필요로 하는 Azure Storage Client DLL의 어셈블리 버전에 대하여 바인딩 리디렉션을 지정하여 Azure Media Service SDK가 최신 버전의 Windows Azure Storage Client 라이브러리와 상호작용할 수 있도록 조정해야 합니다. 이를 위하여 프로젝트에 app.config 파일 (웹의 경우 web.config 파일)을 추가하여 아래의 섹션을 추가합니다.

<?xml version="1.0"?>
<configuration>
...
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.WindowsAzure.StorageClient"
          publicKeyToken="31bf3856ad364e35"
          culture="neutral" />
        <bindingRedirect oldVersion="1.1.0.0" newVersion="1.7.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
...
</configuration>

설치한 Azure SDK의 버전이 1.6 버전인 경우 위의 예제 코드에서 1.7.0.0 대신 1.6.0.0으로 지정하면 됩니다. 저의 경우, Windows 8용 Azure SDK를 설치했기 때문에 1.7 버전으로 지정하였습니다.

테스트 프로젝트 코딩하기

아래의 프로그램 코드를 잠시 살펴보겠습니다.

using System;
using System.Linq;
using Microsoft.WindowsAzure.MediaServices.Client;

namespace MediaServiceTestDrive
{
    class Program
    {
        static void Main(string[] args)
        {
            CloudMediaContext mediaContext = new CloudMediaContext(
                "" /* Account Name */,
                "" /* Account Key */
                );

            IAsset asset = mediaContext.Assets.Create(
                "" /* File Path */,
                AssetCreationOptions.CommonEncryptionProtected);

            IJob job = mediaContext.Jobs.Create("Sample Job");

            IMediaProcessor mediaProcessor = mediaContext
                .MediaProcessors.Where(x => x.Name == "Windows Azure Media Encoder")
                .FirstOrDefault();

            ITask task = job.Tasks.AddNew(
                "Sample task", mediaProcessor,
                "H.264 256k DSL CBR" /* Encoding Template Name */,
                TaskCreationOptions.None);

            task.InputMediaAssets.Add(asset);
            task.OutputMediaAssets.AddNew(
                "Output asset",
                true, AssetCreationOptions.None);

            job.Submit();

            while (true)
            {
                foreach (var eachJob in mediaContext.Jobs.ToList())
                {
                    Console.WriteLine(eachJob.State);
                }
                System.Threading.Thread.Sleep(5000);
            }
        }
    }
}

호출 절차가 다소 복잡해 보이지만 논리적으로 여러 작업들을 비동기 방식으로 찾아볼 수 있도록 구성한 것이 특징입니다. 우선 제일 먼저 CloudMediaServiceContext 클래스의 인스턴스를 만들어 연결을 성립시킵니다. 이 과정에서 계정 이름과 비밀 키 값을 요구하는 데 이 부분은 manage.windowsazure.com에 나와있는 미디어 서비스의 계정 이름과 키 값을 지정하면 됩니다. 스토리지 서비스에 대한 계정 이름과 키 값이 아님을 유의합니다. 스토리지 서비스에 대한 계정 이름과 키 값은 미디어 서비스 내부에서 별도로 동기화하여 보관하는 기능이 있으므로 이를 참고합니다.

그 다음 파일을 스토리지에 올리기 위한 절차이자 인코딩 대상을 지정하기 위한 절차로 Asset을 만듭니다. Asset을 만들 때 지정하는 인수에는 로컬 컴퓨터의 미디어 파일의 경로를 지정하며, 이것을 스토리지에 업로드하기 위하여 시간이 다소 걸릴 수 있습니다.

그 다음으로 작업을 하나 정의합니다. 작업 안에는 여러 가지의 세부 태스크가 존재할 수 있으며 이것을 논리적으로 하나의 작업으로 취급합니다.

그 다음에는 수행하려는 작업을 처리해줄 수 있는 미디어 프로세서 개체를 가져와야 합니다. 프로세서는 Azure Media Service가 제공하는 범위 안에서만 사용이 가능함에 유의합니다. LINQ 식을 사용하여 미디어 프로세서 개체를 확인하고 그 중 필요한 것을 택합니다. 여기서는 단순 인코딩 처리를 위하여 Windows Azure Media Encoder를 선택합니다.

그 다음으로 작업에 태스크를 하나 추가합니다. 태스크를 추가할 때에는 태스크의 이름과 미디어 프로세서 개체, 미디어 프로세서의 동작 특성을 정의하는 인코딩 템플릿 이름 등을 지정합니다. Windows Azure Media Encoder의 경우 인코딩 템플릿 이름에 대한 정보를 Expression Encoder SDK에서 확인할 수 있습니다. 이름들에 대한 목록은 http://msdn.microsoft.com/en-us/library/microsoft.expression.encoder.presets_members.aspx 에서 확인 가능합니다.

만들어진 태스크의 입력과 출력 대상을 정의하는데, 앞서 지정한 asset을 입력에 추가하고, 출력에는 새로운 asset을 생성하도록 예약합니다.

모든 구성이 끝나면 Job 객체의 Submit() 메서드를 호출하여 작업을 의뢰합니다. 이 떄 부터 모니터링 기능을 사용하여 작업의 진행 상황을 실시간으로 질의할 수 있습니다. 각각의 작업이 완료되면 State 속성이 Completed로 나타나므로 이를 통해서 작업 완료 여부를 확인 가능합니다.

실제로 어떻게 결과물이 나타나는가?

스토리지를 실제로 접속해 보면 새로운 컨테이너들이 만들어집니다. 입력용 Asset을 위한 전용 컨테이너가 먼저 만들어지고, 출력용 Asset을 위한 전용 컨테이너가 나중에 만들어지는 순서입니다. 각각의 컨테이너들은 초기에는 비공개 상태로 설정되어있습니다.

입력용 컨테이너로 만들어진 것을 열어보면 요청한 파일어 업로드된 것을 볼 수 있습니다.

출력용 컨테이너에는 기대한대로 인코딩된 파일과 메타 데이터 파일이 들어있습니다. 

출력용 컨테이너 폴더의 퍼미션 설정을 BLOB 공개로 전환하고 CDN을 연결하면 즉시 서비스 가능한 동영상이 제공되는 것입니다.

좀 더 자세한 정보를 보려면?

간단하게 한 페이지 안에 기본적인 코딩 레시피를 모아놓은 페이지가 있으므로 이 이후에 좀 더 구체적인 작업을 하기 원한다면 아래 페이지에서 내용을 확인하기 바랍니다. PlayReady와 같은 DRM 적용도 매우 쉽게 수행할 수 있습니다.

http://go.microsoft.com/fwlink/?LinkId=251359&clcid=0x412

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2012. 6. 25. 01:50

Xpress Engine meets Windows Azure Web Site

지난번 시간에는 Windows Azure Web Site를 이용하여 Word Press 블로그를 설치하고 사이트를 시작하는 방법을 살펴보았습니다. 오늘은 좀 더 실질적인 예제를 살펴보려고 하는데요, 바로 Xpress Engine을 Windows Azure Web Site 위에서 실행하는 것입니다.

이미 알려져 있다시피 Windows Azure Web Site를 공유 환경에서 실행하는 경우 최대 10개의 웹 사이트를 무료로 사용하실 수 있고, 이러한 환경에서 Xpress Engine을 설치하고 시작할 수 있다면 커뮤니티를 처음 운영하려는 분들께는 여러모로 큰 도움이 될 것입니다.

이 강좌는 Windows Azure Web Site Preview를 신청하여 계정을 활성화한 분들에 한하여 유효하며, 이후에 정식 출시될 Windows Azure Web Site에서는 더 쉽고 간편하게 이 글의 내용을 따라서 진행할 수 있을 것입니다.

호스팅 환경에 대해서 알아두기

Windows Azure Web Site는 지난번에 간단히 살펴본 대로 기본 실행 환경은 Windows Azure 위에서 실행됩니다. 그리고 데이터베이스로는 SQL Database (예전 이름은 SQL Azure 였습니다.) 또는 Clear DB의 MySQL Database 중 한 가지를 택할 수 있었습니다. 여기서 사용하려고 하는 것은 Clear DB의 무료 데이터베이스 상품이며 동시 연결 개수 4개, 데이터베이스 크기 1GB의 상품을 Windows Azure가 Clear DB와 연계하여 기본적으로 자동으로 신청하고 관리해 줍니다.

달리 표현하면, 반드시 Windows Azure 환경이 아니어도 Clear DB 홈페이지에 직접 가서 같은 상품을 신청하거나 더 나은 상용 버전의 서비스로 따로 신청해도 무방합니다. 그러나 서비스가 분리된 것과는 무관하게 Clear DB에서 여러분에게 제안하는 상품은 Windows Azure 데이터 센터 위에서 실행되는 MySQL 데이터베이스이므로 단순히 Clear DB의 상품을 이용하는 것과는 차이가 있습니다.

Xpress Engine은 Microsoft SQL Server를 지원하므로 데이터베이스 활용에 능숙하다면, Windows Azure Virtual Machine을 이용하여 SQL Server를 내장하는 VM을 추가 신청하여 이 VM에 직접 연결하도록 설치를 구성해도 됩니다. 하지만 비용에 있어서 최상의 이점을 누릴 수 있도록 하기 위하여 Clear DB의 MySQL 상품을 활용하는 방법으로 이번 강좌를 풀어나가려 합니다.

준비 작업 – 새 웹 사이트 신청하기

웹 사이트를 하나 만들도록 합니다. 새 웹 사이트 만들기로 이동합니다.

데이터베이스와 함께 새로운 웹 사이트를 만들기 위하여 두 번째 항목을 클릭합니다.

웹 사이트 이름을 지정하고, 새 MySQL 데이터베이스를 만들 것을 주문합니다.

데이터베이스의 이름을 확인하고, 사용권 계약에 동의함을 표시한 후 마침 버튼을 클릭합니다.

잠시 기다리면 사이트와 MySQL 데이터베이스가 자동으로 생성됩니다.

드문 경우이지만 만약 위와 같이 데이터베이스 생성이 실패했다는 메시지가 나타나는 경우, 당황하지 말고 Clear DB 홈페이지 (http://www.cleardb.com/)에서 회원 가입을 하고, Windows Azure 무료 데이터베이스 상품 신청 페이지를 아래 그림처럼 찾아서 신청하도록 합니다.

데이터베이스 상품 이름은 Mercury이며, Windows Azure 데이터센터 위에서 실행됨을 알리는 내용을 볼 수 있습니다. 이후 상용 버전으로 업그레이드하는 경우, 여기서 사용하는 데이터베이스에 대한 비용은 Microsoft가 아닌 Clear DB를 통해서 결재하게 됩니다.

데이터베이스를 생성한 후 대시보드 페이지로 이동하면 실행 중인 데이터베이스 이름이 보이는데, 데이터베이스 이름을 클릭합니다.

접속 정보와 아이디, 비밀 번호를 기록합니다. 서버 주소의 경우, 위의 그림을 기준으로 이야기해보면 us-mm-azure-east-01.cloudapp.net이 되며, 데이터베이스 이름은 cdb_8a5322cd38, 그리고 하단의 아이디와 비밀 번호를 확인합니다.

같은 정보가 Windows Azure Web Site 대시보드에서는 Connection String 페이지에 나타나므로 참고하시기 바랍니다.

이제 XE 파일들을 직접 올리기 위하여 FTP 접속 정보를 초기화해야 합니다. Reset Deployment Credential 링크를 오른쪽 편에서 찾아 클릭하면 아래와 같이 설정 화면이 나타납니다.

접속 정보를 재 설정하고 난 다음 FTP 클라이언트로 서버에 접속을 시도합니다. 여기서는 FileZilla 클라이언트를 사용하였지만 여러분이 선호하는 FTP 클라이언트를 직접 사용해도 무방합니다. 단, Windows 탐색기와 통합된 FTP 클라이언트의 경우 특성 상 여러 연결을 만들 수 있고 이 때문에 접속자 수 초과가 일어나 접속이 안될 수 있습니다.

위와 같이 접속 정보를 설정한 다음 연결하면 아래 그림과 같이 디렉터리 목록이 열거됩니다. 기본 페이지 파일을 삭제합니다.

이제 XE 홈페이지에 방문하여 XE Core 또는 여러분이 선호하는 기본 패키지 파일을 내려 받도록 합니다.

파일의 압축을 풀고 난 다음, XE의 루트 디렉터리의 모든 파일들을 아래 그림과 같이 FTP를 통하여 올리도록 합니다. 적지 않은 시간이 걸릴 수 있고, 파일의 수가 많으므로 실패한 내역이 없는지 확인하기 바랍니다.

모든 파일이 업로드 되면 아래 그림과 같습니다.

이제 웹 사이트에 접속을 시도해봅니다. 아래 그림과 같이 잘 나오면 기본적인 PHP 실행 환경에는 이상이 없는 것입니다.

하단의 언어를 한국어로 설정하고, 사용권 계약에 동의한 다음 계속 진행합니다.

다행히 XE에서 요구하는 PHP 요구 사항들을 모두 지원합니다. 계속 진행합니다.

MySQL 데이터베이스를 트랜잭션 없이 사용하기 위하여 기본 옵션을 선택합니다.

Windows Azure – 또는 – Clear DB 홈페이지에서 확인한 접속 정보를 기재합니다.

짧은 주소 사용은 체크하지 않고, 시간대 설정만 지정하여 완료 버튼을 클릭합니다. 짧은 주소 사용의 경우 현재 Rewrite Module을 Windows Azure Web Site 환경 설정 상에서 직접 변경할 만한 방법이 마땅히 없는 상태입니다. (그러나 IIS 자체적으로 Apache HTTP Server의 Rewrite Configuration File을 Import하는 기능이 이미 있습니다.)

관리자 메일 주소, 비밀 번호 등 기본 정보를 입력하고 완료 버튼을 클릭합니다. 이 부분에서 시간이 많이 걸릴 수 있으므로 기다립니다.

XE가 Windows Azure Web Site에서 성공적으로 실행되는 모습입니다. 관리자로 로그인된 상태도 확인이 되는 군요. XE의 관리 패널로 한 번 이동해보겠습니다.

기대했던 대로 XE의 관리 패널도 잘 보입니다.

마무리하기

전반적으로 해외 데이터센터를 통해서 웹 사이트가 구동되는 상황이기 때문에 국내에서는 아직 많이 느립니다. 하지만 정식 출시와 함께 Azure Web Site가 완전한 서비스를 하게 되면 더 빠르고 안정적인 서비스를 지원하게 될 것입니다. 이번 강좌는 Windows Azure Web Site가 국내 CMS 웹 응용프로그램을 얼마나 안정적으로 지원할 수 있는지 측정해보기 위한 데 큰 의미를 두고 있습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

  1. mysql정보를 어디서 확인하나요?

    2012.07.31 00:03 [ ADDR : EDIT/ DEL : REPLY ]
    • \조인\ Azure Web Site에서 linked resource로 직접 mysql을 만드셨다면 1GB 무료 버전의 mysql db가 연동되어서 만들어지고, 웹 사이트 configuration 섹션에서 connection strings에 mysql 연결 문자열이 나타날 것입니다. 만약 여기서 만들지 않고 cleardb.com에서 직접 만드셨다면 이곳의 정보를 확인하셔야 합니다.

      2012.08.02 09:08 신고 [ ADDR : EDIT/ DEL ]

PaaS2012. 6. 10. 02:09

안녕하세요. Windows Azure MVP 남정현입니다. 최근에 새로 추가된 Windows Azure Web Site 서비스는 이름에서 알 수 있듯이 Windows Azure를 통해서 여러분이 원하는 웹 사이트를 쉽게 구축하고 운영할 수 있도록 도움을 주는 호스팅 서비스입니다. 기존에 사용하였던 호스팅 서비스나 무료 홈페이지 계정과 비슷한 기능들을 제공하지만 더 풍부하고 더 강력한 기능을 지원합니다. 이번 강좌에서는 Windows Azure Web Site를 이용하여 워드프레스 블로그 사이트를 만드는 과정을 살펴볼까 합니다.

NOTE: Windows Azure Web Site는 Windows Azure 계정을 만들고 나서 2012년 6월 현재는 별도의 Preview 프로그램을 신청해서 개설할 수 있습니다. http://www.windowsazure.com/ 웹 사이트에 방문하셔서 계정을 만들 수 있습니다. 이 강좌는 Windows Azure 계정 및 Windows Azure Web Site 프로그램 가입이 완료된 이후를 기준으로 쓰여져 있습니다.

http://windows.azure.com/ 대신 http://manage.windowsazure.com/ 으로 접속해야 Windows Azure Web Site 기능을 관리하실 수 있습니다.

웹 사이트에 접속하면 Microsoft Online ID를 묻는 페이지가 위의 그림과 같이 나타나는데, ID와 비밀 번호를 사용하여 접속합니다.

접속한 후에는 위의 그림과 같이 관리자 페이지의 UI를 볼 수 있는데, 신규 서비스 개설을 위하여 하단의 NEW 메뉴를 클릭합니다.

그러면 화면이 열리면서 신청 가능한 항목들이 나타납니다. 만약 위의 그림과 같이 Web Site 항목이 활성화 되어 있지 않으면 별도로 프로그램을 신청해야 하는 상태이므로 Windows Azure 홈페이지로 이동하여 베타 프로그램을 신청해야 합니다. 이 제한은 2012년 6월 이후로는 적용되지 않을 것입니다.

어떤 방식으로 웹 사이트를 만들 것인지 한 번 더 선택해야 하는데, 갤러리에 올려져 있는 웹 사이트 템플릿을 활용하려고 하는 것이므로 From Gallery 메뉴를 클릭합니다.

그러면 사용 가능한 웹 애플리케이션의 종류들이 보이는데 상당히 종류가 많고 다양합니다. 오늘 살펴보려고 하는 것은 워드프레스 블로그이므로 BLOGS 메뉴를 클릭합니다.

웹 애플리케이션의 설치를 위해서 필요한 마법사 화면이 새로 나타납니다. DNS에 여러분의 웹 사이트에 고유하게 할당하려는 ID를 지정합니다. 이 주소는 나중에 여러분이 가지고 있을 수도 있는 개인 도메인 주소와는 별개로 서버 할당에 필요한 자체 주소이므로 반드시 입력해야 합니다. 그리고 데이터센터의 위치도 적절하게 선택합니다. 필요한 항목을 기재한 다음에는 우측 하단의 화살표 버튼을 클릭하여 다음 단계로 진행합니다.

갤러리에 등록된 워드프레스는 MySQL 데이터베이스를 기반으로 운영됩니다. 기본적으로 Windows Azure는 MySQL을 직접 호스팅하지 않고, SuccessBricks의 ClearDB 서비스와 한방에 통하도록 해줍니다. 그 과정에서 필요한 내용들을 검토하신 후 체크 박스를 클릭하면 완료 버튼이 활성화됩니다.

웹 사이트가 생성 중이라는 메시지가 나타납니다. 약 3~5분 정도면 웹 사이트 배포까지 끝나고 곧바로 사이트가 뜹니다. 아래 그림과 같이 Ready로 나타나면 준비가 된 것입니다.

위와 같이 상태가 나타나면 해당 항목을 클릭합니다.

트래픽 상황과 디스크 사용 공간 등 호스팅에서 필요한 일반적인 모든 정보들이 한 눈에 전광판으로 나타납니다. 페이지를 좀 더 아래쪽으로 스크롤해서 내용을 살펴볼까요?

강조 표시해놓은 항목들이 기존에 여러분이 알고 있었던 호스팅 서비스와 일치하는 항목들입니다. FTP 사용자 ID와 비밀 번호를 필요에 따라 얼마든지 매번 새롭게 재설정할 수 있고, 웹 사이트를 보려면 어디로 가야 하는지, FTP 서버로 접속하려면 어떻게 해야 하는지, 호스팅 상품 외에 연결된 데이터베이스가 무엇인지 모두 알 수 있습니다. 이제 웹 사이트를 한 번 들어가보겠습니다.

당연히 워드프레스 블로그의 첫 설치 화면이 나타납니다. 필요한 항목들을 기입합니다.

Install WordPress 버튼을 클릭합니다.

ID는 최고 관리자 ID인 admin을 입력하고 방금 전에 지정한 비밀 번호를 입력하여 관리자 페이지로 접속합니다.

기대했던 대로 워드프레스 관리자 화면이 나타납니다. 웹 사이트 안을 여기저기 살펴보면 완전하게 워드프레스 블로그가 설치된 것을 알 수 있습니다.

다시 관리자 화면으로 돌아와보면 실시간으로 트래픽 상황이 업데이트된 것을 확인할 수 있습니다. 관리자 화면의 모니터링 도구가 단순히 통계 자료를 보여주는 것에서 그치지는 않는다는 것을 쉽게 알 수 있습니다. 그러면 좀 더 자세한 내용을 살펴보기 위하여 상단의 다른 몇 가지 메뉴들을 살펴보겠습니다.

MONITOR 메뉴를 클릭하면 표 형태로 잘 정리된 각각의 메트릭을 한 눈에 살펴볼 수 있습니다.

그리고 이것이 Windows Azure만의 매력적인 부분이라고 할 수 있는데, 여러분의 인스턴스 유형을 여기서 자유롭게 변경할 수 있습니다. 만약 여러분의 웹 사이트가 일반적인 웹 사이트가 아닌 영화, 음반 등의 홍보 웹 사이트라고 한다면 동시 접속 인원이 매우 빠르고 급격하게 증가할 가능성이 많습니다. 이럴 때 정말 완벽한 서비스를 구현하려면 기존에는 마땅한 대책이 없었습니다. 하지만 Windows Azure는 상당히 다양한 옵션을 제공합니다. 그리고 이 옵션은 모두 완전하게 제 기능을 다 합니다.

기본적으로 여러분이 웹 사이트를 만들면 아래와 같은 상태에서 실행됩니다.

1대 ~ 2대의 가상 서버 인스턴스가 존재하고 그 안에 수 많은 분리된 환경의 웹 사이트들이 있으며 그러한 가상 서버 인스턴스들 중 하나를 택하여 서비스를 운영하는 방식입니다. 대개는 이렇게 운영하더라도 충분히 성능을 낼 수 있습니다. 그러나 방금 이야기한 경우처럼 정말 엄청난 성능이 필요하다면 인스턴스 유형을 Reserved Instance로 바꿀 수 있는데, 아래 그림과 같이 사용할 수 있음을 뜻합니다.

인스턴스 자체를 여러분의 웹 사이트를 위하여 실행되도록 점유할 수 있고, 인스턴스의 크기 또한 서비스 규모에 맞추어 변경할 수 있습니다. 이것이 이전에 여러분이 Windows Azure로 살펴보셨을 수도 있는 Web Role의 더 발전된 형태입니다.

Windows Azure는 이번 업데이트로 완전히 새롭게 달라진 서비스들로 중무장하였습니다. Microsoft가 운영하기 때문에 MySQL이나 리눅스를 지원하지 않는다는 것은 더 이상 통하지 않는 편견이 되었고, 편의성에서도 전혀 손색이 없으며, 기존의 국내외 호스팅 서비스들만큼 – 또는 – 그 이상의 품질을 보여주고 있습니다.

만약 웹 사이트를 좀 더 완벽하게, 그리고 더 풍부하게 운영하기 원한다면 Windows Azure가 제공하는 다른 여러 부가 서비스들과 조합했을 때 더 큰 시너지 효과를 낼 수 있을 것입니다. 그러나 기본적인 Windows Azure Web Site 서비스 하나만으로도 상당한 메리트가 있다고 할 수 있을 것입니다.

다음 번에는 Windows Azure Web Site가 제공하는 FTP를 이용하는 방법과 간단한 PHP 웹 사이트의 설치와 활용 방법을 살펴보도록 하겠습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

  1. WEB SITES에서 SSL도 사용할 수 있을까요?

    2012.07.11 21:49 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 기본적으로 HTTPS Endpoint도 같이 생성되는 것을 확인하였습니다. 필요한 경우 HTTPS Endpoint로 모든 요청이 연결되도록 변경하거나, 웹 사이트 설정을 바꾸실 수도 있을 것 같습니다.

      2012.07.13 09:03 신고 [ ADDR : EDIT/ DEL ]

PaaS2012. 5. 14. 01:07

Windows Azure VM Role을 이용하여 Base Image를 최초로 만들 때 가장 많이 시행 착오를 겪는 부분 중에 하나는 초기 Base Image의 VHD 파일 크기를 정확히 확인하지 않고 만들게 되는 부분인데, 이렇게 만들고나면 VHD 파일을 축소하는 방향으로는 수정할 수 없어서 작업이 번거로워집니다. 이러한 시행착오를 사전에 예방할 수 있도록 도움을 드리기 위하여, 개인적으로 이러한 Base Image VHD 파일들을 템플릿으로 만들어서 공유합니다.

업로드한 이미지 파일들은 Master Boot Record (MBR) 영역을 차지하도록 만들어진 단일 NTFS Primary Partition을 가지도록 포맷되었으며, 곧바로 설치에 쓰일 수 있도록 구성되어있습니다.

위의 파일들은 모두 RAR 형식으로 최고 압축률을 사용하여 압축하도록 만들어진 파일들로, 압축 해제를 위해서는 WinRAR 또는 최신 버전의 RAR 유틸리티가 필요하며, 압축을 해제하려면 파일을 저장할 파티션의 잔여 공간이 VHD 파일을 포함하여 충분한 공간이 남아있어야 합니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 12. 15. 10:11

최근 개편된 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의 구성 요소들은 지금까지와 마찬가지로 독립적인 노선을 유지하게 될 것 같습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 9. 12. 23:32

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

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 7. 25. 13:00

Windows Azure Platform에서 최근 들어 가장 좋아진 기능을 꼽으라 한다면 바로 원격 데스크톱의 지원일 것입니다. 검증된 형태의 템플릿을 사용하는 경우에는 문제가 될 일이 거의 없지만, 여러분이 직접 Web Role이나 Worker Role을 만들거나, 혹은 이러한 템플릿 위에서 무언가 여러분만의 고유한 기능을 추가하려고 하면 실제로 배포하고 난 이후 전혀 예상치 못한 문제에 봉착하는 경우가 상당히 많습니다. 여러 가지 이슈들이 있을 수 있고, 그 때 마다 적절한 해결법은 모두 다릅니다. 이 경우 원격 데스크톱은 여러분에게 큰 보탬이 되어줄 것입니다.

보편적인 원격 데스크톱과 다른 점

같은 기술을 사용하지만, 서버에서 지원하는 원격 데스크톱과는 사실 많이 다릅니다. 일상적으로 우리는 원격 데스크톱을 관리 목적으로 사용하거나, 개발 목적으로 구축한 서버의 경우 한 발 더 나아가서 원격 데스크톱 위에서 프로그램을 긴급히 디버깅하거나 작성하는 일도 많이 합니다. 하지만 Windows Azure가 제공하는 원격 데스크톱은 어디까지나 문제 해결의 용도로만 사용해야 합니다.

이렇게 해야만 하는 가장 큰 이유는, Windows Azure는 처음부터 탄력성을 중시하는 시스템 운영 정책을 사용하기 때문에 예고 없이 개별 Virtual Machine이 업그레이드되거나, 순환되거나, 교체될 수 있고 또한 같은 일을 하는 Virtual Machine이 늘거나 줄어들 수도 있습니다. 이러한 과정에서 원격 데스크톱으로 재정의하거나 변경한 환경은 임의로 초기화되므로 원격 데스크톱으로 해결한 문제가 다시 원래 상태로 돌아오는 문제가 발생할 수 있습니다. 원격 데스크톱으로 해결할 수 있는 문제의 성격을 정확히 파악하고, 수행했던 작업을 여러분의 프로젝트에 다시 반영하는 과정이 이 때문에 반드시 필요합니다.

Windows Azure에서는 각각의 Virtual Machine이 우리가 생각하는 하나의 완벽한 서버의 개념이 아닌, 마치 응용프로그램이 사용하는 임시 자원과 비슷한 Scope에 놓여있기 때문에 전통적으로 우리가 잘 따르던 제한된 수의 서버를 이용한 서비스 프로그래밍 개념과는 많이 다른 것입니다.  원격 데스크톱 말고도 프로그래밍 방법에 관해서도 이 때문에 많은 도전을 받게 되어있습니다.

원격 데스크톱 지원을 Windows Azure 프로젝트에 추가하는 법

원격 데스크톱을 기존 Web Role Worker Role에 추가하기 위해서는 Windows Azure Tools for Visual Studio 1.3 버전 이상의 도구가 설치되어있고 이 버전의 SDK를 기반으로 프로젝트가 새로 만들어지거나 업그레이드되어야 합니다. 준비가 끝나면 다음의 단계를 따릅니다.

참고로 Windows Azure 프로젝트에 원격 데스크톱 지원을 추가할 수 있는 것은 프로젝트 속성 단계에서가 아니라 배포 직전에서의 단계입니다. 이 부분에 대한 혼동이 없도록 합니다.

Step 1: Windows Azure 프로젝트를 솔루션 탐색기에서 찾아 오른쪽 버튼으로 클릭한 후 나타나는 팝업 메뉴에서 게시 메뉴를 클릭합니다.

Step 2: 패키지만 만들 것인지, 또는 Visual Studio 안에서 배포와 함께 서비스 시작까지 자동으로 진행시킬 것인지를 묻는 대화 상자가 나타나는데, 라디오 버튼들의 상태와 관계없이 아래쪽의 Configure Remote Desktop connections 링크를 클릭할 수 있으므로 이 링크를 클릭합니다.

Step 3: 도구를 이용하여 생성한 적이 있었던 인증서와 시스템에 미리 설치된 인증서들이 열거되는 드롭 다운 박스를 클릭하면 아래와 같이 새 인증서를 생성할 수 있는 항목이 나타나는데 이 항목을 클릭합니다.

Step 4: 인증서의 Friendly Name을 입력하고 OK 버튼을 클릭합니다. 앞으로 이런 식으로 인증서를 만들어 활용할 일이 많을 것이므로, 서비스를 실행하려는 Windows Azure 계정의 이름과 프로젝트의 이름을 지정하여 Friendly Name을 지정해두면 인증서를 알아보기 쉽습니다. 이에 관해서는 여러분 나름의 규칙을 정해두기를 권장합니다.

Step 5: 새로 만든 인증서를 선택하고 View 버튼을 클릭합니다.

Step 6: 임시로 만든 인증서이므로 인증서가 유효하지 않다는 경고가 보이지만 Windows Azure에서 관리자 인증을 목적으로 사용하기 위한 인증서의 조건에는 부족하지 않습니다. 자세히 탭을 클릭하고 하단의 파일에 복사 버튼을 클릭합니다.


Step 7: 인증서 내보내기 마법사가 나타납니다. 다음 버튼을 클릭합니다.


 

Step 8: Windows Azure에 제공해야 하는 인증서는 개인 키 값을 포함하는 PFX 형식의 인증서이므로 아래 대화 상자에서 개인 키를 내보내도록 선택하고 다음 버튼을 클릭합니다.

Step 9: 개인 정보 교환 (PKCS-12) 형식을 사용하도록 지정하고, 추가 옵션 없이 다음 버튼을 클릭합니다.

Step 10: 개인 키에 포함할 비밀 번호를 지정합니다. 보안을 위하여 가능한 고유하면서도 유추가 어려운 여러분 만의 강력한 암호를 지정할 것을 권장합니다. 확인 암호까지 한 번 더 입력하고 다음 버튼을 클릭합니다.

Step 11: 내보낼 파일 경로를 지정하고 다음 버튼을 클릭합니다.

Step 12: 모든 사항을 확인하고 완료 버튼을 클릭하면 인증서 내보내기가 마무리 됩니다.

Step 13: 모든 설정을 저장하고 Step 3의 대화 상자로 다시 되돌아 와서, 아래와 같이 필요한 정보들을 입력합니다. 사용자 이름, 비밀 번호, 계정 만료 기간을 지정합니다. 계정 만료 기간은 여러분의 편의에 맞추어 입력합니다. 보안을 위해서는 계정 만료 기간을 짧게 설정하고, 관리자 포털 사이트에서 직접 기간 연장을 하는 것이 좋습니다. 모든 설정이 끝나면 OK 버튼을 클릭합니다.

Step 14: 이제 이 설정을 사용하기 위해서는 http://windows.azure.com/ 에 접속해서 방금 우리가 내보낸 PFX 인증서 파일을 Windows Azure Portal에 직접 등록해야 합니다. 사이트에 로그인 한 다음 Hosted Services, Storage Accounts & CDN 메뉴를 클릭하고, Hosted Services 메뉴를 클릭합니다. 이렇게 하면 아래와 같은 화면이 나타날 것입니다.

Step 15: 여러분의 Cloud Service를 호스팅할 Hosted Service 항목을 찾아, 하단의 Certificates 폴더를 클릭하면 상단의 리본 메뉴가 Add Certificate / Delete Certificate 버튼만 나타나도록 변경됩니다. 여기서 Add Certificate 버튼을 클릭하면 아래와 같이 Modal 대화 상자가 나타납니다. PFX 파일을 지정하고, 내보내기 때 지정한 비밀 번호를 입력 후 Create 버튼을 클릭합니다.

Step 16: 이제 해당 Cloud Service Production이나 Staging에 배포하고 나면 원격 데스크톱 연결을 테스트해볼 수 있습니다. 정상적으로 적용되었다면 도구 모음의 배열이 여러분이 접속하려는 해당 인스턴스를 클릭했을 때 다음과 같이 바뀌어 나타납니다.

Step 17: 아래는 실제로 접속한 화면의 예시입니다.

인증서에 대하여

원격 데스크톱을 적용해보고 잘 동작한다면 이제 좀 더 자신감을 가지고 디버깅을 시작할 수 있을 것입니다. 그러나 몇 가지 막연한 것도 있을 것인데, 특히 인증서에 관해서는 더더욱 그럴 것입니다. 만약 실수로 여러분이 내보낸 인증서가 사라지게 된다면 패키지를 만들어서 Azure에 게시할 수 있을까요? 일단은 가능합니다. 하지만 여러분의 마음이 놓일 수 있는 상황을 만들기 위해서는 이전에 언급했던 절차를 다시 진행해야 하는 번거로움이 따르므로 인증서 관리는 항상 신중히 해야 합니다.

그리고 관리자 권한으로 로그인할 수 있도록 지정한 계정의 만료일이 넘었을 때, 서비스를 다시 업그레이드하지 않고도 만료일이나 비밀 번호를 바꿀 수도 있으므로 이 부분에 대해서도 안심해도 되겠습니다.

Azure RDP 파일이 보통의 RDP 파일과 다른 점

Windows Azure의 경우 Load Balancer가 있기 때문에 각각의 개별 Virtual Machine이 직접 IP 주소를 노출하는 일이 없습니다. 그런데 어떻게 Windows Azure Management Portal에서 제공하는 RDP 파일을 통해서 정확히 해당 Instance에 접속할 수 있는 것일까요? 의문을 풀기 위해, Azure에서 사용하는 RDP 파일 형식에 대해서 잠시 살펴보기로 하겠습니다. 이 파일 형식을 정확히 이해하고 활용하실 수 있다면 관리 포털 사이트까지 들어가는 수고 없이 곧바로 여러분이 원하는 원격 데스크톱 세션을 만들 수도 있습니다.

full address:s:qrcode.cloudapp.net
username:s:********
LoadBalanceInfo:s:Cookie: mstshash=<Role Name>#<Instance Name>#Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp

RDP 파일 자체의 내용은 매우 단순합니다. Full address username은 여러분이 알고 있는 것과 같습니다. 하지만 LoadBalanceInfo 부분이 실제로 연결을 성립하는데 꼭 필요한 정보들이 담겨있는 부분입니다. <Role Name> Windows Azure Portal에서 접속하려는 Role의 이름으로, Windows Azure 프로젝트 내 Role 프로젝트의 이름과 일치하는 부분입니다. 그리고 Instance 이름은 현재 실행 중인 인스턴스의 이름을 의미하며, 보통 Role Name 뒤에 _IN_[n] 형태의 접미사가 붙고, n 값은 0부터 시작합니다. 그리고 #Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp 문자열을 지정하여 Windows Azure Load Balancer와 상호작용해야 함을 명시하고 있습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 7. 23. 09:00
지난 시간에는 Windows Azure에 여러분이 게시하려고 했거나, 이미 게시한 Web Role, Worker Role 등을 원격으로 제어하기 위해서 인증서를 등록하는 방법을 알아보았습니다. 전통적인 IT 환경에서 널리 통용되는 Active Directory 기반의 인증이 Windows Azure에서는 극히 제한적으로만 활용할 수 있기 때문에 인증서, 정확히는 X.509 형식의 인증서를 관리하는 일은 Windows Azure 기반의 관리나 서비스 개발에 있어서 매우 중요합니다.

오늘은 Windows Azure 환경에서 사용되는 대표적인 인증서 활용 사례들을 살펴보고, 인증서를 체계적으로 관리할 수 있는 방안을 논의해보기로 하겠습니다.

Windows Azure Web Role의 HTTPS 지원

Windows Azure Web Role은 내부적으로 IIS 7.0 (Guest OS 버전을 Windows Server 2008 R2로 지정하였을 경우 IIS 7.5)를 기반으로 웹 사이트나 WCF, XML 웹 서비스 등을 호스팅하도록 되어있습니다. 이 때, 보안 향상을 위하여 HTTPS 프로토콜을 기반으로 호스팅할 필요가 있는데 이 때 Windows Azure에서는 HTTPS 프로토콜 형성에 필요한 인증서를 Windows Azure Portal에 별도로 등록하도록 요구합니다. 이렇게 하는 이유는, Windows Azure가 필요 시에 수행하는 동적 인스턴스 복제 때 마다 시스템에 필요한 인증서를 자동으로 설치할 수 있도록 하기 위함이고 또한 HTTPS 기반의 프록시 릴레이를 구현하기 위함입니다. 

이를 위해서 Windows Azure에 제출해야 하는 인증서는 개인 키 값을 포함하는 PFX 형식의 인증서 파일이며, 개별 Windows Azure 프로젝트에서는 인증서의 손도장 값 (Thumbnail)을 설정 파일 상에 지정해야 합니다. 이전에 언급한 대로, 손도장 값은 단순히 어떤 인증서를 사용할 것인가에 대한 설정일 뿐이며, 실제로 인증서를 관리하는 것은  Windows Azure에서 관리를 하는 것입니다. 개인 키를 포함한 인증서는 외부로 유출되지 않도록 따로 잘 보관하여야 하며, 보안 상 Windows Azure에 제출한 개인 키 포함 인증서는 외부 유출 방지를 전제로 다시 회수하기 어렵게 되어있습니다.

참고로, Windows Azure에 제출하지 않은 인증서에 대한 Thumbnail 값을 사용하려고 하면 Windows Azure Portal 사이트에서 패키지를 게시하기 전에 이를 검사하여 배포할 수 없음을 안내하는 메시지가 나타납니다. 인증서에 대한 정보는 메타 데이터 형태로 기술된 XML 파일을 이용하여 확인할 수 있는 것이므로 이를 검사하는 것이므로 이 과정 자체는 오래 걸리지 않습니다.

Hosted Service용 인증서

Hosted Service용 인증서는 각 VM에 직접 설치하는 인증서로, VM 내에서 사용하기 위한 목적으로 제공되며, 나중에 설명할 기회가 있을 것입니다만 Windows Azure AppFabric Access Control을 Windows Azure 환경에서 정상적으로 사용하기 위해서는 꼭 필요하고, 또한 Remote Desktop 서비스를 개통하기 위해서도 필요합니다.

Windows Azure 환경에서의 Remote Desktop은 네트워크 수준 인증을 사용할 수 없기 때문에 모든 암호화 과정을 미리 등록한 인증서를 기반으로 할 수 있도록 되어있습니다. 이는 지난 시간에 살펴본 것과 같은 것으로, Visual Studio를 이용하여 클라우드에 게시할 수 있는 패키지 파일을 작성하기 직전에 지정할 수 있도록 되어있으며 현재는 개별 Role 단위가 아니라 Azure Project 전체에 걸쳐 공유하는 방식으로 인증서 지정이 가능합니다.

Remote Desktop용 인증서 역시 프로젝트 상에서는 Thumbnail 값만이 필요하지만 실제로 작동할 수 있으려면 Windows Azure의 프로젝트용 인증서 목록 안에 들어있어야 합니다. Windows Azure Portal 사이트에서 역시 이 설정을 검사하므로 등록되지 않은 인증서를 사용하려고 하면 업로드 후 배포가 취소됩니다.

Windows Azure Management API용 인증서

Windows Azure에서 사용하는 인증서의 또다른 유형으로는 Management API에서 사용하는 인증서가 있습니다. 이 인증서는 Management API를 사용하려 하는 Consumer와 Management API Provider 사이의 암호화 통신을 성립하기 위한 목적으로 사용되는 인증서입니다.

Management API용 인증서를 포털 사이트에 제출하는 방법은 앞서 살펴본 두 가지 형태의 인증서를 제출하는 방법과 차이가 있습니다. 포털 사이트 내에서 Management API용 인증서는 제출 후 각 VM에 설치되지는 않으므로 양쪽의 용도를 정확히 구분할 필요가 있습니다.

테스트용 인증서를 간단히 만드는 방법

이와 같이 인증서를 활용하는 폭이 많지만 한 가지 궁금한 것은, 때 마다, 그리고 갱신 철마다 매번 VeriSign이나 Thawte와 같은 인증 기관을 통해서 적지 않은 금액을 지불하고 인증서를 갱신해야 하는 것인가에 대한 부분입니다. 결론부터 말하면, 권장 사항으로 말할 것 같으면 모든 인증서를 그렇게 하는 것이 가장 최적이지만, 현실적으로는 그렇게 할 필요가 없습니다. 프로젝트에 관계되어있는 내부 관계자들 사이에서 이용하기 위한 서비스에서 필요한 인증서라면 (원격 데스크톱 제어 시 필요한 인증서와 같이) 임시 인증서를 생성하고 사용하면 됩니다. 하지만 HTTPS 웹 사이트를 실행하려는 경우라면 이는 내부 이해 관계자들 사이가 아닌 대외적인 웹 사이트가 될 가능성이 크기 때문에 정상적인 인증서를 발급받아 서버 인증서로 설치할 수 있도록 해주는 것이 꼭 필요할 것입니다.

정식 인증서를 사용하기 전에는 자체 서명 인증서를 통하여 이런 기능을 미리 시험해볼 수 있으며, 자체 서명 인증서를 만드는 방법은 Windows SDK에 포함되어있는 MAKECERT를 이용하거나 IIS 7 관리자 콘솔의 인증서 생성 마법사를 이용하는 방법이 있습니다. 이 중 명령줄 도구를 사용하는 방법은 http://blogs.microsoft.co.il/blogs/applisec/archive/2008/04/08/creating-x-509-certificates-using-makecert-exe.aspx 의 내용을 활용하시면 도움이 될 것입니다.

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 5. 9. 13:00

Windows Azure를 이용하여 프로그래밍을 하는 작업은 개발자나 관리자 모두에게 큰 변화를 요구합니다. 그 중에서도 가장 큰 변화는, 관리하고 점검해야 할 리소스의 폭 자체에 큰 변동이 온다는 것입니다. 대개의 경우, 인프라를 서비스로 제공받을 것인지, 플랫폼까지를 서비스로 제공받을 것인지, 심지어는 소프트웨어 자체를 서비스로 제공받기를 원할지 중에서 하나를 골라야 합니다. 하지만 개발자들의 관심사는 무엇을 서비스로 제공하는 것 말고도, “어떻게활용할 수 있는가에 대한 것 역시 이슈가 됩니다.

Windows Azure와 같은 플랫폼 기반 클라우드에 대해서 일반적으로 많이 오해하는 부분 중 하나는, 지금 내가 운영 중인 웹 사이트나 서비스 전체를 클라우드로 옮겨야만 하는 것에 대한 부분입니다. 이렇게 하지 않으면 클라우드를 쓰는 것이라고 말할 수 없는 것일까요? 결론부터 이야기하면 전혀아닙니다. 클라우드를 이용하는 방법은 전적으로 여러분의 아이디어에 달려있는 것이다.

신뢰할 수 있고 유연한 저장소를 응용프로그램에 통합하기

Windows Azure에는 서비스나 웹 사이트를 호스팅하기 위한 Compute가 있고, Compute의 성능에 대응할 수 있는 초고속 대용량 저장소인 Storage 서비스가 같이 그룹을 지어 다닙니다. 물론 둘 사이는 Affinity Group으로 묶어서 재해가 발생했을 경우 가용성을 보장할 수 있도록 밴드를 형성하는 것이 기본입니다. 하지만, 기존에 개발 중인 소프트웨어 그 자체에 신뢰할 수 있고 유연한 저장소를 만들고자 한다면 독립적으로 Storage 서비스만을 이용할 수도 있습니다.

익히 알려진 대로, Storage 서비스에는 세부적으로 세 가지 유형의 저장소가 있습니다. 대표적으로 파일을 저장하거나 BLOB 이미지를 관리할 수 있는 BLOB Storage, 대용량 비 관계형 데이터베이스인 Table Storage, 그리고 고속으로 메시지를 큐에 저장하고 불러올 수 있는 Queue Storage가 있습니다. 이들 서비스 모두 HTTP HTTPS 프로토콜을 지원하는데다가, RESTFUL 기반 서비스이기 때문에 인터넷과 호환되는 응용프로그램을 개발할 것이라고 한다면, 여러분이 어떤 개발 도구를 사용하든, 어떤 운영 체제를 목표로 응용프로그램을 개발하든 관계없이 마음껏 활용할 수 있습니다. C# Visual Basic .NET 의 경우 Windows Azure SDK 안의 공식 어셈블리를 사용하면 LINQ to Azure Table Storage까지 사용할 수 있으며, 그 외 많은 오픈 소스 라이브러리들을 Microsoft Interoperability Bridge 공식 웹 사이트를 통하여 찾아볼 수 있습니다.

여러분의 웹 사이트를 좀 더 인터넷 친화적으로 만들기

요즈음 웹 사이트들은 매우 개방적입니다. 단순히 RSS ATOM Feed로 데이터를 노출한다거나, RESTFUL 기반 URL 다시 쓰기를 지원한다고 해서 그런 것이 아니라, 인증에 대한 개념 자체를 완전히 다르게 해석하고 접근하는 사이트들이 많기 때문입니다. Open ID, Live ID 등 다양한 방법으로 불리고 있지만 한 가지 일관성을 보이는데 바로 이들 개별 웹 사이트들은 여러분의 ID와 암호가 무엇인지에 대해서는 전혀 관심이 없고, 그저 여러분이 누구인지에 대해서만 관심이 있을 뿐이라는 점입니다. 이러한 인증 행태를 놓고 클레임 기반 인증이라고 말합니다.

클레임 기반의 인증을 사용하는 웹 사이트들의 대표적인 예로, Twitter 관련 플러그인 사이트들이 있으며, 페이스 북에 올라가는 수많은 Social App들 역시 그러합니다. 그리고 국내에서는 그간 유명했던 스프링노트가 Open ID를 잘 지원하고 있고, 과거의 이야기가 되었지만 ME2DAY 역시 Open ID를 지원했던 때가 있습니다. 클레임 기반의 인증을 통하게 되면 어떤 이점이 있기에 이렇게 많은 웹 사이트들이 채택을 하고 있는 것일까요? 조금 전에 이야기한 것처럼, 여러분의 웹 사이트가 책임지고 관리해야 할 위험 부담 중 가장 큰 것을 완전히 덜어버리고 비용도 절감할 수 있기 때문입니다.

클레임 기반의 인증을 여러분의 웹 사이트에 적용한다는 것은, 해당 웹 사이트를 방문하는 사용자들이 이미 타 기관에서 인증을 거친 후에 다시 여러분의 웹 페이지로 이동한 것을 의미하고 여기에 대한 모든 정보를 해당 인증 기관으로부터 선택적으로 넘겨 받게 되는 것입니다. 다시 이야기하지만 상대방의 ID와 암호를 알 필요 없이 피아식별이 된 상태를 유지할 수 있다는 것입니다.

Windows Azure의 경우, 여기에 한 가지 더 편리한 서비스를 제공하는데, 이번에 새로 업그레이드된 Windows Azure AppFabric Access Control v2.0이 그 주인공입니다. 이하 Access Control은 처음 발표 당시에는 여러분이 소유하고 있었던 Active Directory를 인증의 주체로 세울 수 있는 Active Directory Federation Services (AD FS)와 이에 연관된 서비스만을 지원했지만, 이번 업그레이드에서는 그 뿐만 아니라 Windows Live ID, Google, Yahoo, Facebook 등의 유명한 인터넷 서비스 공급자들의 ID로 신원 인증 수단으로 추가 지원하게 되었습니다. 인증 관련 서비스에 장애가 발생할 걱정 없이, 그리고 여러분의 개별 웹 사이트에 대한 해킹 위험은 최소화시키면서 서비스 그 자체에만 집중할 수 있게 되는 것입니다.

확장 가능한 Cache/Session 서비스 사용하기

Windows Azure에 근래 들어서 추가된 또 다른 매력적인 서비스는 바로 AppFabric Cache 서비스입니다. AppFabric Cache Server AppFabric Cache와 기술을 공유하지만, 내부적으로는 Windows Azure Cloud Computing 기술을 바탕으로 매우 높은 성능의 Cache 서비스를 제공하는 것으로, ASP .NET 뿐만 아니라 다른 여러 플랫폼과도 혼용해서 사용할 수 있는 것이 장점입니다.

단순히 Cache 서비스뿐만 아니라, Session State까지 AppFabric Cache에서 통합 관리할 수 있기 때문에, 사이트 간 Session 공유나 Single Sign On 등의 기능을 어렵지 않게 구현할 수도 있습니다.

그 외에도 수 많은 가능성들

이 글에서 모두 열거하기 힘들 정도로 Windows Azure의 서비스들은 날이 갈수록 풍성해지고 성숙도를 더해가고 있습니다. Real-World Windows Azure Development Guide 시리즈는 Windows Azure Platform의 여러 기술들을 지속적으로 알리고 개발자들에게 좀 더 친숙한 Cloud 개발을 할 수 있는 방안을 모색하기 위하여 시리즈로 연재 될 예정입니다. 많은 관심과 피드백을 독자 여러분들께 부탁 드리고자 합니다.

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 3. 29. 00:21

이전 글: [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 라이선스로 전환할 수 있도록 해준다.

매우 이상적인 이야기처럼 들릴 수도 있지만 사실 중요한 문제가 두 가지가 있다. 라이선스에 관한 것이 있고, 또 다른 하나는 기술적인 구성 상의 문제이다. 다음의 표에 대략적인 내용을 언급해두었다.

구성 요소 및 역할

변경 방향

3rd Party Software

Plan A: Public Cloud 호환 라이선스로 재계약

Plan B: 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합 / 단 Traffic 추가로 인한 변동 사항은 해당 공급자와 재 협상 필요

3rd Party Software Data

SQL Server Embedded DB

è MDF 및 LDF 파일을 SQL Server에 연결하고, 해당 DB를 SQL Azure로 이관해야 함

è MDB 파일이나 ACCDB 파일의 경우 SQL Server로 이관 후 SQL Azure로 이관해야 함

기타 데이터베이스

è 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합

SQL Server

Plan A: SQL Azure로 부분/전체 Migration

Plan B: 관계 지향적이지 않고 대용량 DB가 필요한 경우 Windows Azure Table Storage 사용

Plan C: 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합

Exchange Server

Plan A: Office 365로 부분/전체 Migration

Plan B: 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합

SharePoint Online

Plan A: Office 365로 부분/전체 Migration

Plan B: 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합

Lync Online

Plan A: Office 365로 부분/전체 Migration

Plan B: 기존 서버를 유지하고, Windows Azure Connect로 네트워크 통합

Active Directory

AD DS, AD LDS 모두 기존의 On-Premise 시스템을 Windows Azure Connect를 경유하여 활용하는 것이 최선

 

라이선스에 관한 문제의 본질은 다음과 같다. Windows Azure Compute를 통해서 서비스가 실행되면, Service Level Agreement (SLA) 계약 이행을 위하여 기본적으로 VM을 1대 이상 사용하는 것을 전제로 한다. 최소 1대만을 유지하도록 설정해도 상관은 없지만, 필연적으로 사용량이 증가하고 서비스를 위하여 배치된 VM들의 상태가 바빠지는 것이 감지되면 자동적으로 Fabric Controller가 원본 VM 이미지를 복제하여 새로운 VM을 복제하기 시작한다. 이것이 의미하는 바는 단순하다. 물리적인 Instance의 수가 자동으로 늘어나므로 그 안에 포함된 3rd 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) 집필진 활동 중
Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 2. 27. 16:40

다음 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around cloud computing – 1인 1근두운 시대
이전 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around Cloud Computing – 당신이 어디에 있든 관계없는 세상

이력서 안 고친지 꽤 지났는데……

지난 글에서는 Windows Live, Live@edu, Office 365를 통하여 사람들이 가정에서, 학교에서, 그리고 직장에서 Cloud Computing과 어떻게 친하게 지낼 수 있는지를 살펴보았다. 오늘은 기업 내에서 충실하게 제 몫을 다하고 있는 전산 자원들을 Cloud Computing 환경에 맞도록 업그레이드시키기 위한 방법인 가상화에 대하여 살펴보려고 한다. 가상화는 Cloud Computing의 한 축을 이루는 중요한 기술이다.

일각에서는 Cloud Computing의 도래를 두고, Microsoft나 유명 IT 기업들만의 잔치판이 될 것이므로 기업 내에서 일하는 모든 IT 전문가와 개발자들이 스스로 사표를 내도록 종용 당하게 만들 것이라고 좌절하는 목소리가 심심치 않게 들려온다. 그러나 필자의 생각은 다르다. 오히려 이전보다 더 뛰어나고 완벽한 IT 기술을 필요로 하게 될 것이며, 한 층 더 자동화되고 지능적인 시스템과 같이 일할 수 있도록 해야 하며, 사실 지금이 바로 열심히 여러분의 이력서의 새 버전을 작성해야 할 때인 것이다.

가상화에 대한 이해

이 글을 읽는 독자 대다수는 집에서 여러분의 배우자나 어머님께서 설거지하시는 모습을 잘 기억하고 있을 것이다. 그릇을 닦기 위하여 수세미를 사용하고, 그릇에 묻어있는 기름기를 걷어내기 위하여 매직 블록을 조각 내어 주방 세제에 묻혀 사용하는 그런 모습 말이다. 필자는 서버 가상화를 설명하는데 이보다 더 좋은 소재는 없다고 생각한다.

방금 이야기한대로 서버 가상화는 멀티 코어로 확장되는 엄청난 성능의 서버 컴퓨터를 효율적으로 사용할 수 있도록 도와주는 매우 똑똑한 전략이다. 매직 블록을 통으로 다 쓰는 것보다는, 잘게 조각 내어 여러 차례 필요한 만큼 사용하는 것이 더 오래 쓰고 좋은 세척 능력을 보여준다. 이전과는 다르게 서버 컴퓨터도 이러한 방법으로 나누어 쓰는 것이 대세인 시대가 되었다. 그렇지만 이를 어떻게 나누고 관리할 것인가?

응용프로그램 개발자들에게 있어서 이 질문에 대한 답은 병렬 프로그래밍 기법이다. 병렬 프로그래밍 그 자체는 이전부터 계속 사용이 가능했던 기법이었지만 최근에 중요한 변화를 맞이하게 되었다. 병렬 프로그래밍은 엄밀히 말하면 사람이 인지하기 어려울 정도로 빠른 속도로 사용자가 컴퓨터에게 지시하여 형성한 문맥들을 회전하면서 작업을 처리하는 것으로, CPU의 발전 과정과 연계를 지어보면 쉽게 이해할 수 있다. 초창기의 CPU들은 회전의 빠르기를 뜻하는 주파수가 높지 않았기 때문에 많은 작업을 할 수 없었지만, 어느 순간에 이르러서는 단일 CPU가 GHz 단위까지 주파수를 높여서 만족스러운 성능을 보여주기도 하였다. 그러나 속도가 아무리 빠르다 한들 결국 문맥들 사이를 전환할 수 있는 성능 상의 임계는 변치 않기 때문에 이를 원점에서 극복할 수 있도록 다중 CPU의 시장 진출이 활성화된 것이다. 이에 따라 여러 개의 CPU를 기본적으로 운영 체제의 재량에 따라 활용할 수 있는 기회가 생겼고, 응용프로그램 개발자들에게도 같은 기회가 주어진 셈이다.

서버 가상화는 여기에서 출발한다. 운영 체제가 사용자에게 제공할 수 있는 병렬 연산은 두 가지로 볼 수 있는데, 비교적 실행 시간이 짧거나 유한한 범위 내에서 작업이 완료될 수 있는 알고리즘의 병렬화를 커버하기 위한 Multithread 연산은 개발자들을 위한 영역이다. 그러나 유한한 시간 내에 종결되는 작업이 아닌, 독립적인 세션을 만들어서 운영하는 방법도 필요했는데 그것이 가상화 기술이다. 초창기의 가상화 기술은 Emulation에 가까웠던 것으로 다른 시스템의 동작을 모방하여 특정 프로그램이나 동작을 재현하는 경우가 많았다. 그러나 시간이 흐를수록 좀 더 실용적으로 가상화 기술을 개발하기 시작하여 실제로 사용할 수 있는 형태로 만들기 시작하여 현재의 가상화 기술에 이르게 되었다. 이러한 가상화 기술을 Hypervisor라고 하며, 우리가 흔히 이해하는 것은 Type 2의 개념이고, 요즈음 주목을 받는 것은 Type 1의 개념이다.

Type 1과 Type 2 사이의 차이점은 한 마디로, 가상화 기술을 사용자에게 서비스하는 관점의 차이이다. Type 2의 경우 사용자는 가상화 기술을 하나의 하위 응용프로그램으로 보는 구조이고, Type 1은 가상화 기술로 생성된 다수의 독립적인 서브 시스템 앞에 사용자가 한 명 이상 접근하는 구조이다.

사실 Type 1의 Hypervisor 자체는 1960년대부터 지속적으로 개발해온 시스템이지만, 일부 고가의 하드웨어에 한정되는 사양이었기 때문에 많은 관심을 받지 못하였다. 뿐만 아니라 일반 PC에서 이를 구현하기에는 성능도 부족하였고, 또한 일반 PC에서 실행되는 운영 체제의 전부를 Type 1의 가상화를 구현하는 데에 모두 바치는 것 또한 굉장한 낭비였기 때문이다. 그러나 PC 및 Workstation Computer의 사양이 드디어 이런 기능을 구현하기에 충분한 수준까지 이르게 되면서 다시금 주목 받게 된 것이다.

가상화를 구현하는 방법에 있어서는 전 가상화와 반 가상화로 나눌 수 있는데 전 가상화는 동일한 아키텍처의 시스템을 하나의 격리된 영역에서 다시 구축하는 것을 말하는데, CPU, BIOS 등 가장 하단에 위치하는 하드웨어까지 Emulation을 하는 것을 말한다. 가상화를 통하여 모든 운영 체제를 완전히 독립적으로 실행할 수 있는 것은 이런 사양을 전제로 하기 때문이다. 그러나 전 가상화 이외에도 호스트 시스템과의 상호작용, 연동 제어 등의 요구 사항이 실제로는 더 필요했기 때문에 가상과 실제 사이의 경계를 가로지를 수 있는 인터페이스가 필요한데 이를 반 가상화를 통하여 구현하고, 반 가상화 기술을 통하여 가상 환경 상의 성능 저하를 개선하는 경우도 있다. 즉, 현실과 타협한 것이 반 가상화에 의한 구현인 셈이다.

반 가상화를 구현하는 방법은 가상화 기술 제조 업체마다 차이가 많지만, 호스트 운영 체제를 처음부터 가상화 기술을 잘 수용할 수 있도록 개조하는 방법이 있고, 기본 목적을 유지하면서 확장된 아키텍처를 수용할 수 있도록 확장하는 방법이 있는데, Microsoft의 Hyper-V는 후자에 속하는 방법을 제공한다. 뿐만 아니라 Windows Server Core 환경 위에도 Hyper-V Hosting 기능을 제공하여 호스트 컴퓨터가 외부 네트워크에 노출되는 표면적을 최소화하고 안정성을 보장하는 기법을 구상하는 것 역시 다른 오픈 소스 플랫폼들과 마찬가지로 가능하다. 기존에 구매한 Windows Server 인프라를 버리고 중복 투자할 필요 없이, 약간의 방법 터득 만으로도 충분히 만족스러운 Private Cloud를 구현할 준비가 이미 되어있는 것이다. 그러므로 부디 멀리 떠나지 말자.

IT 전문가들은 가상화로 무엇을 어떻게 할 것인가?

가상화 기술로 시스템을 분할하고 나면 그 다음에는 무엇을 할 것인가? 이 질문에 대해 IT 전문가들이 찾을 수 있는 방안은 시스템 구성 복잡도의 감소, 빠른 테스트 환경 구축, 가상 데스크톱 인프라 구축으로 분류할 수 있다.

서버를 한 대 이상, 여러 대를 배치할 수 있는 전산 환경에서는 한 서버에 1개 이상의 역할을 맡기지 않지만 현실적인 이유와 비용 상의 문제 때문에 이런 규칙은 쉽게 깨진다. 가상화를 이용하여 시스템을 나눈다면 이 규칙을 다시금 당연하게 받아들일 수 있게 될 것이다. 여기에, 게스트로 사용하려는 서버 운영 체제가 Windows Server 2008에 해당하는 경우 테스트 환경까지 자동화할 수 있는 혜택도 덤으로 얻는다. Windows AIK를 사용하여 자동 응답 파일을 만들 수 있고, 이렇게 만들어진 자동 응답 파일을 WIM2VHD와 같은 도구에 매개 변수로 지정하여 Windows 설치 디스크 이미지를 곧바로 부팅 가능한 가상 하드 디스크로 Provisioning하는 것뿐만 아니라 기초 설정까지 단번에 Customizing하는 것이 가능하다.

이렇게 만들어진 원본 가상 하드 디스크를 기점으로 차이점 보관 디스크 등을 사용하여 가상 하드 디스크들을 버전 관리할 수 있으므로 각종 업데이트와 Hotfix 설치에 민감하게 반응하는 시스템을 가상화해야 하는 경우 이는 매우 이상적인 환경이 아닐 수 없다. 이러한 작업들을 Private Cloud Computing 환경에 알맞게 솔루션 차원에서 도와주는 것이 바로 System Center Virtual Machine Manager이며, 관리자가 수작업으로 이러한 과정을 수행하지 않고 Active Directory 인프라를 이용하여 인증부터 시스템 Provisioning까지 웹 상에서 처리할 수 있도록 돕는 것이 SCVMM Self Service Portal이다.

가상 데스크톱 인프라는 앞서 설명한 기술들로 갖추어진 인프라를 이용하여 종전에 널리 사용되었던 터미널 서비스가 결합되어 완성된다. 종전의 터미널 서비스에서 보여지던 것은 동일하게 구성된 서버들 사이를 라운드 로빈 등의 알고리즘을 이용하여 연결을 분산시키고, 사용자가 응용프로그램을 빌려 쓰는 방식이었다. 반면 VDI는 응용프로그램 대여가 아닌 가상 PC 전체를 완전히 특정 사용자에게 임대하는 방식이기 때문에 VDI로 만족할만한 성과를 얻을 수 있으려면 얼마나 빠르게 VDI용 가상 PC를 Provisioning할 수 있는지도 관건이 된다. 뿐만 아니라, 이런 식으로 만들어진 가상 PC들에 대한 최신 업데이트와 보안 점검을 수행하기 위해서는 종전에 잘 알려진 WSUS나 Forefront를 쉽게 제어할 수 있는 System Center 솔루션 전반이 역시나 필요하다.

지금 언급한 사항들만 대충 살펴보더라도 관리자가 가상화나 Private Cloud 기술 때문에 직업을 잃어버리기는커녕 한층 더 복잡하고 높은 수준의 기술에 대한 이해가 필요함을 알 수 있다. Microsoft VDI에 대한 전반적인 Overview 및 Licensing 정보를 살펴보려면 아래의 동영상을 살펴보기 바란다.



http://www.microsoft.com/showcase/en/us/details/9291a982-2f32-4d25-84bb-671accbcb002

그리고 여기에 여러분들은 한 가지 더 이점을 얻을 수 있다. Windows 7 SP1과 Windows Server 2008 R2 SP1의 출시와 더불어서 가상 컴퓨터 상의 게스트 운영 체제들의 성능을 미리 계산된 불연속적인 값에 의한 설정이 아닌, 연속적이고 유동적으로 변경 가능한 설정으로 재 구성이 가능한 Dynamic Memory 기능과 더불어, 다소 비싼 하드웨어를 필요로 하지만 Remote Session을 경유하더라도 3D 그래픽과 렌더링을 경험할 수 있는 RemoteFX 기술 지원까지 가능하게되어 한 층 더 높은 활용도를 제공한다. Windows 7 SP1과 Windows Server 2008 R2 SP1은 지금 Windows Update를 통하여 업데이트가 가능하며, 기술적인 상세 정보는 http://blogs.technet.com/b/koalra/archive/2011/02/10/windows-7-windows-server-2008-r2-1-rtm.aspx 의 내용을 확인하기 바란다.

개발자들은 가상화로 무엇을 할 것인가?

개발자들에게도 가상화는 작업하는 방법에 많은 변화를 가져다 준다. 그 중에서도 테스트 과정에 지대한 영향을 가져다 준다. 가상화를 통해서 가장 먼저 수혜를 누리는 것은 바로 Mobile 및 Embedded 장치 개발이다. 원칙적으로, Mobile과 Embedded 장치를 대상으로 응용프로그램을 개발하기 위해서는 개발자 당 1대 이상의 실제 장치가 필요한 것이 당연하다. 하지만, 앞에서 언급한 전 가상화 기술을 통해서 Intel CPU가 아닌 Mobile 장치의 CPU를 Emulation하여 약간의 제한 사항이 있지만 기본적인 테스트에는 문제가 없도록 해주는 테스트 및 디버깅 환경을 완성시켜준다. 이는 Windows Mobile 6.x, Windows Phone 7, Windows Embedded Compact 7을 통해서 쉽게 경험할 수 있었던 부분들이다.

그러나 한 발 더 나아가서, 테스트와 디버깅을 실제 Windows 운영 체제에서도 실행할 수 있어야 하고, 테스트 주도 개발 (TDD) 방법론에 입각하여 테스트를 수행하고, 확실한 QA를 수행하여 개발자와 직접 상호 작용할 수 있는 개발 방법론을 구현할 수 있도록 하려면 그 다음은 무엇이 필요할까? 답은 Visual Studio 2010 Ultimate부터 제공되는 Test Lab Management이다.

Test Lab Management는 내부적으로 SCVMM와 Hyper-V를 사용하여 테스트 환경을 구축하게 되며, Team Foundation Services (TFS) 영역 내에서 관리되는 프로젝트와 통합되어 자동 및 수동 테스트 케이스에 따라 테스트를 진행하고 Screenshot과 같은 일차원적인 정보 수집 말고도 시스템 상태, 문제가 발생했던 시점의 Stack Trace 기록은 물론 변수 상태까지 기록하여 데이터베이스로 저장하는 IntelliTrace 로그 수집까지 처리한다. 필요한 모든 주변 정황들이 소프트웨어 통제 환경 아래에 놓이게 되므로 재현 불가능한 버그가 나타나지 않도록 도와준다. 아래의 동영상은 Test Lab Management로 실제로 QA를 진행하는 과정을 보여주는 Overview 동영상이며 한 번 재미 삼아 보기를 권한다.




http://msdn.microsoft.com/en-us/vstudio/ff945982

다음 시간에는

기본적으로 가상화를 통하여 일상적인 시스템 관리 작업 및 테스트 작업들을 소프트웨어가 서 있는 땅 아래로 가져다 놓고 모든 것을 Top-Down으로 관리하는 것이 이루려고 하는 목표이다. 이전에 언급하였던 대로, 개념적으로는 간단할 수 있지만, 이러한 작업들을 성공적으로 수행할 수 있으려면 적어도 규모에 관계없이 여러분이 완전히 제어하고 통솔할 수 있는 데이터 센터의 소유와 IT 전문가, 그리고 개발자들을 필요로 한다. 그리고 이런 환경을 가지고 있든, 가지고 있지 않든 진정으로 뛰어난 성능을 필요로 하고, 비즈니스의 핵심 가치에 집중하기를 원한다면, 다음 시간에 언급할 Windows Azure Platform으로의 이동을 바로 지금 준비할 때이다.

처음 Windows Azure Platform이 발표된 이후부터 지금 이 순간까지 많은 변화가 있었고, 지난 PDC'10에서 발표된 업데이트에는 IT 전문가들이 Private Cloud 뿐만 아니라 Public Cloud에서도 역량을 펼칠 수 있도록 도와주는 Windows Azure Connect 및 Virtual Machine Role이 발표되었다. 앞으로 2회 연재에 걸쳐서 Windows Azure Platform이 IT 전문가들과 개발자들에게 어떤 변화를 가져다 줄 수 있는지 더 살펴보려고 한다.

글쓴이 이력

  • 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) 집필진 활동 중
Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2011. 2. 25. 10:36

안녕하세요. Windows Azure MVP 남정현입니다. 이제 2월도 얼마 남지 않았네요. 2011년을 새로운 마음으로 맞이하고나서 정말 빠르게 시간이 흐르는것 같습니다. 오늘은 Windows Azure를 좀 더 쉽고 간편하게 경험할 수 있는 방법을 소개해드리기 위하여 글을 올립니다.

Windows Azure Virtual Lab

이전에 특정 프로그래밍 언어나 Windows Server 제품군, 또는 실버라이트 개발 등을 위하여 Virtual Lab으로 미리 학습을 해보신 적이 있으신가요? Microsoft는 가상화 기술을 이용하여 인터넷 상에서 누구나 무료로 Microsoft의 최신 기술을 컴퓨터에 추가적인 소프트웨어를 설치하지 않고서도 테스트해볼 수 있는 Virtual Lab을 운영합니다. 단순히 테스트 환경만 제공하는 것이 아니라 구체적인 실습 가이드 라인을 통하여 자습할 수 있도록 도와줍니다. Windows Azure Virtual Lab의 컨텐츠는 계속 업데이트되고 있으며 이 글을 올리는 현 시점에서 다음의 Virtual Lab이 제공됩니다.

  • MSDN Virtual Lab: Windows Azure Native Code
  • MSDN Virtual Lab: Building Windows Azure Services with PHP
  • MSDN Virtual Lab: Getting Started with Windows Azure Storage
  • MSDN Virtual Lab: Building Windows Azure Services
  • MSDN Virtual Lab: Using Windows Azure Tables
  • 실제 Windows Azure 계정을 제공하는 것은 아니며, Visual Studio 및 Windows Azure Tools for Visual Studio가 미리 설치된 가상 PC 환경을 제공하는 것입니다. 업데이트되는 전체 Virtual Lab 컨텐츠를 보시려면 http://msdn.microsoft.com/en-us/dd540819 페이지를 방문하시면 되겠습니다.

    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요

    PaaS2011. 2. 17. 16:37

    인터넷 검색 중에 아주 흥미로운 웹 캐스트를 하나 발견하였습니다. 닷넷 기반 응용프로그램 프레임워크 전문 개발 업체인 DevForce를 기반으로 하는 Prism Explorer와 이에 연관된 Northwind 샘플 데이터베이스를 기초로 하는 엔터프라이즈 응용프로그램을 Windows Azure Platform의 Windows Azure Compute와 SQL Azure Database로 마이그레이션하는 웹 캐스트입니다. 기본적으로 이 동영상은 DevForce 프레임워크의 클라우드에서의 활용 가능성 및 실리성을 설명하기도 하지만, 동시에 Windows Azure Platform에 대한 실질적인 예를 들어주는 좋은 사례라 생각하여 블로그에 백서와 동영상에 대한 링크를 첨부하였습니다.

    백서 다운로드 (English Only): http://www.ideablade.com/PDF/DevForceInAzure.pdf
    동영상 출처 (English Only): http://www.ideablade.com/Videos/PrismExToAzure/
    홈페이지: http://www.ideablade.com/DevForceProductPlatform/DevForceInAzure.aspx

    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요

    PaaS2011. 2. 14. 17:22

    이전 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around Cloud Computing - “Everything as a Service”
    다음 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around cloud computing – 지금이 여러분의 이력서를 새로 쓸 시간

    여러분이 어디에 있든 관계없는 세상은 이제 현실

    당연한 이야기이지만 여러분이 어디에 있든 관계없는 세상은, 이제는 전세계 어디서나 적용된다. 물론 세세하게 따지고 들어가면 예외 사항이 많지만 필자가 이 글에서 논하고 싶은 것은 "가능성"에 대한 사실이다. 여러분이 자주 다니고 이용할 수 있는 공항, 커피 전문점, 식당, 심지어는 호텔 안에서도 즉시 노트북이나 스마트폰을 켜고 3G 인터넷이나 WIFI 인터넷을 쓸 수 있다. 회사 컴퓨터 앞에 앉아서 하던 것처럼 메일 서비스에 접속하여 여러분 앞으로 메일을 확인하거나, 가까운 사람과 이야기를 나누기 위하여 메신저에 접속하여 수다를 떠는 것이 너무 당연하다.

    클라우드 시대 이전에도 이런 일은 가능했다. 물론 여기에도 클라우드에 대한 이야기가 일부 – 또는 – 전체가 포함이 되어있을 것이다. 그러나 클라우드의 도래를 말하는 지금, 여기서 무엇을 더 기대할 수 있을까? 이번 글에서 이야기하려는 Office 365는 앞에서 이야기하였던 "여러분이 어디에 있든 관계없는 세상"에 덧붙여 – 여러분이 어디에 있든 자유롭게 일할 수 있는 세상이 이제 현실이라는 말을 만들어준다.

    가정과 회사를 넘나들며 사용할 수 있는 최고의 소프트웨어+서비스 – Windows Live

    Windows Live는 Microsoft가 일반 사용자들에게 제안하는 온라인 서비스이자, 동시에 서비스에 연동되는 소프트웨어 전반을 제공하는 패키지로, 대표적인 소프트웨어+서비스 전략 기반의 상품이다. 2005년 11월 1일 처음 발표된 이후로 지속적으로 새로운 제품 라인을 구축하고, 사용자들의 요구 사항을 반영하며, 더 새로운 서비스와 소프트웨어로 개선해 나가고 있는 중인 "진행형" 서비스이다.

    Windows Live에서 가장 유명한 것은 여러분이 MSN 시절부터 줄곧 사용해왔을 Windows Live Messenger이다. 멀리 떨어져있는 사람들과 마치 옆에 있는 것처럼 화상 카메라와 마이크로 폰 등을 이용하여 실시간으로 영상 채팅을 하기도 하고, 텍스트와 이미지 등을 잘 사용하여 간단한 메시지를 주고 받기도 해왔다. 그리고 더 길고, 더 많은 메시지를 전달하기 위하여 Windows Live Messenger와 함께 Hotmail 전자 메일 서비스도 같이 활용하는 사람들이 많았다. 결론적으로, 이 두 가지의, MSN 포털 서비스의 일부로 출발한 소프트웨어와 서비스를 필두로 수 많은 확장 소프트웨어와 서비스들이 지금의 Windows Live를 이루고 있는 것이고 더 나아가서는 Windows 운영 체제의 강력한 확장 패키지로 자리잡게 된 것이다.

    그 중에서도 이 글을 쓰는 현 시점에서는 단연 Windows 7과 Windows Live의 조합이 여러분을 위치로부터 자유롭게 해줄 프리미엄 패키지가 되어줄 것이다. 2010년 말에 새롭게 선보인 Windows Live Essential 2011과 더불어, 몇 가지 주목할 만한 온라인 서비스를 살펴보자.

    Windows Live Mail - Windows 98 이상, Windows XP 이하의 운영 체제들을 자주 사용해왔던 많은 사용자들의 기억에 남아있는 Outlook Express를 계승하는 차세대 경량 메일 클라이언트 소프트웨어이다. Outlook Express에서는 이전에 Hotmail 웹 API를 이용하여 메일을 보내거나 확인할 수 있는 기능을 제공했지만 현재는 Windows Live Mail로만 이 기능을 이용할 수 있다. Windows Live 소프트웨어의 일부이므로 Windows Live ID를 사용하여 사용자 인증을 수행하고, Windows Live Messenger와 함께 사용할 수도 있다. 이번 2011 버전에서 더 좋아진 점은 다른 인터넷 서비스들과 더 친화적으로 가까워져서 Google의 메일 서비스 등과도 더 잘 작동한다.

    Windows Live Mesh - 이번 Windows Live Essential 2011에서 많은 사용자들의 인기를 얻고 있는 동기화 소프트웨어이다. 초고속 인터넷이 활성화되고, 사용자들이 컴퓨터를 켜놓고 이동하거나, 컴퓨터의 성능이 좋아짐에 따라 유휴 시간에 처리할 수 있는 작업량이 늘어났다는 점에 착안하여 지정한 폴더를 클라우드 서비스 저장소 상에 미리 동기화하는 방법으로 여러분이 언제 어디에 있든 자료를 빠르고 쉽게 접근할 수 있도록 도와주는 백그라운드에서 실행되는 소프트웨어이다.

    Windows Live Family Safety - Windows Vista에서 제공된 자녀 보호 기능과 Windows Live OneCare에서 제공되던 동일 서비스를 좀 더 확대하고 강력하게 기능을 보강한 서비스이다. 일방적인 ID/암호를 사용하여 관리하는 타 소프트웨어처럼 Brute Force 방식으로 뚫릴 가능성이 있거나, Windows 운영 체제 기능의 일부가 아니라는 한계 때문에 쉽게 파괴되는 등의 취약점을 일절 허용하지 않는, Microsoft가 검증하는 자녀 보호 기능을 무료로 사용할 수 있다. 이러한 기능을 위하여 불완전한 추가 소프트웨어를 구입하는 일은 없어야 하겠다.

    Windows Live Writer - 블로거들을 위한 소프트웨어로 처음 알려진 이후로 국내외 수많은 블로거들이 애용하는 소프트웨어이다. 주요 블로그 서비스들을 모두 지원하고, 다른 Windows Live 소프트웨어와 Microsoft Office 제품과 호환되는 WYSIWYG 편집 기능을 제공하므로 웹 브라우저로 작업하면서 느끼는 불편함을 겪지 않고 최상의 편집 환경을 유지할 수 있는 장점이 있다.

    Windows Live Photo Gallery - 디지털 카메라를 이용하는 사람들의 수가 전세계적으로 매우 많다. 하지만 디지털 카메라를 이용하여 사진을 관리하는 작업은 결코 간단하지 않다는 것을 이미 우리는 여러 해 동안 잘 경험해왔다. 그리고 가끔은 사진을 잘못 찍어서 다른 사람에게 미안했던 경험도 있을 것이다. Windows Live Photo Gallery는 Windows Live SkyDrive와 연계하여 사진을 체계적으로 클라우드에 저장하고 공유할 수 있는 방안, 전자 메일로 손쉽게 전송할 수 있는 방안, 그리고 비슷한 여러 장의 사진을 이용하여 마음에 들지 않는 사진을 원하는 사진으로 전문적인 소프트웨어 없이 편집할 수 있는 기능까지 기존의 멀티미디어 관련 기능 위에 신 기능으로 중무장하였다.

    Windows Live Messenger – Windows Live Essential 이전부터 지속적으로 발전을 거듭해왔고, 두 말할 필요 없는 최고의 메신저 서비스와 소프트웨어이다. 역사가 오래된 만큼 이제는 더 넣을 것이 없지 않겠는가 하는 생각이 들기도 했지만 이런 예상을 뒤엎고 더 많은 사람들에 다가갈 수 있는 기능이 더해져 더욱 매력적으로 업그레이드되었다. Social Network 서비스, 그 중에서도 Facebook과 같이 이전의 메신저나 전자 메일과는 조금 다른 형태의 커뮤니케이션 방식에 대해서도 완벽한 기능을 제공한다. 이에 맞추어, 기존의 메신저 대화 이름은 가장 최근에 남긴 상태 메시지로, 첫 화면은 대화 상대 목록을 보여주는 화면 말고도 넓은 패널에 여러 Social Network 서비스로부터 수집된 지인들의 동향까지 보여주며, 동영상과 사진도 브라우저를 열지 않고 그 자리에서 바로 볼 수 있게 해준다. 무엇보다도, Facebook의 채팅 기능과 Messenger 대화 상대 기능을 직접 연결할 수 있는 것은 참 좋은 기능이다.

    Windows Live Hotmail – Hotmail이 더 새로워졌다. 이전의 느리고 답답한 화면은 잊어버려도 좋다. 사용자가 원하는 것이 무엇인지 스스로 찾아 알려주는 똑똑한 기능과 함께 이번 2011 업데이트에서는 별도의 소프트웨어를 설치하지 않아도 메일을 이용하여 슬라이드 쇼를 작성하거나 오피스 문서를 곧바로 작성하여 첨부할 수 있으며, 역으로 받아온 메일의 사진들을 슬라이드 쇼로 보거나 오피스 문서를 웹 상에서 보고 편집할 수 있는 기능도 제공한다. 또한, Live View의 기능은 지속적으로 발전하여 별 뜻 없이 메일 본문에 YouTube 동영상 링크를 붙여 넣었거나 FEDEX의 운송장 번호를 붙여 넣었다면 Live View 영역에 YouTube 동영상을 웹 브라우저를 열지 않고 바로 볼 수 있게 해주고, 물류 운송 상태를 FEDEX 홈페이지에 직접 가지 않고 곧바로 조회하여 보여주기까지 한다.

    Windows Live SkyDrive – 많은 인기가 없을 것이라 생각한, 여느 웹 저장소와 다를 것이 없어 보였던 이 서비스가 바로 이번 Windows Live 2011 업데이트의 중추라고 한다면 아마 놀라게 될 것이다. 제품 로고에 있는 것처럼 하늘 위에 떠 있는 구름에 저장하는 것처럼 답답한 메일 첨부 파일이나 하드 디스크의 어느 한 구석이 아닌, 언제 어디서나 찾아 쓸 수 있는 여러분만의 대용량 저장 공간을 제공한다. 이를 이용하여 Hotmail과 Photo Gallery는 슬라이드 쇼를 남들에게 보여줄 수 있도록 도와주고, 또 Hotmail과 Office Web App이 웹 상으로 문서를 편집하는 기능도 제공하며, 앞서 살펴본 Live Mesh 또한 다름아닌 SkyDrive에 모든 데이터를 저장하기도 하고 로컬 드라이브에 다시 파일을 내려주기도 한다. 무엇보다도 Office Web App을 직접 사용하면 여러 사람이 동시에 편집에 참가하여 공동 작업을 할 수도 있으므로 못하는 것이 없다.

    12년동안 학생 여러분들의 베프 (Best Friend)가 되어줄 Live@edu

    초등학교 6년, 중학교 3년, 고등학교 3년 동안 학교 생활을 하는 수많은 어린이와 청소년들에게도 이제는 과거와 다르게 컴퓨터를 사용하는 것은 과제에서부터 학습에 이르기까지 꼭 필요한 일이 되었다. 이 단락을 시작하기 전에, 독자 여러분이 아직도 컴퓨터를 사용하는 것이 게임만 하기 위함이라고 생각하여 아직도 컴퓨터를 사주지 않은 부모에 해당된다면 당장 생각을 바꾸기를 권한다. 컴퓨터 게임을 오래 하는 것이 걱정된다면 Windows Live Family Safety를 설치하여 이를 예방할 수 있기 때문이다. :-)

    본론으로 돌아와서, Live@edu는 학교 IT 관리자가 추가 비용 없이, Microsoft의 클라우드 데이터 센터를 활용하여 학교 내의 전자 메일 및 저장소 시스템을 구축할 수 있도록 도와주는 서비스이다. 앞에서 살펴본 Windows Live 서비스가 개인을 위한 서비스라면, Live@edu는 Microsoft Exchange Online을 기반으로 제공되지만 공동 편집, 웹 오피스 등의 기능을 추가로 제공하여 학생이나 선생님이 컴퓨터를 사용하는 위치가 문제가 되지 않게 하여 실시간으로 과제를 수행하고 평가할 수 있도록 도와준다. 교사들의 경우, 문서 작성 후 공유에 드는 시간과 비용을 최소화하여 더 본질적인 업무를 수행할 수 있도록 도와준다.

    더 나아가서, Microsoft가 고등 교육 기관의 학생들을 위하여 제공하는 무료 소프트웨어 제공 프로그램인 DreamSpark를 Live@edu를 이용하여 손쉽게 신청할 수도 있다. 국내의 경우, DreamSpark를 이용하여 학생들이 참가할 수 있는 각종 IT 관련 경진대회에 필요한 소프트웨어를 스스로 다운로드 받을 수 있도록 해준다. Live@edu 서비스는 뒤에서 소개할 Office 365 for Education으로 업그레이드될 예정에 있다.

    사무실에 천근만근인 몸을 운반하지 않도록 도와줄 구세주 – Office 365

    Office 365는 이전에 Microsoft Business Productivity Online Suite (BPOS)로 소개되었던 세 가지 온라인 서비스인 Exchange Online, SharePoint Online, Lync Online을 필두로 기존에 출시된 Microsoft Office 2010을 소프트웨어로 채택하여 소프트웨어+서비스를 구현하는 기업용 오피스 클라우드 솔루션이다. 클라우드 솔루션이므로, 전체 서비스를 구현하기 위하여 기존과 같이 모든 것을 구입하고 관리하고 유지 보수할 필요가 "전혀" 없이 Microsoft에게 맡기면 되는 것이다.

    Exchange Online은 Exchange Server 2010을 기반으로 구현된 클라우드 서비스로, 전문적인 Exchange Server 엔지니어 없이도 엔터프라이즈 서비스를 가능하게 한다. 메일 뿐만이 아니라 일정 관리, 연락처 동기화, Windows Mobile 6.5 및 Windows Phone 7, iPhone, Android, BlackBerry 등 다양한 스마트 폰 장치와의 동기화를 지원하므로 언제 어디서나 업무에 관한 커뮤니케이션이 중단되지 않도록 도와준다. 무엇보다도 클라우드 기반의 서비스이므로 비싼 서버 장비와 서버 소프트웨어 라이선스를 필요로 하지 않는다는 것은 많은 기업들에게 직접 사용할 수 있는 플랫폼이든 기존의 전산 자원을 보호하기 위한 추가 계층이든 그 의미에 관계 없이 매력적으로 다가올 것이다.

    SharePoint Online은 기업이 Enterprise Social Communication을 구현할 수 있도록 도와준다. 단순한 문서 공유 및 팀 협업의 차원을 뛰어넘어, 최근 SharePoint를 통하여 구현하는 다양한 비즈니스 응용프로그램과의 호환성이 보장되므로 기업 내부에서는 저렴한 비용으로 다차원의 데이터를 관리할 수 있으며, 기업 외부를 위해서는 SharePoint Online을 통하여 만들 수 있는 공개 웹 사이트를 이용하여 주문 요청, 사용자 피드백 수렴 등 다양한 마케팅 및 영업 활동을 가능하게 해준다. 기술적으로 보면, 당연히 OData 프로토콜을 사용할 수 있으므로 SharePoint Online 그 자체는 훌륭한 Contents Management System이자 Database인 셈이다.

    Lync Online은 기존의 Office Communications Server의 차기 제품인 Lync Server의 클라우드 버전으로 기업 내 인스턴트 메시징을 역시 클라우드 기반에서 해결할 수 있도록 도와준다. 그리고 Lync Client는 이전 버전의 클라이언트처럼 단순한 메신저 – 또는 – Outlook에 제한적으로 통합되는 형태를 넘어서서 Office 응용프로그램 곳곳에서 쉽게 활용할 수 있도록 추가 기능으로 제공되었다. Lync Client를 사용하는 방법을 이용하여 위치에 관계없이 클라우드를 이용하여 다른 사람에게 즉시 인스턴트 메시징을 보낼 수 있다는 것은 매력적인 일이다.

    Office Web App은 Windows Live에서와 마찬가지로 Exchange Online과 SharePoint Online의 웹 확장 기능에서 그 진가를 발휘한다. 그리고 여러분의 컴퓨터에 지금 당장 Office Professional Plus 2010이 설치되어있다면 소프트웨어의 장점과 서비스의 편리함을 모두 누릴 준비가 되어있는 것이다.

    다음 시간에는

    다음 시간에는 IT 관리자와 개발자 여러분들이 지금껏 열정과 혼을 다하여 능력을 발휘해왔던 Windows Server 플랫폼이 클라우드 시대에서는 어떻게 변화하고, 더 나은 기능을 제공하는지에 대하여 살펴볼 것이다. 클라우드 시대에 알맞은 관리 방법과 개발 방법론을 익히는 것은 IT 관리자와 개발자에게도 일반 사용자들처럼 동일한 변화를 요구로 하는 것이다.

    글쓴이 이력

    • 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) 집필진 활동 중
    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요

    PaaS2011. 2. 1. 01:30
    한국 Microsoft의 박중석 Evangelist님의 아이디어 (http://blogs.msdn.com/b/jspark/archive/2011/01/31/110131-windows-azure.aspx) 를 기초로 Windows Azure Consumption Rate를 계산하고, 환율을 입력하면 자동 계산이 가능하도록 만든 Excel Worksheet를 공유합니다. 필요한 부분만 편집할 수 있도록 워크시트를 잠가두었습니다. 비용 계산이 필요하신 분들께 도움이 되고자 자료를 만들어 공유하며, 잘못된 부분이나 수정이 필요한 부분은 이야기해주시면 곧바로 업데이트하겠습니다. :-D

    http://cid-318484c5aad6b73d.office.live.com/browse.aspx/rkttu.com%20Documents/Windows%20Azure%20Consumption%20Calculator
    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요

    PaaS2011. 1. 30. 03:08

    Windows Azure AppFabric에 새로 추가될 구성 요소 중 가장 많은 기대를 받고 있는 서비스가 2011년중 런칭을 준비하고 있습니다. 바로 Access Control에 관한 향상인데, 매력적인 내용이 무궁 무진합니다. 이제 여러분은 기존에 개발한 웹 응용프로그램에 약간의 수정을 가하는것 만으로도 손쉽게 Windows Live ID, Google, Yahoo!, Facebook을 통한 통합 인증을 구현할 수 있고 더불어서 기존에 설치하여 운영 중인 Active Directory Domain이 있다면 여기에 Active Directory Federation Services 2.0을 추가 설치하여 이와 연동하는 것도 가능합니다. ASP.NET 응용프로그램 관점에서 이는 전적으로 Windows Identity Foundation (WIF)을 통하여 손쉽게 구현할 수 있는 부분입니다.

    Windows Identity Foundation에 대한 간략한 소개

    Windows Identity Foundation (이하 WIF)은 XML Web Service Enhancements에서 소개된 적이 있는 WS-Trust와 WS-Federation 표준을 지원하는 .NET 기반의 ID/클레임 기반 인증을 손쉽게 구현할 수 있도록 도와주는 기술 집합입니다. 단순한 프레임워크만 제공되는 것이 아니고, Visual Studio 2008이나 Visual Studio 2010에 연동하여 프로젝트의 설정을 변경할 수 있도록 도와주는 기능도 같이 설치되므로 코드 작업을 거의하지 않고 기본 틀을 만드는 것이 가능합니다.

    WIF는 전통적으로 ASP.NET 기반 응용프로그램에서 사용하던 인증 방식을 초월합니다. 전통적으로 ASP.NET 기반 응용프로그램들은 웹 브라우저를 통하여 접근하는 사용자들에게서 직접 ID와 비밀 번호를 받아 이를 내부 DB와 대조하여 쿠키를 교환하는 방식을 사용해왔습니다. 대부분의 경우 이는 합당한 것이며 당연한 절차였습니다. 하지만 잘못 구현할 경우 정보가 유출되거나 의도하지 않은 사고로 이어지기 쉬웠고, 대개는 이러한 일 때문에 웹이 다소 위험한 공간이라는 편견을 사용자들에게 가지게 하는 부작용도 초래하였습니다. 하지만 WIF는 사용자 인증이라는 다소 민감한 사안을 좀 더 전문적인 기관이나 검증된 솔루션으로 위임한 채, 이들 기관으로부터 결정된 사항을 비대칭 암호화 기반의 데이터로 넘겨받아 피아식별에 필요한 정보만을 추출하여 사용하는 방식을 이용하는데에 큰 도움을 줍니다.

    클레임 기반의 인증에서 가장 좋은 점은, 인증에 관한 모든 불안 요소를 제거하고, 피아식별이 완료된 이후에 해당 사용자를 정확히 식별하고 프로필을 안전하게 관리하는 것에만 집중하면 된다는 것입니다. 좀 더 서비스의 완성도를 높이는 일에 많은 시간을 할애하고 노력을 기울일 수 있음을 의미합니다.

    Windows Identity Foundation의 역할

    WIF를 프로그래밍 코드 측면에서 살펴보면 핵심은 System.Threading.Thread.CurrentPrincipal 정적 프로퍼티에 있습니다. 기본적으로 이 프로퍼티는 IPrincipal 인터페이스를 구현하는 특정 객체의 참조를 반환하는, 즉, ASP.NET의 기본 인증 방식을 통하여 인증이 완료된 사용자임을 증명하는 객체가 반환됩니다. 하지만 WIF를 사용하도록 구성한 시점부터는 IClaimsPrincipal 인터페이스를 사용하여 하나 이상의 클레임 정보를 아래와 같이 액세스할 수 있게 됩니다. (C# 코드)

    IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];

    이미 사용자는 이 페이지를 실행하기에 앞서 적당한 인증 절차를 모두 거쳐 웹 사이트에 로그인한 상태이며, 이러한 부분들은 WIF 내의 FedUtil 도구가 자동 생성하는 STS (Secure Token Service) 웹 사이트에 의하여 처리가 끝납니다. WIF의 개발자 경험에 관한 역할은 이 FedUtil 도구를 개발자가 손쉽게 부를 수 있고, FedUtil 도구를 통하여 기존 ASP.NET이나 WCF 프로젝트가 WIF와 성공적으로 통합될 수 있도록 설정을 업데이트하는 데에 주 목적이 있습니다. 물론 필요하다면 FedUtil을 이용하여 STS 없이 Classic ASP.NET 인증 체계를 이용하도록 되돌리는 것도 가능합니다.

    클레임 기반의 인증을 사용한다는 것은 좋은데 이 일을 누가 대신 처리해준다는건지 이해가 잘 되지 않을 수 있습니다. 사실 기본적으로 WIF 내의 FedUtil은 이러한 일을 해주기 위한 도구입니다. WIF 기반 응용프로그램으로 기존 응용프로그램 코드를 변환하거나 복원하는 역할, STS 서비스를 새로 만드는 역할을 담당하게 됩니다. STS 서비스는 자신의 역할을 올바로 수행할 수 있도록 추가적으로 개발될 필요가 있는데 이때 STS 자체는 ASP.NET 응용프로그램의 형태로 작성된 것이고, 다양한 종류의 WIF 보조 서비스들과 상호작용하면서 실제 요구 사항에 부응하는 인증 시스템을 만들 수 있게 된 셈입니다.

    AppFabric Access Control?

    AppFabric Access Control은 이제 여기서 가장 중요한 역할을 담당하게 됩니다. STS를 클라우드로 올려서 서비스로 제공하는 것이기도 하고 동시에 일반적으로 직접 구현이 어려운 주요 유명 서비스들의 인증 방식을 변환하여 제공해주는 매우 중요한 역할을 합니다. AppFabric Access Control의 역할을 로컬 환경에서 구현하려면 많은 기능들을 A-to-Z로 구현해야 하며 이 자체만으로도 굉장한 프로젝트가 될 것입니다.

    AppFabric Access Control이 클레임을 생성하는 과정은 입력과 출력으로 나눌 수 있는데, 입력은 사용자로부터의 입력이 실제 클레임 정보 제공자로부터 들어오는 과정을 말하는 것으로 초기 버전의 Access Control보다 더 강력해진 것입니다. 그렇게 되어 Google과 Yahoo!, Facebook, AD FS를 경유하는 인증이 가능해지게 되었습니다. 그리고 출력은 이후 시리즈에서 더 살펴볼 예정이지만 사전에 정의된 Rule Group에 의하여 조건부로 설정된 결정 사항들을 전달하는 방식을 여러가지 형태로 제공하는 것으로 OpenID, Facebook, OAuth, WS-Authentication, WS-Federation 등 이름만 들어도 쉽게 알 수 있는 인증 방식들을 제공합니다.

    다음 시간에는

    다음 시간에는 WIF를 이용하여 ASP.NET MVC 3 응용프로그램을 코드 수정 없이 신속하게 클레임 기반의 인증을 지원하는 웹 사이트로 변환하는 과정을 보이도록 하겠습니다. 감사합니다.

    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요

    PaaS2011. 1. 22. 03:11

    이전 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around Cloud Computing - “Dynamic Set of Connected Computers”
    다음 글: [Windows Azure Platform/A Lap around Cloud Computing] - A Lap around Cloud Computing – 당신이 어디에 있든 관계없는 세상

    모든 것은 서비스로 통한다

    지난 글에 이어서 오늘은 Everything as a Service, 줄여서 흔히들 XaaS라고 부르는 개념에 대한 이야기를 나누어보려고 한다. 지난 시간에는 Cloud Computing에 대한 기술적인 정의를 살펴보기 위하여 “Dynamic Set of Connected Computers”라는 문장을 이야기했었는데 그렇다면 이 문장에 부합하는 시스템을 가지고 도대체 무엇을 어떻게 할 것인가라는 이야기를 해야 할 필요가 있을 것이다.

    사실 Cloud Computing은 우리도 모르는 사이에 이미 우리 생활 속 깊숙이 자리잡고 있었다. 다만 이것이 Cloud Computing이라고 이야기할 수 있을 만큼 성숙했는가 그렇지 않았는가의 차이일 뿐이다. 실질적으로 Cloud Computing은 언제부터 우리 생활 속에 자리 잡았을까?

    현 시점에서 Windows 운영 체제의 사용에 익숙한 대다수의 컴퓨터 사용자들은 과거에 발표된 적이 있는 Windows 98이라는 운영체제를 잘 알고 있다. 1997년 말에 처음 발표되었고, 사전적인 정의로만 놓고 본다면 시장에서 획기적인 사용자 인터페이스로 사람들의 이목을 잡아 끌었던 Windows 95라는 운영체제의 성공적인 후속 버전으로 잘 알려져 있다. 약간 기술적으로 접근해보면 Internet Explorer 4.0을 포함하고 있고, 이 때문에 반독점 시비에 휘말렸던, Microsoft의 입장에서는 다소 쓰라린 추억을 품게 했던 그런 운영 체제였다. 우리가 아는 모습은 여기까지였다.

    하지만 Windows 98에서 우리는 Cloud Computing의 시작을 이미 경험하였다. 놀랍게도, Microsoft는 인터넷이라는 수단을 이용해서 Windows 운영 체제를 출시 이후에도 신속하게 수정하고 사용자들의 요구 사항을 전세계 어디에서든 직접 반영할 수 있도록 하는 기술인 Windows Update를 처음 선보였다. 우리는 이것이 당연한 일이라고 생각한다. 하지만 이러한 서비스를 제공해야 하는 Microsoft의 입장에서는 어떠했을까? 대충 계산해보아도 Windows 98을 각 가정에서 하나씩 사용한다고 가정하더라도 전 세계적으로 보면 정말 엄청난 수의 클라이언트를 보유한 셈이다. 이러한 클라이언트들에게 서비스차원에서 소소한 업데이트들을 제공하기 위하여 데이터센터를 구축하고 운영해왔던 것이다.

    Cloud Computing은 이와 같이 정확한 규모를 파악하기 어려운 서비스에 대하여 꼭 필요한 접근 방식이다. 우리가 흔히 이야기하는 클라이언트-서버 컴퓨터 환경을 기반으로 하지만, 접속을 하는 클라이언트의 수가 사실 천문학적으로 많을 수도, 혹은 처음 잡았던 운영 규모에 비해 접속하는 클라이언트의 수가 얼마 되지 않아 비용이 낭비되는 상황이 될 수도 있는 서비스의 운영에 대해 확실한 방안을 제시한다. 우리가 평소에 물을 사용하기 위하여 사용한 물의 양을 재거나 양동이를 가지고 물을 받아서 쓰는 일을 하지 않는 것과 마찬가지로, Cloud Computing을 사용하면 Web Hosting이나 Server Hosting을 할 때와는 다르게 서비스를 사용한 만큼만 비용을 지불하면 된다. , 서비스의 본질에만 초점을 맞추기만 하면 나머지는 Cloud Computing 서비스 제공자의 역할로 모든 것이 돌아간다는 것이다.

    무엇으로 서비스를 만드는가?

    Cloud Computing 서비스 제공 업체 입장에서는 무엇으로 서비스를 만들어 제공하는가가 중요한 관점이 될 수 있다. 대부분의 경우 세 가지 범주 안에 모든 것이 설명되는데, 인프라를 기반으로 서비스를 제공하는 Infrastructure as a Service (이하 IaaS), 플랫폼을 기반으로 서비스를 제공하는 Platform as a Service (이하 PaaS), 그리고 소프트웨어나 이에 관련된 기반 기술을 활용하여 서비스를 제공하는 Software as a Service (이하 SaaS) 세 가지로 나눌 수 있다.

    IaaS의 경우 Cloud Computing의 도래 이전부터 하드웨어, 네트워크 통신망과 같이 근간이 되는 인프라와 자원에 대한 전문적인 서비스를 제공해오던 사업자들의 관점에서 강점으로 내세우는 Cloud Computing 방식이다. 인터넷 연결을 이용하여 장소와 시간의 제약을 없애고, 약간의 제어용 소프트웨어를 덧붙여 하드웨어, 네트워크 통신망을 자유롭게 제어하고 필요한 만큼 추가하거나 삭제할 수 있는 방안을 제시한다. 여기에는 대표적으로 Amazon, Rackspace 등의 기업이 잘 알려져 있다.

    PaaS의 경우 Cloud Computing 이전부터 기반 기술을 보유하고 발전시켜왔던 사업자들의 관점에서 강점으로 내세우는 Cloud Computing 방식이다. IaaS 사업자 또는 독자적 IaaS 플랫폼을 구축한 이후에 각자 자신들의 철학과 이념을 잘 반영한 Cloud Computing 기반 플랫폼을 IaaS와 마찬가지로 인터넷 연결을 이용하여 사용하고 제어할 수 있도록 제공한다는 취지이다. 여기에는 대표적으로 Microsoft, Salesforce 등의 기업이 잘 알려져 있다.

    마지막으로 SaaS의 경우 IaaS PaaS를 통하여 최종 사용자에게 실질적인 서비스를 제공하기 위한 취지로 해석되는 경우가 많다. 대표적으로 Google Docs Microsoft Office Web Apps가 이러한 범주에 속하는데, 데스크 탑에서 구현할 수 있는 소프트웨어를 웹에서 동시에 사용할 수 있도록 하는 것이 특징이다. 특별히, Microsoft의 경우 SaaS가 보통 의도하는 인터넷 전용의 서비스를 넘어서 기존의 데스크 탑에 설치되는 소프트웨어와 SaaS 기반의 서비스가 서로 균형을 맞추어 사용자에게 적절한 선택을 할 수 있도록 Software + Service 전략을 제시하곤 한다.

    지금 열거한 IaaS, PaaS, SaaS는 하드웨어, 소프트웨어, 그리고 전략적 플랫폼이라는 IT 업계의 3대 주요 구성 요소들을 빠짐없이 모두 열거한 것이다. 이 세 가지 범주를 벗어나는 Cloud Computing 서비스는 없으며, 정확히 한 가지에 국한되는 Cloud Computing 서비스도 없다. , 이 세 가지 범주를 이용하여 과거, 지금, 그리고 앞으로 등장할 Cloud Computing 서비스에 대한 이야기를 할 수 있을 것이다. 다만 한 가지 주의해야 할 점이 있다면, Cloud Computing이 반드시 인터넷과 전형적인 컴퓨터 장치만 사용해서 이뤄지는 것은 아니라는 점이다.

    서비스로 무엇을 제공하는가?

    이러한 특성을 기반으로 무엇을 서비스화하고 Cloud Computing에 올린다면 좋을까? 여기에 대한 답은 의외로 쉽게 찾을 수 있다. 서비스의 규모에 관계없이 사람들이 원하고 바라는 것이면 무엇이 되어도 좋다. 지금부터는 XaaS의 광범위함을 이야기해볼까 한다.

    Case #1 – TTS (텍스트를 음성으로 변환) 기술

    펜티엄 컴퓨터의 판매가 활발하던 시절, 모 대기업의 컴퓨터 제품을 구입하면 번들로 따라오던 소프트웨어를 모두들 기억할 것이다. 텍스트를 입력하면 여기에 해당되는 사람의 음성 출력을 컴퓨터가, 어눌하지만 꽤나 자연스럽게 표현하는 것이다. 그래서 별로 새로울 것이 없어 보인다. 하지만 이러한 TTS 기술이 Cloud Computing 환경을 만나서 서비스로 탈바꿈하면 어떨까?

    iSpeech.org (http://www.ispeech.org)를 방문하면 여기에 대한 현실적인 구현 사례를 만나볼 수 있다. 텍스트 음성 변환을 구현하는 곳은 많았지만 그 지속성이 오래가지 못하는 경우가 대다수인데, 이것을 하나의 완성된 Cloud Computing 서비스로 만들어서 매우 주목을 받고 있다. 여기서 중요한 것은 기존의 경우 텍스트 음성 변환을 이용하기 위하여 음성 데이터 파일과 이를 구현하는 소프트웨어 엔진을 특정 컴퓨터에 설치해야 했으며 심지어는 이 소프트웨어의 파일 크기도 매우 크고, 가격도 매우 비싸기까지 했다. 그러나 이제는 이러한 서비스를 특정 컴퓨터에 설치하는 일 없이, 필요해서 생각이 나면 곧바로 여러분의 웹 브라우저는 물론, 여러분이 개발할 응용프로그램의 기능 상 일부분으로 통합하는 것까지 정당한 비용 지불만 있다면 24시간 365일 가능한 것이다. 이해를 돕기 위하여, iSpeech.org 에서 만든 샘플 오디오를 첨부하였다.

    문장: Barack Obama said: I think when you spread the wealth around it's good for everybody.
    오디오:


    이 서비스를 이용하여 회원 가입 없이는 10, 무료 회원은 1분 이내의 음성 변환을 시험해볼 수 있으며, API를 사용하거나 전문적인 활용이 필요한 경우 계정을 업그레이드하고 비용을 지불하는 방법으로 더 나은 서비스를 받을 수 있다. 한 마디로, TTS as a Service (TaaS)라고 정의할 수 있는 것이다.

    Case #2 – Windows Live

    Windows Live의 역사는 장대하다. 그리고 다양한 실험을 거쳐서 지금의 형태를 띠게 된 것이라 할 수 있다. Windows 95 시절 처음 소개되었던 The Microsoft Network를 통하여 인터넷 서비스를 어떻게 제공하면 좋을지 Microsoft는 지속적으로 고민의 고민을 거듭해왔고, 본격적으로 TCP/IP 기반의 인터넷이 활성화되기 시작할 무렵 출시된 Windows 98부터는 동적 웹 페이지 기능 혹은 – DHTML, AJAX (COM 기반 HTTP Request), 웹 서체와 같은 더 확장된 인터넷 기능을 제공하는 Internet Explorer 4.0과 더불어 인터넷의 본질에 접근하기 시작하였다. 물론 이 무렵에도 지속적으로 MSN은 전형적인 Internet Contents 제공 사업자로서의 모습을 갖추고 있었다.

    그러나 MSN 이상으로, 사용자가 인터넷을 좀 더 친숙하고 편리하게 사용할 수 있는 방안이 없을지에 대한 지속적인 고민이 더해져, 2005년 늦가을에 Microsoft Windows Live의 첫 버전을 발매하였다. Windows 운영 체제를 사용하는 사용자들의 경험을 배반하지 않으면서도 인터넷 서비스가 갖추어야 할 강력함을 동시에 유지하는 어려운 실험을 시작하였고, 시간이 갈수록 이 실험에 대한 성과가 나타나기 시작하였다.

    현재의 Windows Live는 개인 사용자들이 Microsoft의 다양한 인터넷 자원에 접근하기 위한 핵심 운영 체제와 동일한 맥락을 갖는다. Microsoft Windows 95 시절 이후부터 유지하고 발전시켜왔던 MSN 웹 사이트는 물론, 전자 메일 서비스를 제공하는 Hotmail, 인스턴트 메신저 서비스를 제공하는 Windows Live Messenger 등 일반 사용자를 위한 서비스가 핵심이 되고, Windows Azure Platform의 등장과 더불어서 Cloud Computing 환경에서의 Claim 기반 인증 수단으로 Windows Live ID는 그 핵심을 차지하고 있다.

    그리고 Windows Live는 지속적으로 다른 웹 응용프로그램들의 장점을 수용하고 발전시켜나가면서 우리가 잘 아는 Google AJAX 기반 Web Application과 다르지 않은, 그러면서도 기존 Office Windows 사용자들의 경험을 배반하지 않는 Web Application을 성공적으로 Windows Live에서 제공하기 시작하였다. 한 마디로, Windows Live Microsoft의 핵심 인터넷 서비스이자 Microsoft가 출시하는 각종 소프트웨어는 물론 여러분이 고객에게 제공하게 될 서비스에 Microsoft의 인터넷 서비스를 자연스럽고 강력하게 통합시킬 수 있는 확장 기능 집합이라 할 수 있다.

    Case #3 – TROPO

    TROPO에 대해서는 생소한 사람들이 많을 것이다. 이 서비스를 한 마디로 요약하면, 전화 통신 시스템을 가상화한 것이라고 말할 수 있다. 어떻게 그게 가능했을까? 답은 VOXEO Corporation의 기술력에 있다.

    VOXEO Corporation은 전통적으로 전화 통신 기반으로 지속적으로 연구 개발을 해왔던 기업으로 기간 망을 운용하는 사업자들처럼 사업의 규모에 집중한 것이 아니라, 전화를 이용한 부가 가치 창출에서 꼭 필요한 자동화 시스템을 구현하는 일에 많은 자원을 투자한 것으로 유명한 회사이다. 덕분에 이 분야에 뛰어든 다른 여러 회사들 가운데에서도 VOXEO Corporation의 행보는 남다르다고 할 수 있다.

    필자 역시 이 회사의 존재도, 이 회사가 Cloud Computing 서비스라고 소개하는 TROPO에 대해서도 사실은 전혀 알지 못하였다. 그러나 인터넷 검색을 통하여 처음 접하였고, 이 회사에서 제공하는 TROPO 서비스를 알게 되었으며, 덕분에 Imagine Cup 2010 대회에 참가하기 위하여 제출한 아이디어에서 이 서비스의 능력을 Windows Azure Platform과 연계하여 적극 활용하여 원하는 IT 솔루션을 실제로 그려낼 수 있었다.

    종전에는 자동 응답 시스템, 혹은 대화형 음성 응답 시스템을 구현하기 위해서는 여러 개의 전 이중 회선을 전화국으로부터 할당 받아 전화 수신이 폭주하는 경우에도 최대한 전화를 받을 수 있도록 해야 했고, 이러한 기능을 수행할 수 있는 매우 비싼 장비를 구축해야 하고, 이러한 장비를 제어하고 유지보수하기 위한 소프트웨어를 개발하는 등 생각할 수 있는 모든 역량을 집중해야 한다. 그러나 여기서 장치, 전 이중 회선, 유지 보수 등 생각할 수 있는 모든 복잡한 요소를 제거하고 순수하게 어떤 시나리오를 재현하는 음성 응답 시스템을 만들 수 있는 스크립트만을 작성하여 게시하면, 미리 지정된 전화 번호로 전화를 걸었을 때 작성한 스크립트대로 동작하는 것을 들을 수 있다. 더 중요한 것은, 기능을 테스트하고 개발하는 동안에는 무료로 사용하고 실제로 서비스를 수행할 때 비용을 지불할 수 있다는 것이다.

    빠른 이해를 돕기 위하여, DEMO 응용프로그램을 Skype를 통하여 직접 테스트해볼 수 있다. DEMO 응용프로그램은 아래와 같은 스크립트로 구성되어있다.

    answer();
    say("Yes, Tropo is this easy!");
    hangup();

    그리고 위의 응용프로그램을 테스트하기 위하여, 다음 중 하나의 수단을 사용할 수 있다.

    전화 또는 문자 메시지: +1.240.242.7909
    IM (Jabber/G-Talk):
    tropo-homepage@tropo.im
    Skype: +99000936 9991429732
    SIP:
    sip:9991429732@sip.tropo.com

    전화, Skype, SIP 등을 이용하여 음성 출력을 사용하는 통신 수단으로 이 응용프로그램에 접근한다면 TTS 엔진을 통하여 변환된 음성을 들을 수 있을 것이다. 반면 텍스트 기반 통신 수단으로 이 응용프로그램에 접근한다면 문자 메시지나 대화에 대한 응답으로 텍스트를 받을 수 있을 것이다. , TROPO는 음성과 텍스트에 대한 완벽한 가상화를 지원하고 있는 것이다.

    만일 TROPO에 대하여 좀 더 자세히 알아보고 싶다면 http://www.tropo.com/ 을 방문하면 된다.

    다음 시간에는

    다음 시간부터는 순차적으로 Microsoft 3Cloud Computing 전략에 대하여 살펴보기로 할 예정이다. 그 중 가장 첫 번째로, Office 365에 대한 이야기를 풀어보고자 한다. Office 365는 이전에 언론 등을 통하여 Business Productivity Online Standard (BPOS) Suite로 소개되었으며 이것이 Microsoft Office 2010 또는 그 이후 버전과 함께 군을 이루어 2010년중에 정식 버전으로 소개될, 현재 Windows Live가 제공하는 개인 및 SOHO를 위한 Office 확장과는 별개인 더 전문적인 Mobile Office Cloud Computing 서비스이다. 그 후, Windows Server Family에서 사용할 수 있는 Cloud Computing과 상호 운용 기술을, 마지막으로는 Windows Azure Platform에 대하여 개발자 관점과 IT Professional 관점으로 나누어 상세하게 다루어볼 예정이다.

    글쓴이 이력

    l  Blog: http://www.rkttu.com / E-MAIL: rkttu@rkttu.com / Twitter: @rkttu

    l  Windows Azure MVP (2011) / Visual C# MVP (2009-2010)

    l  ㈜코아뱅크 코아기술연구소 (http://www.corebank.net) 연구원 재직 중

    l  Windows Azure Café SYSOP (http://cafe.naver.com/wazure)

    l  Visual Studio 2010 Team Blog (http://www.vsts2010.net) 집필진 활동 중

    Posted by Cloud Developer 남정현 (rkttu.com)

    댓글을 달아 주세요