블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

어제 발표된 Microsoft Azure의 IaaS 서비스와 Amazon의 AWS 서비스 사이에 가격 비교를 해봤다.

아래 내용은 네트워크 비용이나 Blob Storage 등 부가 서비스를 제외하고 EC2 서비스 만을 비교한 것이다.

 

 

요약 - Linux VM의 경우 동일, Windows VM의 경우 MS가 저렴

Linux VM의 경우 동등 인스턴스 크기에서는 Amazon과 Azure 양쪽 가격이 같다. Azure가 레퍼런스해서 만든 느낌이 가득하다. 

 

Azure 장점 

- Windows Server VM의 경우 Amazon 대비 저렴. Amazon은 Windows VM에 대해서 별도의 가격 정책을 책정하나, Azure의 경우 Linux와 Windows를 모두 동일하게 가져감

 

Azure 단점

- 인스턴스 종류가  XS,S,M,L,XL 로 4개로 한정, 이에 반면 Amazon은 용도에 맞게 High-Memory Instance, High CPU Instance, Cluster Compute Instance, Cluster GPU Instance등을 다양하게 제공

 

결론

Instance의 실제 성능이나 IO 성능등은 테스트해서 비교해봐야겠으나, 일단 가격 정책상으로는 서로 경쟁할만한 위치에 왔다고 보여짐.

 

참고 자료

AWS 가격 - http://www.ec2instances.info/

Azure 가격 - http://www.windowsazure.com/ko-kr/pricing/calculator/?scenario=virtual-machines

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

한마디로 이야기 하자면

- "대단한 서비스이다."

- "멀티미디어 컨텐츠에 대해서 End2End 시나리오를 지원한다."

- "독보적인 서비스이다"

 

주관적인 생각이지만 그만큼 가치가 있는 서비스라고 생각한다.

2012년 6월8일 한국 시간 오전 5시에 Windows Azure의 새 버전이 발표되었다. 여기에 클라우드 서비스로 추가된 것이 'Windows Azure Media Services"이다.

 

이 서비스의 시나리오를 요약하자면

1) [업로드] 컨텐츠 사업자가 Azure에 멀티미디어 컨텐츠를 업로드 하면,

2) [워크플로우] 사용자가 정한 컨텐츠 처리 로직을 수행하게 되는데

3) [인코딩] 컨텐츠를 필요한 포맷으로 인코딩 하고

4) [Ingestion] 각종 후처리 (광고 삽입,메타데이타 추출등)를 거치고

5) [DRM] 필요에 따라 컨텐츠에 DRM을 삽입해준다.

6) [저장] 이렇게 후처리가 끝난 컨텐츠들은 Azure에 저장이 되고

7) [배포] 사용자가 원하는 시스템으로 컨텐츠를 전송하거나 또는 CDN으로 배포가 된다.

8) [서비스] 이렇게 배포된 서비스는 Azure에서 제공하는 CDN을 통해서 Streaming 서비스가 가능하게 된다.

9) [Adaptive Streaming] Streaming시에 단말 사용자가 접속한 인터넷 회선 사항에 따라서 컨텐츠의 인코딩 품질을 조정하면서 끊김없는 동영상 서비스를 가능하게 한다.

10) [클라이언트 지원] Streaming등의 컨텐츠 서비스를 위해서 윈도우즈 플랫폼 뿐만 아니라 애플 iOS 플랫폼용 SDK까지 제공하여, 단말 개발까지 지원한다.

 

위에서 시나리오를 설명하였지만, 한마디로 멀티미디어 컨텐츠 생성을 제외한 저장,후처리,스트리밍 서비스 및 개발 지원까지의 Full 시나리오를 지원하며, 워크 플로우를 통해서 컨텐츠 후처리 로직을 다양하게 설정할 수 있다.

 

이번 Azure 업그레이드에서 주목할만한점중 하나는 "개방성"인데, Media Services에도 이 개방성의 사상이 반영 되었다. 즉, DRM, CDN등에 대해서 Third Party Solution과 Integration이 가능하다. CDN은 Akamai를 Streaming 서비스는 Wowza를 DRM에는 BuyDRM,EZDRM들을 이미 지원하고 있다.

 

아직 정식 서비스가 아닌 시범 서비스 단계이기는 하지만 멀티미디어 컨텐츠 서비스를 위한 강력한 클라우드 서비스 플랫폼임에는 틀림이 없고, 비용이 많이 들고 복잡도가 높은 멀티미디어 서비스를 클라우드 환경에서 플랫폼 형태로 제공함으로써 많은 사용자 서비스를 만들어내는데 기여할것으로 기대된다.

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 

내일 오전 5시에(한국시간) Azure 새버전이 발표됩니다.

