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. 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)

댓글을 달아 주세요

Azure Storage/Database2013. 2. 3. 15:16

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

Windows Azure를 가지고 무엇을 할 수 있을까? 이 점에 대해서 궁금해하시는 많은 분들을 위하여 레시피 강좌 시리즈를 지속적으로 업로드하려고 합니다.

이번에 소개해드리려고 하는 내용은 요즈음 유행하는 HTML5 기반의 앱과 관련된 내용입니다. 서버의 렌더링을 필요로하지 않고 스스로 동작할 수 있는, 마치 앱과 같은 특성을 지닌 지능적인 HTML 페이지를 Windows Azure BLOB Storage위에서 호스팅하는 방법입니다.

사실 지금 소개해드리려는 내용은 굉장히 간단한 내용이지만, 활용하기에 따라서는 굉장히 유용한 레시피가 될 수 있습니다. 이벤트나 행사 웹 사이트와 같이 단순하지만 기간 내에 액세스가 폭증하는 페이지들을 호스팅해야 하는 요구 사항이 종종 있는데 이럴 때 활용하시면 일을 매우 단순하게 만들 수 있습니다.

정적 웹 사이트에 담을 내용 준비하기

정적 웹 사이트란 문자 그대로 웹 디자이너가 작업을 끝마친 시안 형태의 웹 페이지에서부터 ASP, PHP, ASP.NET, CGI, Python, Perl 등 생각할 수 있는 서버측 구성 요소를 하나도 들여오지 않고 jQuery나 Dojo 같은 자바스크립트 프레임워크들, 그리고 외부의 Open API만을 활용해서 온전하게 작동하는 웹 앱에 이르기까지 운영해야 할 서버 측의 비용을 고려하지 않고 만들 수 있는 모든 종류의 웹 사이트 및 웹 앱을 뜻합니다. 자바스크립트 세계의 발전에 따라 정적 웹 사이트의 의미도 크게 확장되었다고 볼 수 있습니다.

여기서는 jQuery Mobile을 이용하여 만든 간단한 웹 사이트를 Windows Azure Storage를 이용해서 호스팅하도록 해보겠습니다. 소개하는 내용이 아니더라도 여러분이 손수 만든 개인 모바일 홈페이지도 괜찮고 무엇이든 시험해볼 수 있는 것이면 됩니다.

  • 준비물 1: CloudBerry Client for Windows Azure BLOB Storage (Pro 버전 대신 Freeware를 설명합니다.)
  • 준비물 2: jQuery Mobile 패키지 파일
  • 준비물 3: 여러분이 올릴 간단한 웹 페이지 파일 및 이미지 파일

CloudBerry Client for Windows Azure BLOB Storage 설치하기

CloudBerry Client는 여러 종류의 Windows Azure BLOB Storage 클라이언트 중 다루기 쉽고 간편한 인터페이스를 제공하는 무료 클라이언트입니다. CloudBerry Client는 Windows Azure 이외에도 KT UCLOUD Biz Storage 클라이언트와 같은 OpenStack Client도 지원합니다.

http://www.cloudberrylab.com/ 웹 사이트에 방문하시면 메인 페이지에 CloudBerry Explorer Freeware라는 이름의 다운로드 링크 컬렉션이 보일 것입니다. 여기서 for Windows Azure를 선택하여 이번 레시피에서 설명하는데 필요한 도구를 다운로드하고 설치합니다.

프리웨어이지만 사용자 등록을 권하는 부분이 있는데, 지속적으로 이 도구를 사용하게 될 것을 감안하여 재량껏 등록하여 사용하기 바랍니다. 등록하지 않고 진행해도 사용에는 큰 지장은 없을 것입니다.

설치 후 아래와 같이 프로그램이 나타나는지 확인합니다.

계정 정보 등록하기

새로운 계정 정보를 등록하려면 아래 그림과 같이 File 메뉴의 Azure Blob Storage Accounts 메뉴를 선택합니다.

아래와 같이 대화 상자가 나타날 것입니다. Add 버튼을 클릭합니다.

