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


Archive»


 
 
I have summarized some of the follow-ups below as discussed: User Data and Meta Data – that can be used for bootstrapping as we discussed and I showed you a demonstration of - documentation: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html IP Addresses in VPC Auto Scaling Groups: Auto Scaling will automatically assign IP addresses using the DHCP provider when a new instance is launched. However, you could bootstrap it to assign additional IP addresses, using the Elastic Network Interface. Please be sure to consider the following too: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#MultipleIP Scaling Down Policies: For Auto Scaling Group policies, please use the following syntax when defining the scale down policy (notice how the negative adjustment value requires an "=" sign to work correctly: as-put-scaling-policy policy_scaledown1 --type ChangeInCapacity --auto-scaling-group koreaASG --adjustment=-1 --region ap-southeast-1 AWS Labs: Please download the AWS Labs that I showed you from the following location. It has step-by-step instructions for many scenarios and is a good way to get "your hands dirty" with the various services. It covers Auto Scaling as well as VPN connectivity to VPC using software-VPN. https://aws-labs.s3.amazonaws.com/latest/AWS%20Labs%20Workbook%20v2.2.zip?AWSAccessKeyId=AKIAI4BYU4OOGEEU5JZQ&Expires=1356896712&Signature=70P0jfBWqZkHy%2BO9hREOYJb5zWY%3D Custom Metrics: I have attached the step-by-step exercise we talked about for setting up custom metrics monitoring. These scripts are written in Perl, but you can use your own favorite language (I believe your preference is Java). For Java you can use the PutMetricDataRequest API. Custom metrics cost USD 0.50 per metric per month. Chef and CloudFormation: Please see below for the article on using CloudFormation with Chef configuration management: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC8QFjAA&url=https%3A%2F%2Fs3.amazonaws.com%2Fcloudformation-examples%2FIntegratingAWSCloudFormationWithOpscodeChef.pdf&ei=GKqpUKGlEcbprQeY84GYAg&usg=AFQjCNE8MEewryO9PWVzBC5e086rEWYAwA&cad=rja Also see this link for a range of CloudFormation articles: http://aws.amazon.com/cloudformation/aws-cloudformation-articles-and-tutorials/ CloudFormation Services Not Supported: These are some of the services not supported by CloudFormation (at least not yet). You can see the up-to-date list of supported resources here. Not supported are: Elastic MapReduce, Amazon Fulfillment Web Services, CloudSearch, Simple Workflow Service, Simple Email Service, AWS Direct Connect, Flexible Payment Services, Simple Pay, DevPay, Glacier, Import/Export, Storage Gateway, Alexa, Mechanical Turk. I am still trying to confirm the roadmap for SWF global expansion and Provisioned IOPS. Thanks. Oyvind

AWS (Amazon Web Service) 사용시 주의 사항


1. IP가 매번 바뀐다.

aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다.


2. io bandwidth를 믿지 마라

aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또는 application server간에 네트워크 대역폭이 느리고 또는 일정하지 않기 때문에 대 부분의 병목이 여기서 발생한다.

이를 해결하기 위한 방법은 큰 ec2 instance를 사용하면 높은 대역폭을 사용할 수 있으며,

Provisioned IOPS를 지원하는 ec2 instance의 경우에는 일정 수준의 IOPS를 보장해준다. (물론 돈을 내야 한다.)

또는 고 성능의 IOPS를 보장하는 인스턴스를 사용하는 것도 방법이 된다.

다른 방법으로는 Placement group이라는 옵션을 사용할 수 있다. 이는 clustering이 필요한 솔루션 (Nosql이나 cache 솔루션)을 사용할때 이 placement group을 이용하면, 해당 서버들을 가능하면 물리적으로 가까운 곳에 위치 시켜서, network 지연을 최소화 한다.

참고 http://bcho.tistory.com/630


3. 미리 resource를 확보해라.

EIP는 5개, EC instance는 20개가 처음 계정을 만들었을때 디폴트 값이다. 테스트 환경을 사용하거나 몬가 하다보면 eip나 ec2 instance가 모자르게 되는데, 미리 미리 확장에 대비해서 확보해놓는 것도 중요하다. 신규 신청시 시간이 걸리기 때문에 미리 신청해놔야 하며, 상품에 따라서 미리 확보해놓으면 과금이 될 수 있다. 아래는 디폴트로 확보되는 자원의 수이다.

EIP – 5
EC2 instance – 20
EBS Volumes – 5,000 volumes or an aggregate size of 20 TiB (max volume size is 1TB)
PIOPS - 10,000 Provisioned IOPS or an aggregate size of 20 TiB (whichever is smaller) S3 Buckets – 100 
Route53 - 100 Hosted Zones and 10,000 Resource Record Sets per Hosted Zone 
ELB - 10 concurrent load balancers 
RDS – 20 RDS MySQL instances (each instance has hard limit max 1024GB) and up to 5 Read Replica instances can be created from a Master. 
VPC – 5 VPCs, 20 subnets each, 50 Security Groups each, 50 rules per Security Group and 5 Security Groups per instance. 10 Network ACLS per VPC, 20 rules per ACL. 10 Route Tables per VPC and 20 entries per route table


4. 가급적이면 VPC를 사용하자.

VPC는 Virtual Private Cloud의 약자로 10.x.x.x 와 같은 내부 ip 대역을 사용할 수 있게 해준다. 이는 논리적으로 다른 서비스(다른 사용자의)와 분리하게 해줄뿐더러, ip를 고정으로 사용할 수 있게 해주시 때문에 위의 1번 문제를 회피할 수 있도록 해준다.


5. 과금에 관련해서.

안쓸때는 꺼놔라. 다 과금 된다.

1시간5분을 사용하더라도 2시간으로 과금된다. 서버의 startup과 down은 시간 단위로 하자.


6. RDS

최대 용량이 1TB이다. 장점은 AZ(Zone)간의 HA를 기본적으로 지원한다.

replica는 db당 최대 5개 까지만 지원한다.


7. multicast

AWS는 multicast를 지원하지 않는다. 상당수의 클러스터링 솔루션이 muticast를 사용하는 경우가 많다.(Oracle RAC) 이경우에는 AWS에서 클러스터를 사용할 수 없다.


8. ELB는 고정 IP가 아니다.

ELB는 HA와 확장성을 지원하기 위해서 DNS Round Robine 방식으로 연결된다. 즉 고정 IP를 사용할 수 없다. 시스템에 대한 접근 IP(방화벽등을 위해서)가 필요할 경우 ELB 앞단에 HA Proxy등 별도의 Proxy를 둬야 한다.


9. AWS에는 IDS가 없다.

기본적으로 탑재된 침입 탐지등의 ids/ips 솔루션이 없기 때문에, 보안이 중요한 경우 이를 사전 고려 해서 ec2 위에서 기동 될 수 있는 ids/ips 솔루션을 탑재하는 것이 좋다.


10. 장기적인 이용에는 on-demand instance를 이용하지 마라.

on-demand instance는 그때 그때 사용하기는 좋지만 과금 모델이 가장 비싸다. 어느정도 기간을 가지고 이용할 예정이면 reserved instance나 spot instance를 이용하는 것이 저렴하다.






요즘 일이 바뻐서 블로그 포스팅을 거의 못하고 있습니다.
많이 버는 만큼, 그동안 충전해왔던 지식이나 노하우를 주로 방전하는 느낌입니다.

어쨌거나, 클라우드의 양대 산맥인 아마존 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 단으로 오픈을해서, 조금 더 선택의 폭을 넓혀 줬으면 합니다.
이상 사견이었습니다.

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

 

 


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/ 를 참고하기 바란다.