AWS Cloud Practitioner Essentials - 모듈2 [EC2, Elastic Load Balancing]

EC2

가상 머신 : 호스트를 다른 여러 인스턴스와 공유해서 사용

 

멀티 테넌시 : 호스트 머신에서 실행하는 하이퍼바이저라고 하는 것이 가상 머신끼리 서로 물리적인 리소스를 공유하도록 책임을 지고 있는데,  이렇게 여러 가상머신이 기본적인 하드웨어를 공유하는 것

 

하이퍼바이저

• 멀티 테넌시 조정을 책임지고 이 모든 과정은 AWS에서 관리
• 하이퍼바이저는 호스트의 리소스를 서로 공유하는 가상 머신이라고 하는 것을 서로 분리해주는 일을 책임
  • = 각 EC2 인스턴스가 서로 격리가 되어서 안전하다는 뜻
  • 서로 리소스를 공유할 수는 있지만 EC2 인스턴스는 그 호스트에 있는 다른 EC2 인스턴스는 전혀 인식하지 못함 = 안전 & 분리

인스턴스의 수직 확장 : EC2의 굉장히 작은 인스턴스부터 시작해서 애플리케이션이 서버 한도를 초과하기 시작하면 그때 인스턴스에 더 많은 메모리와 CPU를 제공

 

-

 

EC2 인스턴스 유형

 

(if 커피숍)EC2 인스턴스 = 직원 = 클라이언트 요청 처리 = 여러 명, 여러 역할 필요

 

계산원 = 메모리 최적화 EC2 인스턴스바리스타 = 컴퓨팅 최적화 인스턴스라떼아트 직원 = 엑셀러레이티드 컴퓨팅 인스턴스커피 = 인스턴스가 생산하는 항목

 

<인스턴스 패밀리>

1. 범용 인스턴스 : 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공 
   • 애플리케이션 서버
   • 게임 서버
   • 엔터프라이즈 애플리케이션용 백엔드 서버
   • 중소 규모 데이터베이스
     • if 컴퓨팅, 메모리, 네트워킹에 필요한 리소스가 거의 동일한 애플리케이션 -> 어느 한 리소스 영역의 최적화가 필요한 애플리케이션 X => 범용 인스턴스 실행 적합
2. 컴퓨팅 최적화 인스턴스 : 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합
   • 범용 인스턴스와 마찬가지로 컴퓨팅 최적화 인스턴스는 웹 서버, 애플리케이션 서버, 게임 서버와 같은 워크로드에 사용가능
   • 컴퓨팅 최적화 애플리케이션은 고성능 웹 서버, 컴퓨팅 집약적 애플리케이션 서버 및 게임 전용 서버에 적합하다는 점이 다름
   • 컴퓨팅 최적화 인스턴스를 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용가능
3. 메모리 최적화 인스턴스 : 메모리에서 대규모 데이터 집합을 처리하는 워크로드에 빠른 성능을 제공
   • 컴퓨팅에서 메모리 = 임시 스토리지 영역, CPU가 작업을 완료하는데 필요한 모든 데이터와 명령 들어있음 
   • 컴퓨터 프로그램&애플리케이션 -> 스토리지에서 메모리로 로드된 후 실행
   • 이러한 로드 프로세스 덕분에 CPU가 컴퓨터 프로그램에 직접 액세스 할 수 있는거임
     • if 애플리케이션 실행 전 많은 데이터 미리 로드해야하는 워크로드 있음(고성능 데이터, 많은 양의 비정형 데이터의 실시간 처리가 필요한 워크로드 등) => 이러한 사례는 메모리 최적화 인스턴스 사용 고려 
4. 엑셀러레이티드 컴퓨팅 인스턴스 : 하드웨어 액셀러레이터 또는 코프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서 보다 더 효율적으로 수행(부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등)
   • 컴퓨팅에서 하드웨어 액셀러레이터 = 데이터 처리를 가속화할 수 있는 구성 요소
   • 가속 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합
5. 스토리지 최적화 인스턴스 : 로컬 스토리지의 대규모 데이터 집합에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계
   • 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등의 워크로드 적합
     • 컴퓨팅에서 초당 입출력 작업 수(IOPS) = 스토리지 디바이스의 성능 측정 지표 = 디바이스가 1초 내에 수행할 수 있는 입력 또는 출력 작업의 수 
       • => 스토리지 최적화 인스턴스는 지연 시간이 짧은 임의 IOPS를 애플리케이션에 제공하도록 설계
     • 입력 작업 - 데이터베이스에 입력되는 레코드처럼 시스템에 투입되는 데이터 / 출력 작업 - 서버에서 생성된 데이터(예; 데이터베이스의 레코드에 대해 수행되는 분석) 
       •  IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지 최적화 인스턴스 적용 고려

 

