Microsoft 클라우드 서비스 Azure에 대한 소개

Microsoft Cloud Platform은 전통적인 Iaas,Paas 뿐만 아니라 그위에 CRM ,Exchange ,Office ,SharePoint 등 다양한 형태의 소프트웨어를 서비스 형태로 제공하고, Xbox Live나 Windows Live와 같은 애플리케이션 서비스도 제공한다. 그러나 본 문서에서는 전체 Microsoft Cloud에 대한 설명을 하는 것이 아니라 엔터프라이즈 애플리케이션 개발과 배포를 위한 클라우드에 대한 부분에 초점을 맞추기 때문에, Paas 인 Microsoft Windows Azure에 대해서 설명하도록 한다.

Azure Compute

Azure는 기본적으로 Paas 형의 클라우드다. Iaas 형태의 클라우드가 OS까지만 제공한다면, Paas형태의 클라우드는 아래 그림과 같이 애플리케이션을 수행 할 수 있는 Runtime과 각종 Middleware (Web Application Server, DBMS, Service Bus etc)등을 포함해서 서비스로 제공한다.

Iaas의 경우에는 이렇게 사전 제공되는 형태의 플랫폼이 없기 때문에 고객 마음대로 플랫폼을 설치 구성할 수 있기 때문에 요구사항에 대한 유연성이 매우 높지만, 반대로 플랫폼에 대한 구입,설치 및 설정과 유지보수에 대해서는 모두 고객이 책임져야 하기 때문에 그만큼 비용과 관리 인력,시간이 소요된다.

 Azure는 Paas형태의 클라우드 서비스로 .NET 기반의 플랫폼과 Microsoft 기반의 미들웨어는 물론이고, PHP,JAVA와 같은 다른 기술을 지원할 수 있는 플랫폼 서비스를 제공한다.

<그림. Iaas와 Paas의 차이 >

 

Web Role & Worker Role

이러한 애플리케이션 서비스 모델을 Azure Compute라고 하고, 각 구체적은 서비스 모델에 따라서 ‘Role’이라는 개념으로 정의되는데, 크게 “Web Role”과 “Worker Role” 로 분리된다.

Web Role은 ASP.NET 기반의 웹 애플리케이션 서비스를 하기 위한 프로세스 모델로 생각하면 된다. IIS(Internet Information Server)내에서 기동이 된다.
 Worker Role은 백 그라운드 작업을 하기 위한 Role로 생각하면 된다. HTTP 인터페이스를 가지지 않고 TCP나 Q등을 통해서 Invoke가 되고, Windows Server의 서비스 프로세스로 기동된다.
Web Role 자체는 추가적인 설명이 필요 없을 듯 하고, Worker Role은 일종의 Unix Process(?)와 유사한 개념으로 생각하면 되는데, 자바 진영의 MDB (Message Driven Bean)과 같은 개념으로도 사용될 수 있고, TP Monitor들의 서비스 프로세스와 같은 개념으로도 사용될 수 있다.

흥미로운 것 중의 하나는 Worker Role을 이용하여 요즘 유행하는 Map & Reduce (하나의 거대 작업을 작은 단위로 나눠서 패레럴 하게 처리한 후 합쳐서, 전체 성능을 끌어올리는 알고리즘) 을 구현할 수 있다. Map & Reduce를 수행하기 위해서는 앞단에서 작업을 분배해주는 작업 큐와, 작업 내용을 저장할 저장소가 필요한데, 이는 Windows Azure의 Storage Service의 Queue Service를 이용해서, 각 Worker Role에 작업을 분산 지정할 수 있고, Storage Service의 Blob이나 Table Storage를 이용하여 작업 내용을 저장할 수 있다.

VM Role

이번에 PDC 2010에서 새로 발표된 Role로써는 VM Role이 있다. Amazon EC2의 AMI와 같은 형태의 Iaas 서비스라고 생각하면 된다. VM Role 이전에 Windows Azure는 Paas 성격이 강했으나, 이번 VM Role의 추가로, Windows 기반의 Iaas 서비스가 가능하게 되었다. OS의 Virtual Machine Image를 통째로 VM Role에 올려서 독립적인 OS를 사용할 수 있다.