아래와 같이 계정 정보 입력 대화상자가 나타나는지 확인합니다.

  • Display name: 이 프로그램 상에서 나타낼 항목 이름으로 자유롭게, 알아보기 쉬운 이름으로 입력합니다.
  • Account: Windows Azure 저장소의 ID를 입력합니다. URL을 보면 <계정 이름>.blob.core.windows.net와 같은 형태로 구성되어있는데 여기서 <계정 이름>에 해당하는 ID를 입력합니다.
  • Shared Key: Windows Azure 관리 포털에서 나타나는 이 저장소에 대한 Shared Key를 입력합니다. Primary Key나 Secondary Key 중 하나를 입력하면 됩니다. 보안 향상을 위하여, 서비스 구성을 위해 활용하는 Key와는 다른 여분의 Key를 이곳에 설정하는 것이 좋습니다. 이렇게 하여 불시에 이 Key를 갱신하여 유출 사고 등에 유연하게 대처할 수 있게 됩니다.
  • Use SSL: SSL 통신을 사용할 지의 여부를 결정합니다.
  • Development Storage: 실제 서비스가 아니라 Windows Azure Storage Emulator로 연결할 경우 이 항목을 체크합니다.

계정 정보를 확인하려면 http://manage.windowsazure.com/ 으로 이동하여 저장소 계정 화면에 대한 대시 보드를 아래와 같이 확인합니다. 그 다음 하단의 도구 모음에서 Manage Keys 버튼을 클릭합니다.

아래와 같이 모달 대화 상자가 나타나면 Storage Account Name을 복사하시고, Primary Access Key 또는 Secondary Access Key 중 하나를 복사하여 위의 대화 상자에 입력하도록 합니다.

모든 설정이 완료되면 Test Connection 버튼을 클릭하여 연결이 잘 되는지 확인합니다. 연결에 성공하면 아래와 같이 대화 상자가 나타날 것입니다.

jQuery Mobile 패키지 준비하기

기본적으로 jQuery Mobile 패키지 파일을 CDN에서 받아서 이용하는 방법이 편리합니다. 이렇게 하면 jQuery Mobile 다운로드에 관한 트래픽을 우리쪽 서버가 아닌 다른 위치의 CDN으로 분산시킬 수 있으므로 트래픽 관련 비용 절감에 도움이 되기도 합니다. 여기서는 jQuery Mobile 패키지를 우리쪽 서버에 업로드하는 것을 기준으로 예제를 만들어 보도록 하겠습니다.

http://jquerymobile.com/download/ 웹 페이지에 접속하여 아래와 같이 Latest Stable Release를 찾아 JavaScript와 CSS 파일 패키지를 Minified Version으로 다운로드하기 바랍니다. 링크를 클릭하면 저장이 아니라 파일이 열리는 동작으로 다운로드가 발생할 수 있으므로 링크를 오른쪽 버튼으로 클릭하고 다른 이름으로 저장 기능을 사용하여 저장하기 바랍니다.

그리고 jQuery Mobile이 필요로하는 jQuery 라이브러리 파일도 가져와야 합니다. http://jquery.com/download/ 웹 페이지에 접속하여 아래와 같이 Minified Version을 다운로드합니다.

NOTE: 최근에 릴리즈한 1.9.x 버전의 경우 jQuery Mobile과 호환성 문제가 있을 수 있으므로 1.8.x 릴리즈를 다운로드해야 할 수 있습니다. 1.9.x 버전이 작동하지 않을 경우 1.8.x 버전을 사용하여 진행할 수 있습니다.

컨테이너를 만들고 권한 설정하기

이제 컨테이너를 만들고 여기에 파일을 업로드할 차례입니다. 다시 CloudBerry Storage Explorer로 되돌아가서 오른쪽 패널의 Source 드롭 다운 상자에서 방금 추가한 계정을 선택하여 접속을 시도합니다. 

Windows Azure Storage는 전통적인 웹 호스팅 환경과는 다르며, 기본적으로 1계층의 컨테이너만을 지원합니다. 그리고 컨테이너보다 더 깊이있는 레벨의 폴더 계층을 형성하려면 올리는 파일의 이름에 경로 구분을 위한 문자 ('/')를 포함시켜 폴더처럼 보이게 하는 방법을 사용하게 됩니다.

