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


Archive»


 
 
요즘 오픈 소스 기반의 클라우드 솔루션을 보다 보니 트렌드가 많이 변했다고 느끼는데, 그중 하나가 Cross-Cloud-Management이다.

Microsoft의 경우 Concero라는 코드명으로 Private Cloud와 Azure 기반의 Public Cloud를 동시에 관리하는 기능을 제공하는데, 예를 들어 관리자가 Application을 만들고 Private Cloud로 Targetting하면 내부 클라우드에 배포 되고 Targetting을 미국 Azure로 하면 미국에 배포되는 모델이다.
즉 Private과 Public Cloud를 하나의 회사 클라우드로 통합 관리하는 모양이 되는데...
년초에 이 개념을 보고 차암 대단하다고 생각했는데..

이번에는 Right Scale이라는 솔루션을 봤는데. 이놈은 클라우드 위에서 Public Cloud간 또는 Public-Private Cloud간의 통합된 통제를 가능하게 한다.


RightScale은 Azure,Amazon,Rackspace등 주요 Public Cloud에 대한 중앙 관제를 제공하면서
Ecualyptus나 OpenStack으로 개발된 Private Cloud도 똑같이 중앙 관제가 가능하다. (Ecualyptus나 OpenStack은 Amazon EC2 호환이 되니까는 가능하다.) 즉 수평적,수직적인 클라우드 통합을 지원한다.

JClouds

아울러서 클라우드 개발 부분에서도 변화가 있는데, 재미있는 프레임웍중 하나가
jclouds.org
이다.
클라우드의 주요 기능등 예를 들어 S3,EBS 등을 Java API로 쌓아 놓은 것인데..
재미있는 점은 Amazon 뿐만 아니라 Azure,Ecualytus,Terramark 등 주요 클라우드 서비스들을 호출할 수 있도록 되어 있는데, Abstraction이 되어 있어서 비슷한 기능은 Provider만 바꾸면 되는 구조라는 것이다. 즉 Azure의 BlobStorage나 Amazone의 S3는 그 구조와 용도가 유사한데, JCloud에서는 이것을 하나의 인터페이스로 묶어서 클라우드 서비스 사업자 Depdency 없이 프로그래밍을 할 수 있도록 해준다.

참~~ 한국에서는 Azure나 Amazon 사용하지도 못하고, 그나마 KT가 이제 슬슬 클라우드 서비스 시작할려고 하는데, 벌써 바깥 세상은 한참 변하고 있네요.

 
  • Scale out unit provisioning
    • Bare metal provisioning
  • Reporting
  • Life cycle management
  • Charge back model
  • IO Segregation
  • Self Service Portal
  • Multitenancy
  • Fabric Management
  • Live Migration
  • Automated Patch (Customer requirement is required. 보안 패치를 8시간 내에 모든 서버에 제공한다던지..)
  • Resource Pool Management
    • Asset (VLAN,IP,MAC,LUN) management
  • Scale out unit design

 
가상화만 고민하는데,
대충 이넘들은 고민해야 할듯..



아키텍쳐는 간단, 결국 Workflow 설계랑 PI를 어떻게 할것인가가.. 문제.
ITIL이랑 접속 시키는 것도 필요하고.~~

Cloud Architecture

클라우드 컴퓨팅 & NoSQL/IaaS 클라우드 | 2011.02.24 04:20 | Posted by 조대협


결국 이거지 머.. VM,Resource Pool, Fabric Management.

 아마존 EC2는 아마존 클라우드 서비스의 가장 대표적인 Iaas 서비스 컴포넌트이다. 아마존은 하드웨어 서버를 가상화해 그 하드웨어 자원을 사용자에게 제공하고, 사용자는 그 위에 운영체제와 소프트웨어를 설치해 클라우드 서비스를 이용한다는 개념이다.

 

아마존 EC2

아마존에서는 사전에 Pre configure 된 운영체제 이미지를 제공해, 사용자로 하여금 원하는 이미지와 소프트웨어를 직접 선택할 수 있게 하거나 또는 사용자가 직접 시스템에 대한 이미지를 AMI(Amazon Machine Image)라는 형태로 올려서 사용할 수 있도록 한다.

아마존에서 제공하는 Pre configure 된 이미지들은 < 1>과 같다.

 

Database

IBM DB2

IBM Informix Dynamic Server

Microsoft SQL Server Standard 2005/2008

MySQL Enterprise

Oracle Database 11g

Batch Processing

Hadoop

Condor

Open MPI

Web Hosting

Apache HTTP

IIS/Asp.NET

IBM Lotus Web Content Management

IBM WebSphere Portal Server

Application

Development

Environments

IBM sMash

JBoss Enterprise Application Platform

Ruby on Rails

Application Servers

IBM WebSphere Application Server

Java Application Server

Oracle WebLogic Server

Video

Encoding & Streaming

Wowza Media Server Pro

Windows Media Server

< 1> Pre configure 된 이미지

 

< 1>에서 보는 것과 같이 자바, 닷넷, Ruby on Rails와 같은 프로그래밍 플랫폼과 오라클, MySQL, DB2와 같은 데이터베이스는 물론이고, Media Server와 같은 스트리밍 서비스와 WebSphere Portal과 같은 애플리케이션 서비스도 제공한다.

기본적으로 아마존 EC2는 하드웨어를 가상화하기 때문에 원하는 운영체제와 원하는 소프트웨어를 대부분 인스톨 할 수 있다. 이런 이유로 플랫폼에 대한 수용력이 높다는 장점을 가지고 있다.

하지만 가상화된 하드웨어 자원에 대해서만 서비스를 제공하고 그 위에 설치되는 운영체제와 소프트웨어에 대한 서비스는 제공하지 않는다. 이것이 약점으로 작용할 수 있다. 왜냐하면 사용자 입장에서 해당 소프트웨어에 대한 라이선스 구매와 유지보수료 지불에 대한 추가적인 비용이 발생할 수 있으며, 각각의 소프트웨어에 대한 설치와 운영을 별도로 해야 하기 때문이다.

