AWS Cloud Practitioner Essentials #2

Amazon EC2
온프레미스 리소스를 사용할 경우, 미리 하드웨어를 구매해야 하고, 서버가 배달될 때까지 기다려야 하며, 물리적 데이터 센터에 서버를 설치해야 하고, 필요한 모든 구성을 수행해야 한다. 이에 비해 Amazon EC2 인스턴스를 사용할 경우 AWS 클라우드에서 가상 서버를 사용하여 애플리케이션을 실행할 수 있다. 몇 분이면 Amazon EC2 인스턴스를 프로비저닝하고 시작할 수 있고, 워크로드 실행을 완료했다면 인스턴스 사용을 중지할 수 있다. 인스턴스가 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고, 인스턴스가 중지 또는 종료된 상태에서는 비용을 지불하지 않는다. 결국, 필요한 서버 용량에 대해서만 비용을 지불하므로 비용을 절감할 수 있다는 말이 된다.

 
Amazon EC2 작동 방식
① 시작: 먼저 인스턴스를 시작한다. 기본 구성 인스턴스가 포함되어 있는 템플릿을 선택하여 시작한다. 이러한 구성에는 운영 체제, 애플리케이션 서버 또는 애플리케이션이 포함된다. 또한 인스턴스의 특정 하드웨어 구성인 인스턴스 유형을 선택한다.
② 연결: 다음으로 인스턴스에 연결한다. 여러 가지 방법으로 인스턴스에 연결할 수 있다. 프로그램과 애플리케이션에는 인스턴스에 직접 연결하고 데이터를 교환하는 여러 가지 방법이 있다. 사용자가 로그인하여 인스턴스에 연결하고 컴퓨터 데스크톱에 연결할 수도 있다.
③ 사용: 인스턴스에 연결했다면 바로 사용할 수 있다. 명령을 실행하여 소프트웨어 설치, 스토리지 추가, 파일 복사 및 정리 등의 작업을 수행할 수 있다.
 
Amazon EC2 인스턴스 유형
Amazon EC2 인스턴스 유형은 다양한 작업에 최적화되어 있다. 인스턴스 유형을 선택할 때는 워크로드 및 애플리케이션의 구체적 요구 사항을 고려해야 한다. 여기에는 컴퓨팅, 메모리 또는 스토리지 기능에 대한 요구 사항이 포함될 수 있다.
 
① 범용 인스턴스: 범용 인스턴스는 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공한다. 이는 애플리케이션 서버, 게임 서버, 엔터프라이즈 애플리케이션용 백엔드 서버, 중소 규모 데이터베이스와 같은 다양한 워크로드에 사용할 수 있다. 컴퓨팅, 메모리, 네트워킹에 필요한 리소스가 거의 동일한 애플리케이션이 있다고 가정해 본다면, 어느 한 리소스 영역의 최적화가 필요한 애플리케이션이 아니기 때문에 범용 인스턴스에서 애플리케이션을 실행하는 것이 좋은 것이다.
 
② 컴퓨팅 최적화 인스턴스: 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합하다. 범용 인스턴스와 마찬가지로 컴퓨팅 최적화 인스턴스는 웹 서버, 애플리케이션 서버, 게임 서버와 같은 워크로드에 사용할 수 있다. 하지만 컴퓨팅 최적화 애플리케이션은 고성능 웹 서버, 컴퓨팅 집약적 애플리케이션 서버 및 게임 전용 서버에 적합하다는 점이 다르다. 또한, 컴퓨팅 최적화 인스턴스를 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용할 수도 있다.
 
