AWS - EC2

Contents

EC2(Elastic Compute Cloud)는 컴퓨팅 파워를 제공하는 AWS의 클라우드 서비스다. Elastic(탄력적)이란 수식어가 붙은 만큼, 탄력적인 운용이 특장점이다. 예컨데, 필요 할 때, 필요한 만큼만 쓰다가 필요 없으면 언제든지 인스턴스를 내릴 수 있다. 인스턴스를 내리거나 혹은 삭제하더라도 볼륨(volume)을 보관할 수 있으므로, 원할 때 복구할 수도 있다.

EC2가 생각만큼 (성능 대비)저렴하지 않다고 한다. 나 역시 그렇게 생각한다. 하지만 이건 어디까지나 EC2 만을 떼어 놓고 생각 했을 때 그렇다는 이야기다. 서비스 규모가 좀 커져서 EC2를 AWS의 다른 서비스를 연결 하려다보면, 왜 AWS를 사용해야 하는지 느낌이 온다.

예를들어 OpenAPI를 제공하는 메시징처리 인프라를 구축한다고 가정할 때, 필요한 컴포넌트들을 한번 나열해 보자.

1. EC2 Instance : 기본이다.
2. Load balancer : 당연히 필요하다.
3. Message queue : Message queue 자체는 특이할게 없는 기술이다. 하지만 가용성과 확장성을 고려해서 설계할 경우 전혀 다른 기술적이슈를 해결해야 한다.
4. 공유메모리 : 인스턴스들간 공유해야 할 공유메모리 인프라.
5. RDBMS : 그 자체로는 특별한 기술이 아니지만, 가용성/확장성을 확보하려면 상당한 경험과 노력, 시행착오가 필요하다.
6. NoSQL 솔류션
7. Object Stroage
8. 보안
9. 멀티미디어를 처리해야 할 경우 이와 관련된 솔류션들
10. CDN
11. Auto scaling & 모니터링
12. 하드웨어 유지보수

큰 꼭지들만 나열한게 이렇다. 이러한 컴포넌트들을 개발하고 연동하고 유지/보수 해야 한다고 생각해보라. AWS를 이용하면, 이들 이슈의 상당부분을 AWS 인프라에 떠 넘길 수 있다.

AWS는 인스턴스를 만들기 위해서 AMI(Amazon Machine Images)이라는 독자적인 머신 이미지를 제공한다. AWS는 자주 사용하는 운영체제들에 대한 AMI를 만들어서 배포하고 있다. 이들 AMI는 아마존에서 제공하는 툴들이 설치되서 배포되기 때문에, AWS의 다른 컴포넌트들과 쉽게 연동할 수 있다는 장점이 있다. AWS에서 패키지들을 직접관리하기 때문에, AWS의 기본 AMI를 사용하는 경우가 많다.

https://lh5.googleusercontent.com/-zfxL9d3oziE/UXGFjZZmz1I/AAAAAAAADBI/YsLTVc_o7qM/s800/rds05.jpg

유저가 자신의 목적에 맞는 AMI를 직접 만들어서 올릴 수도 있다. AWS에는 다양한 용도의 유저생성 AMI들이 있는데, 이들을 이용하면 쉽게 자기가 원하는 서비스를 만들 수 있다. AMI는 마켓플레이스와 연동할 수도 있어서, 기업이나 개인이 자신들이 개발한 서비스를 배포하기 위한 채널로도 사용한다. 때에 따라서는 비용을 지불해야 하는 AMI도 있다. aws marketplace를 방문해 보자. Ruby 개발 환경에서, Wordpress, MongoDB, SAP, CentOS, OpenVPN, NginX 서버 등등 다양한 AMI들이 준비돼 있다.

AWS는 다양한 종류의 EC2를 제공한다. 주로 Core 개수와 메모리 크기에 따라서 대략 15개 정도의 tier로 구분된다. 각 tier내에서는 볼륨 크기, IOPS등을 이용한 세부적인 튜닝이 가능하다. 물론 tier마다 비용에 차이가 있으니, 서비스에 맞는 녀석을 사용해야 함은 당연하다. 주로 사용하는 표준 인스턴스와 마이크로 인스턴스만 정리했다. 다른 인스턴스(고성능, 클러스터링등)등에 대한 내용은 http://aws.amazon.com/ko/ec2/pricing/ 를 참고하자.

