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


Archive»


 
 

Amazon Opsworks 소개

시스템에 설치와, 애플리케이션을 자동화

배경

얼마전에, Amazon에서 새로운 클라우드 서비스인 Opsworks를 발표하였다.

[출처:Amazon Opsworks 소개 페이지]

비단 클라우드 뿐만 아니라, 서버 시스템을 개발하다보면, 당면 하는 과제중의 하나가, 소프트웨어 설치와, 애플리케이션의 배포이다.

예전에야 큰 서버 한대에, WAS 하나 설치하고, DB를 다른 서버에 설치해서  사용했지만, 요즘 같은 시대에는 x86 서버 여러대에 WAS를 분산 배치하고, 여러 솔루션들 설치해서 사용하고, 시스템의 구조 역시 훨씬 더 복잡해 졌다. 그래서, 이러한 제품 설치를 자동화 하는 영역이 생겼는데, 이를 Configuration Management(이하 CM)이라고 한다. CM의 개념은 Microsoft System Center Configuration Manager의 제품 소개나 White Paper를 보면, 정리가 잘 되어 있다. Unix 진영의 Configuration Management 영역은 오픈소스로 Puppet이나 Chef가 주류를 이룬다. 그중에서 Chef Recipe 라는 것을 제공하여, 특정 제품에 대해서 설치를 자동화 하는 스크립트를 제공한다. 일일이 제품마다 설치 스크립트를 만들지 않아도, Recipe만 입수하면 손 쉽게 제품을 설치할 수 있다. 특히나 클라우드 환경에서는 개발 환경이나 스테이징,QA 환경을 다이나믹하게 만들었다가 없앴다 하기 때문에 더군다나, 이러한 Configuration Management가 아주 중요하다.

 기존에는 Amazon 이미지인 AMI를 이용하여, 솔루션이 미리 설치된 AMI를 만들어 놓고, bootstrap 기능을 이용하여, 서버가 기동 될때, 특정 환경 변수를 설정하게 하거나

CloudFormation을 이용하여 설치를 자동화 할 수 있었다. 그러나 AMI 방식은 너무 단순해서 복잡한 설정이 어렵고 처음에는 반드시 직접 설치해야 하는 부담이 있었고, CloudFormation은 그 복잡도가 너무 높아서 사용이 어려웠다.

이번에 발표된 Opsworks는 이 중간즘 되는 솔루션으로 보면 된다.

Stack, Layer 그리고 Instance의 개념

Opsworks는 기본적으로 오픈소스 Chef를 이용하여 구현되었다. Chef를 이용해서 아마존에 맞게 개념화 해놓았는데, 먼저 Opsworks의 개념을 보자. Opsworks를 이해하려면 3가지 개념, Stack, Layer 그리고 Instance의 개념을 이해해야 한다.

우리가 PHP 웹서버 + MYSQL로 이루어진 웹 애플리케이션을 개발한다고 하자, 그리고 앞단은 HAProxy를 사용해서 로드 밸런싱을 한다고 하면, 이 애플리케이션은 크게, HA Proxy로 이루어진 Load Balancer Layer 그리고, PHP 웹서버를 사용하는 Application Server Layer 그리고, MySQL로 이루어진 DB Layer 3가지 계층으로 이루어진다.

3 가지 계층은 (HAProxy+PHP Web Server+MySQL) 다른 웹 개발에도 반복적으로 사용될 수 있다.


이렇게 각 계층을 Layer라고 하며, 이 전체 계층을 반복적으로 재사용하기 위한 묶음을 Stack이라고 한다. 그리고, 각 계층에 실제 서버를 기동했을 경우 각 서버를 Instance라고 한다. 예를 들어 하나의 HA Proxy 서버를 띄우고, 이 아래 4개의 PHP Web Server를 기동했다면, 이 시스템은 PHP Web Server로 된 Application Server 계층에 4개의 Instance를 갖는게 된다.

