AWS CLF-02 #2 상세 정리

Amazon Elastic Compute Cloud(Amazon EC2)

Amazon EC2(Amazon Elastic Compute Cloud)는 클라우드에서 Amazon EC2 인스턴스로 안전하고 크기 조정이 가능한 컴퓨팅 용량을 제공합니다.

회사 리소스의 아키텍처를 책임지고 있으며 새로운 웹사이트를 지원해야 한다고 가정해 보세요. 기존의 온프레미스 리소스를 사용하면 다음과 같은 작업을 수행해야 합니다:

• 하드웨어를 구매하기 위해 선불로 돈을 지출합니다.
• 서버가 배송될 때까지 기다립니다.
• 물리적 데이터 센터에 서버를 설치합니다.
• 필요한 모든 구성을 수행합니다.

이에 비해 Amazon EC2 인스턴스를 사용하면 가상 서버를 사용하여 AWS 클라우드에서 애플리케이션을 실행할 수 있습니다.

• 몇 분 안에 Amazon EC2 인스턴스를 프로비저닝하고 시작할 수 있습니다.
• 워크로드 실행이 끝나면 사용을 중단할 수 있습니다.
• 인스턴스를 중지하거나 종료할 때가 아니라 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.
• 필요하거나 원하는 서버 용량에 대해서만 비용을 지불하여 비용을 절감할 수 있습니다.

Amazon EC2 작동 방식

 

시작

먼저 인스턴스를 시작합니다. 인스턴스에 대한 기본 구성이 포함된 템플릿을 선택하여 시작합니다. 이러한 구성에는 운영 체제, 애플리케이션 서버 또는 애플리케이션이 포함됩니다. 또한 인스턴스의 특정 하드웨어 구성인 인스턴스 유형도 선택합니다.

인스턴스 시작을 준비할 때 인스턴스 안팎으로 유입 및 유출될 수 있는 네트워크 트래픽을 제어하기 위한 보안 설정을 지정합니다.

연결하기

다음으로 인스턴스에 연결합니다. 여러 가지 방법으로 인스턴스에 연결할 수 있습니다. 프로그램과 애플리케이션은 인스턴스에 직접 연결하여 데이터를 교환할 수 있는 여러 가지 방법을 사용할 수 있습니다. 사용자는 로그인하여 컴퓨터 데스크톱에 액세스하여 인스턴스에 연결할 수도 있습니다.

사용

인스턴스에 연결한 후에는 인스턴스 사용을 시작할 수 있습니다. 명령을 실행하여 소프트웨어 설치, 스토리지 추가, 파일 복사 및 정리 등의 작업을 수행할 수 있습니다.

 

Amazon EC2 인스턴스 유형

Amazon EC2 인스턴스 유형은 다양한 작업에 최적화되어 있습니다. 인스턴스 유형을 선택할 때는 워크로드 및 애플리케이션의 특정 요구 사항을 고려하세요. 여기에는 컴퓨팅, 메모리 또는 스토리지 기능에 대한 요구 사항이 포함될 수 있습니다.

범용 인스턴스

범용 인스턴스는 컴퓨팅, 메모리 및 네트워킹 리소스의 균형을 제공합니다. 다음과 같은 다양한 워크로드에 사용할 수 있습니다:

• 애플리케이션 서버
• 게임 서버
• 엔터프라이즈 애플리케이션용 백엔드 서버
• 중소규모 데이터베이스

컴퓨팅, 메모리 및 네트워킹에 필요한 리소스가 거의 동일한 애플리케이션이 있다고 가정해 보겠습니다. 이 애플리케이션은 단일 리소스 영역에서 최적화가 필요하지 않으므로 범용 인스턴스에서 실행하는 것을 고려할 수 있습니다.

컴퓨팅 최적화 인스턴스

컴퓨팅최적화 인스턴스는 고성능 프로세서의 이점을 활용하는 컴퓨팅 기반 애플리케이션에 이상적입니다. 범용 인스턴스와 마찬가지로 웹, 애플리케이션, 게임 서버와 같은 워크로드에 컴퓨팅 최적화 인스턴스를 사용할 수 있습니다.