1세대(M1) 표준 인스턴스	메모리	로컬 인스턴스 스토리지	컴퓨팅 유닛
스몰	1.7GiB	160GB	1 ECU
미디엄	3.75GiB	410GB	2 ECU
라지	7.5GiB	850GB	4 ECU
엑스트라 라지	15Gi B	1690GB	8 ECU[1]

2세대(M3) 표준 인스턴스	메모리	로컬 인스턴스 스토리지	컴퓨팅 유닛
엑스트라 라지	15GiB	EBS 전용	13 ECU
더블 엑스트라 라지	30GiB	EBS 전용	26 ECU

마이크로라는 이름처럼 매우 저렴한 비용으로 사용가능한 저사양의 인스턴스다. 하지만 이게 다가 아니다.

마이크로 인스턴스는 호스트의 CPU 자원을 경합하는 방식으로 탄력적으로 CPU 자원을 소모할 수 있다. 아래는 M1.스몰과 마이크로 인스턴스의 CPU 사용 레벨을 보여주고 있다.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/Micro_General_Comparison_to_m1small.png

m1.small는 고정된 CPU레벨을 가지고 있다. 반면 마이크로는 background와 Max 레벨에서 CPU자원을 사용할 수 있다. 예컨데, 평소에 CPU를 많이 소모하지 않을 때는 background 레벨에서 CPU를 사용하다가, CPU자원 사용량이 늘면 MAX CPU 레벨까지 CPU를 사용할 수 있다.

물론 항상 MAX CPU 레벨을 사용할 수 있는건 아니다. 호스트에서 제공하는 CPU를 두고 다른 마이크로 인스턴스들이 서로 경합을 벌이기 때문이다. 만약 경헙을 벌이는 인스턴스들이 적다면, 비교적 높은 수준에서 CPU를 사용할 수 있을 것이고, 그렇지 않을경우에는 충분한 CPU 파워를 얻지 못할 거다.

마이크로 인스턴스는 주기적으로 CPU를 소비하는 웹 서비스나, 배치작업 처리에 적당한 인스턴스 타입이다. 가격이 m1.스몰의 1/3 정도이므로 서비스 특성에 따라서, m1.스몰대신 사용하는 것으로 비용을 아낄 수 있다.(잘만 튜닝한다면, 성능도 올릴 수 있을 것이다.)

여기에서 Auto provisioning는 운영체제의 auto provisioning와 소프트웨어의 auto provisioning를 모두 포함하는 개념이다.

운영체제 auto provisioning는 손으로 운영체제를 설치하고 켜는 것을 자동화하겠다는 것 이상의 의미다. Auto provisioning관리하려고 하는 시스템의 형상을 코드화 하고, 그 코드를 로직(프로그램)을 이용해서 실행하는 것이다. 서비스의 유지/보수, 품질에 직접적으로 관련된다. 예전부터 운영체제 프로비저닝은 "노가다"였는데, 노가다를 자동화 함으로써 남는 시간에 서비스의 다른 측면에 노력을 기울일 수 있는 혜택도 덤으로 누릴 수 있다.

인스턴스의 auto provisioning, 운영체제와 소프트웨어의 형상을 관리하기 위한 (아마도)백가지 쯤 되는 방법들이 있는 것 같다. 이것들을 다 섭렵할 수는 없는 노릇이라서, 그냥 내 생각을 정리하려 한다.

일단 AWS에서 제공하는 cloudformation, Opsworks와 같은 툴이 있고, 몇몇 (chef 기반으로 된 것들도 본적이 있다.)상용툴들도 있는 것 같다. 이들 제품을 보고 얻은 결론은 다음과 같다.

• 이런 툴들은 퍼블릭한 환경을 대상으로 한다. 대다수가 사용하기에는 무난한 툴이지만, 자신의 시스템/네트워크 환경에 맞춰서 제대로 관리하려고 하면 한계가 보인다.
• 관리 시스템 구축을 위한 팀이 제대로 운영되고 있다면, 자신의 환경에 맞게 직접 만드는게 낫다.
• 예전 같으면 직접 만드는 걸 권하지 않았을 것이다. 그때는 그냥 중구 난방이었다. 100개의 시스템/네트워크 환경이 있었다면, 이를 관리하기 위한 100가지 방법이 있었다. 제대로 된 툴이 없이 능력껏 구성하다 보니 그렇게 된거다.
• 지금은 좋은 툴들이 많다. Chef, puppet, cloud-init 여기에 AWS에서 제공하는 툴들을 잘 조합하면, 자신의 환경에 최적화된 시스템을 구축할 수 있다.

내가 선택한 툴은 chef와 AWS의 user metada의 조합이다. 대략의 구성은 다음과 같다.

