Amazon EC2 소개 (개정)

아마존의 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를 사용하는 것이 좋다.