그러나 컴퓨팅 최적화 애플리케이션은 고성능 웹 서버, 컴퓨팅 집약적인 애플리케이션 서버 및 전용 게임 서버에 이상적이라는 차이점이 있습니다. 또한 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에도 컴퓨팅 최적화 인스턴스를 사용할 수 있습니다.

메모리 최적화 인스턴스

메모리최적화 인스턴스는 메모리에서 대규모 데이터 세트를 처리하는 워크로드에 빠른 성능을 제공하도록 설계되었습니다. 컴퓨팅에서 메모리는 임시 저장 영역입니다. 메모리는 중앙 처리 장치(CPU)가 작업을 완료하는 데 필요한 모든 데이터와 명령을 저장합니다. 컴퓨터 프로그램이나 애플리케이션을 실행하기 전에 스토리지에서 메모리로 로드됩니다. 이 사전 로드 프로세스를 통해 CPU는 컴퓨터 프로그램에 직접 액세스할 수 있습니다.

애플리케이션을 실행하기 전에 대량의 데이터를 미리 로드해야 하는 워크로드가 있다고 가정해 보겠습니다. 이 시나리오는 고성능 데이터베이스 또는 대량의 비정형 데이터를 실시간으로 처리하는 워크로드일 수 있습니다. 이러한 유형의 사용 사례에서는 메모리 최적화 인스턴스 사용을 고려하세요. 메모리 최적화 인스턴스를 사용하면 메모리를 많이 필요로 하는 워크로드를 실행하고 뛰어난 성능을 얻을 수 있습니다.

가속 컴퓨팅 인스턴스

가속 컴퓨팅 인스턴스는 하드웨어 가속기 또는 코프로세서를 사용하여 CPU에서 실행되는 소프트웨어에서 가능한 것보다 더 효율적으로 일부 기능을 수행합니다. 이러한 기능의 예로는 부동 소수점 숫자 계산, 그래픽 처리, 데이터 패턴 일치 등이 있습니다.

컴퓨팅에서 하드웨어 가속기는 데이터 처리 속도를 높일 수 있는 구성 요소입니다. 가속 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 이상적입니다.

스토리지 최적화 인스턴스

스토리지 최적화 인스턴스는 로컬 스토리지의 대용량 데이터 세트에 대한 순차적인 읽기 및 쓰기 액세스가 필요한 워크로드를 위해 설계되었습니다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 빈도가 높은 온라인 트랜잭션 처리(OLTP) 시스템 등이 있습니다.

컴퓨팅에서 초당 입출력 작업 수(IOPS)라는 용어는 스토리지 장치의 성능을 측정하는 지표입니다. 이는 장치가 1초 동안 수행할 수 있는 다양한 입력 또는 출력 작업의 수를 나타냅니다. 스토리지에 최적화된 인스턴스는 애플리케이션에 수만 개의 낮은 지연 시간, 랜덤 IOPS를 제공하도록 설계되었습니다.

입력 작업은 데이터베이스에 입력된 레코드와 같이 시스템에 입력되는 데이터로 생각할 수 있습니다. 출력 작업은 서버에서 생성된 데이터입니다. 출력의 예로는 데이터베이스의 레코드에 대해 수행되는 분석을 들 수 있습니다. IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지에 최적화된 인스턴스가 이러한 종류의 사용 사례에 최적화되지 않은 다른 인스턴스 유형에 비해 더 나은 성능을 제공할 수 있습니다.

 

Amazon EC2 가격

Amazon EC2를 사용하면 사용한 컴퓨팅 시간에 대해서만 비용을 지불하면 됩니다. Amazon EC2는 다양한 사용 사례에 맞는 다양한 가격 옵션을 제공합니다. 예를 들어, 사용 사례에서 중단을 견딜 수 있는 경우 스팟 인스턴스를 사용하여 비용을 절약할 수 있습니다. 또한 예약 인스턴스를 통해 조기에 커밋하고 최소 사용 수준을 고정하여 비용을 절감할 수도 있습니다.

