모듈 2: 클라우드 컴퓨팅

이 장에서는 Amazon Cloud Computing을 대표하는 Amazon Elastic Compute Cloud(Amazon EC2)와 이에 대한 적절한 사용 및 관리 서비스에 대하여 알아본다. (EC2라는 용어는 자주 봐 왔는데 C가 2개라서 EC2라는 거를 이제 알게 되었다.)

 

Amazon Elastic Compute Cloud(Amazon EC2) 소개

우리가 온프레미스 환경에서 흔히 서버라고 말하던 장비를 EC2라고 한다. 용어에서 볼 수 있듯이 쉽게 말해 "클라우드 컴퓨터"를 말한다. 아마존 클라우드 환경에서 가장 기본이 되는 서비스라고 할 수 있다.

 

다음 특성을 가진 온프레미스 환경과 비교하여

• 미리 하드웨어를 구매해야 한다.
• 서버가 배달될 때까지 기다려야 한다.
• 물리적 데이터 센터에 서버를 설치해야 한다.
• 필요한 모든 구성을 수행해야 한다.

Amazon EC2 인스턴스를 사용할 경우 다음과 같은 장점이 있다.

• 몇 분이면 Amazon EC2 인스턴스를 프로비저닝하고 시작할 수 있다.
• 워크로드 실행을 완료했다면 인스턴스 사용을 중지할 수 있다.
• 인스턴스가 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고 인스턴스가 중지 또는 종료된 상태에서는 비용을 지불하지 않는다.
• 필요한 서버 용량에 대해서만 비용을 지불하므로 비용을 절감할 수 있다.

위와 같이 Amazon EC2 인스턴스를 사용하면 우리가 사용한 만큼만 비용을 지불하는 종량 과금이 되는데, 이를 "온디맨드 서비스"라고 한다. 대부분의 Amazon AWS의 서비스는 이러한 온디맨드 서비스로 유지된다.

 

Amazon EC2 작동 방식

 

Amazon EC2 인스턴스 유형

컴퓨터를 하나 장만한다고 생각해보자. 게임용 컴퓨터가 필요한 사람은 사람은 그래픽카드에 많은 투자를 할 것이고, 많은 사진이나 동영상을 보관하고 싶은 사람은 디스크 용량에 많은 투자를 할 것이고, 일반적인 문서작업을 하고 싶은 사람은 적절한 사양을 비용에 맞춰 구입할 것이다. 또 어떤 사람은 잠깐만 사용하고 말 것이라 임대를 하는 경우도 있을 수 있다.

이처럼 Amazon EC2도 용도에 맞게 유형 별로 인스턴스를 생성하여 사용할 수 있는데, 각 유형은 "인스턴스 패밀리"로 분류되어 특정 유형의 작업에 최적화 된다.

• 범용 인스턴스
  컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공하므로 애플리케이션 서버, 게임 서버, 엔터프라이즈 애플리케이션용 백엔드 서버, 중소 규모 데이터베이스와 같은 다양한 워크로드에서 사용할 수 있다.
• 컴퓨팅 최적화 인스턴스
  고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합하다. 고성능 웹 서버 또는 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용할 수 있다.
• 메모리 최적화 인스턴스
  메모리에서 대규모 데이터 세트를 처리하는 워크로드를 처리할 수 있다. 애플리케이션을 실행하기 전에 많은 데이터를 미리 로드하는 경우나, 방대한 양의 비정형 데이터의 실시간 처리가 필요한 고성능 데이터베이스일 수도 있다.
• 액셀러레이티드 컴퓨팅 인스턴스
  하드웨어 액셀러레이터 또는 코어 프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행한다. 이러한 기능의 예로는 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등이 있다.
• 스토리지 최적화 인스턴스
  로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등이 있다.

 

Amazon EC2 요금

Amazon EC2는 사용 사례에 따라 다양한 요금 옵션을 제공한다.

• 온디맨드
  선결제 비용이나 최소 약정은 적용되지 않는다. 인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다. 온디맨드 인스턴스의 사용 사례에는 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행이 포함된다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않는다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용 절감 효과가 더 크기 때문이다.
• Amazon EC2 Savings Plans
  1년 또는 3년 기간 동안 일정한 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있다. 이 기간 약정을 통해 온디맨드 요금에 비해 최대 72%까지 비용을 절감할 수 있다. 약정 사용량까지는 할인된 Savings Plan 요금이 청구되며(예: 시간당 10 USD), 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금이 부과된다.
  
• 예약 인스턴스
  온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션이다. 표준 예약 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정으로, 예약 인스턴스 약정 기간이 끝나면 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있다. 하지만 다음 중 하나를 수행할 때까지는 온디맨드 요금이 부과된다.
  - 인스턴스 종료
  - 인스턴스 속성(인스턴스 유형, 리전, 테넌시, 플랫폼)과 일치하는 새 예약 인스턴스를 구입
• 스팟 인스턴스
  시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합하다. 스팟 인스턴스는 미사용 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 요금의 최대 90%까지 비용을 절감할 수 있다. 필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사 데이터 처리 작업)에 적합하다.
  