API에서 폴더를 탐색한다는 것은 이러한 특성에 따라 실제 폴더로 스택 자료 구조를 이용해서 탐색하는 방식이 아니라, Where Clause를 이용할 때 사용할 수 있는 Prefix Matching 기법을 사용하게 됩니다. 즉, 같은 Prefix를 보유하는 컨테이너 내의 파일들은 논리적으로 같은 폴더에 있는 것으로 취급이 가능합니다.

컨테이너를 만들기 위해서는 아래 그림과 같이 오른쪽 편의 도구 모음을 클릭합니다.

아래와 같이 대화 상자가 나타나면 컨테이너의 이름을 입력하고 권한을 설정합니다.

위의 권한들에 대해 각각 내용을 살펴보면 다음과 같습니다.

  • Full public read access: 이 컨테이너의 URL로 접속하면 컨테이너 안에 무슨 파일이 들어있는지 목록을 조회할 수 있는 기능과 더불어 모든 파일에 대해 다운로드 기능을 제공함을 의미합니다.
  • Public read access for blobs only: 이 컨테이너의 URL로 접속하면 권한이 없다는 오류 메시지가 나타나고, 대신 이 컨테이너 안의 정확한 파일의 URL을 알고 있는 경우 해당 파일은 다운로드가 가능함을 의미합니다.
  • No public read access: 컨테이너이든 그 안에 들어있는 파일이든 인증을 거치지 않고는 읽을 수 없도록 보호함을 의미합니다.

위의 세 가지 옵션 중에서 지금 우리가 선택하려는 것은 두 번째 옵션으로, 정적 웹 호스팅에서 어떤 파일이 들어있는지 사용자가 확인할 필요 없이 개별 URL에 대해서만 안다면 자동으로 모든 서비스가 제공되므로 파일에 대해서만 공개하도록 만들 것입니다.

파일 업로드하기

여기서는 정적 웹 호스팅을 간단하게 테스트해볼 목적으로 1계층 컨테이너 안에 같은 파일들을 넣어보려고 합니다. 여러분의 컴퓨터에서 아래와 같이 파일을 준비하시면 됩니다.

그리고 위의 index.html 파일의 소스 코드는 아래와 같습니다.

이제 위의 소스 코드를 Azure Blob Storage로 업로드합니다. 아래와 같이 파일이 업로드된 것을 확인합니다.

결과 확인하고 QR코드로 만들어 배포하기

이제 마지막으로 올라간 파일이 잘 작동하는지 확인할 차례입니다. 위의 파일들 중 index.html 파일을 오른쪽 버튼으로 클릭하여 URL을 확인합니다.

아래와 같이 대화 상자가 나타나면 Copy to clipboard 버튼을 클릭하여 주소를 복사하고 웹 브라우저에서 열어보도록 합니다. (혹은 Open link 버튼을 눌러도 됩니다.)

웹 브라우저에서 아래와 같이 잘 나타나는지 확인합니다.

이제 이 URL을 QR코드로 만들기 위하여 http://qr.naver.com/ 으로 접속하여 QR코드를 만들면 모바일 웹 사이트 구축이 완료됩니다.

더 나아가기

만약 폴더 구조를 유지하면서 파일 업로드를 하기 원한다면, Storage Explorer에서는 폴더를 직접 생성하는 기능이 없지만, 미리 로컬에서 만든 폴더째로 한꺼번에 업로드하면 자동으로 폴더를 생성하게 됩니다.

그리고 Windows Azure CDN 노드를 추가하면 이 상태 그대로 CDN 서비스를 받을 수 있습니다. CDN 엣지 노드 형성은 2013년 2월 현재 신규 포털이 아닌 구 버전의 포털 http://windows.azure.com/ 에서 관리할 수 있습니다.

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)

댓글을 달아 주세요

PaaS2010. 12. 6. 02:15

지난 글 보러 가기 - [Software Development/Windows Azure] - Windows Azure VM Role 미리보기 #1

지난 시간에 이어서 오늘은 Windows Azure에서 사용할 수 있는 VM Role을 구성하기 위하여 어떤 작업을 해야 하는지 실제 VM Role 구성 방법을 살펴보는 글을 올립니다.