문제

 

Q. 데이터 웨어하우징 애플리케이션에 적합한 Amazon EC2 인스턴스 유형? 

A. 스토리지 최적화

 

(* 데이터 웨어하우스 : 보다 정보에 입각한 의사 결정을 내릴 수 있도록 분석 가능한 정보의 중앙 리포지토리,

데이터는 트랜잭션 시스템, 관계형 데이터베이스 및 기타 소스로부터 보통 정기적으로 데이터 웨어하우스로 들어감,

;데이터 저장 방식

1) 자주 액세스하는 데이터 : 매우 빠른 스토리지(예: SSD 드라이브)에 저장

2) 자주 액세스하지 않는 데이터 : 저렴한 객체 스토어(예: Amazon S3)에 저장

=> 데이터 웨어하우스는 자주 액세스되는 데이터가 “빠른” 스토리지로 이동되어 쿼리 속도가 최적화되는지 자동으로 확인)

 

Q. 고성능 데이터베이스에 적합한 Amazon EC2 인스턴스 유형?A. 메모리 최적화

 

Q. 배치처리 워크로드에 가장 적합한 인스턴스 유형?

A. 컴퓨팅 최적화

• 메모리 최적화 인스턴스는 고성능 데이터베이스와 같이 메모리에서 대용량 데이터 세트를 처리하는 워크로드에 더 적합합니다.
• 스토리지 최적화 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대한 높은 순차적 읽기 및 쓰기 액세스가 필요한 워크로드를 위해 설계되었습니다. 이 질문에서는 처리할 데이터의 크기를 특정하지 않았습니다. 배치 처리에는 그룹으로 데이터를 처리하는 작업이 포함됩니다. 컴퓨팅 최적화 인스턴스는 고성능 프로세서를 활용하는 이러한 유형의 워크로드에 적합합니다.

-

 

EC2 비용

 

EC2 요금제	설명
온디맨드	사용한 컴퓨팅 시간에 대해서만 비용을 지불 - 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 가장 적합 -사용 사례: 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행 - 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않음
예약 인스턴스	계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션(1, 3년 약정) - 표준 예약 인스턴스 : 안정적 상태의 애플리케이션에 필요한 EC2 인스턴스 유형 및 크기, 그리고 해당 애플리케이션을 실행할 AWS 리전을 알고 있는 경우에 적합 - 컨버터블 예약 인스턴스 :  EC2 인스턴스를 여러 가용 영역 또는 다양한 인스턴스 유형에서 실행해야 하는 경우
EC2 Instance Savings Plans	특정 인스턴스 패밀리 및 리전에 대해 1년 또는 3년 기간 동안 시간당 지출 약정 - 약정 기간 동안 Amazon EC2 사용량에 유연성이 필요한 경우 유용한 옵션
스팟 인스턴스	- 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합
전용 호스트	사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버 -기존 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 라이선스 규정 준수를 유지 - EC2 옵션 중 가장 고비용

 

 

문제

 

Q. 한 리전에서 특정 OS, 인스턴스 패밀리 및 크기, 테넌시를 실행할 여러 EC2 인스턴스를 지정할 경우 할인을 제공하는 Amazon EC2 요금 옵션?

A. 표준 예약 인스턴스

( 표준 예약 인스턴스에서는 다음을 지정해야 함

• 인스턴스 패밀리 및 크기
• 플랫폼 설명
• 테넌시
• 리전

지정한 수의 EC2 인스턴스가 1년 또는 3년 기간 동안 보장)

 

Q. 특정 인스턴스 패밀리 및 리전에 대해 1년 또는 3년 기간 동안 시간당 지출 약정을 할 경우 할인을 제공하는 Amazon EC2 요금 옵션?A. EC2 Instance Savings Plan

 

 

Q. 총 6개월 동안 실행되며 중단을 견딜 수 있는 워크로드가 있습니다. 가장 비용 효율적일 수 있는 Amazon EC2 구매 옵션? 

A. 스팟 인스턴스

 