온디맨드

온디맨드 인스턴스는 중단할 수 없는 단기간의 불규칙한 워크로드에 이상적입니다. 선불 비용이나 최소 계약이 적용되지 않습니다. 인스턴스는 사용자가 중지할 때까지 계속 실행되며, 사용한 컴퓨팅 시간만큼만 비용을 지불하면 됩니다. 온디맨드 인스턴스의 샘플 사용 사례에는 애플리케이션 개발 및 테스트, 예측할 수 없는 사용 패턴을 가진 애플리케이션 실행 등이 있습니다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장되지 않습니다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용을 더 많이 절감할 수 있기 때문입니다.

Amazon EC2 절약 요금제

AWS는 Amazon EC2를 비롯한 여러 컴퓨팅 서비스에 대한 절약 플랜을 제공합니다.Amazon EC2 절약 플랜을 사용하면 1년 또는 3년 동안 일정한 양의 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있습니다. 이 기간 약정을 통해 온디맨드 비용보다 최대 72%까지 절감할 수 있습니다.

약정까지의 사용량은 할인된 절약 요금제 요율(예: 시간당 $10)로 청구됩니다. 약정을 초과하는 사용량은 일반 온디맨드 요금으로 청구됩니다.

절약형 요금제 옵션을 고려 중인 경우, AWS 비용 탐색기를 통해 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량을 분석할 수 있습니다. 또한 AWS 비용 탐색기는 절약 요금제에 대한 맞춤형 권장 사항도 제공합니다. 이러한 권장 사항은 이전 Amazon EC2 사용량과 1년 또는 3년 저축 플랜의 시간당 약정 금액을 기반으로 월별 Amazon EC2 비용을 얼마나 절약할 수 있는지 추정합니다.

예약 인스턴스

예약 인스턴스는 계정의 온디맨드 인스턴스 사용에 적용되는 청구 할인입니다. 1년 또는 3년 기간의 표준 예약 및 전환 예약 인스턴스와 1년 기간의 예약 예약 인스턴스를 구매할 수 있습니다. 3년 옵션을 사용하면 더 큰 비용 절감 효과를 얻을 수 있습니다.

예약 인스턴스 기간이 끝나면 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있습니다. 그러나 다음 중 하나를 수행할 때까지 주문형 요금이 청구됩니다:

• 인스턴스를 종료합니다.
• 인스턴스 속성(인스턴스 유형, 리전, 테넌시 및 플랫폼)과 일치하는 새 예약 인스턴스를 구매합니다.

스팟 인스턴스

스팟 인스턴스는 시작 및 종료 시간이 유연하거나 중단을 견딜 수 있는 워크로드에 이상적입니다. 스팟 인스턴스는 사용하지 않는 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 가격에서 최대 90% 할인된 가격으로 비용을 절감할 수 있습니다. 필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사를 위한 데이터 처리 작업)이 있다고 가정해 보겠습니다. 비즈니스의 전체 운영에 영향을 주지 않고 처리 작업을 시작 및 중지하려고 합니다. 스팟 요청을 하고 Amazon EC2 용량을 사용할 수 있는 경우, 스팟 인스턴스가 시작됩니다. 그러나 스팟 요청을 했는데 Amazon EC2 용량을 사용할 수 없는 경우, 용량을 사용할 수 있을 때까지 요청이 성공하지 못합니다. 사용할 수 없는 용량으로 인해 백그라운드 처리 작업의 시작이 지연될 수 있습니다. 스팟 인스턴스를 시작한 후 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 증가하면 인스턴스가 중단될 수 있습니다. 이 경우 백그라운드 처리 작업에는 문제가 발생하지 않을 수 있습니다. 그러나 애플리케이션 개발 및 테스트의 앞선 예에서는 예기치 않은 중단을 피하고 싶을 가능성이 높습니다. 따라서 이러한 작업에 적합한 다른 EC2 인스턴스 유형을 선택하세요.

전용 호스트

전용호스트는사용 전용으로 완전히 전용화된 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버입니다.

