EC2란

전통적인 데이터 센터 및 서버룸의 기능을 AWS에서는 EC2 (Elastic compute cloud) 를 통해서 제공한다. 전통적인 서버의 기능 뿐만 아니라 인스턴스 운영에 필요한 각종 지원 서비스 및 기능 강화요소를 통합적으로 제공하며, 리소스 모니터링, 리소스 할당 및 관리, 컨테이너 오케스트레이션 등의 기능이 포힘된다.

사용자는 인스턴스를 통해 스토리지, 메모리, 네트워크 인터페이스 등에 접근할 수 있으며 자신이 원하는 스펙과 운영체제등을 결정 할 수 있다. 또한 비용 역시 자신이 사용한 리소스 양에 따라서 부담하면 된다.

인스턴스 프로비저닝

AMI 종류 선택

1. Amazon 퀵 스타트 AMI
   • Linux 또는 windows server os의 다양한 배포판을 기반으로 다양한 용도로 사용된다. 최신의 기능은 물론 공식적인 지원을 제공한다.
2. AWS 마켓플레이스 AMI
   • SAP 및 Cisco를 포함해 수많은 기업용 소프트웨어 벤더가 지원 및 제공하는 AWS 공식 상용 이미지이다.
3. 커뮤니티 AMI
   • AWS 커뮤니티에 존재하는 이미지로 주로 특수한 목적에 적합하도록 개발 및 배포가 된다. 소프트웨어 리소스의 커스텀 조합으로 어플리케이션 빌드 계획인 경우 적합할 수 있다.
4. 프라이빗 AMI
   • 직접 프라이빗 AMI를 만들어서 사용하는 것도 가능하다. (이미지 가지고 본인의 취향에 맞춰서 커스텀) 이렇게 만들어진거는 AMI로 공유하거나 로컬에서 AWS VM 을 통해서 사용 할 수 있다.

기본적으로 이미지는 어떤 리전에서나 동일한 기능을 제공하는것이 일반적이지만. 특정 AMI는 하나의 리전에서만 사용할 수 있는 경우도 있다.

AMI : amazon machine Image 로 런칭할 인스턴스의 루트 데이터 볼륨에 어떤 OS와 어떤 소프트웨어가 포함되어야 하는지 설명하는 정보가 담긴 템플릿 문서
(AWS ec2 사용에 필요한 OS들은 여기에 정의 되어있다.)

EC2 인스터스 실행에 따른 비용 외에 본인이 선택한 AMI 소프트웨어에 대한 시간당 비용 또는 라이센스 비용이 청구 될 수 있다.

인스턴스 타입

AWS는 인스턴스 타입에 따라서 하드웨어 리소스를 할당한다.
인스턴스 타입 선택 시 , 컴퓨트 파워, 메모리, 스토리지 용량 등이 균형을 이루고 있는 것이 좋다.

사용자의 니즈는 시간에 따라 변할 수 있기 때문에 기존에 사용하는 인스턴스를 중지시키고 새로운 인스턴스 타입으로 변경하거나, 기존 인스턴스 사양의 수정 또는 복사본을 만들어서 다시 시작할 수도 있다.

이미지 출처

1. 범용 타입 (general purpose)
   • T3,T2,M5,M4등의 타입으로 컴퓨트, 메모리, 네트워크 리소스의 균형에 초점을 맞춰 일반적이며 다양한 목적에서 사용하도록 설계되었다.
   • T2 타입의 경우 1개의 가상 vCpu 및 0.5gb의 메모리를 지닌 t2.nano 부터 8개의 vCpu 및 32GB의 메모리를 지닌 t2.2xlarge 까지 다양한 인스턴스가 포함된다.
2. 컴퓨트 최적화 (compute optimized)
   • 고사양의 웹서버 구현 및 고성능이 요규되는 머신러닝 워크로드 처리에는 컴퓨트 최적화 타입인 C6i타입이 적합하다.
3. 메모리 최적화 (memory optimized)
   • arm,intel,amd 기반의 메모리 최적화 타입 인스턴스는 고성능 데이터베이스, 데이터 분석, 캐싱 작업에 적합하다.