③ 메모리 최적화 인스턴스: 메모리에서 대규모 데이터 집합을 처리하는 워크로드에 빠른 성능을 제공하기 위해 설계되었다. 컴퓨팅에서 메모리는 임시 스토리지 영역이다. 여기에는 중앙 처리 장치(CPU)가 작업을 완료하는 데 필요한 모든 데이터와 명령이 들어 있다. 컴퓨터 프로그램이나 애플리케이션은 스토리지에서 메모리로 로드된 후 실행된다. 이 사전 로드 프로세스 덕분에 CPU가 컴퓨터 프로그램에 직접 액세스할 수 있다. 애플리케이션을 실행하기 전에 많은 데이터를 미리 로드해야 하는 워크로드가 있다고 가정해 보도록 한다. 고성능 데이터베이스일 수도 있고 방대한 양의 비정형 데이터의 실시간 처리가 필요한 워크로드일 수도 있다. 이러한 유형의 사용 사례에서는 메모리 최적화 인스턴스 사용을 고려해야 한다. 메모리 최적화 인스턴스를 사용하면 많은 메모리가 필요한 워크로드를 실행하고 뛰어난 성능을 얻을 수 있다.
 
④ 엑셀러레이티드 컴퓨팅 인스턴스: 하드웨어 액셀러레이터 또는 코프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서 보다 더 효율적으로 수행한다. 이러한 기능의 예로는 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등이 있다. 컴퓨팅에서 하드웨어 액셀러레이터는 데이터 처리를 가속화할 수 있는 구성 요소다. 가속 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합하다.
 
⑤ 스토리지 최적화 인스턴스: 로컬 스토리지의 대규모 데이터 집합에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등이 있다. 컴퓨팅에서 초당 입출력 작업 수(IOPS)라는 용어는 스토리지 디바이스의 성능을 측정하는 지표다. IOPS는 디바이스가 1초 내에 수행할 수 있는 입력 또는 출력 작업의 수를 나타낸다. 스토리지 최적화 인스턴스는 지연 시간이 짧은 임의 IOPS를 애플리케이션에 제공하도록 설계되었다. 입력 작업은 데이터베이스에 입력되는 레코드와 같이 시스템에 투입되는 데이터라고 생각할 수 있다. 출력 작업은 서버에서 생성된 데이터다. 출력의 예로는 데이터베이스의 레코드에 대해 수행되는 분석을 들 수 있다. IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지 최적화 인스턴스는 이러한 종류의 사용 사례에 최적화되지 않은 다른 인스턴스 유형보다 나은 성능을 제공할 수 있다.
 
Amazon EC2 요금
Amazon EC2에서는 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다. Pay as you use인 것이다. Amazon EC2는 사용 사례에 따라 다양한 요금 옵션을 제공한다. 예를 들어 사용 사례가 중단을 견딜 수 있는 경우 스팟 인스턴스로 비용을 절감할 수 있다. 이에 예약 인스턴스로 사전 약정을 하고 최소 사용 수준을 고정하여 비용을 절약할 수도 있다.
 
① 온디맨드: 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 가장 적합하다. 선결제 비용이나 최소 약정은 적용되지 않는다. 인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다. 온디맨드 인스턴스의 사용 사례에는 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행이 포함된다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않는다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용 절감 효과가 더 크기 때문이다.

② 예약 인스턴스: 계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션이다. 여기에는 두 가지 유형의 예약 인스턴스가 있다. 표준 예약 인스턴스 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정으로 구입할 수 있고, 3년 약정 옵션으로 더 큰 비용 절감을 실현할 수 있다.
⑴ 표준 예약 인스턴스: 이 옵션은 안정적 상태의 애플리케이션에 필요한 EC2 인스턴스 유형 및 크기, 그리고 해당 애플리케이션을 실행할 AWS 리전을 알고 있는 경우에 적합하다. 예약 인스턴스를 사용하려면 다음 자격 요건을 명시해야 한다.
a. 인스턴스 유형 및 크기 / b. 플랫폼 설명(운영 체제) / c. 테넌시: 기본 테넌시 또는 전용 테넌시
이렇게 EC2 예약 인스턴스의 가용 영역을 지정할 수 있다. 이 사양을 지정하면 EC2 용량이 예약된다. 그러면 필요할 때 원하는 양의 EC2 인스턴스를 사용할 수 있게 되는 것이다. 
⑵ 컨버터블 예약 인스턴스: EC2 인스턴스를 여러 가용 영역 또는 다양한 인스턴스 유형에서 실행해야 하는 경우 컨버터블 예약 인스턴스가 적합할 수 있다. 참고로, EC2 인스턴스를 실행하는 데 유연성이 필요한 경우 더 큰 할인 혜택을 받는다.
 