장점중의 하나는 Windows Server 2008로 운영하고 있는 on premise 시스템을 통째로 이미지로 떠서 그대로 Azure Compute의 VM Role에 옮겨서 운영할 수 있다는 것이다. Windows Server Base 라면 한번에 클라우드로 전환이 가능하게 된다.

Blob Storage Service

다음은 Blob Storage이다. 이미지,동영상 또는 큰 사이즈의 Binary 데이터등을 저장하는데 사용되는 서비스이다.

특징은 대용량의 저장성을 보장하고, 특히 CDN (Contents Distribution Network – 일종의 웹캐슁 서비스와 비슷하게 생각하면 된다. 각 지역 마다 캐쉬 서버를 두고 컨텐츠를 그 캐쉬 서버에 복제해서 지역적인 차이로 인한 다운로드 속도를 절감해준다.)과의 연동을 통해서 Blob Data를 원거리에서 접근하는데 성능을 보장한다.

SNS 서비스에서 이미지,동영상 저장 서비스나, 일반 기업에서 Archiving 서비스 (경비 지출서에 영수증등을 스캔해서 몇 년동안 저장해야 하는 기업 내부 규정)등에 유용하게 사용될 수 있다.

Table Storage Service

말 그대로 테이블 형태로 데이터를 저장한다. 사용자당 여러 개의 테이블을 소유할 수 있으며, 각 테이블은 다수의 컬럼으로 정의된 행을 포함한다. 그냥 편하게 RDBMS의 하나의 테이블이나, 엑셀 테이블 하나 생각하면 된다.