Virtual Machine 안에 정상적으로 Windows Server 2008 R2를 설치했다면, 이제부터는 VM Role로 변환하기 위하여 필요한 여러가지 설정을 적용하고, 추가 구성 요소를 설치할 차례입니다. 그리고 당연한 이야기이지만 Windows Update - 또는 - Microsoft Update를 통하여 필요한 모든 업그레이드와 보안 패치, 핫 픽스 등을 실제 배포전까지 가능한한 모두 포함하는 것이 바람직합니다.

1. VM Role로 배포하기 위하여 만든 가상 서버 인스턴스에 관리자로 로그인하여 바탕화면이 나타날 때 까지 기다립니다.

2. 시작 - 모든 프로그램 - 관리 도구 - 서버 관리자 순으로 항목을 클릭하면 아래 그림과 같이 콘솔 화면이 나타날 것입니다. 콘솔 화면 좌측의 트리 뷰에서 역할 항목을 선택하면 역할 구성 내역 보고서가 전면에 나타납니다. 이 화면에서 역할 추가 링크를 클릭하여 마법사를 시작하고, 첫 소개 화면에서 다음 버튼을 클릭합니다.

 

3. 서버 역할 선택 단계에서 여러분이 원하는 기능을 구성할 수 있습니다. 여기서는 웹 서버 역할만을 사용하도록, 웹 서버 (IIS) 앞의 확인 상자에 체크하고 다음 버튼을 클릭하겠습니다.

 

4. 웹 서버 역할을 위하여 필요한 준비 사항과 관련 정보를 설명하는 페이지가 나타납니다. 다음 버튼을 클릭합니다.

 

5. 역할 서비스 선택 대화 상자에서 필요한 구성 요소들을 선택합니다. 기본 기능만을 테스트해볼 것이므로 다른 추가 설정 없이 다음 버튼을 클릭합니다.

 

6. 이제 이 가상 서버에 웹 서버 역할을 추가할 준비가 다되었음을 확인하는 페이지가 나타납니다. 웹 서버 역할이 포함되어있는지 다시 한 번 확인하고, 설치 버튼을 클릭합니다.

 

7. 설치가 마무리되면 아래와 같이 완료 보고서가 나타납니다. 마침을 눌러 마법사를 종료합니다.

 

8. 서버의 역할을 정의하였고, Windows Azure와 상호작용하거나 전형적인 .NET 기반 응용프로그램을 원활하게 호스팅할 수 있게하기 위하여 서버의 기능을 추가해야 합니다. 서버 관리 콘솔의 좌측 트리뷰에 있는 항목들 중 기능 항목을 선택하면 기능 구성 상태 보고서가 나타납니다. 여기서 기능 추가 링크를 클릭하고, 첫 소개 화면에서 다음 버튼을 클릭합니다.

 

9. (중요한 작업 1) 아래 기능 선택 대화 상자에서, .NET Framework 3.5.1 항목 앞의 체크 상자를 클릭합니다. .NET Framework는 잠시 뒤에 설치할 Windows Azure Integration Component를 위하여 필수적인 기능입니다.

 

10. 이제 설치할 구성 요소들을 확인하고 설치 버튼을 누릅니다.

 

11. 설치가 모두 마무리되면 설치 완료 보고서가 아래와 같이 나타납니다. 마침 버튼을 클릭하여 마법사를 완료합니다.

 

12. (중요한 작업 2) 독립적인 서버 운영 환경과는 달리 윈도 애저 환경에서 서버는 패브릭 관리자의 지시에 맞추어 동작해야 합니다. Windows Update와 Microsoft Update에서 제공하는 자동 업데이트 기능은 시스템의 안정성과 최상의 보안 상태 유지를 위하여 기본적으로 켜져있지만 이러한 규칙을 준수하기 위하여 해당 서비스를 자동으로 실행되지 않도록 수정해야 합니다.

Windows Update - 또는 - Microsoft Update가 자동으로 시스템을 업데이트하지 않도록 하기 위하여 제어판의 Windows Update 아이콘을 더블 클릭합니다. 그러면 아래와 같이 화면이 나타나게 됩니다. 좌측의 링크 모음들 중에서 설정 변경 항목을 클릭합니다.

 

13. 아래와 같이 화면이 나타나면, 자동으로 업데이트하지 않는 것으로 설정을 변경하고 확인 버튼을 클릭합니다.

 