4. 가속 컴퓨팅 (accelerated computing)
   • 고성능의 범용 그래픽 프로세싱 유닛이 탑제된 타입이 있으며, 최신의 NVIDIA GPU를 사용할 수 있다. 주로 고성능 컴퓨팅, 금융분석, 인공지능 워크로드등에 사용된다.
5. 스토리지 최적화 (storage optimized)
   • 대용량 스토리지 볼륨을 탑재한 스토리지 최적화 인스턴스로 분산 파일 시스템 또는 고용량 데이터 처리 애플리케이션 구현에 활용 될 수 있다.

인스턴스 환경설정

1. AWS 리전
   EC2 리소스는 해당 리전 내에서만 관리 될 수 있다.
   기본적으로 사용자와 가장 가까운곳을 선택한다. 리전 선택시 리전별로 비용과 기능 특징들이 다를 수 있다는 것에 주의하여 선택하자.

2. VPC(Virtual private cloud)
   사용이 간편한 AWS 네트워크 생성 및 관리도구이자 클라우드 인프라 관리 도구다. VPC를 통해 인스턴스를 다른 환경 요소와 쉽게 격리시킬 수 있다. 참고로 VPC를 추가하더라도 NAT 게이트웨이 또는 VPN에 연결하지 않으면 별도의 비용이 발생하지 않는다.

3. 테넌시(tenancy)

   • ec2 인스턴스를 생성할떄 테넌시 모델을 선택할 수 있다. 기본 설정은 공유 테넌시(shared tenancy) 이며 이는 본인의 인스턴스가 하나의 물리적 서버에서 다른 누군가의 인스턴스와 동시에 실행되고 있음을 의미한다. 공유 테넌시는 어쨌든 가상으로 분리가 된거라고 보면된다.
   • 높은 보안 수준이 요구되는 경우 외부 환경과 완전히 격리된 상태에서 인스턴스를 운영해야하며 물리적으로 격리된 서버를 제공하는 전용 인스턴스 (dedicated instance)옵션을 선택해야한다.
   • 전용 호스트(dedicated host)는 더 엄격한 보안 규정 및 라이센스 요구사항을 준수해야하는경우 적합

플레이스먼트 그룹

AWS의 인스턴스는 기본적으로 서버 인프라를 다양한 목적에 광범위하게 사용될 수 있게 설계되었지만. 상황에따라서 요구사항이 다른 경우 있을 수 있다.
EC2 플레이스먼트 그룹(placement groups)은 사용자의 니즈를 반영한 서버 프로필을 정의할 수 있는 도구 이다.

• 클러스터(cluster) 플레이스먼트 그룹
  - 근거리에 위치한 단일 AZ에 연관된 인스턴스를 론칭
  - 전송 지연 수준이 낮은 네트워크 제공으로 고성능 컴퓨팅 어플리케이션에 적합
• 스프레드(spread) 플레이스먼트 그룹
  - 데이터 소실 및 서비스 실패와 같은 위험을 감소시키기 위해 다수의 AZ를 사용하고 서로 다른 하드웨어 랙에 인스턴스를 분산 배치한다.
• 파티션(partition) 플레이스먼트 그룹
  - 연관 인스턴스를 하나의 파티션으로 묶어서 사용 할 수 있다.
  - 파티션에 속한 인스턴스는 다른 파티션의 인스턴스와 물리적으로 분리해서 배치할 수 있다.

인스턴스 가격 모델

EC2는 온디멘드, 예약, 스팟 등 세가지 가격 모델 가운데 하나를 구매해서 사용 할 수 있다.

온디멘드
- 12개월 이내 기간 계속해서 서버를 운영을 해야하는 경우 사용하기 적합
- 인스턴스 실행 시간단 비용을 지불할 수 있다.
- 필요에 따라 인스턴스를 시작 및 중단시킬 수 있다.
- 시간당 비용은 가장 비싼 모델이다.
예약 인스턴스
- 1년 이상의 기간 동안 항상 서버를 운영할 계획에 적합
- 1~3년 단위로 갱신하는 예약 인스턴스를 구매하면 할인 혜택 크다.
- 전체 비용은 일시에 지불하거나, 기간 내 점증형으로 비용을 부담하거나 할 수 있다.