기존의 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 라이선스 규정 준수를 유지할 수 있습니다. 온디맨드 전용 호스트 및 전용 호스트 예약을 구매할 수 있습니다. 모든 Amazon EC2 옵션 중에서 전용 호스트가 가장 비쌉니다.

#1. Amazon EC2 확장하기

확장성

확장성은 필요한 리소스로만 시작하여 스케일 아웃 또는 스케일 인을 통해 변화하는 수요에 자동으로 대응하도록 아키텍처를 설계하는 것을 포함합니다. 결과적으로 사용한 리소스에 대해서만 비용을 지불합니다. 고객의 요구를 충족하기 위한 컴퓨팅 용량 부족에 대해 걱정할 필요가 없습니다.

확장 프로세스가 자동으로 수행되기를 원한다면 어떤 AWS 서비스를 사용하시겠습니까? Amazon EC2 인스턴스에 이 기능을 제공하는 AWS 서비스는Amazon EC2 자동 확장입니다.

Amazon EC2 자동 확장

로딩이 되지 않고 자주 시간 초과되는 웹사이트에 접속하려고 시도한 적이 있다면 웹사이트가 처리할 수 있는 것보다 많은 요청을 받았을 수 있습니다. 이 상황은 바리스타가 한 명밖에 없는 커피숍에서 고객의 주문을 받기 위해 긴 줄을 서서 기다리는 것과 비슷합니다.

Amazon EC2 자동 확장을 사용하면 변화하는 애플리케이션 수요에 대응하여 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있습니다. 필요에 따라 인스턴스를 자동으로 확장 및 축소함으로써 애플리케이션 가용성을 더욱 안정적으로 유지할 수 있습니다.

Amazon EC2 자동 확장에서는 동적 확장과 예측 확장이라는 두 가지 접근 방식을 사용할 수 있습니다.

• 동적 확장은 변화하는 수요에 대응합니다.
• 예측확장은 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 스케줄링합니다.
•  

#2 Amazon EC2 확장하기

클라우드에서 컴퓨팅 성능은 프로그래밍 리소스이므로 확장 문제에 대해 보다 유연한 접근 방식을 취할 수 있습니다. 애플리케이션에 Amazon EC2 자동 확장을 추가하면 필요할 때 애플리케이션에 새 인스턴스를 추가하고 더 이상 필요하지 않을 때 종료할 수 있습니다.

Amazon EC2 인스턴스에서 애플리케이션을 시작할 준비를 하고 있다고 가정해 보겠습니다. 자동 확장 그룹의 크기를 구성할 때 최소 Amazon EC2 인스턴스 수를 1개로 설정할 수 있습니다. 즉, 항상 하나 이상의 Amazon EC2 인스턴스가 실행 중이어야 합니다.

자동 확장 그룹을 생성할 때 최소 Amazon EC2 인스턴스 수를 설정할 수 있습니다.최소 용량은 자동 확장 그룹을 생성한 후 즉시 시작되는 Amazon EC2 인스턴스 수입니다. 이 예제에서 자동 확장 그룹의 최소 용량은 Amazon EC2 인스턴스 1개입니다.

다음으로 애플리케이션을 실행하는 데 최소 하나의 Amazon EC2 인스턴스가 필요하지만원하는 용량을 Amazon EC2 인스턴스 2개로 설정할 수 있습니다.

참고: 자동 확장 그룹에서 원하는 Amazon EC2 인스턴스 수를 지정하지 않으면 원하는 용량이 최소 용량으로 기본 설정됩니다.

자동 스케일링 그룹에서 설정할 수 있는 세 번째 구성은최대 용량입니다. 예를 들어, 수요 증가에 대응하여 스케일 아웃하도록 자동 확장 그룹을 구성할 수 있지만 최대 4개의 Amazon EC2 인스턴스까지만 확장할 수 있습니다.

Amazon EC2 자동 확장은 Amazon EC2 인스턴스를 사용하기 때문에 사용한 인스턴스에 대해서만 비용을 지불합니다.

 