14. 이제 시스템은 자동으로 업데이트를 찾거나 자동으로 업데이트를 설치하지 않습니다. 업데이트 확인 링크를 클릭하여 필요한 모든 업데이트의 설치를 계속 진행합니다. 업데이트를 설치하는 과정에서 시스템이 다시 시작될 수 있습니다.

(중요한 작업 3) 여기서 중요한 것은, 시스템을 다시 시작하거나 한 번의 업데이트가 끝난 후 작업을 마치지 마시고, 다시 Windows Update 프로그램에 들어와서, 더 이상 중요한 업데이트가 검색되지 않을 때 까지 설치를 끝내야 합니다.

 

15. 이제 Windows Azure Integration Component를 설치할 차례입니다. Integration Component는 다른 Virtual Machine Addition과 마찬가지로 ISO 파일로 제공됩니다. 해당 ISO 파일은 Windows Azure SDK 버전 1.3과 함께 배포되며, SDK를 설치한 컴퓨터의 %PROGRAMFILES%Windows Azure SDK\v1.3\iso 디렉터리 아래의 WAVMROLEIC.ISO 파일을 아래 그림에서 소개하는 기능을 이용하여 가상 드라이브에 마운트하여 설치를 진행할 수 있습니다.

 

16. 게스트 컴퓨터에서 자동 실행 대화 상자가 아래와 같이 나타납니다. 폴더 열기 링크를 선택하면 다음과 같이 파일 목록이 나타납니다. WaIntegrationComponents-x64.msi 파일을 더블 클릭하여 실행합니다.

 

17. 잠시 후 설치 마법사가 나타납니다. 다음 버튼을 클릭합니다.

 

18. Integration Component가 시스템을 정확히 제어할 수 있도록 하기 위하여 관리자 계정의 암호를 지정해야 합니다. 암호를 입력한 후 다음 버튼을 클릭합니다.

 

19. 이제 Integraton Component를 설치할 수 있습니다. 아래 화면에서 설치 버튼을 클릭하여 설치를 계속 진행합니다.

 

20. 설치 과정 중간에 다음과 같은 하드웨어 장치 설치의 허용 여부를 묻는 대화 상자가 나타날 수 있습니다. 허용하도록 합니다. 이 장치는 Windows Azure Drive의 기능을 위하여 꼭 필요한 구성 요소입니다.

 

21. 아래와 같이 설치가 진행될 것입니다. 설치는 시스템 수준과 상황에 따라 시간에 차이가 있을 수 있지만 보통 30초 이내에 설치가 완료됩니다.

 

22. 정상적으로 설치가 완료되면 아래와 같이 완료 안내 페이지가 나타납니다. 마침 버튼을 클릭하여 설치 마법사를 종료합니다.

 

23. 시스템을 다시 시작해야 함을 안내하는 대화 상자가 나타납니다. 예 버튼을 클릭하여 시스템을 다시 시작합니다.

 

24. 이제 여러분이 원하는 소프트웨어나 필요한 서비스를 추가적으로 더 설치하고 올바르게 작동하는지 점검합니다. 모든 커스터마이징이 끝나면, 25단계로 이동합니다.

25. (중요 작업 4) 시작 메뉴의 "프로그램 및 파일 검색" 입력 상자 - 또는 - Windows 키 + R키를 눌러 실행 프롬프트 창을 열어 다음과 같이 명령어를 입력합니다. 이 프로그램은 현재 실행 중인 Windows 운영 체제에서 시스템에 관련된 기본 정보들을 제거하고 다른 컴퓨터로 이식할 수 있도록 돕는 시스템 유틸리티입니다.

%WINDIR%\SYSTEM32\SYSPREP\SYSPREP.EXE

26. 아래와 같이 대화 상자가 나타나면 일반화 체크 상자를 클릭하여 선택하고, 시스템을 종료하도록 옵션을 설정합니다. 그 다음 확인 버튼을 클릭합니다.

 

27. 잠시 후 Virtual Machine이 완전히 Shutdown되고 이제 가상 하드 디스크를 Windows Azure Platform으로 가상 하드 디스크 파일을 업로드할 준비가 끝나게 됩니다.

다음 시간에는

