'Cloud Azure'에 해당되는 글 2건

  1. 2011.03.25 Cloud Computing with Microsoft: Part 5
  2. 2011.03.11 Cloud Computing with Microsoft: Part 3

이번 파트는 전통적인 On-Premises Computing과 Cloud Computing 서비스를 비교하면서 Cloud 환경으로 발전 모델을 알아보겠습니다.
Deployment Tasks
 image

위의 스키마는 Visual Studio에서 지원하는 Windows Azure SDK를 이용하여, Cloud project를 생성할 수 있고, Package를 Build하고 Publish할 수 있습니다.  이러한 Package와 Configuration File들은 Wndows Azure Developer Portal이나 Windows Azure API를 통해 Windows Azure Platform에 업로드되고 서비스가 시작되는 프로세스를 나타냅니다.

Application Lifecycle Management
일반적인 Deployment와 달리, Cloud 환경에서는 생성한 Code를 Cloud에 올리고 실제 서비스 환경과 동일한 VM에서 테스트를 아주 쉽게 할 수 있다는 것입니다. 
image

VIP-Swap
Local Development/Test 환경에서 Windows Azure platform으로 Code를 등록할때, Application은 Staging Phase에 배치되며, 그 후에 관리자는 Application을 Production에 작업할당을 지시하게 됩니다. 흥미로운것은 Windows Azure Platform에서 staging과 production 환경은 동일하다는 것입니다. 한가지 다른것이 있는데, 접속하는 URL만 다릅니다.
먼저 Staging Phase는 퍼블리싱이 불가능한 글자와 숫자로 조합된 URL(http://c2ek9aa346384629a3401e8119de3500.cloudapp.net/)을 제공받으며, Production은 Administrator에 의해 퍼블리싱이 가능한 URL로 할당받을 수 있습니다. Windows Azure platform에서 Staging 환경을 Production 환경으로 개발공정을 밟아가기 위해서는 Staging URL과 Production URL을 수시로 바꿔줘야 합니다. 이것을 VIP(Virtual IP) Swap이라고 하며, 두번의 마우스 클릭으로 URL을 수시로 변겨알 수 있습니다.

image

Application Architecture
Windows Azure Platform에서 on-premises computing을 Cloud service로 확장할 수 있는 방법론이 많이 있습니다. 하기의 Application Architecture는 On-premises의 Web Role 또는 Front-end에서 HTTP/HTTPS 통신을 통해 Cloud Service로 확장이 가능한 모델을 보여줍니다.image 

Standardizing Core Components
On-Premises에서나 Cloud에서나 필요한 구성 컴포넌트는 동일한것이나 다름없습니다. 즉 표준화가 만들어지고 있다는 것이지요.
다른 말로 표현하면 On-Premises환경에서 별도의 투자없이도 Cloud 환경으로 쉽게 바꿀 수 있습니다. 
image

Cost Model
기본적으로 Windows Azure Service에서 Data 진단은 Memory buffer에서 대기하고 있는 데이타를 기준으로 책정하며, 실제 서비스 데이타로 실행되는 데이타 기준이 아닙니다. Window Azure에서 Log data를 접근할 때, Log data가 Persistent Storage에 저장되어 있어야 합니다. Windows Azure Developer Portal에서 매뉴얼적으로 옮기거나, 또는 Application에 추가가 필요한 Code를 스케줄링을 걸어 Dump로 뜰 수도 있습니다. 그리고 나서, Azure Storage Explorer같은 Tool을 이용하여 Windows Azure Storage에에 저장되어 있는 Log Data를 찾아볼 수 있습니다.
On premises에서 운영되는 Application에서 Data 진단은 Local storage에 저장되어 있으므로 쉽게 접근/이동이 됩니다. 하지만 Cloud에서 Data는 더이상 Quo에 남아있지 않게됩니다. 이유는 위에서 설명한대로 Cloud에서 데이타사용에 대한 비용산정방식 때문이죠. IT 담당자들은 이러한 비용산정방식에 따라 서비스 운영 계획을 세워야 합니다.image

신고
Posted by 엠플 (주)엠플

Part 2에서 Cloud는 기업 사용자를 위한 비즈니스서비스 모델를 간략하게 설명했습니다. , 비즈니스의 연속성을 위한 “Anytime, Anywhere, Any device”를 실현할 수 있는 서비스 모델을 알아봤었습니다. 이러한 서비스 모델이 Cloud Computing에서 지향하는 모델이기도 합니다.

하지만 작금의 IT Technology는 현실적으로 "All thing Service"를 구현하기 힘든 상태입니다. 기업의 인프라를 보면 Server, Deskop, Application으로 크게 구분할 수 있는데, 통합적인 Serive가 아닌 개별적이고 부분적인 Service밖에 지원하지 못 하고 있습니다.

기업에서 Cloud Service로 가장 먼저 이슈가 되는 것이 Application Service입니다.
이번 Part 3에서는 통상적인 Application Service와 Cloud Service의 차이점에 대해 알아보고 효과적인 모델을 제시하겠습니다.

Traditional Computing Model
통상적인 3단계 Application 모델은 front-end, middle-tier, and back-end로 구성됩니다. Web Application을 예를 들면, Front-end는 Application을 직접 제공하는 Web Site입니다. Middle-tier는 Data를 가져올 수 있는 Back-end단의 스토리지와 커넥팅할 수 있는 Logic으로 구성됩니다. 그리고 Service의 최적화 및 고가용성을 위해 Load Balancers(LB) 및 Clustering이 기반하고 있습니다.

                                             [Typical 3-Tier APP Computing Model]

Cloud Computing Model
Microsoft Windows Azure는 Virtualizaition을 통한 가상 하드웨어를 서비스하는 Cloud-Based Compuging입니다. 통상적인 3-tier모델과 같이 중요한 3가지 Component, 즉, Compute, Storage, Fabric Controller입니다. Compute는 Application을 실행할 수 있는 Code를 뜻하고, Storage는 특정한 위치에 Data가 저장된 공간을 말합니다. Windows Azure에서 Compute와 Storage를 Role과 서비스로 부터 제공받은 Data로 돌려 말합니다. Role은 component가 잘 구동될 수 있도록 설정/관리해주는 Compoentn를 말하며, Fabric Controller은 어떤 Application이, 언제, 어디에서 잘 서비스되는지 모니터링할 수 있는 Subsystem입니다. Fabric Controller에 대해서는 Part 4에서 자세하게 얘기하도록 하겠습니다.

                                                   [Windows Azure Comuting Model]
 


Compute Service에는 Web Role, Worker Role, VM Role로 특화됩니다. Web Role은 Public Endpoint로 부터 요청되는 HTTP, HTTPS를 허용할 수 있도록 Virtual machine상에서 IIS를 실행시키는 역할입니다. Windows Azure에서 모든 Public Endpoint는 기본적으로 Load Balance가 지원됩니다.
반면에 Worker Role은 IIS와 별개로 Data Management 및 Data Function과 관련된 업무를 수행합니다. 예를 들어, Worker Role은 사용자의 요구에 특화된 Web Server 또는 Database Hosting을 수행하기 위해 필요하다고 볼 수 있습니다.

Role은 Queue 또는 Socket을 통해 메시지를 전달하고 통신하게 됩니다. 할당되는 Role의 역할은 Application의 configuration에 따라 결정되고, 각각의 Role은 독립적인 Virtual machine을 Windows Azure에 의해 할당 받습니다. 아래 그림은 Shopping list application을 통해 Windows Azure computing 동작모델을 보여줍니다.


                 [Shopping List Application on the Windows Azure Platform]

반면에 VM Role은 Virtual machine입니다. 개발자는 VM Role(VHD)에 Windows service, schedule task를 연동할 수 있으며, Application실행 환경을 쉽게 커스터마이징할 수 있습니다. 

VM Role은 깨지기 쉽거나 Auto 인스톨링이 아닌 요구를 쉽게 배포할 수 있도록 설계되어야 합니다. 또한, 기존 서비스 모델에서 마이그레이션이 용이하게 설계되어야 합니다. 참고적으로 Windows Azure VM Role을 만들고 배포하는 가이드는 아래 링크를 참조하십시요.
http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_vmrolelab_topic2.aspx

Storage service는 Binary, Text data, Message, Structured data를 제공해야 하며, Serivce는 크게 3가지로 구분됩니다.
첫째: Blob Service: Binary, Text data
둘째: Queue Service: Message
셋째: Table Service: Structured data

아래 그림은 Windows Azure BLOB Service를 모델을 설명합니다.

Fornt-end단의 Web Role은 HTTP/HTTPS의 요청을 받고 Worker Role은 ASP.net service와 같은 특정화된 작업을 수행할 수 있는 다양한 형태의 Storage를 제공할 수 있습니다.
참고로 기존 Data를 Clouding으로 마이그레이션 할 수 있는 SQL Azure를 이용하여 다양한 Storage service를 구축할 수 있습니다.
http://msdn.microsoft.com/en-us/windowsazure/sqlazure/cc512119

신고
Posted by 엠플 (주)엠플