Standard AMI

• 표준 운영체제는 하나 만들어서 AMI로 떠 놓는다.

Chef-server

• Chef-server로 운영체제와 소프트웨어 형상을 관리한다.
• Domain 이름 기반으로 role을 적용한다. 예컨데, web01.myservice.com 이라면 web role을 적용한다. 이 role은 대략 apache, php 기타등등 웹 서비스를 위한 cookbook을 가지고 있을 거다.

Linux package repository

• 운영체제와 소프트웨어 버전관리를 위한 레포지토리는 운용해야겠다.

Instance metadata AWS는 인스턴스에 대한 메타정보를 관리하고 있다. 유저는 언제든지 인스턴스의 메타정보들 - 인스턴스 ID, 생성일, 상태, 네트워크 정보, ssh-key 등등 - 을 확인할 수 있다. 인스턴스에서 GET http://169.254.169.254를 호출하면 호출한 인스턴스의 메타정보를 JSON 형태로 돌려준다.

user-data 중요한 점은 Instance metadat에 유저 데이터를 설정할 수 있다는 점이다. Key-Value 형식으로 설정하면, 언제든지 값을 가져올 수 있다. 필요하다면 파일을 올릴 수도 있다. 물론 실행파일도 올릴 수 있을테고, 나중에 인스턴스의 초기 설정등에 사용할 수 있을 거다. user-data 에서 가장 중요한 설정은 인스턴스의 도메인 이름을 박는 거다.

이제 Instance를 만들면 아래의 과정을 따라서 프로비저닝 된다.

1. EC2 API를 이용해서 Standard AMI로 부터 instance를 만든다.
   • 인스턴스를 만들 때, 도메인 이름을 user-data에 설정한다.
2. 인스턴스가 뜬다.
3. init-script를 수행한다.
   • script는 인스턴스 메타데이터에서 도메인 이름을 가져온다.
   • 도메인 이름을 가져왔면, 호스트 이름을 설정한다.
4. chef-client를 수행한다.
   • chef-client는 자신의 호스트 이름으로, chef-server에 등록한다.
5. chef-server는 cookbook을 내려주고
6. cookbook을 실행해서 운영체제와 소프트웨어를 설정한다.

AWS는 cloudwatch라는 모니터링 툴을 제공한다. Cloudwatch를 이용하면, EC2를 비롯한 AWS의 거의 모든 자원을 모니터링할 수 있다.

• EC2 인스턴스
• EBS 볼륨
• ELB
• RDS
• SQS
• SNS
• DynamoDB
• Storage gateway
• Elastic MapReduce
• Autoscaling 그룹

EC2에서 수집할 수 있는 주요 매트릭은 다음과 같다.

• CPU 사용율
• Disk 평균 Read/Write
• Disk Read/Write count

기초 모니터링 자료로는 쓸만하지만, 제대로 모니터링 하기에는 뭔가 많이 아쉽다. 다행히 커스텀 매트릭을 추가할 수 있기는 한데, 그렇다고 하더라도 아래의 제한들 때문에 본격적인 모니터링 툴로 사용하기에는 많이 부족하다.

• 매트릭의 종류에 따라 다르지만 5분 미만의 주기로 수집할 수 없는 매트릭이 있으며, 어떤 매트릭의 경우 1분 주기로 수집하려면 비용을 지불해야 한다.
• AWS API 요청은 무한대가 아니다. 제한이 있다. 50개 정도의 인스턴스를 관리한다고 가정하고, detect time을 줄이기 위해서 5개 정도의 인스턴스를 1 분단위로 수집한다고 하면, 1시간에 15000번의 API를 호출한다.
• AWS console로 모니터링 정보를 볼 수 있지만, 이걸로는 제대로 된 정보를 얻기가 함들다. 결국 매트릭 정보를 수집해서 별도의 데이터베이스에 적재한다음 모니터링 정보를 리포팅 해주는 시스템을 개발해야 한다.
• Cloudwatch에서 제공하는 이벤트 알람 기능은 제한적이다. Auto scaling을 위한 알람용도로는 활용할 수 있지만, 본격 모니터링 이벤트 알람용으로 사용하기에는 부족하다.
• 결국 : Cloudwatch는 기초자료 수집용이다. 모니터링 시스템을 구축해야 한다.

모니터링 시스템 구축은 그냥 zabbix를 믿고 가자.

EC2의 보안은 Security group(이하 sg)와 IAM으로 이루어진다.