오늘 주제에 이어서 다음 시간에는 VM Role을 실제로 게시하는 방법에 대하여 살펴보도록 하겠습니다. VM Role은 이후에도 살펴볼 예정이지만 하드 디스크 이미지를 제작하는 과정과 함께 실제 서비스 모델은 별도로 Publish해야 한다는 점을 기억해둘 필요가 있습니다.

감사합니다.

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

댓글을 달아 주세요

PaaS2010. 12. 4. 01:28

시작하기

Windows Azure Virtual Machine Role (이하 VM Role)은 그 동안 많은 개발자들과 IT Pro들에게 관심사였던 최신 기능으로, 2010년 12월부터 본격적인 Beta 서비스가 제공되기 시작하였습니다. VM Role은 Amazon Elastic Cloud Computing (EC2)에서 제공되어오던 Virtual Machine 기반 클라우드의 장점을 Platform as a Service 버전으로 재 해석하여 통합한 Windows Azure 만의 고유한 기능입니다.

이번 Article은 2010년 11월 버전의 Platform Training Kit에서 소개하는 VM Role Deploy 방법을 한글로 자세히 풀이하기 위한 목적으로 작성된 것으로, VM Role에 대하여 구체적으로 학습해볼 수 있는 계기를 마련해보기 위하여 올립니다. 스크린 샷과 자료의 기본 출처는 Platform Training Kit으로 부터 발췌해온 것임을 미리 밝혀둡니다.

라이선스 문제

여러가지 이슈가 있겠지만 무엇보다도 초미의 관심사는 바로 라이선스에 관한 부분일 것입니다. VM Role은 Windows Azure에 맞추어진 OS가 아닌 기존의 On-Premise의 OS를 호스팅하는 것이기 때문에 특히 민감할 수 밖에 없는데요, 의외로 라이선스 문제는 생각하는 것 만큼 복잡하고 어렵지 않습니다. Physical to Virtual (이하 P2V)를 수행하기 위하여 사용했던 원본 OS의 라이선스 종류에 관계없이, Windows Azure에서 VM Role을 위하여 호스팅되는 OS의 라이선스는 Windows Azure의 라이선스 정책, 즉 유틸리티 컴퓨팅 기반의 사용량 과금에 의해서만 비용이 결정되며 여기에는 일체의 라이선스 비용이 포함되지 않습니다. 순수하게 사용량만을 고려하면 되는 것입니다.

그러나 Windows Azure에서 사용하는 VM Role 라이선스를 역으로 On-Premise로는 가져오실 수 없으며, 또한 VM Role 안에 설치되는 각각의 소프트웨어들에 대한 라이선스는 신중히 결정해야 합니다. 해당 소프트웨어에 대한 라이선스는 종전의 서버 호스팅과는 차이가 많이 날 수 있습니다. 대표적으로, 탄력적인 시스템 운영을 위하여 한 번에 2대 이상의 가상 서버 인스턴스가 구동될 수 있고 사용량이 늘어나면 당연히 Fabric Controller는 VM Image를 복제하여 여러 대의 가상 서버 인스턴스를 생성하게 된다는 점은 원래 소프트웨어를 구입하여 설치했던 조건과는 큰 차이가 날 수 밖에 없는 부분으로, 라이선스를 위반하지 않기 위해서는 해당 소프트웨어 제공 업체가 이러한 클라우드 컴퓨팅 환경에 알맞는 유틸리티 기반의 과금 모델을 제공하는지 충분히 검토해야 합니다.

SQL Server의 경우 가장 이상적인 것은 SQL Server를 포함하는 VM Role을 게시하는것 보다 SQL Azure로 데이터를 이관하는 것입니다. 그러나 법적인 문제나 보안 상의 이유로 인하여 데이터를 이관할 수 없는 경우, Windows Azure Connect (구 Codename: Sydney)를 통해 On-Premise에서 구동 중인 서버들과 Windows Azure Platform에서 실행 중인 Instance들 사이의 네트워크를 같은 레이어에 통합하는 방법을 사용하여 손쉽게 문제를 해결할 수 있습니다. SQL Server 뿐만 아니라 기존에 사용하던 Back-Office Server, Active Directory Domain Controller 등도 무리해서 Windows Azure Platform으로 이주하지 않더라도 이러한 방법으로 문제를 해결할 수 있습니다.