스팟 인스턴스
- 평소 업무와는 다른 고성능의 인스턴스가 필요한 경우
- 특정 리전의 인스턴스에 최고가로 입찰한뒤 입찰 가격 혹은 그 이하의 가격으로 시간 단위로 사용이 가능 하다.
- 작업을 끝날때 혹은 입찰한 시간당 최고가를 넘어선 금액으로 누군가가 입찰하기 전까지 사용할 수있다.

인스턴스 생애주기

인스턴스를 종료하면 서버 기능이 중지되고 관련 리소스는 AWS 리소스 풀 속에 재할당 된다. 인스턴스 종료시 대부분의 경우 1차 스토리지에 저장된 모든 데이터가 삭제된다. 하지만 EBS 볼륨을 스토리지로 사용하는 경우 인스턴스가 종료돼도 볼륨 내 데이터는 유지 된다.

EBS (Elastic Block Storage)
AWS 클라우드의 Amazone EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨

인스턴스가 당장은 필요하지 않지만 종료를 원하지는 않는다면 중지시켰다가 필요할때 다시 시작해서 비용을 아낄 수 있다. - 이때 인스턴스 스토어 볼륨의 데이터는 유실 된다 - 중지 후 재시작시 비지속성 퍼블릭 IP 주소는 다른 새로운 주소로 대체된다 (방지를 위해서는 영구적이고 지속적인 일래스틱 IP 주소를 할당 받으면된다)

인스턴스 시큐리티 그룹 정책은 언제든 업데이트 할 수 있으며, 인스턴스 실행중에도 가능하다.

인스턴스 타입을 변경하면 컴퓨트, 메모리, 스토리지 용량을 업그레이드 할 수 있으며. 인스턴스를 중지시키고 변경사항을 적용한 뒤 다시 시작한다.

리소스 태그

AWS에 배포된 다수의 리소스를 관리하기 위하여 일관된 명명 규칙을 지닌 태그를 부여할 수 있다. EC2뿐만이 아니라 AWS 계정으로 접근할 수 있는 거의 모든 요소에 AWS 리소스 태그를 붙일 수 있으며, 하나의 태그는 키와 연관 값으로 작성한다.

태그를 통해서 리소스의 가시성을 높일 수 있고, 좀 더 쉽게 효과적으로 관리가 가능하다.

EC2 스토리지 볼륨

AWS 에서는 사용 목적에 따라 다양한 볼륨을 제공하며, 인스턴스를 잘 활용하기 위해서는 이들 볼륨의 특징과 각각의 장단점을 이해할 필요가 있다.

EBS 볼륨
하나의 인스턴스에는 다수의 EBS를 부착할 수 있으며 이들 스토리지 볼륨은 기존의 물리적인 서버에 있는 드라이브처럼 사용 가능하다.

EBS 볼륨에 저장된 데이터의 신뢰성은 최소 99.99%로 작동 실패를 걱정할 필요는 없다.

모든 EBS 볼륨은 스냅샷 생성 방식으로 복제할 수 있으며 기존의 스냅샷으로 다른 인스턴스에 부착할 수 있는 볼륨을 만들거나 AMI 생성을 위한 이미지로 변환할 수 있다.

또한 EBS 볼륨은 저장 중이거나 EC2 호스트 인스턴스에서 이동중인 데이터 보호를 위해 암호화 할 수 있다. 암호화 키는 EBS가 자동으로 관리하거나 AWS key Management Service 를 통해 사용 및 관리할 수 있다.

• EBS 프로비전 IOPS SSD
  - 고도의 I/O 작업이 필요한경우.
• EBS 범용 SSD
  - 일반적인 서버 워크로드를 고려한다면, 저지연성 및 범용성을 지닌 범용 SSD 타입이 적합하다.
• HDD 볼륨
  - 대량으로 데이터를 처리할 필요가 없거나 신속한 데이터 입출력이 필요 없는 경우 해당 타입을 통해서 비용을 절감 할 수 있다.
  

인스턴스 스토어 볼륨