따라서 기존 온 프라미스 방식의 운영방식에 비해서 하드웨어 자원을 임대해 쓴다는 점 외에 소프트웨어 비용에 대한 문제와 운영관점 상의 문제가 그대로 남아있어 걸림돌로 작용할 수 있다.

 

아마존 SDB(Simple DB)

아마존 SDB 서비스는 Key-Value 타입의 데이터를 저장하기 위한 데이터 저장소 서비스다.

No-SQL인 카산드라(Cassandra)나 하둡(Hadoop) 기반의 HBase와 유사하게 Key-Value 타입의 데이터를 저장하고, 대용량 데이터의 저장 및 빠른 검색을 지원하며 Value에 들어가는 데이터 형에는 제약이 없다는 점이 특징이다. 이런 특성을 ‘Schemeless’라고 하는데, 관계형 데이터 저장이 필요 없는 데이터 구조에서 데이터 저장의 유연성을 부여해준다.

아마존 SimpleDB의 특징 중 하나는 Geo Replication이 가능하다는 것이다. Simple DB에 저장된 데이터는 물리적으로 떨어진 아마존의 데이터 센터에 복제되기 때문에 데이터의 접근성을 향상시키고 장애 시 데이터에 대한 안정성을 보장받을 수 있다.

* Column DB에 대한 구조와 설명은 지난 회에 연재한 Azure Table Storage를 참고 하기 바란다. (아주 유사한 데이터 구조와 기능을 가지고 있다.)

 

아마존 S3(Simple Storage Service)

SDB Key-Value 타입으로 된 간단한 형식과 작은 크기의 데이터 저장을 위해 디자인됐다면, S3은 대용량 Blob 데이터에 대한 저장을 위해 디자인됐다. 다시 말하면 파일, 이미지, 동영상과 같은 큰 사이즈의 데이터를 저장하기 위해 만들어졌다. 저장될 수 있는 데이터 수에 대한 제한은 없으며, 저장되는 데이터 크기는 레코드 당 1byte에서 최대 5GB를 지원한다.

 

아마존 SQS(Simple Queue Service)

SQS IBM MQ나 자바의 JMS와 같은 전통적인 Queue의 아마존 클라우드 버전이라고 생각하면 된다. Queue를 통해서 Reliable Messaging이나 Asynchronous 아키텍처 구성을 지원한다. Queue에 저장되는 메시지는 개당 최대 64Kb까지 지원되며, 최대 14일까지 Queue에 저장할 수 있다.

 

아마존 RDS(Relational Database Service)

RDB 서비스는 MySQL 기반의 관계형 데이터베이스 서비스를 제공하는 것이다. Geo Raplicaton을 포함한 대부분의 MySQL Feature를 지원하며, 흥미로운 특징 중 하나는 데이터베이스 아키텍처 중 하나인 Query-off loading 아키텍처를 지원한다는 것이다.

이 아키텍처는 읽기 트랜잭션(Read Transaction)이 많은 경우에는 하나의 마스터 데이터베이스(Master DB) Create / Update / Delete를 일으키고, 여러 개의 슬레이브 데이터베이스(Slave DB)에 데이터를 복사해 여러 개의 슬레이브 데이터베이스에서 읽기 관련 트랜잭션을 수행하게 한다. 이 과정을 통해 읽기 트랜잭션을 분산시켜 대규모 처리가 가능하게 된다.

 

아마존 EBS(Elastic Block Storage)

EBS EC2 인스턴스에 Attach 될 수 있는 가상의 하드디스크이다. 하나의 EC2 인스턴스에는 여러 개의 EBS 볼륨이 마운트 될 수 있으며, 하나의 볼륨 크기는 1GB부터 1TB까지이다.

실제로 저장될 때는 S3 서비스를 이용해서 저장되는데, 흥미로운 점은 분산파일구조를 채택하기 때문에 IO Performance가 상당히 높은 편이며, EBS Booting Partition으로도 마운트가 가능하다. 또한 특정 시점에 EBS의 이미지를 S3에 저장하여 백업용으로도 사용할 수 있다.

 

아마존 Elastic Map & Reduce

Map & Reduce는 대규모 분산처리를 위한 처리 알고리즘이다.

Map & Reduce는 하나의 큰 작업을 여러 단위의 작업으로 쪼갠(Map) 후 분산된 노드에서 각각 처리한다. 그리고 난 후 처리결과를 다시 하나로 모으는(Reduce) 작업을 통해 처리시간을 향상 시키는 기법이다. 주로 검색결과분석을 위해 많이 사용되는데, 대표적인 오픈소스 구현으로 하둡이 있다. 아마존에서 바로 이 하둡 기반의 Map & Reduce를 지원한다.

Map & Reduce를 실제로 구축하기 위해서는 많은 수의 CPU와 고성능 입출력을 지원하는 분산파일 시스템이 필요하기 때문에 클라우드 시나리오에 매우 적절한 모델이며, 주로 수학적인 계산이 필요한 과학 및 계산 애플리케이션에 많이 활용될 수 있다.

 

아마존 Elastic Load Balancing

클라우드 서비스에서 여러 개의 인스턴스를 운영한다면 당연히 각 인스턴스 간 부하를 분산시키는 메커니즘이 필요하다. 아마존에서는 Elastic Load Balancing이라는 이름으로 한 단계 향상된 형태의 부하분산 메커니즘을 제공한다.

 

- 하나의 데이터센터 내에서 배포된 인스턴스 간뿐만 아니라 여러 데이터센터에 걸쳐 배포된 인스턴스 간에도 부하분산을 지원한다.

- 각 사용자들에 대해 특정 인스턴스로 ConnectionPinning 해주는(L4에서 TCP Session이 한번 맺어지면 계속 유지되는 것과 유사한 방식) 기능을 지원한다. 이 기능은 서버 쪽에 사용자 상태를 저장하는 아키텍처(웹 세션 저장과 같은 시나리오)를 구현할 수 있게 해준다.