예약 인스턴스 약정 기간 종료 시 Amazon EC2 인스턴스를 중단 없이 계속 사용할 수 있다. 하지만 인스턴스를 종료하거나, 인스턴스 속성과 일치하는 새 예약 인스턴스를 구입할 때까지는 온디맨드 요금이 부과된다.

③ EC2 Instance Savings Plans: AWS는 Amazon EC2를 비롯한 몇몇 컴퓨팅 서비스에 대한 Savings Plans를 제공한다. EC2 Instance Savings Plans는 특정 인스턴스 패밀리 및 리전에 대해 1년 또는 3년 기간 동안 시간당 지출 약정을 할 경우 EC2 인스턴스 비용을 할인한다. 이 기간 약정을 통해 온디맨드 요금 대비 최대 72%의 비용을 절감할 수 있다. 약정 사용량까지는 할인된 Savings Plans 요금이 청구된다(예: 시간당 10 USD). 물론, 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금이 청구된다. EC2 Instance Savings Plans는 약정 기간 동안 Amazon EC2 사용량에 유연성이 필요한 경우 유용한 옵션이다. 가용 영역, 인스턴스 크기, OS 또는 테넌시에 관계없이 선택한 리전에서 EC2 인스턴스 패밀리의 EC2 인스턴스를 실행(예: 버지니아 북부에서 M5를 사용)하면 비용을 절감할 수 있다는 이점이 있다. EC2 Instance Savings Plans가 제공하는 절감 효과는 표준 예약 인스턴스와 비슷하다. 그러나 예약 인스턴스와 달리 할인을 받기 위해 EC2 인스턴스 유형 및 크기(예: m5.xlarge), OS, 테넌시를 사전에 지정할 필요가 없다. 1년 또는 3년 기간 동안 특정 수의 EC2 인스턴스를 약정할 필요도 없다. 또한, EC2 Instance Savings Plans에는 EC2 용량 예약 옵션이 포함되어 있지 않다. Savings Plans 옵션을 고려하고 있는 경우, AWS Cost Explorer를 사용하여 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량을 분석할 수 있다. AWS Cost Explorer는 Savings Plans를 위한 맞춤형 권장 사항도 제공한다. 이러한 권장 사항은 이전 Amazon EC2 사용량과 1년 또는 3년 Savings Plan의 시간당 약정 금액을 기준으로 월별 Amazon EC2 비용을 얼마나 절감할 수 있는지 예상한다.

④ 스팟 인스턴스: 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합하다. 스팟 인스턴스는 미사용 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 요금의 최대 90%까지 비용을 절감할 수 있다. 필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사 데이터 처리 작업)이 있다고 가정해 본다. 전반적인 비즈니스 운영에는 영향을 주지 않고 처리 작업을 시작하고 중지하려고 한다. 스팟 요청을 하고 Amazon EC2 용량을 사용할 수 있는 경우 스팟 인스턴스가 시작된다. 하지만 스팟 요청을 했는데 Amazon EC2 용량을 사용할 수 없다면 용량을 사용할 수 있을 때까지 요청이 성공하지 못한다. 용량을 사용할 수 없으므로 백그라운드 처리 작업의 시작이 지연될 수 있다. 스팟 인스턴스를 시작한 후 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 늘면 인스턴스가 중단될 수 있다. 이 경우 백그라운드 처리 작업에는 문제가 없을 수 있다. 하지만 앞에서 예로 든 애플리케이션 개발 및 테스트에서는 예기치 않은 중단을 방지하는 것이 좋다. 따라서 해당 작업에 더 적합한 다른 EC2 인스턴스 유형을 선택한다.

⑤ 전용 호스트: 사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버다. 기존 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 라이선스 규정 준수를 유지할 수 있다. 온디맨드 전용 호스트와 전용 호스트 예약을 구매할 수도 있다. 지금까지 다룬 모든 Amazon EC2 옵션 중에서 전용 호스트가 가장 비용이 많이 든다.
 