인스턴스 스토어 볼륨은 EBS와 다르게 비지속형 스토리지이며, 인스턴스를 종료시키면 저장된 데이터가 소실된다.
그럼에도 사용하는 이유는 다음과 같다.

• 인스턴스 서버 호스팅 시 물리적으로 부탁되는 SSD이며 NVMe 인터페이스로 연결된다.
• 인스턴스를 생성하면 자동적으로 인스턴스 스토어 볼륨이 생성되며 별도의 비용을 부담하지 않는다.
• 단기적인 목적으로 인스턴스를 시작하는 배포 모델에 적합하며, 외부에서 데이터를 import 해서 사용하므로 내부에 저장된 데이터는 작업 후 삭제돼도 무방하다.

EC2 인스턴스 접속하기

EC2인스턴스도 유일한 IP 주소로 네트워크 상의 위치를 표시한다. 모든 인스턴스는 최소 하나 이상의 프라이빗 IPv4주소를 지닌다.

처음으로 인스턴스를 생성하면 서브넷 내에서만 인스턴스를 연결할 수 있으며, 인터넷과 인스턴스를 바로 연결할 수는 없다. 인스턴스를 외부 리소스와 연결하기 위한 다중 네트워크 인터페이스 환경설정에서 인스턴스 하나 이상의 가상 네트워크 인터페이스를 부착할 수 있다.

이들 인터페이스는 기존의 서브넷 또는 시큐리티 그룹과 반드시 연결돼야 하고, 필요에 따라 서브넷 범위 내에 정적 IP주소를 할당해서 사용할 수 있다.

인터넷과 연결하기 위해서는 인스턴스에 퍼블릭 IP를 할당해서 사용할 수 있다.

EC2 인스턴스의 보안 유지

• 시큐리티 그룹
  - 방화벽과 같은 역할을 한다.
  • 기본적으로 인스턴스로 향하는 모든 유입 트래픽은 거부하고, 나가는 모든 유출 트래픽은 허용한다.
  • 추가적인 정책을 정의하여 해당하는 규칙을 따르게 된다.
• IAM
  - IAM을 통해서 EC2인스턴스는 물론 다른 AWS 리소스에 대한 접속을 제어할 수 있다.
  • AWS계정으로 연결된 특정 서비스와 리소스에 대한 동작을 허용하는 방식으로 IAM롤을 정의할 수 있다.
• NAT(natwork address treanslation)
  - NAT 디바이스를 이용해 인터넷 연결 허용 없이 프라이빗 IP 주소를 통해 인터넷에 접속할 수 있다.
  - NAT인스턴스와 NAT 게이트웨이 두가지로 AWS에서 제공된다.
  
• 키 페어
  - 인스턴스에 대한 원격 로그인 세션은 반드시 암호화 방식으로 연결해야한다. 이러한 보안 세션 실행 방법으로 사용자는 EC2인스턴스 생성 시 키 페어를 생성하게되며, 퍼블릭 키는 EC2서버에 프라이빗 키는 본인의 로컬버신에 저장한 뒤 사용한다. (즉 원격 접속할때 이 private key가 필요한것)

EC2 Auto scaling

애플리케이션 실패 및 복구 상황을 방지하기 위한 서비스로서 실패 상황 발생시 사용자가 미리 지정한 수만큼의 EC2 인스턴스를 프로비저닝하고 시작하며, 요구 수준에 맞춰 인스턴스 수를 동적으로 추가할 수 있다.

-> 인스턴스 실패 또는 예기치 못한 종료 발생시 Auto scaling 이 자동으로 해당 인스턴스를 대체한다.

론치 환경설정

인스턴스 직접생성할때는 다양한 환경설정이 필요하다. 론치 환경설정은 인스턴스를 직접 프로비저닝 할 때 지정하는것과 동일한 정보를 담은 문서라고 할 수 있다.

론치 환경설정은 기존 EC2인스턴스의 설정 내용을 복사해서 생성하거나 처음부터 새롭게 작성할 수 있다.

EC2 Auto Scaling에서만 사용할 수 있으며, 이것만으로 직접 인스턴스를 론칭할수는 없으며 한번 설정된거는 수정이 안되며 수정을 원하면 새로 생성이 필요하다.