Chef & Predefined Cookbook
Opsworks
는 앞에서 언급했듯이 Chef (http://www.opscode.com/chef/기반이다.

Chef에 사용되는 설치 스크립트는 Ruby 언어로 되어 있으며, Opsworks에서는 콘솔에서 편리하게 사용할 수 있도록 Pre-defined Layer를 정해놨다.

Layer

Product

Load Balancing

HAProxy

Applications & Web Server

Node.js RubyOnRails, static web server, PHP

DBMS

MySQL

Cache

Memcached

Monitoring

Ganglia

 이외의 부분은 Custom Layer라고 해서 사용자가 직접 정의해야 하며, Chef를 만든 OpsCode Receipe를 참고하여 설정할 수 있다.

애플리케이션의 배포

이렇게 Stack 구성이 완료되면, 기동후에, 여기에 배포되는 애플리케이션을 배포할 수 있다. 자바로 치면 war, ear 파일등이 된다.

아마존이 충분히 서비스를 고려했다는 점은, 여기서도 나오는데, 애플리케이션 배포중에 중요한 일중 하나가, 배포가 잘못되었을때 기존 버전으로 roll back이 가능해야 한다는 것이다. 이를 지원하기 위해서 보통 배포 서비스를 설계할때는 애플리케이션을 저장할 수 있는 repository를 별도 설계해서, 여러 버전을 저장해놓고, 필요할 경우 Roll Back을 하는데, Opsworks는 이를 지원하기 위해서 다양한 Repository를 지원한다.-AWS S3, 일반 HTTP URL, GitHub ,Subversion

현재 Opsworks에서 지원하는 배포 가능한 앱은 Ruby on rails, PHP, JavaScript(Node.js), Static등을 지원하며, Custom App을 통해서 여러 앱 타입을 지원하도록 할 수 있다.

더 살펴봐야 할것

Opsworks 스크립트를 통해서 할 수 없는 것중 하나는 ELB(Elastic Load Balancer)등의 세팅을 할 수 없다. 오로지 EC2위에 설치하는 것만 가능하다. 설치와 배포를 AWS 인프라와 어떻게 엮어서 할 수 있을까가 과제이다.

아직 베타 서비스이고 사례가 많지는 않지만, 설치와 배포가 중요한 클라우드 환경에서, Chef라는 주요 오픈 소스를 기반으로한 서비스인 만큼 시간을 가지고 지켜볼만한 하다.

 

참고 : http://docs.aws.amazon.com/opsworks/latest/userguide/walkthroughs.html

아마존의 EC2 서비스는 VM 기반의 컴퓨팅 자원을 제공하는 서비스이다.

클릭 몇 번으로 저기 바다 넘어있는 나라에 내 서버를 만들 수 있으며, 내가 사용한 만큼만 비용을 지불하면 된다.
아마존 EC2에서 제공하는 VM은 성능과 특성에 따라 여러가지 타입을 가지고 있다.

일반적인 인스턴스 
  • 1세대 인스턴스(m1) : m1.* 이름으로 시작하며 아마존에서 일반적으로 제공하는 가상화된 VM 인스턴스 이다.
  • 2세대 인스턴스(m3) : 2012년에 발표한 인스턴스로 m3.* 로 시작하며, 기존에 비해서 50% 이상의 높은 CPU 성능을 가지고 있다.
특수목적 인스턴스 

  • 고용량 메모리 인스턴스(m2) : m2.* 이름으로 시작하며 17,34,68 GB등 많은 용량의 메모리를 가지고 있는 인스턴스이다. (가상코어 역시 그만큼 많이 가지고 있다) 데이타베이스나 메모리 캐쉬 서버등 메모리 사용량이 높은 서비스에 이용할 수 있다. 
  • 고성능 CPU 인스턴스(c1) : c1.* 이름으로 시작하며, 같은 메모리나 디스크를 갖는 m1 시리즈에 비해서 상대적으로  CPU 만 더 많이 가지고 있다.
  • 클러스터링 인스턴스(cc1) : cc1.* 로 시작하며, 아마존 인스턴스 중에서 가장 높은 스펙을 가지고 있다. 많은 CPU와 많은 메모리 그리고 10G 기반의 IO 성능을 가지고 있다. 특히 클러스터링 인스턴스는 placement group이라는 옵션을 지원하는데, 아마존의 VM은 내부에서 생성될때, 어느 위치(Rack)에 생성될지 알 수 가 없다. 그래서 인스턴스간의 네트워크 latency가 예측 불가능 한데, 클러스터링 인스턴스를 placement group으로 묶으면, 인스턴스간의 네트워크 latency를 최소화하고 인스턴스간 10GB 네트웍을 사용한다. 클러스터링된 서비스들은 대부분 인스턴스간의 통신을 하고 그 속도에 많은 영향을 받기 때문에, 클러스터링 된 서비스에 매우 유리하다. Cassandra,MongoDB등과 같이 내부적으로 클러스터링이 되는 NoSQL등에도 사용할 수 있다.
  • 클러스터 GPU 인스턴스(cg) : cg* 로 시작하는 인스턴스로, VM에 GPU (그래픽카드에 들어가는 CPU)가 대거로 포함되어 있다. 우리가 사용하는 그래픽 카드에는 GPU라는 프로세스가 들어 있는데, 이 GPU들은 실수 연산 (floating point)과 같은 수치 연산에 매우 최적화되어 있다. 그래서 수치 해석이나 대규모 병렬처리등에 매우 유리한데, 이러한 GPU들은 CPU와는 다르게 큰 코어를 수개~수십개를 가지고 있는 것이 아니라 수백개의 GPU 코어를 가지고 있기 때문에, 수치 연산에 있어서는 탁월한 성능을 발휘할 수 있다.
  • High IO 인스턴스(hi) : hi*로 시작하며 높은 성능의 네트워크와 디스크 IO성능을 보장한다. 특히 디스크 성능이 탁월하게 높은데 그럴 수 밖에 없는 것이 SSD를 사용한다
EBS(디스크) 성능 옵션

그 외에, 위의 VM을 선택한 후에, VM에 따라 다음과 같은 몇 가지 추가 옵션을 제공한다.
EBS는 나중에 설명하겠지만, iSCSI기반의 SAN 스토리지다. PC로 쉽게 생각하면 외장 하드 정도로 이해하면 된다. (물론 그보다는 훨씬 빠르지만). EC2에서 문제가 되었던게 이 EBS 디스크를 VM에 붙였을때, EBS 디스크에 대한 IO 성능 느리고, 그 성능이 일정하지 않았던 문제를 가지고 있었다. 이를 보와하기 위해서 나온 것이 다음과 같은 두 가지 옵션이다.

Provisioned IOPS (PIOPS)
EBS 디스크 용량에 따라서 IOPS를 보장한다.  보장 가능한 IOPS는 EBS용량에 비례하여 증가한다. GB를 기준으로 N GB사용시, 명시적으로 지정 가능한 최대 IOPS는 N*10 IOPS가 된다. (40GB면 400IOPS, 100GB면 1000IOPS) 현재 최대 1,000 IOPS까지 지원된다.
정확하게는 EC2 VM의 옵션이 아니라 EBS의 옵션으로, Provisioned IOPS를 선택하면, IO 성능을 보장할 수 있는 EBS 디스크 영역에 EBS Volume이 생성된다.

EBS Optimized Instance
EBS Optimized Instance는 EBS와 EC2 인스턴스간에 내부적으로 전용 네트워크를 사용하여 대역폭을 안정적으로 유지해준다. 500Mbps~1000Mbps 사이에 대역폭을 설정할 수 있다.

추가적인 기능
아마존 EC2의 VM 서비스는 몇 가지 추가적인 기능을 가지고 있다.

VM Import/Export
Virtualization 기반의 서비스인 만큼 다른 동작중인 VM에 대한 Snapshot을 뜰 수 있고, 이 Snapshot 파일을 Export할 수 있다. 반대로 Local PC나 자사의 데이타 센터에서 사용하는 VM Image를 Import할 수 도 있다. 현재 지원하는 포맷은 VMDK(VMWare 포맷),VHD(Microsoft), RAW 포맷등을 지원한다.

Amazon Marketplace
Amazon Market Place는 EC2 VM을 생성할때, 미리 소프트웨어가 다 깔려져 있는 VM 이미지를 구매할 수 있는 Market place이다.  예를 들어 VM 생성시 RedHat Enterprise Linux 이미지를 선택하면, RedHat Linux가 깔려 있는 VM이 생성된다. OS 뿐만 아니라 SAP와 같은 패키지 소프트웨어에서 부터 LAMP (Linux + Apache +MySQL + PHP)와 같은 여러 소프트웨어 솔루션의 조합까지 다양한 형태의 이미지들을 구매할 수 있다.



물론 이러한 이미지들은 공짜가 아니다 EC2 시간당 사용 요금에 함께 합쳐서 소프트웨어 라이센스비가 청구된다. 
제품에 따라서는 아마존을 통해서 기술 지원을 받을 수 있는 제품들도 있다. 예를 들어 RedHat Linux의 경우 가격은 일반 Linux VM에 비해서 두배 가량 비싸지만, 아마존을 통해서 기술 지원을 받을 수 있다.

Elastic IP
EC2 VM의 특징중의 하나가, VM이 생성되고 그리고 Restart될 때마다 그 IP 주소가 동적으로 매번 바뀌다는 것이다. 이렇게 IP가 바뀌면 서버간의 통신이나 외부 서비스시에 고정 IP가 없으면 서비스가 어렵기 때문에, 아마존에서는 인터넷 고정 IP 자체를 EIP 라는 이름으로 판매한다. EIP를 구매하면, 인터넷 Public IP가 하나 부여되고, 이를 EC2 인스턴스에 부여하면 고정 IP를 사용할 수 있다.

특성
이외에도 EC2 서비스는 몇 가지 특성을 가지고 있다.

IP 주소 변경
앞의 EIP에서도 설명하였듯이, EC2 인스턴스는 EIP를 배정하지 않는 이상 리스타트 때마다 IP가 변경된다. 고정 IP를 사용하는 방법은 EIP와 VPC (Virtual Private Cloud)를 사용하여 Private IP를 배정하는 방법이 있다. (나중에 설명)

IO 성능
EC2 서비스, 아니 모든 클라우드 서비스에서 가장 신경써야 하는 부분이 IO다. 기본적으로 LOCAL 서버 만큼의 성능이 나오지 않는다. 네트워크 구간 성능, EBS 디스크와 연결된 네트워크 성능 모두 일반 LOCAL 서버에 비해서 낮다.(물론 IO 옵션을 적용하고, 큰 인스턴스를 사용하면 높아진다.) 이 IO 성능은 인스턴스 크기에 비례하고, IO 옵션 (PIOPS, EBS Optimized Instance)에 따라서 높일 수 있다. LOCAL 환경에서 개발한 시스템들이 AWS EC2에 올리면 많은 성능 차이가 나는 이유중의 하나가 이 IO 성능 때문이다. 인스턴스별 IO 성능은  http://aws.amazon.com/ko/ec2/ 를 나와 있다. 주의할점은 EC2의 네트워크는 다른 EC2인스턴스와 공유해서 사용되기 때문에, 그 성능이 일정하지 않다. 큰 인스턴스를 사용하면, 전체적으로 성능은 올라가지만 그 성능에 대한 편차가 크기 때문에 서비스전에 반드시 측정 및 테스트 후에 사용해야 한다.

SLA
SLA는 Service Level Agreement의 약자로, 서비스의 안정성을 백분율로 나타낸 것인데, 100%이면 1년에 장애가 없는 것. 99.95%면 1년에 365일 * 0.05% 만큼 장애가 날 수 있다는 것이다. 그런데 아마존 EC2 서비스의 SLA는 바로 99.95% 이다. 1년에 4.38 시간이 장애가 나도 아마존 책임이 아니라는 이야기. 그래서 AWS에서 설계를 할때는 항상 데이타 센터 자체가 장애가 나거나 region이 장애가 나는 것을 염두 해두고 Zone간 또는 Region 간 Fail over (장애 대응) 시나리오를 고려해서 설계해야 한다.

시간 단위 과금
EC2 사용시 주의해야할 점은 시간 단위의 과금이다. 딱 시간 개념으로만 과금을 한다. 분이나 초의 개념이 없다. 무슨말이냐 하면, 1시간을 사용하던, 1시간00분1초~1시간59분59초는 무조건 2시간으로 과금이 된다. 그래서 EC2 인스턴스의 UP time (기동시간)을 자동화 하거나 스케쥴링 할경우에는 시간을 넘지 않도록 해야 불필요한 시간 과금이 발생하지 않는다.

CPU 단위 ECU
아마존은 EC2 인스턴스의 컴퓨팅 능력 즉, CPU의 단위를 ECU라는 단위로 표현한다.
ECU는 하나의 표현 단위일 뿐이지 1 ECU = 1 vCore나, 1CPU를 뜻 하는 것이 아니다.
아마존 홈페이지의 내용을 인용하면, 1 ECU는 
"
ECU(EC2 컴퓨팅 유닛) 1개는 1.0~1.2GHz 2007 Opteron 또는 2007 Xeon 프로세서와 동일한 CPU 용량을 제공합니다. 이는 원본 설명서에 언급되어 있는 초기 2006 1.7 GHz Xeon 프로세서와도 동일한 수준입니다" 라고 나와 있다. 5~6년전 CPU 성능이다.


인스턴스 과금 방식에 따른 분류
EC2는 계약 방식에 따라 다른 가격 체계를 가지고 있다.
  • Free : 개발이나 테스트를 할 수 있게 일부 인스턴스를 무료로 제공한다. micro 인스턴스의 경우 750시간 무료, 그 이후에는 과금이 되니 주의 바람 (참고 http://aws.amazon.com/ko/ec2/pricing/ )
  • On-Demand Instance : 우리가 일반적으로 사용하는 과금 방식으로, 사용한 시간 만큼 비용을 지불하는 형태이다.
  • Reserved Instance : 일정 기간 인스턴스 사용을 약속하고, 그에 대한 Discount를 받는 방식
  • Spot Instance : 입찰 방식의 사용방법.  사용자가 입찰 가격을 제시해놓으면, 아마존에서 남는 인스턴스들에 대해서 Spot 가격을 책정하는데, 이 가격이 입찰가격 내로 들어오면 인스턴스가 기동되는 방식. 입찰 가격이 넘어가면 자동으로 Spot Instance는 다시 종료 된다. 인스턴스의 가동 시간을 예측할 수 없기 때문에, OLTP식의 일반적인 업무에는 적절하지 않고, Batch 나 분석 업무 같이 대규모의 컴퓨팅 자원을 분산해서 처리 하지만, 항상 인스턴스가 떠 있을 필요가 없는 업무에 적절하다.
아마존을 사용하고, 어느정도 EC2의 볼륨이 확정되면 Reserved Instance를 사용하는 것이 좋다. On-Demand는 가격이 비싸다.
그리고 Map & Reduce와 같은 OLTP용 서비스가 아닌 Batch나 계산 업무는 Spot Instance를 사용하는 것이 좋다.


MySQL HA over AWS 옵션

클라우드 컴퓨팅 & NoSQL | 2012.10.29 22:39 | Posted by 조대협

메모를 안해놓으면 또 까먹기 때문에, 정리 차원에서 몇가지 정리


1. MySQL HA over AWS

먼저 MySQL을 아마존 위에서 Zone간 Fail Over를 위해서 몇가지를 고민했다.


1) MySQL Cluster

MySQL의 클러스터링 버전으로, Zone간 Fail Over가 이론적으로 가능하다. 제품 자체도 기존 MySQL과 상당히 차별화 되어 있다.그러나 가격이 상당히 비싼 편이고, 아직은 AWS위에 deployment된 reference가 없기 때문에 상당한 risk를 둬야 한다.


2) Garela, Tungsten