• 전용 호스트
  사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버이다.  지금까지 다룬 모든 Amazon EC2 옵션 중에서 전용 호스트가 가장 비용이 많이 든다.
  

 

Amazon EC2 확장 (Auto Scaling)

365일 24시간 동안 일정한 사용량을 가지는 시스템은 거의 없다. 오전 12시부터 오후 2시까지의 사용량이 가장 높은 시스템도 있고, 야간에 사용량이 높은 시스템도 있다. 월요일이 사용량이 높은 시스템이 있는가 하면, 연말에만 사용량이 높은 시스템도 있다. 우리는 이에 따라 시스템 사양을 최대 트래픽을 기준으로 설정해야 할 지, 평균 트래픽 기준으로 설정해야 할 지 등을 고민해야 한다.

그러나 Amazon Auto Scaling 을 사용한다면 이러한 고민 없이 자동으로 리소스를 확장하고 축소하여 수요 변화에 대응할 수 있다.

Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling 그룹을 생성할 때 최소 Amazon EC2 인스턴스의 수와 희망용량, 최대 용량을 설정하여 자동으로 리소스의 양을 조절할 수 있다. Amazon EC2 Auto Scaling은 Amazon EC2 인스턴스를 사용하므로 사용하는 인스턴스에 대해서만 비용을 지불하면 된다. 이를 통해 비용을 줄이면서도 최상의 고객 경험을 제공하는 비용 효율적인 아키텍처를 구성할 수 있다.

 

Elastic Load Balancing(ELB)을 사용하여 트래픽 리디렉션

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스이다. 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다. 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅된다. 그런 다음 요청을 처리할 여러 리소스로 분산시킨다.

예: Elastic Load Balancing

위 이미지는 Amazon EC2 인스턴스가 Auto Scaling 그룹으로 묶인 상태에서 ELB를 통해 트래픽이 분산되는 개념을 도식화 한 것이다. 모든 트래픽은 ELB를 거쳐서 적합한 EC2 인스턴스로 균등하게 분배된다.

 

메시징 및 대기열

애플리케이션A에서 애플리케이션B로 케시지를 보낸다고 하자. 만약 애플리케이션B에 장애가 발생하여 메시지를 받을 수 없게 되면 일반적인 경우에 애플리케이션A에도 오류가 표시되기 시작한다. 구성요소가 서로 통신하여 데이터를 전송하고, 요청을 이행하는 밀접한 관계를 가질 때 이를 "밀결합된 아키텍처" 또는 "모놀리식 아키텍처"라고 한다. Amazon AWS에서는 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 각 애플리케이션의 연결을 별도의 대기열로 관리해 주는 서비스를 제공하여 "소결합된 아키텍처"를 구현하고자 한다.

이에 AWS에서는 두 가지의 메시징 및 대기열 서비스를 소개한다.

• Amazon Simple Queue Service(Amazon SQS)
  Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있다. Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송한다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제한다.
• Amazon Simple Notification Service(Amazon SNS)
  Amazon SNS는 게시/구독 서비스이다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시한다. Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있다.

 

추가 AWS 컴퓨팅 서비스

위에서 EC2에 대한 Auto Scaling과 Load Balancing 등 서버 인프라에 대한 내용이 있었다면 여기서는 보다 서버에 비종속적인 서비스를 소개한다. 

• AWS Lambda
  서버리스 컴퓨팅 옵션 중 하나로 Lambda 함수라는 곳에 코드를 업로드하여 트리거를 구성하면 Lambda 함수에서 서비스가 트리거를 기다린다. 트리거가 감지되면 코드는 관리형 환경에서 자동으로 실행된다. 자동으로 규모가 조절되고 가용성이 높으며 환경 내 모든 유지관리를 AWS가 수행하기 때문에 사용자가 걱정할 거리가 별로 없는 환경이 구성된다.
• Amazon Elastic Container Service(ECS), Amazon Elastic Kubernetes Service(EKS)
  이 둘은 모두 Docker 컨테이너의 오케스트레이션 도구이다.
  Docker는 많은 곳에서 사용하는 플랫폼으로 운영 체제 수준 가상화를 사용하여 컨테이너에 소프트웨어를 제공한다. 컨테이너는 애플리케이션과 관련 종속성 및 애플리케이션에서 실행해야 하는 모든 구성을 모아 놓은 코드 패키지이며, 이러한 컨테이너는 EC2 인스턴스에서 실행되며 가상 머신 작동 방식과 비슷하게 서로 격리되어 실행된다. AWS에서 Docker 컨테이너를 사용할 때는 단일 EC2 인스턴스뿐만 아니라 클러스터라고 하는 인스턴스 모음에서 실행되는 컨테이너도 시작, 중지, 재시작, 모니터링하는 프로세스가 필요한데, 이러한 작업을 수행하는 프로세스를 컨테이너 오케스트레이션이라고 한다.
  ECS와 EKS는 비슷한 작업을 수행하지만 다른 도구와 다른 기능을 사용한다.
• AWS Fargate
  AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동한다. AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요 없이 자동으로 서버 인프라가 관리된다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 된다.