VM Role을 만들기 위하여 필요한 준비 사항

VM Role을 만들기 위해서는 다음의 준비 사항이 필요합니다.

VM Role 만들기 Step 1 - 게스트 운영 체제 설치하기

VM Role을 만드는 절차를 요약하면, 앞서 언급한 구성 요소에서 짐작하시게 되는 것과 같이 Hyper-V를 이용하여 Guest VM으로 Windows Server 2008 R2를 설치하고, 여기에 여러분이 원하는 커스터마이징을 적용한 이후에 이것을 VM Role 형식에 맞게 포장하여 Windows Azure에 Base Image로 등록하는 것입니다.

현재 베타 버전으로 제공되는 VM Role은 Windows Server 2008 R2를 위한 구성 요소만을 제공합니다. 이에 따라, Windows 7의 Virtual PC로는 64비트 전용 OS인 Windows Server 2008 R2를 실행할 수 없기 때문에 특별히 Windows Server 2008 R2의 Hyper-V가 필요합니다.

1. Windows Server 2008 Hyper-V 호스트 컴퓨터에서 관리자 계정으로 로그인한 후 시작 - 관리 도구 - Hyper-V 관리자를 클릭하여 실행하면 아래와 같은 Management Console이 나타납니다.

 

2. Hyper-V 관리자의 좌측 트리 뷰에서 서버 노드를 마우스 오른쪽 버튼으로 클릭해서 나타나는 메뉴의 "새로 만들기" - "가상 컴퓨터" 항목을 클릭합니다. 그 후 나타나는 마법사 대화 상자에서 "다음" 버튼을 클릭합니다.

 

3. 아래 화면에서 Virtual Machine의 이름을 지정합니다. 여기서는 VM Role이라고 이름을 지정하도록 하고, 정해진 기본 위치를 필요한 경우 변경하거나 설정된 경로를 확인합니다. 다음 버튼을 눌러 다음 단계로 이동하겠습니다.

 

4. 메모리의 크기를 설정하는 단계에서는 자동으로 추천하는 2GB (2048MB) 메모리를 그대로 사용합니다. 다음 버튼을 클릭합니다.

 

5. 네트워크 어댑터를 설정하는 단계입니다. 로컬 영역 연결 - 가상 네트워크 항목이 선택된 상태에서 다음 버튼을 클릭합니다. 이 설정은 처음 VM Role을 시작한 이후 Windows Update (혹은 Microsoft Update)에서 업데이트를 내려받기 위하여 필요한 구성입니다.

 

6. 이제 가상 디스크 구성 단계입니다. 새로운 가상 하드 디스크를 만들기 위하여 첫 번째 라디오 버튼을 클릭하고, 가상 하드 디스크 파일의 이름을 임의로 정한 뒤, 하드 디스크를 만들 위치와 크기를 정합니다. 아래 예제에서는 baseimage.vhd 라는 이름을 사용하고 있고 30GB 하드 디스크를 생성하려고 하고 있습니다.

(중요) 이 단계에서 지정하는 값은 나중에 CSUPLOAD 도구에서 필요하므로 잘 메모해둡니다. - 또는 - 나중에 Virtual Machine 속성에서 찾아볼 수도 있습니다.

 

참고로 가상 하드 디스크의 크기는 인스턴스 레벨에 맞추어 설정해야 합니다. Extra Small 인스턴스에 맞추기 위해서는 가상 하드 디스크의 크기를 20GB 이하로 설정해야 합니다. 만약 이미 만들어진 가상 하드 디스크 파일을 사용하려면 두 번째 라디오 버튼을 선택하고 VHD 파일의 경로를 찾아 보기 버튼을 이용하여 아래 그림과 같이 지정할 수 있습니다.

 

7. 이제 설치 옵션을 선택하는 차례입니다. 나중에 따로 지정하여도 되고, 마법사를 이용하여 기본으로 ISO 이미지 파일 - 또는 - DVD 드라이브에 마운트 하도록 아래 그림과 같이 지정할 수 있습니다. 만약 시험 목적으로 사용하기 위하여 VM Role을 만들고자 한다면 http://www.microsoft.com/windowsserver2008/en/us/trial-software.aspx 에서 트라이얼 버전의 Windows Server 2008 R2 Enterprise Edition을 다운로드받으실 수 있습니다.

 