확장성
확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 한다. 그 결과, 사용한 리소스에 대해서만 비용을 지불한다. 컴퓨팅 용량 부족 때문에 고객의 요구 사항을 충족할 수 없을지 걱정할 필요가 없다. 이 조정 프로세스가 자동으로 수행되도록 하려면 어떤 AWS 서비스를 사용해야 할까? Amazon EC2 인스턴스에 이 기능을 제공하는 AWS 서비스가 Amazon EC2 Auto Scaling이다.
 

Amazon EC2 Auto Scaling

잘 로드되지 않고 빈번히 시간 초과되는 웹 사이트에 액세스하려고 한 적이 있다면 이 웹 사이트가 처리할 수 있는 것보다 많은 요청을 수신한 것일 수 있다. 이는 커피숍에 고객의 주문을 처리할 바리스타가 한 명밖에 없을 때 길게 줄을 서서 기다리는 상황과 비슷하다.

Amazon EC2 Auto Scaling을 사용하면 변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있다. 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지할 수도 있다. Amazon EC2 Auto Scaling에서는 동적 조정과 예측 조정이라는 2가지 접근 방식을 사용할 수 있다.
⑴ 동적 조정은 수요 변화에 대응한다. 
⑵ 예측 조정은 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약한다.
 
클라우드에서는 컴퓨팅 파워가 프로그래밍 방식의 리소스이므로 더 유연한 크기 조정 방식을 사용할 수 있다. Amazon EC2 Auto Scaling을 애플리케이션에 추가하면 필요할 때 새 인스턴스를 애플리케이션에 추가했다가 더 이상 필요하지 않으면 종료할 수 있다. Amazon EC2 인스턴스에서 애플리케이션을 시작할 준비를 하고 있다고 가정해 본다. Auto Scaling 그룹의 크기를 구성할 때 최소 Amazon EC2 인스턴스 수를 1로 설정할 수 있다. 즉, 하나 이상의 Amazon EC2 인스턴스가 항상 실행 중이어야 한다.

Auto Scaling 그룹을 생성할 때 최소 Amazon EC2 인스턴스 수를 설정할 수 있다. 최소 용량은 Auto Scaling 그룹을 생성한 직후 시작되는 Amazon EC2 인스턴스의 수다. 이 예에서 Auto Scaling 그룹의 최소 용량은 Amazon EC2 인스턴스 1개가 된다. 그런 다음 애플리케이션을 실행하려면 최소 하나의 Amazon EC2 인스턴스가 필요하더라도 희망 용량을 Amazon EC2 인스턴스 2개로 설정할 수 있다. Auto Scaling 그룹에서 설정할 수 있는 세 번째 구성은 최대 용량이다. 예를 들어 수요 증가에 대응하여 확장하도록 Auto Scaling 그룹을 구성하되 Amazon EC2 인스턴스 수를 최대 4개로 제한할 수 있다. Amazon EC2 Auto Scaling은 Amazon EC2 인스턴스를 사용하므로 사용하는 인스턴스에 대해서만 비용을 지불하면 된다. 이제 우리는 비용을 줄이면서도 최상의 고객 경험을 제공하는 비용 효율적인 아키텍처를 갖는 것이다.
 

Elastic Load Balancing

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스다. 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다. 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅된다. 그런 다음 요청을 처리할 여러 리소스로 분산된다. 예를 들어 Amazon EC2 인스턴스가 여러 개인 경우 Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없다. Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스이지만 서로 연동하여 Amazon EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공하도록 돕는다.

① 수요가 적은 기간

고객 몇 명이 카페에 들어왔고 주문할 준비가 되었다고 가정해 본다. 계산대가 몇 개만 열려 있다면 이는 서비스가 필요한 고객의 수요와 일치한다. 카페에서 고객이 없는 계산대를 열어 둘 가능성은 적다. 이 예에서는 계산대를 Amazon EC2 인스턴스로 생각할 수 있다.

 

② 수요가 많은 기간

하루 종일 고객의 수가 증가함에 따라 카페는 고객을 수용하기 위해 더 많은 계산대를 연다. 또한, 카페 직원은 열려 있는 계산대에 요청 수를 균등하게 분산할 수 있도록 고객을 가장 적합한 계산대로 안내한다. 이 카페 직원을 로드 밸런서로 생각할 수 있다.

 

