Windows Azure 응용 프로그램 모델
역자 주 : 본 문서는 마이크로소프트의 Windows Azure 웹 사이트에 게시된 칼럼을 태오 사이트 강좌 목적으로 번역한 문서로 마이크로소프트의 공식 번역문서가 아니며 원문에 대한 모든 저작권은 마이크로소프트에 있습니다.
다만, 2012년 6월 Azure 사이트 개편 이후, 원본 컬럼이 사라진 상태입니다.
Windows Azure는 개발한 응용 프로그램을 마이크로소프트 데이터 센터 내부에서 실행되도록 할 수 있으며 그 프로그램을 배포하고 모니터링 할 수 있게 합니다. 이렇게 Windows Azure에서 응용 프로그램을 생성하고 실행할 때 만들어지는 코드(Code)와 구성(Configuration)을 함께 가리켜 Windows Azure 기반 호스트 서비스(Hosted service)라고 합니다. Hosted Service는 시스템의 관리 및 규모의 확장과 축소가 용이하며, 시스템의 재구성과 응용 프로그램 코드를 새로운 버전으로 업데이트 가능합니다. 이 문서에서는 Windows Azure 기반의 Hosted Service 응용 프로그램 모델의 기본적인 사항을 살펴 보도록 하겠습니다.
목차
Windows Azure 응용 프로그램 모델의 장점
응용 프로그램을 Hosted Service로 배포할 때, Windows Azure는 응용 프로그램을 포함하는 하나 또는 그 이상의 가상 머신(Virtual Machine)을 생성하고, Windows Azure 데이터 센터에 있는 물리적인 하드웨어에 해당 가상 머신들을 구성합니다. 클라이언트의 요청이 호스트에서 실행되는 응용 프로그램에 들어오면, 로드 밸런서(Load Balancer, 부하 분산 장치)는 요청을 각 가상 머신으로 분산 처리합니다. 응용 프로그램이 Windows Azure에서 호스팅되면 다음과 같은 세 가지 장점을 가지게 됩니다.
높은 가용성(可溶性, High availability)
Windows Azure에서 고가용성의 의미는 응용 프로그램이 지속적으로 실행되면서 클라이언트의 요청에 대해서 항시 응답을 줄 수 있는 상태를 보장하는 것입니다. 만일 응용 프로그램이 갑작스럽게 종료(예를 들어, 예외처리-Unhandled Exception-오류발생과 같은)되면, Windows Azure는 이를 감지하여 자동으로 응용 프로그램을 재 시작 합니다. 프로그램이 실행되고 있는 시스템의 하드웨어 오류가 발생한 경우에도 Windows Azure는 이 또한 감지하여 자동으로 새로운 하드웨어 시스템에 가상 머신을 생성하고, 그곳에 응용 프로그램을 배포한 뒤 실행합니다.
*Note: 응용 프로그램이 99.95% 가용한 마이크로소프트의 SLA(Service Level Agreement, 서비스 수준 동의서)를 받기 위해서는 프로그램 코드가 실행되는 최소한 2개의 가상 머신을 가지고 있어야 합니다. 이렇게 함으로써 Windows Azure는 문제가 발생한 가상 머신에서 수행되고 있는 프로그램을 정상적으로 동작하는 새로운 가상 머신으로 이동하는 동안 클라이언트의 요청을 정상적으로 처리할 수 있게 됩니다.
확장성(Scalability)
Windows Azure는 응용 프로그램에 가해지는 실제 부하를 처리하기 위해 프로그램이 실행되는 가상 머신들의 숫자를 간단한 조작만으로 변경할 수 있습니다. 즉, 추가적인 리소스가 필요로 할 때, 필요한 만큼의 가상 머신의 사용료만을 지불하면서 작업 부하에 따라 응용 프로그램을 조정할 수 있다는 것을 의미합니다. Azure 상에서 실행되는 가상 머신의 개수는 언제든지 몇 분 안에 변경이 가능합니다.
관리의 용이성(Manageability)
Windows Azure는 PaaS(Platform as a Service)형태로 제공되기 때문에 해당 시스템 장치들이 동작하는데 필요한 인프라스트럭처(H/W, 전기 및 네트워킹)를 관리합니다.
또한 Windows Azure는 .NET Framework와 IIS 서버와 같은 시스템 구성요소의 업데이트는 물론이고 서버의 패치와 보안 업데이트가 적용된 최신 버전의 운영 시스템을 유지하도록 시스템을 관리합니다. 모든 가상 머신들은 Windows Server 2008을 사용하기 때문에 Windows Azure는 진단 모니터링, 원격 데스크톱, 방화벽 그리고 인증서 저장 구성(Certificate Store Configuration)과 같은 추가적인 기능을 제공합니다. 이러한 모든 기능들은 추가적인 비용없이 제공이 됩니다. 미처 생각을 못했을 수도 있지만, Windows Azure 상에서 응용 프로그램을 동작시킬 때 Windows Server 2008 서버 운영체제의 라이선스도 포함이 되어 있기 때문에 추가적인 라이선스 비용은 부가되지 않습니다. 모든 가상 머신들이 Windows 2008 서버로 동작하기 때문에 기존에 Windows 2008에서 동작하던 프로그램들은 별도로 변경하지 않아도 아무런 문제없이 Windows Azure 상에서도 동작을 합니다.
Hosted Service의 핵심 개념
응용 프로그램이 Windows Azure의 Hosted Service로 배포되면, 하나 이상의 역할(Role)로 실행됩니다. '역할'을 간단하게 표현을 하자면 Windows Azure에서 실행되는 응용 프로그램 파일과 구성(Configuration)을 의미합니다. 응용 프로그램과 각각의 응용 프로그램 파일 및 구성의 집합에 대해 하나 이상의 역할을 정의할 수 있습니다. 응용 프로그램에서 각각의 역할에 대해서 실행하기 위한 가상 머신들의 숫자 또는 Role 인스턴스(Role Instance)를 지정할 수 있습니다. 아래 그림은 역할과 Role 인스턴스를 사용하는 Hosted Service 응용 프로그램 모델의 두 가지 간단한 예를 보여줍니다.
그림 1: Windows Azure 데이터 센터에서 수행되는 3개의 인스턴스(가상 머신)를 가진 단일 역할(A) 모델
그림 2: Windows Azure 데이터 센터에서 수행되는 각각 2개의 인스턴스(가상 머신)를 가지고 있는 2개의 역할(A,B)
Role 인스턴스는 일반적으로 입력 엔드포인트(Endpoint, 종단점)라는 것을 통해 데이터 센터에 들어오는 클라이언트의 요청을 처리합니다. 하나의 역할은 0 또는 그 이상의 입력 엔드포인트를 가질 수 있습니다. 각 엔드포인트는 프로토콜 (HTTP, HTTPS 또는 TCP)과 포트를 가리키게 됩니다. 80 포트로 HTTP를, 443포트에서 HTTPS를 수신할 수 있도록 2개의 엔드포인트를 구성하는 것이 일반적입니다. 아래 그림은 클라이언트 요청에 대한 입력 엔드포인트가 서로 다른 2개의 역할에 대한 예를 보여줍니다.
Windows Azure에서 Hosted Service를 만들 때, 클라이언트가 접근하는 데 사용할 수 있는 Public IP 주소를 할당합니다. 또한 호스트 서비스를 작성하면 IP 주소에 매핑되는 URL prefix를 선택해야만 합니다. 다른 누군가가 소유할 수 없도록 prefix.cloudapp.net URL을 확보해야 하기 때문에 이러한 prefix는 고유한 것이어야 합니다. 클라이언트는 URL을 이용하여 Role 인스턴스와 통신합니다. 일반적으로 Windows Azure에서는 prefix.cloudapp.net URL을 배포하거나 게시하지 않습니다. 대신에, DNS 등록 기관에서 DNS 이름을 구입하고 Windows Azure URL로 클라이언트 요청을 리디렉션하도록 DNS 이름을 구성합니다. 자세한 내용은 'Windows Azure에서의 사용자 정의 도메인 이름 구성'을 참조하시기 바랍니다.
Hosted Service 디자인 고려사항
클라우드 환경에서 실행되도록 응용 프로그램을 설계할 때는 지연시간(latency), 고가용성(High Availability) 및 확장성(Scalability)등 생각해야 할 몇 가지 고려 사항들이 있습니다.
Windows Azure에서 Hosted Service를 실행하는 응용 프로그램의 위치(지역)를 결정하는 것은 중요한 고려 사항입니다. 대기시간을 줄이고 최상의 성능이 얻으려면 접속하는 클라이언트와 가장 가까운 곳에 위치한 데이터 센터에 응용 프로그램을 배포하는 것이 일반적입니다만, 예외적으로 개발하는 회사와 가까운 곳에 있는 데이터 센터를 선택하거나 데이터의 위치에 대한 법적인 우려가 있는 상황이라면 그에 따라 적절한 데이터 센터를 선택할 수 있습니다. Windows Azure를 호스팅하는 데이터 센터는 전 세계 8 곳이 위치하고 있습니다. 아래 표는 사용 가능한 데이터 센터의 위치를 보여줍니다. (참고, 2012년 6월 현재 미주에 2개의 데이터 센터가 추가되어 총 8곳이 되었습니다. http://www.windowsazure.com/en-us/support/trust-center/privacy)
| 국가/지역 | 하위 지역 |
| 미국 | 남중부(텍사스) 및 북중부(일리노이) 지역
동부(버지니아)와 서부(캘리포니아) |
| 유럽 | 북쪽(아일랜드) 및 서쪽 지역(네덜란드) |
| 아시아 | 남동 및 서쪽 지역 |
호스트 서비스를 만들 때, 코드가 실행되어야 하는 위치에 대한 하위 지역을 선택합니다.
높은 가용성 및 확장성을 이루기 위해서는 응용 프로그램의 데이터가 여러 Role 인스턴스에서 접근할 수 있도록 중앙 Repository에 보관하는 것이 매우 중요합니다. 이것을 지원하기 위해 Windows Azure는 Blob, 테이블 및 SQL Azure와 같은 저장방식을 제공합니다. 이러한 스토리지 기술에 대한 자세한 내용은 Windows Azure 문서의 'Data Storage Offerings in Windows Azure'을 참조하시기 바랍니다. 아래 그림은 Windows Azure 데이터 센터 내부의 로드 밸런서 프로그램이 동일한 데이터 스토리지에 대하여 접근권한이 모두 각기 다른 Role 인스턴스에 대한 클라이언트 요청을 분산하는 방법을 보여 줍니다. 성능 향상을 위하여 일반적으로 응용 프로그램과 데이터를 동일한 데이터 센터에 위치시킬 수 있습니다. 추가적으로, 데이터가 동일한 데이터 센터 내에서 이동하는 경우에는 비용이 청구되지 않습니다.
확장을 고려한 응용 프로그램의 디자인
단독으로 동작하는 응용 프로그램(간단한 웹 사이트와 같은)을 사용하는 경우에도 해당 프로그램을 Windows Azure에서 호스팅 할 수 있습니다. 그러나 대부분 프로그램은 단독으로 동작하기 보다는 여러 개의 프로그램으로 나누어져 있고 각 프로그램의 작업이 함께 이루어져야 원활하게 동작합니다. 이러한 구조에서는 여러 가지의 역할들로 구성될 것입니다. 예를 들어, 아래 그림에서는 2개의 웹 사이트 Role 인스턴스와 주문처리(Order Processing) 역할을 하는 3개의 인스턴스 그리고 보고서 생성기(Report Generator) 역할을 하는 1개의 인스턴스가 있습니다. 이러한 역할은 모두 함께 동작하고 있으며 모든 코드는 Windows Azure에서 하나의 단위로서 함께 패키징하여 배포될 수 있습니다.
역할별로 응용 프로그램을 분할하여 실행하는 주된 이유는 독립적으로 각각의 Role 인스턴스를 확장할 필요가 있는 경우를 대비해서 입니다. 예를 들어, 추석이나 명절 전과 같이 주문이 많이 발생하는 기간에는 웹사이트의 역할 뿐만 아니라 주문처리 역할을 실행하는 Role 인스턴스의 개수를 늘릴 수도 있습니다. 연휴 이후에는 많은 반품이 있을 수도 있으므로 여전히 많은 웹 사이트 인스턴스가 필요할 수 있지만, 주문을 처리하는 인스턴스는 감소할 수 있습니다. 이후 나머지 기간 동안은 소량의 웹사이트 및 주문처리 인스턴스만이 필요할 수도 있습니다. 이 기간 내내 보고서 생성기(Report Generator) 인스턴스는 하나 만으로도 충분할 수 있습니다. 이렇게 Windows Azure의 역할 기반 배포의 유연성은 변화무쌍한 비즈니스 상황에 동적으로 대응할 수 있습니다.
일반적으로 호스트 서비스 안에는 서로 상호작용하는 Role 인스턴스들이 존재할 수 있습니다. 예를 들어, 웹사이트 역할(Web site Role)은 고객의 주문을 받아서 처리할 뿐이고, 주문과 관련된 처리는 주문처리 역할(Order Processing Role)로 떠넘기게 됩니다. 한 세트의 Role 인스턴스로부터 업무를 전달하는 가장 좋은 방법은 Windows Azure에서 제공하는 대기열 기술(Queuing Technology)인 대기열 서비스(Queue Service) 또는 서비스 버스 대기열(Service Bus Queue)를 사용하는 것입니다. 여기서 대기열(Queue)의 사용은 아주 중요한 부분이라고 볼 수 있습니다. 대기열은 호스트 서비스가 비용대비 작업 부하를 균형있게 조절할 수 있도록 역할을 독립적으로 확장할 수 있게 합니다. 대기열에 있는 메시지의 수가 점차 증가한다면, 주문처리 Role 인스턴스의 개수를 확장할 수 있습니다. 마찬가지로, 대기열에 있는 메시지의 수가 시간이 지남에 따라 감소한다면, 주문처리 Role 인스턴스의 수를 줄일 수 있습니다. 이렇게 하면 실제 작업 부하를 처리하는 데 필요한 인스턴스 만큼만 지불하게 될 것 입니다.
또한, 대기열 기능을 통하여 신뢰성 있는 통신 방식을 제공합니다. 주문처리 Role 인스턴스의 개수를 줄이게 되면 Windows Azure는 어떤 인스턴스를 종료할 것인지를 결정합니다. 대기열 처리 중에 있는 인스턴스를 종료하기로 결정할 수도 있습니다. 그러나, 메시지가 성공적으로 완료되지 않기 때문에 다른 주문처리 Role 인스턴스에서 다시 표시되어 처리됩니다. 이렇게 대기열의 메시지가 갖는 가시성(Visibility) 때문에 메시지는 성공적으로 수행이 됩니다. 대기열 기능은 어떠한 종류의 Role 인스턴스에게도 효과적으로 메시지를 분산하는 로드 밸런서 역할로도 동작을 합니다.
웹사이트 Role 인스턴스의 경우, 네트워크 트래픽을 모니터링하여 규모를 늘려야 할지 줄여야 할지를 결정할 수 있습니다. 주문처리 Role 인스턴스와는 별개로 웹 사이트 Role 인스턴스의 수량을 변경할 수 있습니다. 이것은 매우 강력하면서도 상당한 유연성을 제공합니다. 물론, 응용 프로그램이 추가적인 역할로 구성되어 있다면, 추가적으로 확장성과 비용적인 장점을 향상하기 위하여 역할간의 통신 전달자로서 대기열를 추가할 수 있습니다.
Hosted Service 정의와 구성(Definition & Configuration)
Windows Azure로 호스트 서비스를 배포하기 위해서는 서비스 정의 파일과 서비스 구성 파일을 가지고 있어야 합니다. 이러한 파일은 모두 XML 형식의 파일로, 호스트 서비스를 위한 배포 옵션을 선언적인 방식으로 지정할 수 있습니다. 서비스 정의 파일은 호스트 서비스가 어떻게 통신하게 되는지에 대한 모든 역할을 설명합니다. 서비스 구성 파일에는 각 역할과 각 Role 인스턴스를 구성하는 데 사용되는 설정에 대한 인스턴스의 숫자를 설명합니다.
서비스 정의 파일>
앞에서 언급한 것처럼, 서비스 정의(CSDEF) 파일은 전체 응용 프로그램을 구성하는 다양한 역할들을 설명하는 XML 파일입니다. XML 파일에 대한 스키마는 아래 웹사이트 여기에서 찾아보실 수 있습니다.
http://msdn.microsoft.com/en-us/library/windowsazure/ee758711.aspx
CSDEF 파일에는 응용 프로그램에서 원하는 각 역할에 대해 WebRole 또는 WorkerRole 요소를 포함하고 있습니다. 웹 역할 (WebRole 요소를 사용)은 코드가 Windows Server 2008 및 IIS를 포함하는 Role 인스턴스에서 실행된다는 것을 의미합니다. Worker 역할 (WorkerRole 요소를 사용)로 배포한다는 것은 Role 인스턴스가 Windows Server 2008만을 가지게 된다는 것을 의미합니다(즉, Worker인 경우에는 IIS가 설치되지 않습니다)
서버로 들어오는 웹 요청들을 수신하기 위해 몇 가지 다른 메커니즘을 사용하는 Worker Role(작업자 역할)을 생성하고 배포할 수도 있습니다(예를 들어, 코드에서 .NET의 HttpListener를 만들고 사용하는 경우). 모든 Role 인스턴스는 Windows Server 2008에서 실행되므로 기존에 Windows Server 2008에서 실행되던 응용 프로그램들은 원래대로 작업을 수행할 수 있습니다.
각 역할별로 해당 역할의 인스턴스가 사용할 수 있는 가상 머신의 크기를 지정할 수도 있습니다. 아래 표는 현재 사용될 수 있는 다양한 가상 머신의 규모와 특성을 보여줍니다:
| 가상 머신 사이즈 | CPU | 메모리 | 디스크 | 최고 네트워크I/O |
| Extra Small | 1 x 1.0 GHz | 768 MB | 20GB | ~5 Mbps |
| Small | 1 x 1.6 GHz | 1.75 GB | 225GB | ~100 Mbps |
| Medium | 2 x 1.6 GHz | 3.5 GB | 490GB | ~200 Mbps |
| Large | 4 x 1.6 GHz | 7 GB | 1TB | ~400 Mbps |
| Extra Large | 8 x 1.6 GHz | 14 GB | 2TB | ~800 Mbps |
요금은 Role 인스턴스로 사용하는 각 가상 머신에 대해 시간 별로 부과되고, Role 인스턴스가 데이터 센터 밖으로 보내는 모든 데이터에 대해서도 부과됩니다. 데이터 센터로 입력되는(업로드) 데이터에 대해서는 요금이 청구되지 않습니다. 자세한 내용은 'Windows Azure Pricing'을 참조하십시오. 일반적으로, 응용 프로그램이 오류발생 시 탄력적인 대응이 될 수 있으려면 소수의 Large 사이즈의 인스턴스를 운영하는 것 보다 다수의 Small 사이즈의 Role 인스턴스를 사용하는 것이 좋습니다. 결국, 응용 프로그램의 전체적인 입장에서는 소량의 인스턴스만을 운영하다가 그 중 하나의 인스턴스에서 문제가 발생하여 전체 서비스가 중단이 된다면 오히려 더 심각한 문제가 생길 수 있기 때문에, 다수의 인스턴스를 보유하는 것이 권장 됩니다. 또한, 위에서 말했듯, 마이크로소프트가 제공하는 99.95 %의 서비스 수준 계약(SLA)을 하기 위해서는 각 역할에 대해 최소한 2개의 인스턴스를 배포하는 것이 좋습니다.
또한, 서비스 정의(CSDEF) 파일은 응용 프로그램에서 각 역할에 대해 많은 속성을 지정할 수 있습니다. 아래의 내용은 서비스 정의 파일에서 유용하게 사용할 수 있는 항목들 입니다.
인증서(Certificates): 데이터를 암호화하거나 웹 서비스가 SSL을 지원한다면 인증서를 사용할 수 있습니다. 모든 인증서는 Windows Azure로 업로드 해야 합니다. 자세한 내용은 'Windows Azure의 인증서 관리'를 참조하십시오. 이 XML 설정은 응용 프로그램 코드에 의해 사용할 수 있도록 Role 인스턴스의 인증서 저장소에 기존에 업로드된 인증서를 설치합니다.
구성 설정 이름(Configuration Setting Names): Role 인스턴스에서 실행되는 동안 응용 프로그램(들)이 읽고 싶은 값을 의미하며, 구성 설정의 실제 값은 코드를 재배포하지 않고도 언제든지 업데이트할 수 있는 서비스 구성 (CSCFG) 파일에 설정됩니다. 어떤 다운타임을 가지지 않고 변경된 설정 값을 감지하는 등의 방법으로 응용 프로그램을 작성 할 수 있습니다.
입력 엔드포인트(Input Endpoints): 여기서는 prefix.cloadapp.net URL을 통하여 외부에 노출하고자 하는 HTTP, HTTPS 또는 TCP 엔드포인트(포트)를 지정합니다. Windows Azure에서는 역할을 배포하면 자동으로 Role 인스턴스에 대한 방화벽을 구성합니다.
내부 엔트포인트(Internal Endpoints): 응용 프로그램의 일부로서 배포되는 다른 Role 인스턴스에게 노출하고자 하는 HTTP 또는 TCP 엔드포인트를 지정합니다. 내부 엔트포인트는 응용 프로그램 내부의 모든 Role 인스턴스가 서로 통신을 할 수 있도록 허용하지만, 외부에 있는 Role 인스턴스에서는 접근이 불가능 합니다.
모듈 가져오기(Import Modules): Role 인스턴스 상에 유용한 구성요소를 선택적으로 설치할 수 있습니다. 진단 모니터링, 원격 데스크톱 그리고 Windows Azure Connect(기존에 자체적으로 운영하고 있는 시스템과 보안채널을 이용하여 통신할 수 있도록 하는 기능)와 같은 구성요소를 사용할 수 있도록 합니다.
지역 저장소(Local Storage): 응용 프로그램에서 사용할 수 있도록 Role 인스턴스 상에 하부 디렉토리를 할당합니다. 이 내용은 'Data Storage Offerings in Windows Azure'문서에서 상세하게 설명되어 있습니다.
시작 작업(Startup Tasks): 시작작업은 부팅 시에 Role 인스턴스 상에서 실행에 필요한 구성요소를 설치하는 방법을 제공합니다. 이 작업은 필요 시 관리자 권한으로 수행이 됩니다.
서비스 구성 파일(Service Configuration File)
서비스 구성 (CSCFG) 파일은 프로그램의 재배포없이 변경될 수 있는 설정 정보를 위한 XML 파일입니다. XML 파일에 대한 모든 스키마 정보는 아래 URL에서 보실 수 있습니다.
http://msdn.microsoft.com/en-us/library/windowsazure/ee758710.aspx
CSCFG 파일은 응용 프로그램의 각 역할에 대해 역할 요소를 포함하고 있습니다. CSCFG 파일에서 지정할 수 있는 항목 중 일부는 다음과 같습니다
- 운영체제 버전(OS Version): 이 속성은 응용 프로그램 코드를 실행하는 모든 Role 인스턴스에서 사용하려는 운영 체제 (OS) 버전을 선택할 수 있게 합니다. 이 운영체제는 게스트 OS(Guest OS)로 알려져 있으며 각각의 새로운 버전은 게스트 OS가 출시될 당시 사용 가능한 최신 보안 패치 및 업데이트를 포함하고 있습니다. osVersion 속성 값을 "*"로 설정했다면, 새 게스트 OS 버전이 출시될 경우, Windows Azure가 자동으로 Role 인스턴스의 각 게스트 OS를 업데이트합니다. 그러나, 특정 게스트 OS 버전을 선택하면 자동으로 업데이트를 하지 않습니다. 예를 들어, 'WA-Guest OS-2.8_201109-01"의 값으로 osVersion 속성을 설정하면 모든 Role 인스턴스들은 http://msdn.microsoft.com/en-us/library/hh560567.aspx 웹 페이지에 설명된 내용과 같이 업데이트를 합니다. 게스트 OS 버전에 대한 자세한 내용은 'Windows Azure 게스트 운영체제 업그레이드 관리'를 참조하십시오.
- 인스턴스(Instances): 이 엘리먼트의 값은 특정 역할에 대한 코드를 실행하는 Role 인스턴스의 수를 나타냅니다. 응용 프로그램을 재배포하지 않고도 Windows Azure에 새로운 CSCFG 파일을 업로드할 수 있기 때문에, 이 요소의 값을 변경한 뒤 변경된 CSCFG 파일을 업로드하거나 혹은 응용 프로그램 코드를 동적으로 실행하여 Role 인스턴스의 숫자를 늘리거나 줄이는 것이 가능합니다. 또한, 실제 부하에 맞게 응용 프로그램의 규모를 늘리거나 줄이는 방식으로 Role 인스턴스를 실행하는데 필요한 비용이 청구되는 방식을 조정할 수 있습니다.
- 구성 설정 값(Configuration Setting Values): 이 요소는 설정 값(CSDEF 파일에 정의된)을 나타냅니다. 실행되는 동안 역할은 이러한 값을 읽을 수 있습니다. 이러한 구성 설정 값은 일반적으로 SQL Azure 또는 Windows Azure 저장소에 대한 연결문자열로 사용되곤 하지만, 원하는 목적을 위해 다른 용도로도 사용될 수 있습니다.
호스트 서비스의 생성과 배포
호스트 서비스를 생성하기 위해서는 제일 먼저 Windows Azure 관리 포털 사이트에 접속하여 프로그램이 수행될 수 있는 호스트 서비스를 프로비전닝을 해야 합니다. 이 때 실행하고자 하는 DNS 접두어와 데이터 센터를 지정합니다. 그 다음에 개발환경에서 서비스 정의 파일(CSDEF)을 생성하고 프로그램을 빌드합니다. 그리고, 만들어진 코드와 모든 파일을 서비스 패키지 파일(CSPKG)에 포함시킵니다. 또한, 서비스 구성 파일(CSCFG)을 준비합니다. 역할을 배포하기 위해서는 Windows Azure Service Management API와 함께 CSPKG 및 CSCFG 파일을 업로드 하십시오(이러한 모든 과정은 최근 새로 변경된 Azure에서는 약간 차이가 있을 수 있습니다. 실습 강좌에서는 그에 맞게 설명할 예정입니다. 지금은 개념만 이해하시기 바래요). 일단 배포가 되고 나면, Windows Azure 데이터 센터에서 Role 인스턴스를 프로비저닝을 합니다. 즉, 패키지에서 응용 프로그램 코드를 추출한 다음 그것을 Role 인스턴스에 복사하게 됩니다. 이제 인스턴스를 부팅하게 되면 코드가 Windows Azure상에서 실행되게 됩니다.
아래 그림은 개발 컴퓨터에 작성한 CSPKG 및 CSCFG 파일을 보여줍니다. CSPKG파일은 CSDEF파일과 두 역할에 대한 코드가 포함되어 있습니다. Windows Azure Service Management API와 CSPKG 및 CSCFG 파일을 업로드 후 Windows Azure은 데이터 센터에 Role 인스턴스를 만듭니다. 이 예제에서는 CSCFG 파일은 Windows Azure가 1번 역할의 3개 인스턴스와 2번 역할을 하는 2개 인스턴스를 생성하도록 합니다.
배포, 업그레이드 및 역할의 재구성에 대한 자세한 내용은 '배포 및 업데이트 Windows Azure 응용 프로그램(Deploying and Updating Windows Azure Applications)' 문서를 참조하십시오.
:{3} 
({4})