- 인스턴스의 상태를 파악해 장애가 났을 때, 장애가 난 인스턴스를 인지해 정상적인 인스턴스로만 요청을 전달하는 Fail Over 기능도 지원한다.

 

아마존 Auto Scaling

클라우드에 있어 가장 중요한 기능 중 하나는 바로 쓴 만큼 지불하되, 요구용량이 늘어나면 서비스 가용용량도 따라서 증가해야 한다는 것이다.

인스턴스는 독립된 VM(제약된 CPU와 메모리 용량)을 기본으로 서비스를 제공하기 때문에 인스턴스에 할당된 VM의 용량을 넘어서는 경우에는 추가로 VM을 할당해줘야 한다. 이런 일련의 작업을 자동으로 해주는 것이 바로 Auto Scaling기능이다.

아마존 EC2에서는 “CPU 사용량이 몇 % 이상 또는 저장용량이 얼마 이상”같은 조건을 사용자가 설정해놓으면 조건이 일치되는 시점에서 자동적으로 인스턴스가 늘어나는 서비스를 제공한다.

 

아마존 SNS(Simple Notification Service)

일반적인 서비스 모델은 클라이언트의 요청에 대해서 서버가 응답하는 형태인데 반해 Notification 서비스는 반대로 서버가 클라이언트에 요청을 보내는 모델이다. 대표적으로 핸드폰의 SMS나 이메일 푸쉬 서비스 등이 이에 해당하는데, 아마존에서는 이러한 형태의 Notification Service를 제공한다. 아마존의 Notification Service HTTP SMTP 프로토콜만을 지원한다.

기본적인 모델은 Subscription, Notification을 받고자 하는 클라이언트가 주제(Topic) Subscription을 신청하면 등록된 클라이언트들에서 이벤트가 있을 경우 Notification을 보내주는 형태이다.

 

아마존 VPC(Virtual Private Cloud)

VPC 서비스는 아마존 EC2 클라우드의 인스턴스와 고객사의 온 프라미스 시스템 사이에 VPN을 설정해 EC2 클라우드 인스턴스를 특정 고객사에서만 접근할 수 있게 해주는 서비스이다.

이 서비스는 일종의 Hosted Private Cloud 모델로 EC2 내의 특정 자원에 대한 접근을 특정 고객사로 Dedication 해줄 수 있는 기능을 가지고 있다. 바꿔 말하면 해당 시스템은 EC2 대외 고객은 접근이 불가능하다.

예를 들어 EC2에서는 쇼핑몰의 판매 정보를 온 프라미스 시스템으로 VPC를 통해서 전송하고, 고객에게는 쇼핑몰 판매 서비스를 제공하는 형태의 서비스가 불가능하다는 것이다(VPC 인스턴스는 온 프라미스 시스템과만 접속이 가능하다).

 

아마존 CloudFront

CloudFront 서비스는 아마존에서 제공하는 CDN(Contents Delivery Network) 서비스다. 아마존 S3에 저장된 Binary 데이터를 CDN 노드를 이용해 전세계에 걸쳐서 있는 다운로드 속도에 대한 성능을 올려주는 서비스이다. CDN은 전 세계에 여러 센터에 걸쳐서 배포돼 있는데 CDN 서버들이 일종의 캐시 서버 역할을 해서 거리로 인해서 발생하는 Latency를 줄여준다. <그림 1>에서 보듯 CloudFront는 미국, 유럽, 아시아에 걸쳐 총 16개의 CDN 센터를 운영하고 있다(< 2> 참조).

 

<그림 1> 아마존 CloedFront를 위한 CDN 센터

지역

위치

미국

애슈번(Ashburn), 댈러스/포트워스, 로스앤젤레스, 마이애미, 뉴욕, 뉴어크(Newark), 팰러앨토(Palo Alto), 시애틀, 세인트루이스(St. Louis)

유럽

암스테르담, 더블린, 프랑크푸르트, 런던

아시아

홍콩, 도쿄, 싱가포르