오픈소스로 Replication을 보장하지만, 국내 Support가 없기 때문에, Bug Fix가 어렵다. 그래서 Pass


3) HAProxy

상당히 재미있는 개념인데, Proxy로 어떻게 DB Replication을 하느냐 하는 의문이 들었는데, 원리 자체는 쉽다. 양쪽 Zone에 MySQL을 배치한후, 그 앞에 HAProxy를 넣어서, SQL 부하를 양쪽에 똑같이 분산 시킨다(복제) 즉. insert SQL을 치면 양쪽에 모두 보내서 복제 하는 방식이다. Garela가 이런 방식의 구현 방식을 취한다고 한다.

그러나, 이 아키텍쳐의 경우 Application단에서, write/read를 명시적으로 나눠줘야 하고, error 핸들링이 어려우며 분산 트렌젝션 처리등이 어려운 제약 사항을 가지고 있다.


4) RDS
만사 제일 편한 옵션이기는 한데, 다양한 replication architecture 사용이 어렵다. 그리고 MySQL over EC2에 비해서 용량상 제약이 따른다.


5) Oracle Golden Gate

일단 내가 아는 DB Replication 솔루션 중에 최강이다. 그만큼 가격도 최강이다. 모 업체가 위의 옵션을 다 고민도 해보고 production에 적용도 해봤는데,결론이 OGG(Oracle Golden Gate)로 왔다.