sg는 "네트워크 보안" 영역을 담당한다. sg는 네트워크 장비에서 제공하는 패킷필터링 서비스라고 보면 된다. 가상화영역에서 보자면 Host 에서 제공하는 방화벽이다. 리눅스 가상화 시스템에서는 iptables를 이용해서 구현한다. 유저는 sg를 설정하는 것으로 inbound 트래픽과 outbound 트래픽에 대한 패킷을 필터링 할 수 있다.

기본설정은 inbound트래픽은 ALL DENY, outbound 트래픽은 ALL ALLOW이다. 아래는 sg의 전형적인 사용예이다.

1. 80번 포트와 443 포트는 각각 HTTP와 HTTPS 서비스를 위해서 inbound 패킷을 허용한다. 모든 인터넷에서의 접근을 허용해야 하기 때문에 0.0.0.0/0 네트워크를 허용한다.
2. 22번 포트는 시스템/네트워크 관리자를 위해서 열어 놓는다. ssh는 함부로 접근하면 안되기 때문에, 특정 네트워크(x.x.x.x/32)에서만 접근할 수 있도록 허용한다.

IAM은 AWS 자원에 대한 접근권한을 담당한다. IAM을 이용해서 유저를 만들고, 유저별로 (거의 모든)AWS 자원에 대한 접근권한을 설정할 수 있다.

https://lh3.googleusercontent.com/-lauvW8NGyY4/UfIFyHlQ7MI/AAAAAAAADL4/HHjhCpwy3zE/s640/vpc_security_group.jpg

유저보안은 [Site/System_management/AddcountSecurity 리눅스 유저보안]문서를 참고한다.

VPC를 이용하면, 퍼블릭 네트워크 상에 사설 네트워크를 만들 수 있다. 사설 네트워크를 만드는 이유는 다음과 같다.

1. 자유로운 네트워크 구성.
   • EC2 영역의 사설 IP는 유저가 제어할 수 없다. 지맘대로 만들어지고, 그나마도 고정되는 것도 아니라서 관리하기가 쉽지 않다.
2. VPC는 10.0.0.0/8 에서 자유롭게 네트워크 환경을 구성할 수 있다.
3. 보호해야 할 자원을 퍼블릭 네트워크로 부터 숨길 수 있다.
4. 오피스 네트워크와 VPN을 통해서 연결, 독립된 관리 네트워크를 구성할 수 있다.

VPC와 관련된 내용은 VPC 구축문서를 참고하자.

EC2 인스턴스는 private ip와 public ip 그리고 [wikiSite/cloud/AWS/EIP EIP]를 가진다. 인스턴스가 만들어지면 인터페이스에 AWS region에서 사용할 수 있는 private ip가 할당 된다. Private ip는 DHCP를 통해서 할당이 된다. 이 IP는 유저가 변경할 수 없다.

Public ip는 NAT 서비스를 통해서 할당하는데, 역시 AWS가 자동으로 할당하며 유저가 변경할 수 없다.

AWS가 할당하는 private ip와 public ip는 "고정적"이지 않다. 예컨데, 인스턴스가 재시작 하는 등의 이유로 ip가 변경될 수 있다. 따라서 public ip와 private ip만으로는 인터넷 서비스를 하기가 힘들다.

인터넷 서비스를 하려면 고정된 IP가 필요한데, AWS는 EIP(Elastic IP)라는 이름의 고정아이피 서비스를 제공한다. EIP는 유저의 자원으로 할당 받은 EIP를 자유롭게 인스턴스에 떼었다 붙였다 할 수 있다. 물론 EIP에는 과금이 된다. EIP 하나까지는 공짜, 그 이후로 비용이 추가된다.

AWS의 네트워크의 최소단위 그러니까 L2로 묶이는 단위는 zone이다. 따라서 같은 zone에 있는 인스턴스들 끼리는 private ip를 이용해서 통신이 가능하다. 다른 zone의 인스턴스와 통신하려면, public ip(혹은 EIP)를 이용해야 한다. 과금정책도 이에 따라 달라진다. 같은 zone에 있는 인스턴스들과의 통신에는 네트워크 과금이 되지 않는 반면, 다른 zone의 인스턴스와의 통신은 과금이 된다.

같은 zone에 있는 인스턴스들 끼리는 private ip로 통신하도록 한다. 네트워크 관리에 도움이 될만한 정보 Region별 EIP Network 대역

리눅스 운영체제를 기반으로 설명한다.

EC2 인스턴스로 접근하기 위해서는 아래 두가지 조건을 확인해야 한다.