모놀리식 애플리케이션 및 마이크로서비스
애플리케이션은 여러 구성 요소로 구성된다. 구성 요소는 서로 통신하여 데이터를 전송하고, 요청을 이행하고, 애플리케이션을 계속 실행한다. 구성 요소가 밀결합된 애플리케이션이 있다고 가정해 본다. 이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있다. 이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있다. 이 애플리케이션 아키텍처 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성 요소에도 장애가 발생하고, 심지어 전체 애플리케이션에서 장애가 발생할 수도 있다.
 
그리고 단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있다.

마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 소결합된다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동한다. 소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지된다. AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있다. 애플리케이션 통합을 촉진하는 두 가지 서비스로는 Amazon Simple Notification Service(Amazon SNS)와 Amazon Simple Queue Service(Amazon SQS)가 있다.
 
Amazon Simple Notification Service(Amazon SNS)
Amazon Simple Notification Service(Amazon SNS)는 게시 및 구독 서비스다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시한다. 이는 카페에서 직원이 음료를 만드는 바리스타에게 주문 사항을 전달하는 것과 비슷하다. Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있다. Amazon SNS를 사용하는 방법에는 2가지가 있다.

① 단일 주제에서 업데이트 게시: 카페에 모든 비즈니스 영역의 업데이트를 포함하는 단일 뉴스레터가 있다고 가정해 본다. 여기에는 쿠폰, 커피 상식, 신제품과 같은 주제가 포함된다. 단일 뉴스레터이기 때문에 모든 주제가 그룹화된다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 상식, 신제품에 대한 업데이트를 받는다. 얼마 후 일부 고객이 관심 있는 특정 주제에
대해서만 별도의 뉴스레터를 받으면 좋겠다는 의견을 표명한다. 이에 카페 점주는 이 접근 방식을 시험해 보기로 결정한다.

② 여러 주제에서 업데이트 게시: 이제 카페는 모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나눴다. 각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룬다. 이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 된다. 구독자는 주제를 하나 또는 여러 개 구독할 수 있다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고 두 번째 구독자는 커피 상식 주제만 구독한다. 세 번째 고객은 커피 상식 주제와 신제품 주제를 구독힌다.
 
Amazon Simple Queue Service(Amazon SQS)
Amazon Simple Queue Service(Amazon SQS)는 메시지 대기열 서비스다. Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있다. Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송한다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제한다. Amazon SQS를 사용하는 방법에는 2가지가 있다.

① 주문 이행: 직원이 주문을 받고 바리스타가 주문 음료를 만드는 주문 프로세스가 카페에 있다고 가정해 본다. 직원과 바리스타가 애플리케이션의 두 가지 개별 구성 요소라고 생각한다. 먼저 직원이 주문을 받아 주문지에 적는다. 그런 다음 직원이 바리스타에게 주문지를 전달한다. 마지막으로 바리스타가 음료를 만들어 고객에게 제공한다. 다음 주문을 받으면 이 프로세스가 반복된다. 이 프로세스는 계산원과 바리스타가 함께 조율되는 한 원활하게 진행될 것이다. 만약 직원이 주문을 받아 바리스타에게 전달하려는데 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘다면 어떻게 될까? 직원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 할 것이다. 그러면 주문 프로세스가 지연되고 고객은 주문한 음료를 받을 때까지 더 오래 기다려야 한다. 카페의 인기가 많아지고 주문하려는 고객의 줄이 줄어드는 속도가 더 느려지면 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 될 것이다. 따라서 점주는 대기열을 사용하는 다른 접근 방식을 시도하기로 결정할 수 있다.

② 대기열에 있는 주문: 직원과 바리스타가 애플리케이션의 2가지 개별 구성 요소라는 점을 고려한다. Amazon SQS와 같은 메시지 대기열 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 사용할 수 있다. 이 예에서 프로세스의 첫 번째 단계는 이전과 동일하다. 즉, 고객이 직원에게 주문한다. 그러면 직원이 주문을 대기열에 넣는다. 이를 직원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있다. 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 직원은 계속해서 새 주문을 대기열에 넣을 수 있다. 다음으로 바리스타가 대기열을 확인하고 주문을 검색한다. 그러면 바리스타가 음료를 만들어 고객에게 제공한다. 바리스타는 완료된 주문을 대기열에서 제거한다. 바리스타가 음료를 만드는 동안 직원은 계속 새로운 주문을 받아 대기열에 추가할 수 있는 것이다.
 