기본적으로 이러한 여러가지 옵션이 존재하는 이유가, MySQL EE의 HA 옵션은 DBCR (Linux의 HA솔루션)을 이용하는 방식인데, 전통적인 HA 방식으로 서버가 죽으면, 상대편 서버로 HA하면서 IP를 옮기는 방식인데, 아마존에서는 작동을 안한다고 한다. 그리고 Fail over는 IP를 넘겨서 한다고 쳐도 (물론 back단에서는 MySQL 의 기능을 이용해서 data replicaiton을 해야 한다.) Fail Back이 어떻게 되는지에 대해서 상세한 시나리오는 없다.

조금 더 리서치가 필요한 영역이긴 한데, 이미 다들 안되는 방향으로 잡아서 더 이상 파보지는 않았다.


어제 발표된 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

 

Hadoop Architecture Overview

요즘 클라우드와 빅데이타 그리고 분산 컴퓨팅이 유행하면서 가장 많은 언급 되는 솔루션중하나가 Hadoop이다. Hadoop 이 무엇이길래 이렇게 여기저기서 언급될까? 본 글에서는 Hadoop에 대한 소개와 함께, Hadoop의 내부 동작 아키텍쳐에 대해서 간략하게 소개 한다.

What is Hadoop?

Hadoop의 공식 소개를 홈페이지에서 찾아보면 다음과 같다.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model. ’