탄력적 로드 밸런서

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

로드 밸런서는 자동 확장 그룹으로 들어오는 모든 웹 트래픽에 대한 단일 접점 역할을 합니다. 즉, 들어오는 트래픽의 양에 따라 Amazon EC2 인스턴스를 추가하거나 제거할 때 이러한 요청은 먼저 로드 밸런서로 라우팅됩니다. 그런 다음 요청은 요청을 처리할 여러 리소스로 분산됩니다. 예를 들어, Amazon EC2 인스턴스가 여러 개 있는 경우, Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하여 단일 인스턴스가 대부분의 워크로드를 처리하지 않도록 합니다.

Elastic Load Balancing과 Amazon EC2 자동 확장은 별도의 서비스이지만, 함께 작동하여 Amazon EC2에서 실행되는 애플리케이션이 높은 성능과 가용성을 제공할 수 있도록 도와줍니다.

예시: 탄력적 부하 분산

수요가 적은 기간

다음은 Elastic Load Balancing이 어떻게 작동하는지에 대한 예시입니다. 몇 명의 고객이 커피숍에 와서 주문을 할 준비가 되었다고 가정해 보겠습니다.

계산대가 몇 개만 열려 있다면 이는 서비스를 필요로 하는 고객의 수요와 일치합니다. 커피숍에 손님이 없는 계산대가 열려 있을 가능성은 적습니다. 이 예제에서는 계산대를 Amazon EC2 인스턴스로 생각할 수 있습니다

수요가 많은 기간

하루 종일 고객 수가 증가함에 따라 커피숍은 고객을 수용하기 위해 더 많은 계산대를 엽니다. 다이어그램에서 자동 확장 그룹은 이를 나타냅니다.

또한 커피숍 직원이 고객을 가장 적합한 계산대로 안내하여 요청 수가 열려 있는 계산대 전체에 고르게 분산될 수 있도록 합니다. 이 커피숍 직원을 로드 밸런서라고 생각할 수 있습니다.

모놀리식 애플리케이션 및 마이크로서비스

모놀리식 애플리케이션

애플리케이션은 여러 구성 요소로 이루어져 있습니다. 구성 요소는 서로 통신하여 데이터를 전송하고 요청을 처리하며 애플리케이션을 계속 실행합니다.

컴포넌트가 긴밀하게 결합된 애플리케이션이 있다고 가정해 봅시다. 이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있습니다. 이러한 유형의 아키텍처는모놀리식 애플리케이션으로 간주할 수 있습니다.

이러한 애플리케이션 아키텍처 접근 방식에서는 단일 구성 요소에 장애가 발생하면 다른 구성 요소도 장애를 일으키고 전체 애플리케이션이 장애를 일으킬 수 있습니다.

마이크로서비스

단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지하기 위해마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있습니다.

마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 느슨하게 결합됩니다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소는 서로 통신하기 때문에 계속 작동합니다. 느슨한 결합은 전체 애플리케이션이 실패하는 것을 방지합니다.

AWS에서 애플리케이션을 설계할 때는 서로 다른 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있습니다. 두 가지 서비스가 애플리케이션 통합을 용이하게 합니다: Amazon SNS(Amazon Simple Notification Service)와 Amazon SQS(Amazon Simple Queue Service)입니다.

 

아마존 간편 알림 서비스(아마존 SNS)

Amazon 단순 알림 서비스(Amazon SNS)는 게시/구독 서비스입니다. 게시자는 Amazon SNS 토픽을 사용하여 구독자에게 메시지를 게시합니다. 이는 커피숍에서 계산원이 음료를 만드는 바리스타에게 커피 주문을 제공하는 것과 유사합니다.

Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS 람다 함수 또는 기타 여러 옵션이 될 수 있습니다.

단일 주제에서 업데이트 게시

 

커피숍에 비즈니스의 모든 영역에 대한 업데이트가 포함된 단일 뉴스레터가 있다고 가정해 보겠습니다. 여기에는 쿠폰, 커피 상식, 신제품 등의 주제가 포함됩니다. 이 모든 주제는 단일 뉴스레터이므로 그룹화되어 있습니다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 퀴즈, 신제품에 대한 업데이트를 받게 됩니다.