론치 템플릿

설정 방식 측면에서는 론치 환경설정과 유사하지만 좀 더 직관적이고 이해하기 쉽다. 론치 템플릿은 Auto Scaling 작업시에도 사용할 수 있지만 EC2 인스턴스 사본 생성 또는 스팟 플릿 생성 목적으로도 사용할 수 있다.

론치 템플릿은 버전기능 제공으로 생성 후에도 수정이 가능하다.

Auto Scaling 그룹

Auto Scaling 이 관리하는 EC2 인스턴스 그룹이며, Auto Scaling 그룹 생성에 앞서 론치 템플릿을 생성해야 한다.

인스턴스에 유입되는 트래픽을 분산시키려는 경우 로드밸런서 설정을 하면 되며, Auto Scaling그룹 생성 시 로드 밸런서 타겟 그룹에 연결하면 된다.

Auto Scaling 그룹을 생성하면 사전에 정의한 최소 또는 희망 용량의 인스턴스가 항상 유지되며, 생성된 인스턴스의 헬스 상태가 좋지 못하면 Auto Scaling이 이를 삭제하고 새 인스턴스로 대체한다.

인스턴스 헬스에 대한 판단 기준은 EC2 헬스 체크를 따른다.
이를 통해 메모리 고갈, 파일시스템 오류, 네트워크 오류등을 확인할 수 있다.
(애플리케ㅔ이션에 특화된 문제점은 발견하지 못할 수 있다)

Auto Scaling 그룹 생성 시 몇개의 인스턴스를 프로비전하고 실행할 것인지 지정해야하며 희망하는 인스턴스의 수를 지정하는 것 도 가능하다.

• 최소용량
  - 떠있는 인스턴스의 수로 최소요량의 수 만큼 인스턴스가 유지된다.
• 최대용량
  - 인스턴스의 최대수를 지정한다. 예산 제한선을 고려해 예기치 못한 수요에 의해 지나치게 많은 인스턴스가 추가 되지 않도록 안전 장치 역할을 한다.
• 희망 용량
  - 사용자의 필요에 따라 선택할수있으며 최소와 최대용량 사이에 있어야한다. 즉 기본적으로는 희망 요량만큼 인스턴스가 떠있는거다.
  

Auto Scaling 옵션

• 수동 스케일링
  - 최소,희망,최대 용량 값을 변경하면 해당 내용이 즉시 반영된다.
• 동적 스케일링 정책
  - CloudWatch의 경고 상황을 모니터링한 결과에 따라 희망 용량을 증가시키는 방식으로 작동 하며 아래의 3가지 정책이 있다.

동적 스케일링 정책

• 단순 스케일링 정책
  - 지표가 한계에 도달하면 희망용량대로 인스턴스를 증가시킨다 하지만 아래의 타입에 따라서 증가 수준 또는 속도를 조절한다.
  • ChangeIncapacity
    • 지정 숫자만큼 희망 용량을 증가시킨다
  • ExcatCapacity
    • 현재 값에 상관 없이 용량을 지정 숫자만큼 증가시킨다
  • PercentChangeInCapacity
    • 현재 용량의 비율을 기준으로 증가시킨다.
    • 희먕용량이 4인데 비율이 50%이면 6으로 증가

Auto Scaling 조정 작업 종료 후에는 관련 정책을 다시 실행하기전 휴식기를 갖게 된다. 기본적으로 300초이며 0으로 설정해서 휴식기를 안가질 수 도 있다.

단계별 스케일링 정책
애플리케이션에 대한 요구 수준이 급속히 증가하는 경우 단순 스케일링 정책만으로는 수요에 적절히 대응할 수 없다. 단계별 스케일링 정책은 리소스 사용량의 누적 지표에 따라 인스턴스를 추가할 수 있다.

예를 들어서 CPU 활성화율이 50%를 초과하면 2개를 추가하고 60%를 초과하면 4개를 추가하는 방식이다.

목표 추진 정책
특정 지표와 타겟 값을 선택하면, Auto Scacling이 CloudWatch Alarm 생성, 인스턴스 개수 조정을 위한 스케일링 정책 생성 등 제반업무를 처리한다.