정의를 요약하면, Hadoop은 여러 컴퓨터로 구성된 클러스터를 이용하여 큰 사이즈의 데이타를 처리하기 위한 분산 처리 프레임웍이다.

구조를 보면 엔진 형태로 되어 있는 미들웨어와 소프트웨어 개발 프레임웍의 형태를 띄고 있고, 대용량 데이타를 분산처리를 통해서 처리할 수 있는 솔루션으로, OLTP성의 트렌젝션 처리 (웹과 같이 즉시 응답이 필요한 시스템)보다는 OLAP성의 처리 (데이타를 모아서 처리 후 일정 시간 이후에 응답을 주는 형태)를 위해 디자인된 시스템으로 수분~수일이 소요되는  대규모 데이타 처리에 적합한 프레임웍이다.

Hadoop을 기반으로 한 여러가지 솔루션이 있으나 본 글에서는 Hadoop 자체에 대해서만 설명하도록 하겠다.

Map & Reduce의 기본

Hadoop의 분산 처리 방식은 기본적으로 “Map & Reduce”라는 아키텍쳐를 이용한다. Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계 (Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 

<그림 Map & Reduce의 기본 개념 >

예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자. 우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다. 이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만, 전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후, 그 결과를 하나로 더하면, 조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다. 이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce를 하기 위해서는 Input 데이타를 저장하고, 이 데이타를 조각으로 나눠서 저장하고, 조각에서 처리된 임시 결과를 저장 그리고 합쳐서 저장할 각각의 저장 공간이 필요하다. 이 공간은 전체 분산 처리 시스템에 걸쳐서 접근이 가능해야 하고, 대용량의 데이타를 저장할 수 있어야 하는데, Hadoop에서는 이 공간으로 분산 파일 시스템 (Distributed File System)을 사용하며, 이를 HDFS (Hadoop Distributed File System)이라고 한다. 그리고 위에서 설명한 것 처럼 MR을 위해서 데이타를 처리하는 부분을 Map & Reduce 모듈이라고 한다.

사용 시나리오

Hadoop Map & Reduce는 대용량 데이타에 대한 분석에 대해서 최적화 되어 있다.

즉 웹 시스템이나 OLTP (Online Transaction Processing)과 같은 1~5초내에 응답이 오는 형태의 Request/Response 방식의 Synchronous 형식의 시나리오에는 적합하지 않고, Input을 넣은 다음 수분 후에 결과를 받아서 보는 비동기 (Asynchronous) Deferred 형태의 시스템에 적절하다.

 수학적 계산을 위한 연산 처리, 대규모 저장 및 분석, BI (Business Intelligence)와 같은 데이타 분석과 같은 후처리(지연처리) 중심의 분석 시나리오에 적합하다.

Hadoop 구성

앞에서 설명한 것과 같이 Hadoop은 크게 분산 데이타 처리를 하기 위한 Map & Reduce 모듈(이하 MR) MR Input/Output 데이타를 저장하는 파일시스템인 HDFS (Hadoop Distributed File System)으로 구성되어 있다.

HDFS (Hadoop Distributed File System)

HDFS는 분산 데이타 처리를 위해서 데이타를 저장하기 위한 파일 시스템으로, 다음과 같은 특징을 가지고 있다.

  • 대용량의 파일 (페타 바이트)을 저장할 수 있다.

  • 많은 수의 파일을 저장할 수 있다.

  •  Streaming Data Access

  •  Commodity Hardware

  • Multiple writers, arbitrary file modifications

HDFS의 구성 컴포넌트는 크게 두가지로 나뉘어 진다. (Namenodes, Datanodes).

Namenodes

Namenodes는 일종의 Master node로 파일에 대한 메타 데이타를 저장하는 노드로, 디렉토리 구조, 파일에 대한 각종 메타 데이타, 그리고 물리적 파일이 저장되어 있는 위치등을 저장한다.

Datanodes

Datanodes는 실제 파일을 저장하고 읽어온다. 하나의 파일을 블록이라는 단위로 나눠서 저장하는 역할을 수행한다. 그리고 Namenodes와 주기적으로 통신하여 저장하고 있는 블록에 대한 정보를 Namenodes에 저장하도록 한다.

Namenodes에는 모든 블록에 대한 메타정보가 들어와 있기 때문에, Namenodes가 장애가 나면 전체 HDFS 이 장애가 나는 SFP ( Single Failure Point )가 된다. Namenodes에 대한 이중화가 필요하다. Namenodes에 대한 이중화 방안에 대해서는 추후에 설명하도록 한다. Namenodes SFP로 작용하는 것은 Hadoop 운영상에 아주 중요한 운영 포인트로 존재한다. 근래에는 HDFS의 약점을 보완하기 위해서 GlusterFS Hadoop을 지원하면서, 파일 시스템으로 HDFS를 사용하는 대신 GlusterFS로 대처할 수 있다.

블럭 (Block)

블럭은 HDFS에서 Read Write를 하는 최소 단위이다. 하나의 파일을 여러개의 블럭으로 나눠서 저장된다. Hadoop의 블럭 사이즈는 일반적인 파일 시스템의 블럭사이즈 ( Kilobytes – 일반적으로 파일시스템에서는 512 KB )에 비해서 큰 블럭사이즈를 사용한다. Hadoop에서는 디폴트로 64MB를 사용하고, 보통 128MB를 사용한다.

클 블럭사이즈를 사용하는 이유는, MR 처리에 있어서 Map Task가 하나의 파일 사이즈 단위로 처리하기 때문에, 작은 파일 억세스 보다는 Map Task 단위로 처리할 수 있는 단위가 필요하다. (이것이 블럭) 이를 위해서 큰 사이즈 단위로 파일 처리를 할 수 있는 블럭을 지정하는 것이다.

또한 블럭 크기를 크게 함으로써, 해당 파일에 대한 Seeking Time을 줄일 수 있고, 블럭 사이즈를 적게 하면 Master Node에서 저장 및 처리해야 하는 데이타의 양이 많아지기 때문에 Master Node에 많은 부하가 걸리기 때문에 큰 블럭 사이즈를 사용한다. 이런 이유로 반대로 블럭 사이즈가 작거나 사이즈가 작은 데이타 처리의 경우 Hadoop에서는 충분한 분산 처리 성능을 기대하기 어렵다.

HDFS는 대규모 분산 처리에 필요한 대용량 input 데이타를 저장하고 output 데이타를 저장할 대용량 파일 시스템을 지원한다. HDFS 시절 이전에는 고가의 SAN (Storage Area Network)장비나 NFS 장비를 사용했어야 했는데, Hadoop은 일반 x86 서버에 Disk를 붙인 형태의 저가의 서버 여러개를 연결하여 대규모 분산 파일 시스템을 구축할 수 있게 해줌으로써, 값비싼 파일 시스템 장비 없이 분산 처리를 가능하게 해주는 것이다

Read/Write Operation

1) Read Operation