얼마 후 일부 고객은 관심 있는 특정 주제에 대해서만 별도의 뉴스레터를 받고 싶다는 의사를 표시합니다. 커피숍 소유주는 이 방법을 시도하기로 결정합니다.

여러 주제의 업데이트 게시

이제 이 커피숍은 모든 주제에 대한 단일 뉴스레터 대신 세 개의 개별 뉴스레터로 나누었습니다. 각 뉴스레터는 쿠폰, 커피 관련 퀴즈, 신제품 등 특정 주제를 다루고 있습니다.

이제 구독자는 자신이 구독한 특정 주제에 대한 업데이트만 즉시 받게 됩니다.

구독자는 단일 주제 또는 여러 주제를 구독할 수 있습니다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고, 두 번째 고객은 커피 퀴즈 주제만 구독하는 식입니다. 세 번째 고객은 커피 퀴즈와 신제품 주제를 모두 구독합니다.

아마존 단순 대기열 서비스(Amazon SQS)

AmazonSQS(Amazon Simple Queue Service)는 메시지 큐 서비스입니다.

Amazon SQS를 사용하면 메시지가 손실되거나 다른 서비스를 사용할 수 없어도 소프트웨어 구성 요소 간에 메시지를 보내고, 저장하고, 받을 수 있습니다. Amazon SQS에서 애플리케이션은 메시지를 큐로 보냅니다. 사용자 또는 서비스가 대기열에서 메시지를 검색하여 처리한 다음 대기열에서 삭제합니다.

예시: 주문 처리

커피숍에서 계산원이 주문을 받고 바리스타가 주문을 만드는 주문 프로세스가 있다고 가정해 보겠습니다. 계산원과 바리스타를 애플리케이션의 두 가지 개별 구성 요소로 생각하면 됩니다.

먼저 계산원이 주문을 받아 종이에 적습니다. 다음으로 계산원이 바리스타에게 종이를 전달합니다. 마지막으로 바리스타가 음료를 만들어 고객에게 제공합니다.

다음 주문이 들어오면 이 과정이 반복됩니다. 이 과정은 계산원과 바리스타가 서로 협력하는 한 원활하게 진행됩니다.

만약 계산원이 주문을 받아 바리스타에게 전달하러 갔는데 바리스타가 휴식 중이거나 다른 주문으로 바쁘다면 어떻게 될까요? 계산원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 합니다. 이렇게 되면 주문 프로세스가 지연되고 고객은 주문을 받기까지 더 오래 기다려야 합니다.

커피숍의 인기가 높아지고 주문 라인이 더 느리게 움직이면서 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 됩니다. 그래서 대기열을 사용하는 다른 접근 방식을 시도하기로 결정합니다.

예시: 대기열에 있는 주문

계산원과 바리스타는 애플리케이션의 두 가지 개별 구성 요소라는 점을 기억하세요. Amazon SQS와 같은 메시지 큐 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 주고받을 수 있습니다.

이 예에서 프로세스의 첫 번째 단계는 이전과 동일하게 고객이 계산원에게 주문을 하는 것입니다.

계산원이 주문을 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 완충 역할을 하는 주문 보드라고 생각하면 됩니다. 바리스타가 휴식 중이거나 다른 주문으로 바쁘더라도 계산원은 대기열에 새 주문을 계속 넣을 수 있습니다.

그런 다음 바리스타가 대기열을 확인하고 주문을 가져옵니다.

바리스타가 음료를 준비하여 고객에게 제공합니다.

그런 다음 바리스타는 완료된 주문을 대기열에서 제거합니다.

바리스타가 음료를 준비하는 동안 계산원은 계속해서 새 주문을 받아 대기열에 추가할 수 있습니다.

 

서버리스 컴퓨팅