1. Security group : ssh(22번 포트)에 대한 inbound 트래픽을 허용해야 한다.
2. SSH key pair : 유저는 (AWS console을 이용해서)ssh key pair목록을 관리할 수 있다. 유저는 AWs console 명령을 이용해서 private key와 public key를 만들수 있다. public key는 AWS에 저장하고 있다가 인스턴스가 만들어 질 때, 시스템 유저에 복사한다. 유저는 private key를 로컬 시스템에 저장하고 ssh client(putty 등)을 이용해서 접근하면 된다.

AWS에서의 운영체제 점유율이다. 2013년 6월 데이터다. 참조 - EC2 Statistics

http://gigaom2.files.wordpress.com/2013/06/aws-ec2-usage-by-operating-system.jpg

리눅스 운영체제가 80% 이상의 점유율을 보이고 있다. 각 리전별 HTTP ping 응답 속도를 검사할 수 있다. 서비스 리전을 선택할 때 혹은 리전의 네트워크 상황을 검사할 때 유용하게 사용할 수 있다. 클라이언트(웹브라우저)에서 aws region의 지정된 URL에 대해서 HTTP 질의 하는 방식이다.

• CloudPing

AWS 서비스는 "필요한 만큼 쓰고, 쓴 만큼 지불한다" 라는 정책하에 설계됐다. 이 정책하에서 유저는 상당한 자유도를 가지고, 유저가 사용할 자원에 대한 비용을 계획할 수 있다.

자유를 제대로 누릴려면 댓가가 필요하다고 배웠던 기억이 난다. AWS의 경우에 그 댓가는 "비용"이다. 아는 만큼 그리고 부지런한 만큼 비용을 절약할 수 있다.

서비스의 가용성을 높이기 위해서, 인스턴스를 AV zone으로 분리해서 구성하기도 한다. 하나의 zone의 네트워크가 맛이가더라도 다른 zone의 인스턴스가 계속 서비스를 하도록 하기 위함이다.

AWS는 같은 zone 내에서의 트래픽에 대해서는 과금하지 않지만, 다른 zone으로 흐르는 트래픽에 대해서는 과금을 한다. 따라서 가용성 때문에 AV zone을 구성했다고 하더라도, 가능하면 트래픽이 zone을 넘나들지 않도록 해야 한다. 하지만 가용성을 만족하면서, 트래픽까지 관리하는 건 쉬운일이 아니다. 아래의 구성을 보자.

가용성을 확보하기 위해서는 웹 서버 뿐만 아니라 데이터베이스도 가용성을 유지해야 하는데, 결국 웹 서버중 하나는 Active 데이터베이스에 붙기 위해서 AV zone을 건너 뛰어야 한다[2] .

이론은 괜찮은데, 가용성의 확보가 필요한 경우 쓸만한 팁은 아니다.

"이벤트" 라든지 "마케팅 효과" 기타 등등의 이유로 트래픽 유입이 늘어나서 서비스를 감당하기 힘들어 지면, scale-in 하거나 scale-out 둘 중 하나의 방법으로 늘어난 트래픽에 대응해야 한다.

Auto-scaling은 자동으로 (scale-out 방식으로) scaling 해주는 서비스다. Auto-scaling 기능을 제공하기 때문에, 굳이 서비스 초기에 무리해서 인스턴스를 잡아서 비용을 날릴 필요가 없다. 그냥 적당한 개수의 인스턴스를 전개한다음, 이들을 auto-scaling 그룹에 묶어서 관리하면 된다. 유저는 scaling 조건만 만들어 놓으면 된다. 예컨데

1. 인스턴스들이 CPU를 평균 80%이상 소모하면
2. 트래픽이 일정 수준이상이면
3. 메모리의 사용율이 90% 이상이면

Scaling 하라는 식이다.

Auto-scaling은 Scale-out 뿐만 아니라 Scale-in도 지원한다. 자원의 사용율이 어느 정도 이하면, 자동으로 인스턴스를 줄여서 비용을 아낄 수 있다. 일년 혹은 삼년단위의 기간동안 인스턴스의 사용을 예약하는 서비스다. 일정기간 사용을 보증하기 때문에, 저렴한 가격에 인스턴스를 사용할 수 있다. 스타트업 서비스 개발에는 적합하지 않지만, 중/장기간 서비스가 예상되는 경우, 백업, 사내 정보관리등 "오랜 시간 동안의 인스턴스 확보가 확실한 경우"에 사용할 수 있다.

• 생활코딩 - Elastic Compute Cloud(EC2)