• 예약 인스턴스는 1년 또는 3년의 약정 기간이 필요하므로 X
• 전용 인스턴스는 단일 고객 전용 하드웨어에서 Virtual Private Cloud(VPC)를 통해 실행됩니다. 전용 인스턴스에는 공유 하드웨어에서 실행되는 다른 선택지의 인스턴스보다 비용이 많이 듭니다.
• 온디맨드 인스턴스는 6개월 동안만 실행되어야 하는 요구 사항을 충족합니다. 하지만 최소 약정 기간이 필요 없고, 중단을 견딜 수 있으며, 온디맨드 인스턴스보다 비용이 저렴한 스팟 인스턴스가 가장 적합한 선택입니다.

-

 

EC2 Auto Scaling

 

- 수요에 따라 인스턴스를 추가하고 필요 없는 인스턴스는 폐기함, 24시간 내내 적절한 수의 인스턴스만 보유한다는 뜻

- 변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거가능

- 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지가능

- Auto Scaling 그룹에서 희망 Amazon EC2 인스턴스 수를 지정하지 않으면 희망 용량은 기본적으로 최소 용량으로 설정

 

; 접근 방식

• 동적 조정 : 수요 변화에 대응
• 예측 조정 : 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약

 

-

 

Elastic Load Balancing 

 

; 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스

 

• 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 함
• 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅 됨
• 그런 다음 요청을 처리할 여러 리소스로 분산
• 단일 EC2 인스턴스가 전체 워크로드를 처리하지 않아도 되도록 보장하는 역할

 

-

 

메시징 및 대기열

 

; 구성요소가 밀결합된 아키텍처 - 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있음

=> 이러한 유형의 아키텍처를 모놀리식 애플리케이션

=> 한 구성 요소에서 장애가 발생하면 다른 구성 요소에도 장애가 발생하고, 전체 애플리케이션에서 장애가 발생할 수 있음

 

; 소결합된 아키텍처 -  단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동

=> 전체 애플리케이션에 장애 발생하는 것 방지

 

=> 접근방식

1. Amazon Simple Queue Service(SQS) = 메시지 대기열 서비스

 

• SQS를 이용하면 규모에 상관없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신 가능

(if 커피숍 : 메시지 = 커피, 주문 주문판 = SQS 대기열, 메시지에는 주문자 이름, 커피 주문 내용, 주문한 시간이 표시)

 

• 메시지에 포함된 데이터 = 페이로드 / SQS 대기열 = 메시지가 처리되기 전까지 배치되는 곳

 

2. Amazon Simple Notification Service(SNS) = 게시/구독(Pub/Sub) 서비스

• 메시지를 서비스에 전달하는 데 사용한다는 점에서 비슷하지만 알림을 최종 사용자에게도 전송가능
• 모바일 푸시, SMS와 이메일을 사용하여 알림을 최종 사용자에게 전달할 수도 있음
• SQS 대기열, AWS Lambda 함수, HTTPS 혹은 HTTP 웹 후크와 같은 엔드포인트도 구독자가 될 수 있음

 

-

 

+ 추가 컴퓨팅 서비스 소개

 

서버리스 컴퓨팅 : 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻

 

AWS Lambda : 사용한 컴퓨팅 시간에 대해서만 비용을 지불, 코드를 실행하는 동안에만 요금이 부과됨

• 코드를 람다에 업로드
• AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정
• Lambda -> 트리거된 경우에만 코드를 실행

컨테이너 : 애플리케이션과 애플리케이션에서 실행해야 하는 모든 구성을 모아 놓은 코드 패키지, 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공

 

ECS, EKS - 컨테이너 오케스트레이션 도구 

 

1. Amazon Elastic Container Service(ECS) : 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템

- 도커 컨테이너 지원

 

- Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원

- Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지 가능

 

2. Amazon Elastic Kubernetes Services(EKS) : Kubernetes를 실행하는 데 사용할 수 있는 완전관리형 서비스

(Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어)

 

AWS Fargate : 컨테이너용 서버리스 컴퓨팅 엔진, Amazon ECS와 Amazon EKS에서 작동함

- 서버를 프로비저닝하거나 관리할 필요가 없음.  AWS Fargate는 자동으로 서버 인프라를 관리함.

- 컨테이너를 서버리스 컴퓨팅 플랫폼에서 실행시킬 수 있도록 하는 엔진 

 

 

Q. 컨테이너식 애플리케이션을 배포하고 관리하려고 할 때 사용할 서비스로 적합한 것?

A. EKS

풀이:

• AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고 코드를 실행할 수 있는 서비스입니다.
• Amazon Simple Queue Service(Amazon SQS)는 대기열을 통해 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있는 서비스입니다.
• Amazon Simple Notification Service(Amazon SNS)는 게시/구독 서비스입니다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시합니다.