서버리스 컴퓨팅
Amazon EC2에서 실행하려는 애플리케이션이 있는 경우 다음과 같이 해야 한다.
1단계: 인스턴스(가상 서버)를 프로비저닝한다.
2단계: 사용자 코드를 업로드한다.
3단계: 애플리케이션이 실행되는 동안 계속해서 인스턴스를 관리한다.

서버리스는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻이다. 즉, 서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있다. 서버리스 컴퓨팅의 또 다른 이점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성이다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있다. 이와 같은 서버리스 컴퓨팅용 AWS 서비스는 AWS Lambda다.
 

AWS Lambda

AWS Lambda(opens in a new tab)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스다. AWS Lambda를 사용하는 경우 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다. 코드를 실행하는 동안에만 요금이 부과된다. 사실상 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있으며 이를 관리할 필요는 전혀 없다. 예를 들어 간단한 Lambda 함수로 업로드되는 이미지의 크기를 AWS 클라우드에 맞춰 자동으로 조정하는 함수가 있을 수 있다. 이 경우 새 이미지를 업로드할 때 함수가 트리거된다.

AWS Lambda 작동 방식
1단계: 코드를 Lambda에 업로드한다. 
2단계: AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정한다.
3단계: Lambda는 트리거된 경우에만 코드를 실행한다.
4단계: 사용한 컴퓨팅 시간에 대한 요금만 지불한다. 위의 이미지 크기 조정 예에서는 새 이미지를 업로드할 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하면 된다. 이미지를 업로드하면 Lambda가 트리거되어 이미지 크기 조정 기능을 위한 코드를 실행한다.
 
컨테이너
AWS에서는 컨테이너식 애플리케이션을 빌드하고 실행할 수도 있다. 컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공한다. 보안성, 신뢰성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로에도 컨테이너를 사용한다.

① 여러 컨테이너가 있는 단일 호스트: 회사의 애플리케이션 개발자의 컴퓨터 환경이 IT 운영 직원이 사용하는 컴퓨터의 환경과 다르다고 가정해 본다. 개발자는 애플리케이션 환경이 배포와 상관없이 일관되게 유지되기를 원한다. 따라서 컨테이너식 접근 방식을 사용한다. 이를 통해 애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단하는 데 드는 시간을 줄일 수 있다.

② 수백 개의 컨테이너가 있는 수십 개의 호스트: 컨테이너식 애플리케이션을 실행할 때는 확장성을 고려하는 것이 중요하다. 여러 컨테이너가 있는 단일 호스트 대신 수백 개의 컨테이너가 있는 수십 개의 호스트를 관리해야 한다고 가정해 본다. 또는 수천 개의 컨테이너가 있는 수백 개의 호스트를 관리해야 하는 것이다. 규모가 커지면 메모리 사용량, 보안, 로깅 등을 모니터링하는 데 시간이 얼마나 걸릴지 상상해 보자. 끔찍한 일이다.
 
Amazon Elastic Container Service(Amazon ECS)
Amazon Elastic Container Service(ECS)(opens in a new tab)는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템이다. Amazon ECS는 Docker 컨테이너를 지원한다. Docker(opens in a new tab)는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼이다. AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원한다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있다.
 
Amazon Elastic Kubernetes Service(Amazon EKS)
Amazon Elastic Kubernetes Service(Amazon EKS)(opens in a new tab)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전관리형 서비스다. Kubernetes(opens in a new tab)는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어다. 자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력한다. Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 손쉽게 적용할 수 있다.
 
AWS Fargate
AWS Fargate(opens in a new tab)는 컨테이너용 서버리스 컴퓨팅 엔진이다. Amazon ECS와 Amazon EKS에서 작동한다. AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없다. AWS Fargate는 자동으로 서버 인프라를 관리하기 때문이다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 된다.