선택되는 지표는 인스턴스에 추가되는 업무 부하와 비례적으로 변경되는 것이여야한다. (ex, 평균 CPU 활성화율)

목표 추적 정책에서는 스케일아웃/스케일인 정책도 추가할 수 있다.

예약된작업
워크로드 패턴이 예측 가능한 경우나 용량 변화에 선제적으로 대응해 수요 증가 이전에 충분한 인스턴스를 확보하고자 할 때 유용하다.
반복설정도 가능하며 예양된 정책을 삭제하기 위한 종료 시점도 설정할 수 있다.
- 최소, 최대, 희망 용량 값
- 시작 날짜 및 시간

AWS Systems Manager

AWS 리소스 및 온프레미스 서버의 자동 및 수동 작업을 관리한다.
수작업 및 스크립트 작성 등이 필요한 유지보수 작업을 돕는 도구로서 온프레미스와 EC2인스턴스의 패키지 업그레이드, 설치 소프르웨어 목록 생성, 새 어플리케이션 설치 등의 업무등을 돕는다. 결국 크게 보면 액션과 인사이트라는 주요기능을 가진다.

액션

• 자동 또는 수동으로 개별적 또는 일괄적으로 AWS리소스에 대한 각종 작업을 수행한다
  - 자동화 액션 : AWS리소스에 대한 작업을 수행
  - 명령 액션 : linux 또는 windows 인스턴스에 대한 작업을 수행
  - 정책 액션 : 관리중인 인스턴스로부터 목록 데이터를 수집하는 과정을 정의

인사이트
AWS 리소스에 대한 헬스, 컴플라이언스, 운영 세부사항 정보를 AWS System manager라는 단일 영역에 집약시킨다.

컨테이너 실행하기

인스턴스가 생성되고 난 이후에는 높은 실행 속도를 제공하지만, 실행 여부와 상관없이 항상 일정 수준의 리소스를 점유하고 있다는 면에서 유연성 및 경량화의 필요성이 제기 되었으며 자연스럽게 컨테이너 기반의 컴퓨트 모델이 대세가 되었다.

컨테이너 이미지 기반의 분산화된 모듈 아키텍처를 이용해 로딩 타임을 기존의 수분에서 수초로 줄일 수 있게 되었으며, 기존의 인스턴스와 다르게 OS 와 각종 소프트웨어가 필요하지 않도 바이너리 이미지 생성을 위한 (dockerfile) 텍스트 파일만 관리하면 된다.

ECS (elastic container service)

컨테이너 기술의 가장 큰 장점 중 하나는 컴퓨트 리소스 실행을 스크립트화해 좀 더 효율적으로 처리할 수 있다는 것이다. 이를 통해 사용자는 수천 개의 컨테이너를 클러스터 형태로 구성하여 복잡한 아키텍처를 구현해 낼 수 있다.

컨테이너가 많아지며 관리의 복잡성이 문제가 되게 되었고 ECS 를 통해서 효율적인 오케스트레이션이 가능해졌다.

ECS는 대규모 컨테이너 클러스터 실행을 위한 서비스이며, 컨테이너 실행을 위한 인스턴스, 스토리지, 네트워크 리소스의 프로비저닝을 관리하고, 컨테이너 생에 주기 동안 컨테이너의 모니터링 및 관리 작업을 지원한다.

또한 ECS Anywhere는 ECS 플랫폼을 온프레미스 인프라로 확장할 수 있도록 지원하기 떄문에 하이브리드 환경에서 사용하기 적합하다.

EKS (elastic kubernetes service)

기능과 사용 목적등은 ECS와 대체로 비슷하지만 특정 컨테이너 플랫폼에 구애받지 않고 사용할 수 있다. Kubernetes는 글로벌레벨에서 가장 인기 있는 컨테이너 및 오케스트레이션 도구 중 하나이다.

k8s 기반의 환경에 익숙한 경우 EKS가 좋은 선택지가 될 수 있다.
참고로 EKS Anywhere도 존재하기 때문에 온프레미스 환경에서도 사용 가능하다.