8. 모든 과정이 거의 마무리되어갑니다. 마침 버튼을 클릭하여 새로운 Virtual Machine을 생성합니다.

 

9. Hyper-V 관리자로 돌아와서 방금 생성한 Virtual Machine 항목을 찾아, 오른쪽 버튼으로 클릭하고 나타나는 팝업 메뉴에서 연결 메뉴를 클릭합니다. 항목이 바로 나타나지 않을 수도 있으므로 이 경우 좌측의 트리 뷰에 나타나있는 서버 항목을 오른쪽 버튼으로 클릭하여 새로 고침 메뉴를 클릭하여 목록을 갱신할 수 있습니다.

10. 아래 그림과 같이 원격 제어 창이 나타나면 시작 버튼을 클릭하여 Virtual Machine을 재생시킵니다.

 

11. 설치 단계에서 미디어를 정확히 지정했다면 Windows Server 2008 R2 설치 마법사가 가상 PC 안에서 아래 화면과 같이 시작될 것입니다.

 

12. 잠시 뒤에 표시 언어, 시간대, 통화 기호, 키보드 레이아웃 설정을 할 수 있는 화면이 나타납니다. 적절한 선택을 한 후 다음 버튼을 클릭합니다.

 

13. 지금 설치 버튼을 클릭합니다.

 

14. Windows Server 2008 R2 Enterprise (전체 설치) 항목을 선택하는 것에 유의합니다. 서버 코어 설치를 비롯하여 다른 제품의 경우 기능 상에 문제가 발생하거나 라이선스 관계 상 문제가 될 수 있습니다.

 

15. 라이선스 조항에 동의함을 선택하고 다음 버튼을 클릭합니다.

 

16. 사용자 정의 (고급) 설치 항목을 선택합니다. 이 과정을 선택하는 이유에 대해서는 다음 단계에서 자세히 설명하겠습니다.

 

17. 대부분의 경우 설치 관리자의 자동 설정을 이용하면 문제가 없습니다. 그러나 VM Role을 위하여 필요한 작업이 한 가지 있습니다. VM Role에 호환되는 가상 하드 디스크 레이아웃을 만드려면 반드시 하나의 단일 파티션으로 구성해야 하는데, 기본 설치를 이용하면 이 규칙을 준수하지 않게 됩니다. 이를 피하기 위하여 사용자 정의 설치를 선택하였고 아래와 같은 화면이 나타나게 됩니다.

 

17. 이제 Shift + F10 키를 눌러 아래와 같이 명령 프롬프트 창을 시작합니다.

 

18. 명령 프롬프트 창이 나타나면 다음의 순서대로 명령어를 입력합니다.

DISKPART

 

SELECT DISK 0

 

CREATE PARTITION PRIMARY

 

EXIT

 

19. 명령 프롬프트 창이 닫힌 상태에서 새로 만들어진 파티션을 선택하여 Windows 운영 체제 설치를 진행하면 됩니다. 파티션이 보이지 않을 때에는 새로 고침을 선택하십시오.

 

20. 설치가 진행됩니다. 1~2회 이상 시스템이 다시 시작될 수 있습니다. 설치가 완전히 종료될 때 까지 중간에 DVD나 설치 미디어를 제거하는 일이 없도록 유의합니다.

 

21. 완전히 설치가 끝났다면 아래와 같이 관리자 비밀 번호를 지정해야 함을 경고하는 문구가 나타날 것입니다. 아래 화면에서 확인 버튼을 클릭합니다.

 

22. 암호 정책에 만족하는 강력한 암호를 확인을 위하여 두 번 입력하고 Enter 키를 누릅니다. 잠시 기다리면 바탕 화면이 나타날 것입니다.

 

마치면서

다음 시간에는 VM Role로 배포하기 위하여 필요한 게스트 운영 체제에서 필요한 설정을 적용하는 방법과 Windows Azure 환경으로 이미지를 출판하는 방법을 설명하는 내용을 상세히 설명하도록 하겠습니다. 감사합니다.

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

댓글을 달아 주세요