아마존 서비스에 반격을 하기 위해서, 그리고 이제 개발자나 시장의 상황을 어느정도 인지한 듯한 모양을 보입니다.

기존의 윈도우와 .NET만 지원하던 환경에서

Linux 지원과 Java,Python등의 다른 개발 플랫폼 까지 지원하게 된것이 가장 큰 특징이라고 볼 수 있습니다.

글로벌하게 제대로된 IaaS가 AWS 밖에 없었다면 강력한 경쟁 체재가 생기게 된것입니다.

(이럴줄 알았으면 MS에 계속 있을 걸 그랬습니다.)

 

일단 주목할만한 특징들을 살펴보면

1. IaaS 제공 - Windows Server 뿐만 아니라, CentOS,Ubuntu,Suse Linux 제공

o   Windows Server

§  Windows Server 2008 R2

§  Windows Server 2008 R2 with SQL Server 2012 Eval

§  Windows Server 2012 RC

o   Linux

§  OpenSUSE 12.1

§  CentOS-6.2

§  Ubuntu 12.04

§  SUSE Linux Enterprise Server 11 SP2

2. Azure 서비스에 대해 Python과 Java 지원

Azure의 Queue 서비스, BlobStorage 등등의 기반 서비스들을 접근할 수 있는 Java와 Python SDK를 지원합니다.

 

위의 두가지만으로도 AWS와 어느정도 동등한 수준의 서비스를 제공할 수 있을 것으로 보입니다. 물론 세세한 서비스 기능들은 차이가 있겠지만요

 

3. 새로운 서비스 기능 추가

1) Memcached와 같은 프로토콜을 사용하는 캐쉬 서비스가 추가 되었습니다.

2) Media Service라는 것이 추가 되었는데, 정확한 실체는 분석해봐야 알겠지만, Multimedia Contents에 대한 Streaming CDN이 포함되는 것으로 알고 있습니다. Streaming CDN이란 기존의 CDN이 정적 컨텐츠만 캐슁하여 서비스하는데 반해, 동영상이나 음악을 Streaming해주는 서버를 Edge 서버에 위치 시키고 서비스 해주는 기능을 제공한다.

 기존의 CDN이나 이 Streaming CDN은 Akamai가 주로 제공하는데 상당히 고가이고, AWS의 CDN서비스는 Akamai등에 비해서 Edge Node의 수가 부족하여 충분한 성능 발휘가 어렵고 멀티미디어 컨텐츠를 지원하지 않는 단점이 있었다.

 Microsoft의 경우, 인터넷 회선 보유양이 전세계 3위정도로 상당한 네트워크를 가지고 있기 때문에, 높은 수준의 CDN 서비스를 클라우드 환경에서 제공할 것으로 기대된다.

3) 흥미로운 기능중에 하나가 MongoDB 지원성에 대한 언급이 있는데

"Microsoft also announced the availability of the Eclipse plugin for Java, MongoDB integration, Memcached using non-.NET languages, and code configuration for hosting Solr/Lucene. Developers can find out more in the new Windows Azure Developer Center, which includes additional information, tutorials, samples and application templates to quickly get started and create differentiated cloud scenarios."

실제로 MongoDB를 Azure 안쪽에서 서비스로 위치 시킨것인지 단순하게 SDK만 지원하는지는 열어봐야 겠지만 오픈 소스 NoSQL에 대한 지원을 시작한 점은 고무적이다.

 

결론

이번 업그레이드에서 Linux지원과 Java지원은 방향성은 제대로 잡았다.

그러나 이게 그냥 형식적인 구색갖추기인지, 아니면 본격적인 개방형 클라우드 기술 적용인지는 3~4개월은 지나봐야 알겠지만, 고객입장에서는 AWS이외에 글로벌 서비스 능력을 가진 새로운 IaaS가 생긴것만으로도 선택의 폭은 넓어졌다고 본다.

 

참고 자료

http://www.microsoft.com/en-us/news/download/presskits/cloud/docs/MeetWindowsAzureFS.docx

Azure 런칭 행사 웹사이트 : http://www.meetwindowsazure.com/

 

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
요즘 일이 바뻐서 블로그 포스팅을 거의 못하고 있습니다.
많이 버는 만큼, 그동안 충전해왔던 지식이나 노하우를 주로 방전하는 느낌입니다.