< 2> CDN 센터위치(http://www.michaelgaigg.com/blog/2008/11/19/fast-faster-cloudfront-speed-matters/ )

 

아마존 Cloud Watch

 

<그림 2> 아마존 Cloud Watch

 

Cloud Watch EC2 S3 등 아마존 클라우드 서비스에 대한 모니터링 기능을 수행한다. 모니터링을 통해 서버 부하와 장애상태를 체크하고, Elastic Load Balancer와 연동해 비 장애 노드로 요청을 전달한다. 부하상황에 따라 Auto Scaling 서비스와 연동해 서비스 인스턴스 수를 탄력적으로 조정할 수 있게 해준다.

 

지금까지 아마존 클라우드 서비스인 EC2의 기능에 대해서 살펴봤다. 여기서는 플랫폼적인 기능에 대해서만 주력해서 살펴봤다. 아마존은 Amazon MarketPlace Customization하기 위한 Fulfilment Service Billing/Payment Service 그리고 다양한 서포트 프로그램 등을 가지고 있다. 조금 더 자세히 알고 싶다면 홈페이지(http://aws.amazon.com/products/)를 참고하기 바란다.

 

아마존 BeansTalk

얼마 전에 발표된, Amazon PaaS 서비스로, Java/Tomcat을 기반으로 한 PaaS 서비스이다. 개발자가 개발한, 웹 애플리케이션을 WAR 타입으로 묶어서 UPLOAD만 하면 사용할 수 있으며, Tomcat이 구동되는 JVM에 대해서 다양한 성능 설정을 할 수 있다.

아울러, 문제가 생기거나 튜닝이 필요할 때, Tomcat이 구동되는 EC2 인스턴스에 직접 접근하여, OS수준에서 장애 분석이나 대응을 할 수 있다.

기존의 Amazon 서비스들이 IaaS 단계에서 머물러 있었다면, BeansTalk 서비스는 Amazon이 향후 PaaS 시장을 적극적으로 공략할 하나의 가능성을 보여주는 서비스 이다.

 

아마존 EC2 HPC (High Performance Computing)

BeansTalk과 함께, 아마존에서 발표한 서비스중의 하나가 EC2 HPC 서비스 인데, 근래의 HPC의 경향은 CPU를 사용하는 것도 있지만, 수치 연산에 최적화된 GPU를 사용하는 경우도 많다. 일반 수퍼 컴퓨터에 비해서 수치 연산에 최적화 되어 있고, GPU의 경우 수치 해석용 Core가 집적되어 있기 때문에, 가격대비해서 높은 성능을 낼 수 있다.

아래는 EC2 HPC에서 제공하는 인스턴스중의 하나인데,

l  22 GB of memory

l  33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)

l  2 x NVIDIA Tesla “Fermi” M2050 GPUs

l  1690 GB of instance storage

l  64-bit platform

l  I/O Performance: Very High (10 Gigabit Ethernet)

l  API name: cg1.4xlarge

22G의 충분한 메모리와, 1.7 TB의 내부 저장 공간 그리고 2개의 NVIDIA Tesla GPU 를 가지고 있다.


<그림 3. Tesla M2050 GPU>

M2050의 경우 내부에 약 448개의 CUDA 기반의 Core, 3G또는 6G의 내부 메모리를 가지고 있다. HPC의 경우 고성능 계산이 필요한 경우만 한시적으로 사용하는 경우가 많기 때문에, 클라우드에 매우 적절한 시나리오라고 할 수 있다.

 

아마존에 대해서 몇 가지 주요 서비스를 소개했지만, 사실 이외에도 세부 서비스들이 많다.

 

클라우드는 근래에 가장 각광 받는 기술이면서도, 쓴 만큼 비용을 낸다는 개념으로 합리적인 모델이지만, 이번 연재를 통해서 설명한 것과 같이, 여러가지 모델 (IaaS,PaaS,SaaS)를 가지고 있으며, 각각의 특성도 매우 다르기 때문에, 업무의 특성을 이해하고, 기술의 특성을 이해해서 클라우드 지향형 아키텍쳐를 설계해서 시스템을 개발해야 한다. 이러한 이해가 없이 그냥 서비스를 클라우드에 배포한다면, 오히려 더 낮은 안정성과 성능 그리고 높은 비용을 지불해야 할 것이다.

 

 


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


Amazon 클라우드 서비스는 상용화되고 성숙된 Iaas 방식의 Public 클라우드 서비스중의 하나이다. 여기서는 Amazon 클라우드 서비스의 각각의 기능에 대해서 간략하게 소개한다.

Amazon EC2

Amazon EC2 Amazon 클라우드 서비스의 가장 대표적인 Iaas 서비스 컴포넌트이다. Amazon은 하드웨어 서버를 가상화 하여, 가상화된 하드웨어 자원을 사용자에게 제공하고, 사용자는 그 위에 OS와 소프트웨어를 설치하여 클라우드 서비스를 사용하는 개념이다.

Amazon에서는 Pre configure OS 이미지를 제공해서 사용자로 하여금 원하는 이미지와 소프트웨어를 선택할 수 있도록 하고, 또는 AMI (Amazon Machine Image)라는 형태로 사용자가 직접 시스템에 대한 이미지를 올려서 사용할 수 있도록 한다.

Amazon에서 제공하는 Pre configure된 이미지들은 다음과 같다.

 

Application Development Environments

Application Servers

Video Encoding & Streaming

IBM sMash

IBM WebSphere Application Server

Wowza Media Server Pro

JBoss Enterprise Application Platform

Java Application Server

Windows Media Server

Ruby on Rails

Oracle WebLogic Server

 

 

위의 표에서 보는 것과 같이 Java,.NET,Ruby on Rails와 같은 다양한 프로그래밍 플랫폼과 Oracle, MySQL,DB2 과 같은 다양한 데이터 베이스는 물론이고 Media Server와 같은 Streaming Service, WebSphere Portal과 같은 애플리케이션 서비스도 제공할 수 있는 구조가 된다.

기본적으로 EC2는 하드웨어를 가상화하기 때문에 원하는 OS와 원하는 소프트웨어를 대부분 Install할 수 있는 장점을 가지고 있기 때문에 플랫폼에 대한 수용력이 높다.

 반대로 가상화된 하드웨어 자원에 대해서만 서비스를 제공할 뿐 그위에 설치되는 OS와 소프트웨어에 대해서는 서비스를 제공하지 않기 때문에 사용하는 사용자 입장에서는 해당 소프트웨어에 대한 라이선스 구매와 유지 보수료 지불에 대한 비용 지불 그리고 각각 소프트웨어에 대한 설치와 운영을 별도로 해야 하기 때문에 기존 on premise 방식의 운영 방식에 비해서는 하드웨어 자원을 임대하여 쓰는 것 이외에는 소프트웨어 비용에 대한 문제와 운영관점의 문제는 그대로 남아 있는 문제점을 가지고 있다.

Amazon SDB (Simple DB)

Simple DB 서비스는 Key-Value 타입의 데이터를 저장하기 위한 데이터 저장소 서비스이다. No-SQL Cassandra Hadoop 기반의 HBase와 유사하게 Key-Value 타입의 데이터를 저장하고, 대용량의 데이터 저장 및 빠른 검색을 지원하며, Value에 들어가는 데이터의 형에는 제약이 없다. 이런 특성을 Schemeless라고 하는데, 관계형 데이터 저장이 필요 없는 데이터 구조에서 데이터 저장의 유연성을 부여해준다.

Amazon SimpleDB의 특징중의 하나는 Geo Replication이 가능하다는 것이다. Simple DB에 저장된 데이터는 물리적으로 떨어진 Amazon의 데이터 센터에 복제되기 때문에 데이터의 접근성을 향상 시키고 장애시 데이터에 대한 안정성을 보장한다.

Amazon S3 (Simple Storage Service)

SDB Key-Value 페어로된 간단한 형식의 작은 크기의 데이터 저장을 위해 디자인 되었다면 S3는 대용량 Blob 데이터에 대한 저장을 위해서 디자인 되었다. 파일,이미지,동영상과 같은 큰 사이즈의 데이터를 저장한다. 저장될 수 있는 데이터의 수는 제한이 없으며, 저장되는 데이터의 크기는 레코드당 1byte에서 최대 5GB를 지원한다.

Amazon SQS (Simple Queue Service)

SQS IBM MQ JAVA JMS와 같은 전통적인 Queue Amazon 클라우드 버전으로 생각하면 된다. Queue를 통해서 Reliable Messaging이나 Asynchronous 아키텍쳐 구성을 지원한다.

Queue에 저장되는 메시지는 개당 최대 64Kb 까지 지원하며, 최대 14일까지 Queue에 저장될 수 있다.

Amazon RDS (Relational Database Service)

RDB 서비스는 MySQL 기반의 관계형 데이터 베이스 서비스를 제공한다. 대부분의 MySQL Feature를 지원하며 (geo replication 포함)

흥미로운 특징 중의 하나는 데이터베이스 아키텍쳐중의 하나인 Query-off loading 아키텍쳐를 지원한다는 것이다. 이 아키텍쳐는 Read Transaction이 많은 경우, 하나의 Master DB Create/Update/Delete를 일으키고 여러 개의 Slave DB에 데이터를 복사하여 여러 개의 Slave DB에서 Read 관련 Transaction을 수행함으로써 Read Transaction을 분산 시켜서 대규모 처리를 가능하게 한다.

Amazon EBS (Elastic Block Storage)

EBS EC2 인스턴스에 Attach될 수 있는 가상의 하드디스크이다. 하나의 EC2 인스턴스에는 여러개의 EBS 볼륨이 마운트 될 수 있으며, 하나의 볼륨 크기는 1GB~1TB이다. 실제로 저장될 때는 S3 서비스를 이용해서 저장되는데, 흥미로운 점은 분산 파일 구조를 채택하기 때문에 IO Performance가 상당히 높은 편이며, EBS Booting Partition으로도 마운트가 가능하다.

또한 특정 시점에 EBS의 이미지를 S3에 저장하여 백업용도로 사용가능하다.

Amazon Elastic Map & Reduce

Map & Reduce는 대규모 분산처리를 위한 처리 알고리즘으로, 하나의 큰 작업을 여러 단위의 작업으로 쪼갠후 (Map) 분산된 노드에서 각자 처리한 후 처리 결과를 하나로 모으는 (Reduce) 작업을 통해서 처리시간을 향상 시키는 기법이다. 주로 검색 결과 분석을 위해서 많이 사용되는데, 대표적인 오픈소스 구현으로는 Hadoop이 있다.

Amazon에서는 이 Hadoop기반의 Map & Reduce를 지원한다.

Map & Reduce를 실제 구축하기 위해서는 많은 수의 CPU와 고성능 IO를 지원하는 분산 파일 시스템이 필요하기 때문에 클라우드 시나리오에 매우 적절한 모델이며 주로 수학적인 계산등이 필요한 과학/계산 애플리케이션에 많이 활용될 수 있다.

Amazon Elastic Load Balancing

클라우드 서비스에서 여러 개의 인스턴스를 운영하면 당연히 필요한 것이 인스턴스간의 부하분산이다. Amazon에서는 Elastic Load Balancing이라는 이름으로 진보된 형태의 부하분산 메커니즘을 제공한다.

o    하나의 데이터센터내에 배포된 인스턴스간 뿐만 아니라 여러 데이터센터에 걸쳐서배포된 인스턴스간에도 부하 분산을 지원

o    각 사용자들에 대해서 특정 인스턴스로 Connection Pinning 해주는 (L4에서 TCP Session이 한번 맺어지면 유지하는 것과 유사한 방식) 기능을 지원한다. 이 기능의 경우 서버쪽에 사용자의 상태를 저장하는 아키텍쳐 (웹 세션 저장과 같은 시나리오)를 구현할 수 있게 해준다.

o    또한 인스턴스의 상태를 파악하여 인스턴스가 장애가 났을 때, 장애가 난 인스턴스를 인지하여 정상적인 인스턴스로만 요청을 전달하는 Fail Over 기능을 지원한다.

Amazon Auto Scaling

클라우드에 있어서 가장 중요한 기능중 하나가, 쓴만큼 지불하되, 요구 용량이 늘어나면 서비스 가용 용량도 따라서 증가해야 한다. 인스턴스는 독립된 VM(제약된 CPU와 메모리 용량)을 기본으로 서비스를 제공하기 때문에 인스턴스에 할당된 VM의 용량을 넘어서는 경우에는 추가로 VM을 할당해줘야 한다. 이러한 일련의 작업을 자동으로 해주는 것이 Auto Scaling기능인데, Amazon EC2에서는 “CPU 사용량이 몇 %이상 또는 저장 용량이 얼마 이상과 같은 조건을 정해놓으면 조건을 일치하는 시점에 자동으로 인스턴스를 늘리는 서비스를 제공한다.

Amazon SNS (Simple Notification Service)

일반적인 서비스 모델이 클라이언트 요청에 대해서 서버가 응답하는데, 비해서 Notification 서비스는 서버가 클라이언트에 요청을 보내는 모델이다. 대표적으로 핸드폰의 SMS나 이메일 푸쉬 서비스등이 이에 해당하는데, Amazon에서는 이러한 형태의 Notification Service를 제공한다.

Amazon Notification Service HTTP SMTP 프로토콜만을 지원한다.

기본적인 모델은 Subscription 모델로, Notification을 받고자 하는 클라이언트가 Topic(주제) Subscription을 신청하면 등록된 클라이언트들에서 이벤트가 있을 경우 Notification을 보내주는 모델이다.

 

Amazon VPC (Virtual Private Cloud)

VPC서비스는 Amazon EC2 클라우드의 인스턴스와 고객사의 on-premise 시스템 사이에 VPN 을 설정하여 EC2 클라우드 인스턴스를 특정 고객사에서만 접근할 수 있도록 해주는 서비스이다.

이 서비스는 일종의 Hosted Private Cloud 모델로 EC2내의 특정 자원에 대한 접근을 특정 고객사로 Dedication 해줄 수 있는 기능을 가지고 있으나, 반대로 해당 시스템은 EC2 대외 고객은 접근이 불가능 하다. 예를 들어 쇼핑몰의 판매 정보를 EC2에서 on-premise 시스템으로 VPC를 통해서 전송하고, 고객에게는 쇼핑몰 판매 서비스를 제공하는 형태의 서비스가 불가능 하다는 것이다. (VPC 인스턴스는 on-premise 시스템과만 접속이 가능하다.)

Amazon CloudFront

CloudFront 서비스는 Amazon에서 제공하는 CDN (Contents Delivery Network) 서비스이다. Amazon S3에 저장된 Binary 데이터를 CDN 노드를 이용하여 전세계에 걸쳐서 다운로드 속도에 대한 성능을 올려주는 서비스이다. (CDN은 전세계에 여러 센터에 걸쳐서 배포되고, CDN 서버들이 일종의 캐쉬 서버 역할을 해서 거리로 인해서 발생하는 Latency를 줄여준다.)

아래 그림과 같이 CloudFront는 미국,유럽,아시아에 걸쳐 총 16개의 CDN 센터를 운영하고 있다.


United States (Ashburn, VA) (Dallas/Fort Worth, TX) (Los Angeles, CA) (Miami, FL) (New York, NY) (Newark, NJ) (Palo Alto, CA) (Seattle, WA) (St. Louis, MO)

Europe Amsterdam,Dublin,Frankfurt,London

Asia Hong Kong,Tokyo,Singapore   16개 센터

(원본 http://www.michaelgaigg.com/blog/2008/11/19/fast-faster-cloudfront-speed-matters/ )

 

Amazon Cloud Watch

Cloud Watch EC2 S3등의 Amazon 클라우드 서비스에 대한 모니터링 기능을 수행한다. 모니터링을 통하여 서버의 부하와 장애 상태를 체크하고 Elastic Load Balancer와 연동하여 비 장애 노드로 요청을 전달하고, 부하 상황에 따라 Auto Scaling 서비스와 연동하여 서비스 인스턴스 수를 탄력적으로 조정할 수 있게 해준다.

 

지금까지 Amazon Cloud의 기능에 대해서 살펴보았다. 여기서는 플랫폼적인 기능에대해서만 주력해서 살펴보았는데, Amazon Amazon MarketPlace Customization하기 위한 Fulfilment Service, Billing/Payment Service, 그리고 다양한 Support 프로그램등을 가지고 있다. 조금 더 자세한 사항은 http://aws.amazon.com/products/ 를 참고하기 바란다.

클라우드 서비스중 Private 클라우드의 경우 대부분 Hypervisor 기반의 가상화를 이용하여 하드웨어 자원을 공유하는 아키텍쳐를 일반적으로 사용하지만, Public 클라우드의 경우 Iaas 형태의 서비스를 제공한다 하더라도, 몇가지 공통적인 특정 서비스를 제공한다.

Public 클라우드에서 제공하는 공통적인 서비스 형태들은 다음과 같다.

 

Storage Service

Storage Service는 말 그대로 데이터를 저장하는 서비스이다. 데이터의 성격에 따라 몇 가지 상세 서비스로 나뉘어 진다.

적은 크기의 많은 수의 데이터 (Table Storage)

데이터의 수가 수천만,테라 단위의 많은 수를 가지고 있으며, 데이터의 복잡도나 각각 레코드의 크기는 크지 않을 경우, 큰 저장 용량과 빠른 검색 속도를 요구 한다. 사용자 profile,게시물 레코드등이 해당하는데, 기업내에 이런 데이터를 저장하기에는 디스크등의 저장소에 소요되는 비용이 너무 크고, 폭발적인 용량 증설이 있을 경우에 비즈니스에 대한 대응성이 늦다. 그래서 대부분의 Public Cloud 서비스에는 이러한 데이터 형태를 저장하는 별도의 저장 메커니즘을 제공하는데, MS Windows Azure Table Storage Amazon SDS가 대표적인 서비스이다.

이러한 데이터 저장 구조는 근래에 서비스 업체를 중심으로 하는 NoSQL 아키텍쳐와 관련이 깊은데, 실제로 페이스북이나 트위터의 경우 많은 데이터에 대한 저장 요구사항과 빠른 검색 및 접근 성능을 요구로 하고 있기 때문에, Cassandra와 같은 Column데이타 베이스를 이용하여 이와 같은 요건을 구현하고 있으며, 이러한 배경이 반역된 것이 위에 언급한 형태의 클라우드 데이터 서비스이다.

크기가 큰 데이터 (Blob Storage)

일반 데이터 파일, 사진,이미지,동영상과 같은 크기가 큰 데이터의 경우 복잡한 쿼리와 같은 연산은 필요로 하지 않지만 저장용량에 대한 비용 문제가 발생하고 특히 여러 국가를 대상으로 서비스 하는 시스템의 경우 데이터의 다운로드 속도가 문제가 된다.

 이런 형태의 데이터를 Blob 데이터라고 하고, Public Cloud에서는 크기가 큰 데이터를 저장하기 위한 서비스를 제공한다. Amazon S3, MS Windows Azure Blob Storage 서비스가 대표적인 예이며, 여러 국가(지역)간의 다운로드 성능을 향상 시키기 위해서 CDN (Contents Delivery Network)을 연계한 서비스를 제공하는 모델이 많다.

복잡한 데이터 연산을 필요로 하는 데이터 (RDBS over Cloud)

다음으로 기업용 애플리케이션이나 복잡한 관계형 데이터를 가지고 있는 경우 쿼리와 관계 관리를 위한 RDBMS 기반의 데이터 서비스가 필요하다. 쉽게 생각하면 RDBMS를 클라우드에 올리고 서비스를 한다고 똑같이 생각하면 되고, 단 이 경우 여러 데이터베이스간의 트렌젝션을 연동하여 보장하는 분산 트렌젝션은 지원하지 않는 것이 보통이다. (클라우드 노드간의 Latency 문제 때문에 분산 트렌젝션 지원시 심각한 성능 저하를 유발한다.)

 Amazon에서 오픈소스인 MySQL을 기반으로한 RDS 서비스나, MS Windows Azure MS SQL을 기반으로한 MS SQL 서비스가 대표적인 사례이다.

가상 디스크 저장소 (Virtual Disk)

마지막으로 애플리케이션 차원에서 양이 많지 않고 애플리케이션 자체적으로 사용할 데이터 또는 Iaas OS에 마운트되는 디스크등을 지원하기 위해서 논리적으로 디스크를 생성하여 가상머신(OS VM)에 마운트하는 서비스를 제공한다.

대표적인 서비스로는 Amazon EBS Microsoft Azure Azure Drive 서비스 등이 있다.

Queue Service

Queue Service는 기존의 IBM MQ, Microsoft MSSQ, Java JMS와 같은 비동기 호출을 지원하는 메시지 큐이다.

클라우드는 특성상, 작업을 하는 Working Instance들이 존재하고, 이 여러 Working Instance간의 작업 배분 또는 작업 요청에 대한 Buffering등을 위해서 중간에 메시지큐가 필요한데 이러한 요구사항을 지원하기 위해서 Public Cloud에서는 Queue 서비스를 제공한다.

대표적인 서비스로는 Amazon SQS, Microsoft Azure Queue Storage 서비스등이 있다.

Data Grid Service

일반적인 엔터프라이즈 소프트웨어 아키텍쳐중에 근래에 발전된 아키텍쳐중 하나는 데이터 그리드라는 아키텍쳐이다. 일종의 거대한 메모리를 여러대의 물리적 서버에 걸쳐서 배포하여 이론적으로 무제한 사이즈의 메모리를 만들고 애플리케이션들이 이 메모리를 통해서 서로 데이터를 공유하거나 또는 데이터 베이스에 대한 2차 캐쉬로 사용하는 시나리오를 많이 사용한다.

실제로 FaceBook의 경우 MySQL 데이터 베이스 윗단에 memcached라는 데이터 그리드를 위치 시켜서 데이터 베이스의 쿼리 성능을 획기적으로 향상 시키는 아키텍쳐를 사용하고 있다.

특히 클라우드 서비스의 경우 각각의 서비스 컴포넌트가 분리되어 있고 그로 인해서 컴포넌트간의 네트워크 Latency가 존재하기 때문에 데이터 조회의 성능을 높이기 위한 캐쉬 서비스와, 여러 인스턴스간의 정보를 공유하기 위한 데이터 버스가 필요하다.

이를 지원하기 위해서 발전된 형태의 Public Cloud에서는 데이터 그리드 서비스를 제공한다.

o    캐쉬 서비스

캐쉬 서비스는 데이터를 저장소 (데이터베이스, 파일)등에 저장하기 전에 2차 캐쉬로 사용하는 형태로 특히 Private 클라우드에 데이터를 놓고 Public 클라우드를 통해서 서비스를 제공하는 경우 지역적 문제로 인한 네트워크 Latency가 심하기 때문에 성능 향상을 위해서 캐쉬 서비스가 필수적으로 요구 된다.

o    메모리 버스

또한 여러 업무 또는 동일 업무라도 여러 서비스 인스턴스 (여러 VM)간의 데이터를 모으고 서로 공유 하기 위한 데이터 버스가 필요한데, Table Storage를 통해서 이러한 정보를 공유하는 시나리오도 있지만, 이보다는 데이터 그리드를 이용할 경우 보다 나은 성능을 보장할 수 있다. (일반적으로 데이터 그리드의 접근방식,데이터 구조는 Table Storage의 접근 방식과 데이터 구조와 거의 동일하다.)

 

대표적인 데이터그리드 서비스로는 Google AppEngine memcache 서비스, Microsoft Azure AppFabric Cache 서비스 등이 있다.

Scalability Support Service

클라우드 서비스의 가장 큰 목적 중의 하나가 하드웨어 자원의 탄력적인 사용이다. 자원의 사용량에 따라서 비용을 지불하는 모델인데, 현재 클라우드 서비스들은 이러한 요건을 만족하기 위해서 라이선스 정책상의 헛점을 가지고 있다. 대부분의 라이선스 정책이 CPU X clock에 메모리 얼마인 인스턴스 단위로 계약을 하고, 이 인스턴스당의 사용량에 대해서 과금을 하는 방식이다. 문제는 초기 계약 당시에 하나의 인스턴스만 계약을 하기 때문에, 용량이 하나의 인스턴스 이상으이 필요할 때 대응이 애매하다는 것이다. 쉽게 말하면 자동으로 인스턴스를 늘려줘야 하고, 늘려진 인스턴스에 자동으로 부하를 분산해줘야 한다. 이것이 클라우드상의 Scalability 문제인데, 이런 문제를 해결하기 위해서 제공 되는 서비스가 Auto Scaling 서비스이다. 일정 수준(SLA 이상)의 용량이 넘어가면 이를 감지해서 자동으로 인스턴스를 추가해주는 서비스이다.

대표적인 서비스로는 Amazon Auto Scaling 기능과 Windows Azure에서는 Monitoring API를 통해서 Instance를 늘려주는 기능을 추가해서 사용한다. (http://code.msdn.com/azurescale)

Virtual Machine Service

Iaas를 위한 가장 기본적인 서비스로, Hypervisor 기반의 하드웨어 자원을 가상화 하여 OS 별로 자원을 할당해주는 서비스이다. Amazon EC2 서비스와 Windows Azure VM Role 서비스가 대표적인 사례이다.

IDM(IDentity Management) Service

클라우드 서비스에 있어서 계정 통합 관리 및 권한 관리는 매우 중요한 이슈이다. 클라우드에 배포되는 여러가지 서비스에 대해서 통합된 계정 관리가 필요하고, 각 서비스에서 요구하는 사용자의 프로필의 스키마(항목)가 다르고 서비스마다 각각 관리가 되어야 하기 때문에 서비스 가입 및 해지 또는 정보 변경에 따라 각각 서비스가 관리하고 있는 사용자 프로파일이 동일하게 변경되어야 한다 (ID Provisioning).

여기에 더해서 만약 on premise 시스템과 연동을 할 경우 기업 내에 이미 계정 및 권한 관리 시스템이 운영되고 있기 때문에 클라우드에 구축된 시스템과 on premise 시스템간의 계정 통합 역시 새로운 이슈로 제기된다.

이런 계정 통합과 통합 권한 관리의 이슈를 해결하기 위해서 클라우드 시스템내에는 통합된 또는 통합 가능한 형태의 계정 권한 관리 시스템이 요구된다.

대표적인 서비스로는 Windows Azure AppFabric ACS 서비스가 있다.

Platform Service (.NET,LAMP etc)

다음으로는 애플리케이션 플랫폼을 배포 및 운영할 수 있는 형태의 서비스를 제공하느냐인데, 쉽게 생각하면, 자바나 .NET 기반의 애플리케이션만 배포하면 되느냐? 아니면 DB,Web Application Server등의 미들웨어도 배포해야 하는냐로 판단하면 된다. 개발된 애플리케이션만 배포하여 운영할 수 있는 인프라가 다 되어 있는 경우에는 Paas (Platform As a Service)이고, 애플리케이션 운영을 위해서 별도의 미들웨어 인스톨이 필요할 경우 미들웨어를 인스톨할 수 있는 인프라만 제공하는 경우이기 때문에 이런 형태는 Iaas(Infra as a service)라고 한다.

Microsoft Azure의 경우 .NET,PHP 등의 애플리케이션 플랫폼을 제공하는 Paas 형태이고, Amazon의 경우에는 가상화된 OS를 기본적으로 제공하고, 그 위에 애플리케이션 운영플랫폼은 별도로 설치해야 하기 때문에 Iaas 형태이다.

Google의 경우 Python JVM기반의 언어 (JRuby)등을 제공하는 Paas 형태이고, 위에서 설명했듯이 MS Azure Paas, Amazon Iaas 형태의 서비스를 제공한다.

Integration Service

클라우드의 요구사항 중 하나는 각각 개별로 배포된 클라우드 기반의 서비스간의 통합 또는 클라우드에 배포된 서비스와 on premise에 배포된 서비스간의 연동이다. 위에서도 IDM등의 시나리오를 통해서 특화된 연동 통합 시나리오에 대해서 언급했지만, 여기서는 좀 더 보편화된 통합 서비스 기능에 대해서 설명한다.

     Internet Service Bus

SOA 서비스에서 메인 계층 중의 하나가 Enterprise Service Bus (ESB)이다. ESB는 여러 다른 비즈니스 서비스간의 통합과 데이터 버스의 개념으로 사용되는 솔루션이다. 클라우드 아키텍쳐에서도 이와 유사한 형태의 데이터 버스와 통합 계층이 필요한데, 기존 ESB의 특징에 더해서 클라우드 아키텍쳐의 특징을 반영할 수 있는 Service Bus가 필요하다.

클라우드는 첫번째로 지역적으로 분산된 위치에 비즈니스 서비스들이 배포 되며, 두번째로 방화벽이나 NAT(네트워크 주소를 변경 시키는 장치)등을 경계로 한 on premise 서비스와 클라우드 내의 서비스를 통합해야 하는 요건을 가지고 있다. 그렇기 때문에 지역간의 라우팅을 담당하고 복잡한 네트워크 토폴로지 (주소 변환,방화벽)를 지원할 수 있는 구조의 Service Bus가 필요하고 이런 특성을 가지고 있는 Service Bus Internet Service Bus라고 제공한다. 이러한 Internet Service Bus는 애플리케이션 플랫폼에 종속적이기 때문에 (Reverse Proxy등의 기능을 제공해야 하기 때문에 프로그래밍 언어의 라이브러리 형태로 일부 모듈이 제공되어야 한다.) Iaas 형태의 클라우드에서는 제공하기 어렵고 애플리케이션 플랫폼을 제공하는 Paas 형태에서 제공하기가 용이하기 때문에 대표적인 Iaas 형태인 Amazon 클라우드에서는 제공하지 않고 있으며 Paas 를 지원하는 Microsoft Windows Azure AppFabric Service Bus가 대표적인 사례이다.

     Legacy Integration Service

다음으로 기업내의 Legacy System을 통합하기 위한 솔루션이 필요한데, 클라우드 이전의 on premise 시스템에서는 EAI (Enterprise Application Integration)이라는 아키텍쳐를 이용했다. EAI Legacy Package Application에 대해서 특정한 Technology를 이용한 통합을 제공하는데, (SAP ERP, Oracle CRM에 대한 Technology 아답터등을 제공하는 방식으로) 이러한 EAI 특성이 클라우드에도 배포되어 on premise에 배포된 Legacy Application이나 클라우드에 배포된 Package Application에 대해서 통합을 지원한다. 대표적인 예로는 Microsoft Azure AppFabric BizTalk 서비스가 있다.

Monitoring Service

마지막으로 Monitoring Service인데, 서비스 현황, 사용량 등을 Dash Board 형태로 표현함은 물론이고, Application의 성능과 건강도를 모니터링할 수 있는 APM (Application Performance Monitoring)등의 기능이 제공되어야 한다.