Client에서 Read를 수행하면, 먼저 Client SDK Namenode에 해당 파일의 데이타 블럭들이 어디에 있는지 블록의 위치를 먼저 물어온 다음에, 순차적으로 해당 데이타 블록이 저장되어 있는 datanodes로 부터 데이타를 블록을 읽어온다.

 

<그림. HDFS Read Operation >

이 과정에서 Namenode라는 놈이 아주 기특한 일을 하는데, 기본적으로 HDFS는 하나의 파일 블록을 저장할때 하나의 datanode에 저장하는 것이 아니라 N개의 datanode에 복제해서 저장한다. (장애 대응을 위하여). Namenode가 블록의 위치를 리턴할때, Hadoop Client로 부터 가까운 곳에 있는 datanode (같은 서버, 같은 Rack, 같은 데이타 센터 순서로..)를 우선으로 리턴하여 효율적인 Read Operation을 할 수 있도록 한다.

2) Write Operation

 

<그림. HDFS Write Operation>

파일 블록 저장은 약간 더 복잡한 과정을 거치는데

파일을 Write를 요청하면,

     먼저 Namenode에서 File Write에 대한 권한 체크등을 수행한다.

     Namenode에서 파일이 Writing Block의 위치한 Datanode를 리턴한다. (1)
파일을 쓰다가 해당 블록이 다 차면, Namenode에 다음 Block이 저장되는 Datanode의 위치를 물어본다.

     Client Stream을 통하여 해당 Datanode Block에 파일을 Write한다. (2)

     Write된 파일을 복제 Datanodes (※ 여기서는 복제노드와 원본 노드를 포함하여 총 3개의 노드가 있다고 가정하자)로 복제(복사)한다. (3,4)

     복제되는 Datanodes들 쌍을 pipeline이라고 하는데, 내부 정책에 따라서 서로 복제할 Datanodes들을 미리 정해놓고 이를 통해서 복제한다. (pipeline Datanode의 물리적 위치 – Rack, 데이타 센터 등을 고려해서 자동으로 결정된다.)

     복제가 모두 끝나면 ACK를 보낸다. (5,6,7)

     파일 Writing을 완료한다.

 

