[이론] Amazon Elastic Compute Cloud(EC2) 기본 개념

안녕하세요 서후아빠입니다. ^_^

이번 세션은 AWS Compute에 대해서 업무적으로 필요한 최소한의 개념에 대해서 간단히 정리해 보았습니다.

이외 내용은 업무적으로 필요할때마다 찾아보시는 것이 효율적이라고 생각합니다.

---

EC2 종류

On-Demand : 약정없이 사용시간만큼 지불, 가격 비쌈

Spot Instance : 경매방식, 아주 저렴, 단 언제든지 제거될 수 있음

Reserved Instance (RI) : 약정(1년~3년), On-Demand보다 저렴

Dedicated : 실제 물리서버 임대 (=베어메탈), 라이선스 이슈 및 규정에 따른 경우

On-Demand는 가장 보편적인 계약방법이며 일반적으로 정가 구매로 생각하시면 됩니다. 만약 사용자가 고정비용으로 장기간 사용하는 경우에는 Reserved Instance 계약하여 정가보다 할인된 금액으로 사용하는 것이죠. 단, RI 계약은 우리가 핸드폰을 약정해서 사용하다가 중도해지하는 경우 위약금이 발생하는 것처럼 특정 인스턴스(ex : t3 model)를 RI계약으로 사용하다가 저용량/과용량 등으로 인하여 변경이 발생하게 되면 기존 계약을 해지하고 재계약을 해야 합니다. 이 과정에서 일부 손실 비용이 발생하기 때문에 일반적으로 6개월~1년 정도 사용해보고, 적정한 인스턴스를 선택하여 RI계약을 하는 것이 바람직합니다. Spot Instance는 이렇게 이해하시면 됩니다. t3 인스턴스를 정가(On-Demand, 100원/H)보다 아주 저렴하게(경매, Spot Instance, 30원/H) 사용하는 계약입니다. 단, 이렇게 구매한 인스턴스는 또 다른 누군가가 경매로 통해 뺏어갈 수 있음을 알고 있어야 합니다. 그러므로 언제든지 삭제해도 문제가 되지 않는 상황에서만 사용하는 것을 추천하며, 중요한 자료는 손실을 대비해야 하니다. Dedicated는 나만 사용할 물리적인 서버를 받는 것이며,  그 물리적인 서버에 인스턴스를 띄워서 사용하는 것입니다. 우리가 노트북에 VMWARE을 설치하고, VM을 띄워서 사용한다는 것과 비슷합니다. 그렇기 때문에 비싸며, 물리적인 서버 장애에 대한 별도 대비가 필요합니다.

EC2 유형

범용 : t2(저렴, 웹서버), m5(범용, 일반)

컴퓨팅 최적화 : c5(cpu성능 우선), F1(하드웨어 가속, 빅데이터 분석)

메모리 최적화 : r4(메모리 성능 우선), x1e(spark), p3(그래픽 우선, 머신러닝, 가상화폐)

저장 최적화 : h1(disk 쓰룻풋 우선,  하둡/맥리듀스), i3(disk 속도 우선, NoSQL/DWH), d2(파일서버/하둡)

대부분의 사업에서는 범용을 사용하며, 특별한 상황(데이터하우스, 빅데이터 등)은 해당하는 모델을 선정합니다.  세부적인 내용은 https://aws.amazon.com/ko/ec2/instance-types/ 참조 바랍니다.

Bastion Host

용도 : Private subnet에 있는 리소스를 인터넷에서 접근할 때
위치 : Public Subnet에 위치

Bastion Host 대신 EC2(Linux or Windows)를 Public Subnet에 배포하여 Bastion Host처럼 사용하기도 합니다.

Scaling 종류

Vertical (수직) : 인스턴스의 성능 향상

Horizontal (수평) : 인스턴스 개수 확장

일반적으로 Autoscaling은 거의 수평 확장으로 구성됩니다.

AutoScaling

용도 : 인스턴스를 최대한 저렴하고, 안정적으로 애플리케이션 모니터링하면서 용량을 자동 조정하기 위해 사용
대상 : EC2, DDB, Spot Fleet(Spot 인스턴스), Aurora, ECS
Lifecycle Hook 

  - 일반적인 용도는 인스턴스가 ELB에 등록되는 시점을 제어하는 것

  - 인스턴스가 시작되고 애플리케이션이 정상 구동될때까지 일정 시간(기본 3,600초) ELB에서 서비스 연결을 막음

AutoScaling을 사용하기 위해서는 인스턴스에 설치되는 Applicatoin 및 3rd party 에서 구조적으로 AutoScaling으로 동작 시 서비스 문제가 발생여부에 대한 사전 검토가 필요합니다. 가장 일반적인 예로 인스턴스에 설치되는 3rd party 솔루션의 Agent가 있는데요. 이러한 Agent는 고정IP 정보 및 Hostname 등을 3rd party 솔루션의 Server에 등록해야 합니다.  그러나 AutoScaling으로 생성된 인스턴스는 이러한 정보가 유동적으로 생성되기 때문에 서비스 장애가 발생합니다.

EC2 AMI 종류별 계정 (장비 접속할 때 필요)

Oracle, Amazone Linux 2 or Amazon Linux : ec2-user
CentOS : ec2-user or centos
Debian : admin
Fedora : ec2-user or fedora
RHEL or SUSE : ec2-user or root
Ubuntu : ubuntu
Bitnami : bitnami
Windows : Administrator

세부 정보는 https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/managing-users.html 참조 바랍니다.

EC2 ImageBuilder 

용도 : 가상 머신 및 컨테이너 이미지의 구축, 테스트 및 배포 간소화
동작 방식
  - 1단계 : Source Image(AMI)

  - 2단계 : EC2 ImageBuilder 

    1) Source Image에 최적화된 Application 설치 

    2) 보안 관련 설정 

    3) Image 테스트 

    4) Golden Image 생성

일반적으로 EC2를 이용하여 서비스를 구성하는 경우 기본 AMI에 필요한 모든 조치를 취한 후, 인스턴스 장애가 발생할 경우를 대비하여 골든 이미지를 만들어 놓습니다. 그리고 시간 경과에 따라 변경사항이 발생하면 그때마다 골든 이미지를 추가 생성하고 서비스 정상 동작 테스트를 하는 과정을 하게 됩니다.

EC2 상태 확인 

System Status checks  : AWS IDC 내의 하드웨어 이슈, "AWS Health Dashboard"라는 서비스에서 장애 시 상세 정보 확인 가능

  - 물리적 네트워크 연결 끊김

  - 시스템 전원 중단

  - 호스트의 소프트웨어 혹은 하드웨어 문제
Instance Status checks : 특정 인스턴스 문제

  - 인스턴스의 시스템 상태 확인 실패

  - EC2 네트워크 구성이 잘못됨

  - 메모리가 모두 사용됨

  - 파일 시스템 손상

  - 호환되지 않은 커널

유지보수를 하다보면 의외로 IDC 전원장애 or 물리적인 장비 장애가 빈번히 발생합니다. 가용영역을 이중화 하였다면 문제가 없지만 그렇지 않다면 서비스 장애 및 데이터 손실을 염두해 두어야 합니다. 그리고 AWS는 가용영역을 이중화 하지 않은 상황에서 IDC 장애에 따른 데이터 손실을 보상해 주지 않습니다.

참조 URL 

RI(Reserved Instance) vs. Savings Plan : https://www.grumatic.com/ko/rireserved-instance-vs-savings-plan/