(데이터 구조에 대한 설명은 Apache Cassandra와 유사하기 때문에 http://bcho.tistory.com/440 문서를 참고하기 바란다.)

그런데 이미 RDBMS나 다른 곳에서도 제공하는 테이블 데이터 구조를 왜 따로 정의했을까? 쉽게 생각하면 요즘 유행하는 NoSQL과 비슷한 사상으로 생각하면 된다. 복잡한 관계형 구조나 Query가 필요 없지만 데이터의 양이 상당히 크고 고성능의 접근성이 요구될 때 사용된다. 트위터가 데이타를 Cassandra와 같은 NoSQL DB에 저장하고 사용하는 것과 같이 이유이다. Amazon의 SimpleDB와 유사한 서비스로 생각하면 된다.

Queue Storage Service

Queue Storage는 우리가 일반적으로 프로그래밍에서 사용하는 Queue를 생각하면 된다. IBM의 MQ나 Java의 JMS와 같은 개념이다.

이러한 Queuing 서비스는 비동기식 처리 방식의 아키텍쳐를 구현할 때 매우 편리한데, 예를 들어 월말 정산을 한다던지, 리포트 생성과 같은 배치 처리를 하고자 할 때, 화면에서 Request를 받고 백그라운드에서 처리를 할 때 유용하게 사용된다. 자바에서 JMS – Message Driven Bean(EJB)와 같은 아키텍쳐를 구축할 수 있다.

Azure Drive

Disk Storage 서비스는 Blob Storage 서비스를 Disk로 Mount 해놓은 서비스이다. Blob Storage가 API를 통해서 접근한다면, Disk Storage는 Application 입장에서는 하나의 물리적인 디스크로 인식하고 접근할 수 있다. 접근 성능을 높이기 위해서 Local VM에 (Windows Virtual Machine) Local Cache를 둬서 성능을 보장한다.

SQL Azure

MS SQL Azure는 쉽게 이해하면 MS SQL RDBMS를 통째로 클라우드에 올려놨다고 생각하면 된다. RDBMS를 클라우드에서 사용할 수 있는 것이다. Amazon의 경우 EC2에 Oracle 이미지를 올려놓고 사용할 수 있지만 클라우드 플랫폼 자체에 녹여놨다고 보기는 약간 어렵지 않을까?

SQL Azure 서비스 중에 하나 중 재미있는 것은 MS SQL Azure 노드간의 데이터 동기화나 MS SQL Azure 노드와 기업내의 SQL 서버간의 데이터 동기화가 가능하다. MS SQL 제품 내부에는 CDC (Change Data Capture) 기능을 가지고 있는데, 아마 이 모듈을 사용해서 구축된 듯하다. 이서비스의 이름은 SQL Azure Data Sync Service로, 이 CDC 기능을 쉽게 Wrapping해놔서, Web UI상에서 복제할 MS SQL Instance를 선택하고, 테이블을 선택하면 자동으로 복제가 진행된다. 아무래도 센터간 복제이기 때문에 실시간 복제는 불가능하리라 생각하고, 아래 동영상을 보니 스케쥴 기반으로 복제를 진행한다.

아래 동영상의 시연을 보면 약 1132건의 트렌젝션 (테이블 생성에서부터, 복제등을 포함해서) 미국에서 유럽 센터간 동기화를 수행하는데 11.4초 정도가 소요된다.

기업 내부에서 CDC를 통해서 데이터 베이스를 동기화 하는 경우는 근 실시간으로 이루어 지는데, Azure Data Sync Service를 통한 지역간 복제는 아무래도 복제 아키텍쳐를 스케쥴 기반으로 설계해야 한다.

AppFabric Service Bus

AppFabric Service Bus는 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합이다.

SOA에서 사용되는 Enterprise Service Bus가 Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing 및 Transformation에 집중을 한다면, Internet Service Bus는 Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있다. 보안과 Message Routing,Transformation은 AppFabric내의 다른 서비스 (ACS와 WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 한다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 한다.

Message Relay

앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 한다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 사상이다.

여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 필요한가? 보통 J2EE의 WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있다. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용한다.

아키텍쳐는 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입이다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없다.

 

Direct Connection

다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 성능이 저하된다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없다. (NAT에 의해서 변경이 되기 때문에)

이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음 번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려준다. 이 기법은 주로 인터넷 메신져에서 많이 사용되는 아키텍쳐로, 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 하도록 한다.

Message Buffer

위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService나 REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하다. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용한다.

이러한 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었는데, 그것이 Message Buffer 이다. 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받는다. 다른 플랫폼들은 Message Buffer에 REST (XML/HTTP)를 이용해서 접근한다.

 

Message Exchange Pattern 변환

먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus는 API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.

조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.

http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원

처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.

Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있다.

쉽게 정리해서 보자면 “클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 이다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘이다.

AppFabric Cache

AppFabric Cache는 전통적인 애플리케이션의 Cache 기능과 함께, 데이터 교환을 위한 데이터 버스 사용 시나리오 두 가지를 지원한다.

전통적인 Cache 시나리오는 DB Query 결과에 대한 Cache나 웹페이지에 대한 Cache 등을 지원할 수 있는데, 특히 웹페이지에 대한 Caching의 경우 기존 페이지를 변경하지 않고 코드 변경 없이 손쉽게 적용할 수 있기 때문에 짧은 노력으로 성능 향상과 함께, Transaction 을 절약함으로써, 하드웨어 자원을 절약할 수 있다

또한 AppFabric Cache는 클러스터 구조를 통해서 수평적으로 무제한 확장이 가능하며, Cache의 크기도 운영중에 Dynamic하게 늘이거나 줄이는 것이 가능하다.

데이터 버스로는 Cache가 여러 Instance간에 접근이 가능하고, 그 접근 속도가 매우 빠르기 때문에, Web Session공유나 Instance간의 데이터 공유의 용도로 사용될 수 가 있다. 기존의 On-premise 시스템에서는 오픈소스인 memcached나, Oracle의 Coherence, MS의 Windows Server AppFabric Cache등을 사용하여 이러한 아키텍쳐를 구현하였는데,클라우드에 이 개념을 도입함으로써 특히나 어려운 클라우드 상의 Instance간의 데이터 교환을 지원할 수 있게 되었다.

AppFabric Integration

On-premise 시스템과의 통합에 있어서 네트워크 회선상의 문제뿐만 아니라, ERP,CRM등과 같은 패키지 소프트웨어에 대한 통합이 또 다른 문제로 작용한다. 이러한 패키지 소프트웨어등은 고유의 기술 (SAP ABAP , Tuxedo ATMI etc)을 사용하기 때문에 이러한 시스템과 연동을 위해서는 별도의 테크놀로지 아답터가 필요하다. 또한 통합을 지원하기 위해서는 복잡한 Process,메시지에 대한 변환, 로깅 및 추적등의 기능이 필요한데, 이러한 영역은 전통적으로 On premise 시스템에서는 EAI(Enterprise Application Integration)을 통해서 해결되어 왔다.

 Windows Azure에서는 이러한 EAI의 요건을 충족하는 Microsoft의 BizTalk을 클라우드에 서비스화함으로써, Cloud 시스템과 On-premise의 패키지 소프트웨어에 대한 통합을 지원하게 되었고, BAM (Business Activity Monitoring) 기능을 지원함으로써, 통합 과정에서 수행되는 프로세스 각 단계에 대한 모니터링을 가능하게 해준다.

 또한 기업간 연동을 위한 B2B Connector를 제공하며, B2B 연동에 필요한 Trading Partner 관리등의 기능을 제공한다.

AppFabric ACS (Access Control Service)

ACS 서비스는 클라우드 내에서 사용되는 계정 체계와 권한 체계에 대한 관리를 담당하고, 타 시스템 (FaceBook과 같은 온라인 서비스나, on-premise 서비스내의 계정권한 시스템)과의 통합을 지원한다.

ACS 는 Active Directory를 근간으로 되어 있으며, 사용자 또는 그룹에 따라서 시스템에 대한 접근 권한을 설정할 수 있다. On premise 시스템에 배포된 Active Directory나 또는 다른 계정 관리 시스템과 통합할 수 있는 인터페이스를 지원하며, X.509등의 여러 credential을 지원한다.

Composite Applications

이번 PDC 2010에 발표된 새로운 서비스로, Azure내의 각종 서비스들을 Composite하여 새로운 서비스를 제공할 수 있는 기능이다. 흔히 WEB 2.0에서 말하는 Mash up과 같은 개념의 서비스로 (Yahoo의 Pipe와 같은 개념). Azure Integration Service가 복잡하고 Stateful한 Orchestration과 Package Software에 대한 Native 프로토콜을 이용한 Integration을  담당한다면, Composite 서비스는 표준 서비스 인터페이스 (REST,SOAP etc)를 기반으로 한 Mediation 기반의 Composition을 지원한다.

 또한 Azure의 Composite 서비스는 단순히 Composition만을 지원하는 것이 아니라 Composite 되는 Workflow구간에 대한 모니터링과 디버깅을 지원하며 Metering 지원을 통해서 사용량 측정(과금이 필요한 경우 과금 기반 자료로 사용 가능)등의 서비스를 제공한다.

Map & Reduce on Azure

다음으로 근래에 구글등의 업체가 검색 기술 향상을 위해서 분산 파일을 기본으로 한 분산 처리 기술인 Map & Reduce를 많이 언급하고 있는데, 이는 하나의 큰 작업을 여러 개의 작업으로 나눠서 작은 컴퓨터에서 처리한 후에 하나로 합해서 PC급의 컴퓨터 여러대를 이용해서 한대의 수퍼컴퓨터와 같은 성능을 내는 아키텍쳐이다.

이미 Amazon은 오픈 소스인 Hadoop을 기반으로 해서 이 Map & Reduce 를 서비스하고 있는데, Map & Reduce는 정확하게는 Hadoop이라는 솔루션이 아니라 아키텍쳐이자 알고리즘이다. 그래서 Azure에서도 Map & Reduce가 구현이 가능하고, 사례가 있는데, Map & Reduce를 구현하는 Reference Architecture를 설명하면 다음과 같다.

o    Map 단계

먼저 처리하고자 하는 데이터를 Blob Storage에 업로드한후 Worker Role을 통해서 작업을 지시한다.

Worker Role은 작업을 작은 조각으로 나누고, 작업 명령을 Queue에 저장한다. (Queue Storage Service 이용)

o    Compute 단계

작업을 수행하는 각각의 Worker Role들은 Queue에서 작업을 하나씩 꺼내고, 처리할 데이타를 Input Data가 저장된 Storage에서 꺼내서 작업 및 계산을 수행한다.

o    Reduce 단계

작업이 끝나면 작업이 끝났다는 내용을 Output Queue에 저장하고 OutPut을 담당하는 Worker Role이 Queue에서 작업이 끝났다는 내용을 하나씩 받아서, 위에서 계산이 저장된 각각의 Blob Storage로부터 작업 결과를 읽어서 합치는 계산을 수행한다.

이 구조에서 Compute (계산)을 담당하는 Worker Role의 수를 탄력적으로 조정하여 Computing Power를 조절할 수 있다.

 이러한 기법은 검색 결과에 대한 계산 (Indexing등), 3D 그래픽 렌더링, 대규모 수학계산, 분석에 응용이 가능하다.

Azure CDN

Azure역시 CDN 서비스를 제공하는데, 전세계 22개의 CDN 센터를 두고 Blob Storage와 연계하여 대용량 데이터에 대한 지역 차이로 오는 Latency를 극복할 수 있도록 해준다.

Azure Connect (cf. Amazon VPC)

Amazon VPC와 유사한 개념의 서비스로, On premise 시스템과 Cloud 서비스간의 연동을 위해서 Secure된 VPN 네트워크를 제공하여 고객에게 Private Cloud 서비스를 제공한다.

이 VPN망은 Private Cloud 서비스를 사용하기 위해서도 사용될 수 있지만, 개발자나 관리자를 위한 관리 인터페이스 접근을 위한 VPN으로, 또는 SQL Azure와 같은 데이터 접근시 보안을 필요로하는 경우 등에 응용되어 사용될 수 있다.

Platform Compatibility

Azure는 Paas인 만큼 어떤 플랫폼을 지원하는지를 확인할 필요가 있는데, Microsoft의 클라우드 플랫폼임에도 불구하고 MS기술만 지원하지는 않는다.

기본적으로 Azure 클라우드에 배포된 각종 기능 (Storage,SQL,AppFabric)등은 Microsoft .NET, Java, PHP,그리고 Ruby Client SDK를 지원하고 있고, 서버쪽에서도 애플리케이션 플랫폼으로는 .NET 뿐만 아니라, PHP와 Apache Tomcat기반의 Java 개발환경을 지원한다. 데이터베이스 관점에서는 MS SQL이외에 MSQL을 함께 지원한다.

PDC 2010에서는 Microsoft에서 향후 Azure에 대해서 개방형 플랫폼 지원을 확장할것이며 특히 Tomcat 기반의 지원을 통해서 Java를 Azure의 First Citizen으로 만들겠다는 Vision을 발표하였다.

Azure Appliance

Microsoft의 Azure가 흥미로운 점 중의 하나는 Azure Platform 자체를 하드웨어를 포함하여 컨테이너 방식으로 직접 고객에게 판매한다는 것이다. Azure Appliance 라는 상품명인데, 아직 현재 테스트중이고 구체적인 판매 가격 등은 미정인 상태지만, eBay를 비롯하여 DELL,HP,Fujitsh 등을 대상으로 고객 테스트를 진행중이다.

Azure Appliance는 Azure를 운영하기 위한 서버,네트워크 장비,공조시설,전원등이 일체형으로 설계되어 있고, Azure Paas까지 모두 인스톨되어 있는 모델로, 컨테이너를 설치와 즉시 전원 공급만으로 운영이 가능하다.

Azure Appliance를 고객사에서 사용할 경우 Azure Platform을 Private Cloud형태로 사용하거나 Public Cloud 형태로 다른 고객에게 서비스할 수 있다. 또한 Azure Appliance에 배포된 Application은 Microsoft Azure와 동일 아키텍쳐를 가지고 있기 때문에 필요에 따라서 Microsoft Azure Platform으로 손쉽게 Migration이 될 수 있다. Azure Appliance에 대한 플랫폼 유지보수와 업그레이드 역시 Microsoft 본사를 통해서 직접 이루어지기 때문에 플랫폼 운영에 대한 비용과 시간 역시 절약할 수 있다는 장점을 가질 수 있다.

 

Azure Appliance는 위의 그림에서 보는 바와 같이 Public Azure가 가진 특징 이외에 기업 특성에 맞춰진 형태의 아키텍쳐 구성이 가능하다.