어쨌거나, 클라우드의 양대 산맥인 아마존 AWS와 Microsoft Azure에 대한 이야기를 해보려고 하는데..
Azure vs AWS의 승자가 누구이냐? 인데. 결론 부터 이야기 하면 AWS의 손을 들어주고 싶습니다.
Blob Storage나 DB 서비스와 같은 액세사리성 서비스는 양쪽다 어느정도 구색을 갖춰 놨다고 했을 때, 핵심인 Compute Service가 문제인데.
기본적으로 Azure는 .NET 기반의 PaaS만 지원하지만, Amazon은 모든 플랫폼을 올릴 수 있는 IaaS 수준 서비스를 제공합니다.
이말인즉슨, 내가 필요한 소프트웨어를 마음대로 올릴 수 있다는 겁니다. 단순하게 Java냐, .Net이냐 차이가 아니라
서비스를 하다보면 NFS가 필요할 수 도 있고, 제공해주는 NoSQL 서비스의 성능 문제로, Mongo나 Cassandra를 쓰고 싶을 수 도 있고, 빌드 환경을 만들어보고 싶을 수 도 있고, 여러가지 요구 사항이 존재하는데, Azure는 그게 안되고, 그냥 딱!! .NET 개발만 해야 한다는 것인데, 단순한 웹 애플리케이션 시나리오라면 모르겠지만
요즘과 같이 빅데이타나 분산 아키텍쳐가 유행하는 시절에 이것만으로는 부족하다는 말입니다.

기술적으로 Azure가 상당히 뛰어난점도 많은데, IaaS 단으로 오픈을해서, 조금 더 선택의 폭을 넓혀 줬으면 합니다.
이상 사견이었습니다.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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가 가진 특징 이외에 기업 특성에 맞춰진 형태의 아키텍쳐 구성이 가능하다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

서비스를 고객에게 제공하다 보면 바이너리 파일이 다운되는 시나리오가 많습니다.
웹사이트에서 이미지,CSS를 다운로드 하는 것은 가장 기본 적인 시나리오이고
사진 저장 및 다운로드, 영화 파일, 또는 일반 파일 다운로드 등이 그 대표적인 시나리오인데, 이런 것들을 사용자 응답시간에 아주 결정적인 영향을 미칩니다.
이런 것을 해결하기 위한것이 CDN (Contents Delivery Network)입니다. 개념은 간단하게 각 지역에 일종의 캐쉬서버를 놓고, 지역이 멀어서 발생하는 네트워크 지연을 해결하겠다는 개념입니다. 전세계적으로 Akamai가 대표적인 CDN 서비스 벤더이지요.
클라우드를 통한 서비스의 경우 아무래도 시스템이 전세계의 어딘가에 배포되어 있기 때문에 서비스 대상이 되는 지역에 서버가 없을 경우 응답속도가 느려질 수 밖에 없고, CDN의 필요성이 높게 대두 됩니다.

Windows Azure에서는 CDN 서비스를 제공하는데, Windows Azure Storage Service의 Blob Storage와 연동하여 서비스를 제공합니다.
또한 아래 그림과 같이 총 22개 지역의 데이타 센터를 통해서 CDN 서비스를 제공하기 때문에 상당히 넓은 커버리지를 자랑합니다.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Windows Azure Compute

AzureAmazon EC2와 같은 OS를 통째로 올리는 Iaas와 같은 클라우드 서비스가 아니라, 애플리케이션을 개발 및 배포할 수 있는 Paas(Platform As A Service)와 같은 개념을 가지고 있다. 쉽게 생각하면 Windows Azure는 일종의 Web Application Server (WAS) 개념으로 생각하면 된다.

Web Role & Worker Role

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

Web RoleASP.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 ServiceQueue Service를 이용해서, Worker Role에 작업을 분산 지정할 수 있고, Storage ServiceBlob이나 Table Storage를 이용하여 작업 내용을 저장할 수 있다.

VM Role

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

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
아무래도 전직이 자바 개발자인지라, Azure를 봐도 자바 지원 여부를 보게 되는데, 재미있는 자료를 몇가지 찾아서 첨부한다.


위의 동영상은 Windows Azure Platform 위에서 Tomcat을 구동 시킬 수 있는 방법에 대한 글이다. 이클립스 연동도 되고 대충 쓸만해 보인다. 일반적인 웹 애플리케이션은 그럭저럭 기동 시킬 수 있을 텐데.. 앞뒤에 붙는 Apache Http 서버라던가, Jennifer와 같은 APM은 아마 적용하기 힘들것 같고, Thread Dump를 이용한 Trace라던가 JVM 튜닝 같은 내용의 적용이 쉽지 않아 보인다. 그냥 일반 서비스성 웹애플리케이션이나 이벤트성 서비스에는 그럭저럭 쓸 수 있을 듯 한데, 상용 서비스에서는 글쎄....??

이건 Azure Storage Service들을 Java에서 사용할 수 있는 API SET
http://www.interoperabilitybridges.com/projects/windows-azure-sdk-for-java.aspx
어짜피 Azure는 REST를 지원하니 Java나 PHP,Ruby등에서 당연 사용할 수 있는 것이지만, Library Set을 지원하니 훨씬 개발하기 편한듯 하다. 샘플 코드를 보니 정말 편한데..
아무래도 대용량 데이타를 유지 관리해야 하는 서비스나, BLOB과 같은 데이타를 유지해야 하는 서비스들에 대해서는 충분히 승산이 있을듯.

