EC2(Elastic Compute Cloud): 쉽게 생각해서 한대의 컴퓨터를 임대해주는 거라고 생각하면 된다. 이 컴퓨터는 특별한 컴퓨터가 아니다. 데스크탑이나 노트북과 똑같은 컴퓨터다. 여기에 자신이 선호하는 운영체제를 설치하고, 웹서비스를 위한 프로그램들(웹서버, 데이터베이스 등)을 설치하면 된다. AWS(아마존 웹서비스)에서는 인터넷을 통해서 이 컴퓨터에서 접속할 수 있는 URL(Public DNS)을 제공하는데, 이 URL을 통해서 웹서비스를 하거나, 자신이 구입한 도메인을 붙여서 서비스할 수도 있다.
물론, 가정용 컴퓨터와 EC2는 중요한 차이가 있다. 인터넷을 통해서만 접속할 수 있고, 주문 후 1분 안에 생성되고, 삭제 즉시 제거된다. 초기 구입비가 전혀 없고, 사용한 만큼 비용을 지불하면 된다. 컴퓨터를 사용하면 프로그램도 설치하고, 파일도 저장하고, 설정도 변경하게 되는데, 이 상태 그대로 저장 할 수 있다. 이것을 이미지라고 한다. 이미지를 이용해서 새로운 컴퓨터를 만들면 이미지에 저장된 상태와 똑같은 컴퓨터를 생성할 수 있다. 컴퓨터를 장만할 때마다 반복되는 설치 작업을 하지 않게 되는 것이다.
Elastic Compute Cloud의 약자로 EC2라고 하며, 아마존 웹서비스의 심장에 해당하는 서비스다.
1. About EC2
EC2는 Elastic이라는 단어가 들어간만큼 탄력적인 운용이 특징이자 정점이다. 예를 들어 필요한 만큼만 쓰다가 필요 없으면 언제든지 인스턴스를 내릴 수 있고, 인스턴스를 내리거나 또는 삭제하더라도 *볼륨(Volume: EBS가 만든 디스크를 볼륨이라 말함)을 보관할 수 있어 사용자가 원할 때 복구할 수 있다.
EC2는 단독으로 사용하려고 하면 가성비가 좋지 않지만 여러 서비스와 함께 사용하면 왜 AWS를 사용해야 하는지 알 수 있다. 예를 들어 *OpenAPI를 제공하는 메시징 처리 인프라를 구축한다고 가정한다면 이때 필요한 컴포넌트들을 보자.
1) EC2 Instance
3) Message Queue
4) 공유메모리
5) RDBMS
6) NoSQL 솔루션
7) Object Storage
8) 보안
9) 멀티미디어를 처리해야 할 경우 이와 관련된 솔루션들
10) CDN: 인터넷상에서 여러 데이터센터를 이용해서 대량의 컨텐츠를 배포하는 시스템
11) Auto Scaling & 모니터링
12) H/W 유지보수
1-1. EC2 AMI
AWS는 인스턴스를 만들기 위해서 AMI(Amazon Machine Images)라는 독자적인 머신 이미지를 제공한다. AWS는 자주 사용하는 운영 체제들에 대한 AMI를 만들어서 배포하고 있는데 이들 AMI는 아마존에서 제공하는 Tool들이 설치되어 배포되기 때문에 AWS의 다른 컴포넌트들과 쉽게 연동할 수 있다는 장점이 있다. AWS에서 패키지들을 직접 관리하기 때문에 AWS의 기본 AMI를 사용하는 경우가 많다.
유저가 자신의 목적에 맞는 AMI를 직접 만들어서 올릴 수도 있다. AWS에는 다양한 용도의 유저 생성 AMI들이 있는데, 이것들을 이용하면 쉽게 본인이 원하는 서비스를 만들 수 있다. AMI는 마켓플레이스와 연동할 수도 있어서 기업이나 개인이 자신들이 개발한 서비스를 배포하기 위한 채널로도 사용한다. 때에 따라서는 비용을 지불해야 하는 AMI도 있다. 예로 AWS Marketplace에는 Ruby 개발 환경에서, Wordpress, MongoDB, SAP, CentOS, OpenVPN, NginX 서버 등등 다양한 AMI들이 준비돼 있다.
1-2. EC2 Tier
AWS는 다양한 종류의 EC2를 제공한다. 주로 Core 개수와 메모리 크기에 따라서 대략 15개 정도의 tier로 구분된다. 각 tier내에서는 볼륨 크기, IOPS 등을 이용한 세부적인 튜닝이 가능하다. 물론 tier마다 비용에 차이가 있어서 서비스의 목적에 맞게 사용해야 한다. 주로 사용하는 표준 인스턴스와 마이크로 인스턴스를 그림으로 확인해보자.
1-2-1. 마이크로 인스턴스
마이크로라는 이름처럼 매우 저렴한 비용으로 사용가능한 저사양의 인스턴스다. 하지만 이게 다가 아니다. 마이크로 인스턴스는 호스트의 CPU 자원을 경합하는 방식으로 탄력적으로 CPU 자원을 소모할 수 있다. 아래는 M1.스몰과 마이크로 인스턴스의 CPU 사용 레벨을 보여주고 있다.
m1.small는 고정된 CPU 레벨을 가지고 있다. 반면 마이크로는 background와 Max 레벨에서 CPU 자원을 사용할 수 있다. 예컨데, 평소에 CPU를 많이 소모하지 않을 때는 background 레벨에서 CPU를 사용하다가, CPU자원 사용량이 늘면 MAX CPU 레벨까지 CPU를 사용할 수 있다. 물론 항상 MAX CPU 레벨을 사용할 수 있는 건 아니다. 호스트에서 제공하는 CPU를 두고 다른 마이크로 인스턴스들이 서로 경합을 벌이기 때문이다. 만약 경합을 벌이는 인스턴스들이 적다면 비교적 높은 수준에서 CPU를 사용할 수 있을 것이고, 그렇지 않을 경우에는 충분한 CPU 파워를 얻지 못할 거다. 마이크로 인스턴스는 주기적으로 CPU를 소비하는 웹 서비스나 배치작업 처리에 적당한 인스턴스 타입이다. 가격이 m1.스몰의 1/3 정도이므로 서비스 특성에 따라서, m1.스몰대신 사용하는 것으로 비용을 아낄 수 있다.
2. EC2 Instance 관리 방안
2-1. Auto Provisioning
여기에서 Auto Provisioning은 손으로 운영체제를 설치하고 켜는 것들 자동화하겠다는 것 이상의 의미다. Auto Provisioning을 관리하려고 하는 시스템의 형상을 코드화 하고, 그 코드를 로직(프로그램)을 이용해서 실행하겠다는 것이다. 서비스의 유지/보수 품질에 직접적으로 관련된다. 예전부터 운영체제의 프로비저닝은 '노가다'였으나 이를 자동화 함으로 남은 시간에 서비스의 다른 측면에 노력을 기울일 수 있다는 혜택을 함께 누릴 수 있게 됐다.
2-2. Chef, Cloud-Init
인스턴스의 Auto Provisioning, 운영체제와 소프트웨어의 형상을 관리하기 위해서는 많은 방법들이 있지만 몇 가지를 살펴보자.
일단 AWS에서 제공하는 Cloudformation, Opsworks와 같은 툴이 있고, 몇몇 상용 툴들도 있는 것 같지만 이들 제품을 보고 얻은 결론은 다음과 같다.
1) 이런 툴들은 퍼블릭한 환경을 대상으로 한다. 대다수가 사용하기에는 무난한 툴이지만 개개인의 시스템이나 네트워크 환경에 맞춰서 제대로 관리하기에는 한계가 있다.
2) 관리 시스템 구축을 위한 팀이 제대로 운영되고 있다면 자신의 환경에 맞게 직접 만드는 것이 낫다
3) 예전에는 직접 만드는 걸 권하지 않았겠지만 지금은 좋은 툴들이 많다. Chef, puppet, cloud-init 여기에 AWS에서 제공하는 툴들을 잘 조합하면 자신의 환경에 최적화된 시스템을 구축할 수 있다.
해당 그림의 툴은 chef와 AWS의 user metadata의 조합이다. 대략의 구성은 다음과 같다.
Standard AMI
-표준 운영체제는 하나 만들어서 AMI로 떠 놓는다.
Chef-Server
-Chef-Server로 운영체제와 소프트웨어 형상을 관리한다.
-Domain 이름 기반으로 Role을 적용한다. 예를 들어 Web01.myservice.com이라면 web role을 적용한다. 이 role은 대략 apache, php 기타 등등 웹 서비스를 위한 cookbook을 가지고 있을 것이다.
Linux Package Repository
-운영체제와 소프트웨어 버전 관리를 위한 Repository는 운용해야겠다.
Instance metadata
AWS는 인스턴스에 대한 메타정보를 관리하고 있다. 유저는 언제든지 인스턴스의 메타정보들 - 인스턴스 ID, 생성일, 상태, 네트워크 정보, ssh-key 등등 - 을 확인할 수 있다. 인스턴스에서 GET http://169.254.169.254를 호출하면 호출한 인스턴스의 메타정보를 JSON 형태로 돌려준다.
user-data
중요한 점은 Instance metadata에 유저 데이터를 설정할 수 있다는 점이다. Key-Value 형식으로 설정하면, 언제든지 값을 가져올 수 있다. 필요하다면 파일을 올릴 수도 있다. 물론 실행파일도 올릴 수 있을 테고, 나중에 인스턴스의 초기 설정 등에 사용할 수 있을 거다. user-data에서 가장 중요한 설정은 인스턴스의 도메인 이름을 박는 거다.
인스턴스를 만들었다면 해당 과정을 따라 프로비저닝을 하면 된다.
1) EC2 API를 이용해서 Standard AMI로부터 Instance를 만든다 → 인스턴스를 만들 때 도메인 명을 user-data에 설정한다.
2) 인스턴스가 뜬다.
3) init-script를 수행한다.
- Script는 인스턴스 메타데이터에서 도메인 이름을 가지고 가져온다.
- 도메인 이름을 가져왔다면 호스트 이름을 설정한다
4) Chef-Client를 수행한다.
- Chef-Client는 자신의 호스트 이름으로 Chef-Server에 등록한다
5) Shef-Server는 CookBook을 내려주고 CookBook을 실행하여 운영체제와 소프트웨어를 설정한다.
2-3. EC2 Instance 모니터링
2-3-1. Cloudwatch를 이용한 매트릭 수집
AWS는 cloudwatch라는 모니터링 툴을 제공한다. cloudwatch를 이용하면 EC2를 비롯한 AWS의 거의 모든 자원을 모니터링할 수 있다.
- EC2 인스턴스, EBS 볼륨, ELB, RDS, SQS, SNS, DynamoDB, Storage gateway, Elastic MapReduce, Autoscaling그룹
EC2에서 수집할 수 있는 주요 매트릭은 다음과 같다.
- CPU 사용률, Disk 평균 Read/WriteDisk , Read/Write count
기초 모니터링 자료로는 쓸만하지만 제대로 모니터링하기에는 아쉽다. 다행히 커스텀 매트릭을 추가할 수 있기는 한데 그렇다고 하더라고 아래의 제한들 때문에 본격적인 모니터링 툴로 사용하기에는 많이 부족하다.
- 매트릭의 종류에 따라 다르지만 5분 미만의 주기로 수집할 수 없는 매트릭이 있으며, 어떤 매트릭의 경우 1분 주기로 수집하려면 비용을 지불해야 한다.
- AWS API 요청은 무한대가 아닌 제한이 있다. 50개 정도의 인스턴스를 관리한다고 가정할 때 detect time을 줄이기 위해서 5개 정도의 인스턴스를 1분 단위로 수집한다고 하면 1시간에 15,000번의 API를 호출한다.
- AWS Console로 모니터링 정보를 볼 수 있지만 이걸로는 제대로 된 정보를 얻기가 힘들다. 결국 매트릭 정보를 수집해서 별도의 DB에 적재한 다음 모니터링 정보를 리포팅해주는 시스템을 개발해야 한다.
- Cloudwatch에서 제공하는 이벤트 알람 기능은 제한적이다. Auto Scaling을 위한 알람 용도로는 활용할 수 있겠지만 본격 모니터링 이벤트 알람용으로 사용하기에는 부족하다.
결론은 Cloudwatch는 기초자료 수집용이며 모니터링 시스템을 구책해야 한다. 모니터링 시스템 구축은 zabbix를 믿고 가는 게 좋다.
2-4. Security
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자원에 대한 접근권한을 설정할 수 있다.
2-5. EC2와 VPC
VPC를 이용하면 퍼블릭 네트워크 상에 사설 네트워크를 만들 수 있다. 사설 네트워크를 만드는 이유는 다음과 같다.
1) 자유로운 네트워크 구성
- EC2 영역의 사설 IP는 유저가 제어할 수 없다. 자기 멋대로 만들어내고 그나마 고정되는 것도 아니라서 관리하기가 쉽지 않다.
2) VPC는 10.0.0.0/8에서 자유롭게 네트워크 환경을 구성할 수 있다.
3) 보호해야 할 자원을 퍼블릭 네트워크로부터 숨길 수 있다.
4) 오피스 네트워크와 VPN을 통해서 연결, 독립된 관리 네트워크를 구성할 수 있다.
-VCP와 관련된 내용은 VCP 구축 문서를 참고하자.
2-6. EC2 Network
2-6-1. Private IP와 Public IP 그리고 EIP
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)라는 이름의 고정 ip 서비스를 제공한다. EIP는 유저의 자원으로 할당받은 EIP를 자유롭게 인스턴스에 뗐다, 붙였다 할 수 있다. 물론 EIP에는 과금이 된다. EIP 하나까지는 무료, 그 이후로는 비용이 추가된다.
AWS의 네트워크 최소 단위, 그러니까 L2로 묶이는 단위는 zone이다. 따라서 같은 zone에 있는 인스턴스들끼리는 private ip를 이용해서 통신이 가능하다. 다른 zone의 인스턴스와 통신하려면 public ip(혹은 EIP)를 이용해야 한다. 과금 정책도 이에 따라 달라진다. 같은 zone에 있는 인스턴트들과의 통신에는 네트워크 과금이 되지 않지만 다른 zone의 인스턴스와의 통신은 과금이 된다.
3. EC2 인스턴스로의 접근(리눅스 기반)
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 등)을 이용해서 접근하면 된다.
4. 그 외
4-1. AWS에서의 운영체제별 점유율
AWS에서의 운영체제 점유율이다.
2013년 6월 데이터 참조 ▼▼▼
https://thecloudmarket.com/stats
https://gigaom2.files.wordpress.com/2013/06/aws-ec2-usage-by-operating-system.jpg
리눅스 운영체제가 80% 이상의 점유율을 보이고 있다.
4-2. Cloud Ping
각 리전 별 HTTP ping 응답 속도를 검사할 수 있다. 서비스 리전을 선택할 때 혹은 리전이 네트워크 상황을 검사할 때 유용하게 사용할 수 있다. 클라이언트(웹브라우저)에서 AWS Region의 지정된 URL에 대해서 HTTP 질의하는 방식이다.
4-3. 인스턴스 비용절감
AWS 서비스는 "필요한 만큼 사용하고, 사용한 만큼 지불한다"라는 정책 하에 설계됐다. 이 정책 하에서 유저는 상당한 자유도를 가지고 유저가 사용할 자원에 대한 비용을 계획할 수 있다. 자유를 제대로 누리려면 대가가 필요하듯 AWS에서의 대가는 '비용'이다. 아는 만큼, 부지런한 만큼 비용을 절감할 수 있다.
4-3-1. Availability zone 간에 트래픽이 흐르지 않게 해라.
서비스의 가용성을 높이기 위해 인스턴스를 AV zone으로 분리해서 구성하기도 한다. 하나의 zone의 네트워크가 오류가 발생하더라도 다른 zone의 인스턴스가 계속 서비스를 하도록 하기 위함이다.
AWS는 같은 zone 내에서의 트래픽에 대해서는 과금하지 않지만, 다른 zone으로 흐르는 트래픽에 대해서는 과금을 한다. 따라서 가용성 때문에 AV zone을 구성했다고 하더라도 가능하면 트래픽이 zone을 넘나들지 않도록 해야 한다. 하지만 가용성을 만족하면서 트래픽까지 관리하는 건 쉬운 일이 아니다.
가용성을 확보하기 위해서는 웹 서버뿐만 아니라 데이터베이스도 가용성을 유지해야 하는데, 결국 웹 서버 중 하나는 Active 데이터베이스에 붙기 위해서 AV zone을 건너뛰어야 한다.
이론은 괜찮은데 가용성의 확보가 필요한 경우 쓸만한 팁은 아니다.
4-3-2. Auto-Scaling
'이벤트', '마케팅 효과' 기타 등의 이유로 트래픽 유입이 늘어나서 서비스를 감당하기 힘들어지면, 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도 지원한다. 자원의 사용율이 어느 정도 이하라면 자동으로 인스턴스를 줄여서 비용을 아낄 수 있다.
참고: https://www.joinc.co.kr/w/Site/cloud/AWS/EC2#fid_2
*EBS란 Elastic Block Store의 약자로 일종의 하드디스크라고 생각하면 된다. EBS의 특징은 아래와 같다.
a. 필요한 용량에 맞게 구입할 수 있다. 이를테면 EC2 인스턴스를 웹서버의 용도로만 쓰고 파일 저장은 S3를 사용한다면 넉넉 잡고 1기가바이트만 구입하면 된다.
b. 필요에 따라서 즉시 생성하고, 제거할 수 있다.
c. 사용한 만큼 과금되는 종량제다.
d. 내부적으로 데이터를 실시간 복제하고 있기 때문에 하드디스크에 비해서 데이터를 잃어버릴 확률이 현저히 낮다.
e. 스냅샷 기능을 제공해서 EBS의 현재 상태 그대로 보존할 수 있다.
f. CloudWatch를 통해서 EBS의 통계를 열람할 수 있다. EC2 인스턴스를 제거해도 EBS는 독립적이기 때문에 데이터가 유지된다.
*Open API: OpenAPI는 REST, SOAP, JavaScript 등을 이용해서, 웹 사이트와 상호작용하는 기술을 의미한다. 기본적으로 웹 기반 응용프로그램의 개발을 목적으로 하고 있지만, 응용프로그램의 종류에 국한받지 않고 사용할 수 있다. OpenAPI는 소위 말하는 웹 2.0과 함께, 일종의 기술적 트렌드가 됐다.
*ELB(Elastic Load Balancing) 시스템에 가해지는 부하를 여러 대의 시스템으로 분산해서 규모 있는 시스템을 만들 수 있도록 해주는 단일 진입점.
*Region: 클라우드 서비스를 제공하는 글로벌 서비스로 원활한 서비스 제공을 위해 주요 지역별로 물리적인 데이터 센터가 있는데 이를 Region이라 칭한다.
'etc.. > AWS' 카테고리의 다른 글
IAM의 개념과 IAM 사용자 & 그룹 생성 (0) | 2020.08.07 |
---|---|
S3, 버킷의 개념과 생성 (0) | 2020.08.07 |
AWS EC2 인스턴스 생성하기 (0) | 2020.08.07 |
AWS Architecture (0) | 2020.07.22 |
AWS 주요 기술 간단 정리 (0) | 2020.07.21 |
댓글