이번 글에서는 간단하게 Hadoop에 대한 개념 소개와 Hadoop의 하부 파일 시스템인 HDFS에 대해서 알아보았다. 다음 글에서는 Hadoop의 Map & Reduce Framework에 대해서 살펴보기로 한다.

 

Amazon EC2의 내부 구조에 대한 고찰이 있는 글이 있어서 링크
http://openfoo.org/blog/amazon_ec2_underlying_architecture.html

1. Xen Server 쓰는 건 다 아는 사실이고
2. EBS를 iSCSI 기반 GNDB (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/GFS_6.0_Administration_Guide/ch-gnbd.html) 를 쓴다는 게 참고할만한 내용

Elastic Block Store

The characteristics of the Elastic Block Store (EBS) lead to the conclusion that it is probably a SAN-based setup. I have guessed that they probably use iSCSI volumes exported to the nodes, and I was surprised that they use something different: Global Network Block Device (GNBD). The backend device of a EBS is listed as something like params = "/dev/gnbd89". Of course I don’t know how the block device exporter is designed and what kind of storage system they use on that side. Some more information about GNBD can be found here, which could also lead to the conclusion that Amazon uses RedHat’s cluster suite.




Amazon EC2 Auto Scale out 아키텍쳐http://docs.amazonwebservices.com/AutoScaling/latest/DeveloperGuide/index.html?Welcome.html

  1. Cloud Watch를 통해서, 이미 기동중인 Instance를 모니터링 한다.
  2. Instance의 CPU나 Throughput을 기반으로 해서 Scale out 여부를 결정한다
  3. Scale out을 하게 되면, 해당 Instance의 AMI를 추가로 Provisioning 한다.
  4. Elastic Load Balancer에 새롭게 추가된 Instance를 연결해준다.

기본적인 아키텍쳐인데, 전형적인 Scale Out 방식이고, Image에 올라가 있는 (VM)의 Application의 Scale out은 지원하지 않고, 개발자 스스로 대비해야 한다.
Apache와 같은 웹서버나, 클러스터링이 되어 있지 않은 Tomcat과 같은 WAS는 가능하겠지만, 아래 글에서 처럼, Oracle이나 MySQL과 같은 DBMS나 JMS등은 Scale out 자체가 불가능 하기 때문에, 자체로 클라우드 대비 아키텍쳐로 디자인 해야 한다. 

 아마존 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)를 가지고 있으며, 각각의 특성도 매우 다르기 때문에, 업무의 특성을 이해하고, 기술의 특성을 이해해서 클라우드 지향형 아키텍쳐를 설계해서 시스템을 개발해야 한다. 이러한 이해가 없이 그냥 서비스를 클라우드에 배포한다면, 오히려 더 낮은 안정성과 성능 그리고 높은 비용을 지불해야 할 것이다.

 

 

클라우드 서비스중 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)등의 기능이 제공되어야 한다.