Amazon EC2에는 AMI로 해서 WebLogic까지 싸악 올릴 수 있군요.
http://www.theserverlabs.com/blog/2009/05/29/setting-up-a-load-balanced-oracle-weblogic-cluster-in-amazon-ec2/
멋집니다. 라이센스를 얼마나 받을 련지 몰겠습니다마나.


신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Windows Azure AppFabric Service Bus

Azure 클라우드에는 AppFabric이라는 또 하나의 서비스가 있습니다. 간략하게 설명하자면 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합입니다. 그 중에서 이번에는 Service Bus에 대해서 설명해보겠습니다.
사실 이 Service Bus를 이해하는데 다소 시간이 걸렸습니다. 왜냐하면 제 기술적인 백그라운드가 SOA이고, 그 중 가장 중요한 컴포넌트 중 하나가 Enterprise Service Bus (ESB)니까요. 그런데 Azure의 Service Bus 개념은 약간 다릅니다. Internet Service Bus (ISB)라는 개념으로 설명을 하더군요.
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)를 이용해서 접근합니다.
 
일단 이렇게 해서 타 플랫폼과의 상호 운용성을 확보해주는 방법인데, Native WCF를 써서 SOAP이나 REST를 쓰는 것에 비해서 어떤 장점이 있는지는 좀 봐야 알 수 있을 것 같습니다.

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의 모듈 중 하나인 Azure Service Bus에 대해서 살펴봤고, 다음 글에서는 AppFabric의 Work Flow 모듈과 보안 모듈(ACS)에 대해서 살펴보겠다.
 


대충 위와 같은 개념인데, ACS가 계정에 대한 통합 역할을 하는 셈입니다.
ACS는 SAML등과 같은 표준을 지원하기는 하지만 Active Directory를 잘 지원합니다. 기업의 계정 시스템이 Active Directory 기반이라면 아주 쉽게 통합이 된다는 겁니다.
그 외에도 Facebook, Open ID와 같은 SNS 기반의 ID 체계와도 통합 로그인을 할 수 있는 Feature를 제공하고 있습니다.
ACS에 대한 내용은 나중에 좀 더 알아보도록 하겠습니다.

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Azure Data Storage Service

요즘 어찌어찌 해서, 클라우드쪽과 특히 마이크로소프트의 클라우드 플랫폼인 Azure 쪽을 보고 있는데, 상당히 흥미롭다. 국내 기업을 대상으로 서비스를 제공하고 있지 않고 국내에 .NET 개발자층이 자바쪽에 비해서 두텁지 않은 관계로, 크게 이슈화는 못 되어가고 있는 것 같지만 기술적인 관점에서는 상당히 흥미롭다. Azure를 한마디로 이야기 하자면 넣을 수 있는 건 정말 다 넣었다. CRM,Exchange 등등과 같은 소프트웨어 서비스 기반의 Saas에서부터 Windows 기반의 Iaas 까지, 거기에 SNS 통합 인증, Windows Live Service등에서 제공되는 OPEN API Integration까지 참 많기는 많다.

하여간 자세한 이야기는 나중에 올리도록 하고, 오늘은 Azure Platform의 데이터 저장 서비스에 대해서 알아보고자 한다.

기업이 클라우드를 사용하려는 근본적인 이유와, 모든 클라우드 업체들이 내세우는 클라우드의 장점은 결국 비용이다. 쓴 만큼 지불하는 비용 구조를 제공하겠다는 것인데, 컴퓨팅에서 비용은 결국 컴퓨팅 파워 (CPU)와 저장소(Storage)비용이다. 그래서 클라우드 서비스들은 강력한 Storage 서비스등을 제공한다. Amazon도 SimpleDB,S3,EBS,RDS,SQS(엄밀하게는 Queue 서비스) 등의 다양한 서비스를 제공하고 있고, Microsoft의 Azure역시 다양한 형태의 Storage 서비스를 제공한다. 일반적으로 클라우드 상의 Storage 서비스는 RDBMS 처럼 OLTP를 지원하기 위한 고급 Feature들 보다는 대용량의 데이터를 저장할 수 있는 Scalability와 대용량 데이터를 Handling할 수 있는 Performance 에 초점이 맞춰져 있다.

일단 Microsoft의 Azure의 Storage 서비스를 보면 크게 아래와 같이 5가지 형태의 서비스를 제공한다.


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


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

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


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

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

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

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


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

SQL Azure
마지막으로 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를 통한 지역간 복제는 아무래도 복제 아키텍쳐를 스케쥴 기반으로 설계해야 한다.

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바