이 모듈의 앞부분에서는 클라우드에서 가상 서버를 실행할 수 있는 서비스인 Amazon EC2에 대해 배웠습니다. Amazon EC2에서 실행하려는 애플리케이션이 있는 경우 다음을 수행해야 합니다:

1. 인스턴스(가상 서버)를 프로비저닝합니다.
2. 코드를 업로드합니다.
3. 애플리케이션이 실행되는 동안 인스턴스를 계속 관리합니다.

 

"서버리스"라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없음을 의미합니다. 서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있습니다.

서버리스 컴퓨팅의 또 다른 장점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성입니다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있습니다.

서버리스 컴퓨팅을 위한 AWS 서비스로는AWS Lambda가 있습니다.

 

AWS 람다

AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스입니다.

AWS Lambda를 사용하는 동안에는 사용한 컴퓨팅 시간만큼만 비용을 지불하면 됩니다. 요금은 코드가 실행 중인 경우에만 적용됩니다. 또한 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 관리 없이 실행할 수 있습니다.

예를 들어, 간단한 람다 함수는 업로드된 이미지의 크기를 AWS 클라우드에 자동으로 조정하는 기능을 포함할 수 있습니다. 이 경우 새 이미지를 업로드할 때 함수가 트리거됩니다.

AWS Lambda의 작동 방식

1. Lambda에 코드를 업로드합니다.
2. AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정합니다.
3. Lambda는 트리거될 때만 코드를 실행합니다.
4. 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 이미지 크기 조정의 이전 예제에서는 새 이미지를 업로드할 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 이미지를 업로드하면 Lambda가 이미지 크기 조정 기능을 위한 코드를 실행합니다.

컨테이너

AWS에서는컨테이너화된 애플리케이션을 빌드하고 실행할 수도 있습니다.

컨테이너는 애플리케이션의 코드와 종속성을 단일 객체로 패키징하는 표준 방법을 제공합니다. 또한 보안, 안정성 및 확장성에 대한 필수 요구 사항이 있는 프로세스 및 워크플로우에 컨테이너를 사용할 수도 있습니다.

예시

여러 컨테이너가 있는 하나의 호스트

회사의 애플리케이션 개발자가 자신의 컴퓨터에 IT 운영 담당자가 사용하는 컴퓨터의 환경과 다른 환경을 가지고 있다고 가정해 보세요. 개발자는 배포에 관계없이 애플리케이션의 환경이 일관되게 유지되기를 원하므로 컨테이너화된 접근 방식을 사용합니다. 이렇게 하면 애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단하는 데 소요되는 시간을 줄일 수 있습니다.

 

수백 개의 컨테이너가 있는 수십 개의 호스트

컨테이너화된 애플리케이션을 실행할 때는 확장성을 고려하는 것이 중요합니다. 여러 개의 컨테이너가 있는 단일 호스트 대신 수백 개의 컨테이너가 있는 수십 개의 호스트를 관리해야 한다고 가정해 보세요. 또는 수천 개의 컨테이너로 수백 개의 호스트를 관리해야 한다고 가정해 보세요. 대규모로 메모리 사용량, 보안, 로깅 등을 모니터링하는 데 얼마나 많은 시간이 소요될지 상상해 보세요.

Amazon Elastic Container Service(Amazon ECS)는 확장성이 뛰어난 고성능 컨테이너 관리 시스템으로, AWS에서 컨테이너화된 애플리케이션을 실행하고 확장할 수 있도록 지원합니다.

Amazon ECS는 Docker 컨테이너를 지원합니다.Docker는 애플리케이션을 신속하게 빌드, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. AWS는 오픈 소스 Docker 커뮤니티 에디션과 구독 기반 Docker 엔터프라이즈 에디션의 사용을 지원합니다. Amazon ECS를 사용하면 API 호출을 사용하여 Docker 지원 애플리케이션을 시작하고 중지할 수 있습니다.

 

• AWS에서 컴퓨팅
• AWS 컴퓨팅 블로그
• AWS 컴퓨팅 서비스
• 실습 튜토리얼: 컴퓨트
• 카테고리 심층 분석: 서버리스
• AWS 고객 사례: 서버리스