AWS SAA-C03 한국어 샘플 10번

[문제10]

회사는 AWS에서 결제 애플리케이션을 실행하려고 합니다. 애플리케이션은 모바일 장치로부터 결제 알림을 받습니다. 결제 알림은 추가 처리를 위해 전송되기 전에 기본 검증이 필요합니다. 백엔드 처리 애플리케이션은 오랫동안 실행되며 조정하려면 컴퓨팅 및 메모리가 필요합니다. 회사는 그렇지 않습니다. 인프라를 관리하고 싶습니다. 어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족합니까?

A. Amazon Simple Queue Service(Amazon SQS) 대기열 생성 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림 수신 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 전송하도록 규칙 구성 백엔드 배포 Amazon Elastic Kubernetes Service(Amazon EKS)의 애플리케이션 독립 실행형 클러스터 생성

B. Amazon API Gateway API 생성 API를 AWS Step Functions 상태 시스템과 통합하여 모바일 장치로부터 결제 알림 수신 상태 시스템을 호출하여 결제 알림을 검증하고 알림을 백엔드 애플리케이션에 보냅니다. Amazon에 백엔드 애플리케이션 배포 탄력적 Kubernetes Service(Amazon EKS). 자체 관리형 노드로 EKS 클러스터를 구성합니다.

C. Amazon API Gateway API 생성 API를 AWS Lambda와 통합하여 모바일 장치에서 결제 알림 수신 Lambda 함수를 호출하여 결제 알림을 검증하고 알림을 백엔드 애플리케이션에 보냅니다. Amazon Elastic Container Service에 백엔드 애플리케이션 배포 (아마존 ECS). AWS Fargate 시작 유형으로 Amazon ECS를 구성합니다.

D. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 대기열을 Amazon EventBridge 규칙과 통합하여 모바일 장치에서 결제 알림을 받습니다. 결제 알림을 검증하고 백엔드 애플리케이션에 알림을 보내도록 규칙을 구성합니다. Amazon EC2 스팟 인스턴스의 백엔드 애플리케이션 기본 할당 전략으로 스팟 집합을 구성합니다.

[요구사항 분석]

1. 결제 알림 수신: 모바일 장치로부터 결제 알림을 받아야 합니다.
2. 기본 검증 필요: 결제 알림을 추가 처리하기 전에 기본 검증이 필요합니다.
3. 오랫동안 실행되는 백엔드 처리 애플리케이션: 백엔드 애플리케이션은 지속적으로 실행되어야 합니다.
4. 컴퓨팅 및 메모리 조정 필요: 백엔드 애플리케이션은 조정 가능한 컴퓨팅 및 메모리가 필요합니다.
5. 인프라 관리 최소화: 인프라 관리에 대한 오버헤드를 최소화해야 합니다.

[각 보기 분석]

A

1. 내용 검증
1) SQS와 EventBridge를 사용하여 결제 알림을 수신하고 처리하는 방식으로 안정적인 메시징을 제공할 수 있습니다.
2) EKS를 사용하여 백엔드 애플리케이션을 배포하는 것은 가능하나, 관리 오버헤드가 크다는 점에서 문제가 있습니다.

2. 요청 사항 처리 가능성

• 결제 알림 수신, 검증, 백엔드 처리 모두 가능하나, 운영 오버헤드가 크기 때문에 요구 사항을 완전히 충족하지 못할 수 있습니다.

3. 특정 옵션: EKS는 관리형 Kubernetes 서비스입니다.
4. 가능성: 가능하지만 관리해야 할 인프라가 많아 운영 오버헤드가 증가합니다.

B

1. 내용 검증
1) API Gateway와 AWS Step Functions를 통해 결제 알림을 수신하고 검증하는 방식은 적합합니다.
2) 하지만, EKS의 자체 관리형 노드를 사용하는 만큼 추가 관리 작업과 오버헤드가 필요합니다.

2. 요청 사항 처리 가능성

• 결제 알림 수신 및 검증은 가능하나, EKS의 관리 오버헤드가 클 수 있어 요구 사항을 충분히 충족하지 못할 가능성이 있습니다.

3. 특정 옵션: EKS는 관리형 Kubernetes 서비스입니다.
4. 가능성: 가능하지만, 관리 오버헤드가 증가하여 운영의 복잡성이 높아질 수 있습니다.

C

1. 내용 검증
1) API Gateway와 AWS Lambda를 사용하여 결제 알림을 처리하고, AWS Fargate를 통해 ECS에서 백엔드 애플리케이션을 실행하는 것은 적합한 솔루션입니다.
2) 서버리스 아키텍처를 통해 관리 오버헤드를 최소화할 수 있습니다.

2. 요청 사항 처리 가능성

• 결제 알림 수신, 검증, 백엔드 처리 모두 가능하며, 운영 오버헤드가 낮기 때문에 요구 사항을 잘 충족합니다.

3. 특정 옵션: AWS Fargate는 서버리스 컨테이너 관리 서비스입니다.
4. 가능성: 가능하며, 서버를 따로 관리할 필요가 없어 운영 부담이 적습니다.

D

1. 내용 검증
1) SQS와 EventBridge를 사용하여 결제 알림을 수신하고 처리하는 것은 가능하나, EC2 스팟 인스턴스를 사용하는 것은 가용성 문제를 일으킬 수 있습니다.
2) 스팟 인스턴스의 중단 가능성 때문에 운영의 안정성이 저하될 수 있습니다.

2. 요청 사항 처리 가능성

1) 결제 알림 수신 및 검증은 가능하나, 스팟 인스턴스의 특성으로 인해 운영의 안정성이 떨어질 수 있습니다.

3. 특정 옵션: EC2 스팟 인스턴스는 AWS의 저렴한 가격으로 인스턴스를 사용할 수 있는 옵션입니다.
4. 가능성: 가능하지만, 자원이 예기치 않게 중단될 수 있어 가용성에 문제가 발생할 수 있습니다.

[결론]

1) A는 요구 사항을 충족하지만, 운영 오버헤드가 크므로 비추천합니다.
2) B는 복잡성이 크고 관리 오버헤드가 높아 비추천합니다.
3) C는 요구 사항을 잘 충족하고, 관리 오버헤드를 최소화할 수 있는 최적의 선택입니다.
4) D는 처리 가능하지만, 스팟 인스턴스의 불안정성으로 인한 가용성 문제로 인해 비추천합니다.

결론적으로, C가 가장 적합하며 요구 사항을 가장 잘 충족하는 솔루션입니다.

[관련 AWS 서비스 설명 및 옵션]

1. Amazon API Gateway

• AWS에서 API를 생성, 배포 및 관리할 수 있는 서비스로, RESTful API 및 WebSocket API를 지원합니다.
• 서버리스 아키텍처에서 Lambda와 통합해 요청을 처리할 수 있습니다.

2. AWS Lambda

1) 서버를 관리하지 않고 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다.
2) 이벤트 기반으로 코드를 실행하며, 필요할 때만 실행되므로 비용 효율적입니다.

3. Amazon Elastic Container Service (ECS)

1) 컨테이너화된 애플리케이션을 실행, 관리할 수 있는 서비스입니다.
2) AWS Fargate를 사용하여 서버를 관리하지 않고 컨테이너를 실행할 수 있습니다.

4. Amazon Simple Queue Service (SQS)

1) 비동기 메시징 서비스를 제공하여 애플리케이션 간의 메시지 전송을 안정적으로 처리할 수 있습니다.
2) 메시지를 대기열에 저장하고 소비자 애플리케이션이 해당 메시지를 처리하도록 합니다.

5. AWS Step Functions:

• AWS Step Functions는 서버리스 방식으로 애플리케이션의 여러 컴포넌트를 조정하고, 상태 머신을 정의하여 비즈니스 로직을 구성할 수 있도록 해주는 서비스입니다. 이를 통해 복잡한 워크플로를 구성하고 관리할 수 있습니다.

6. Amazon Elastic Kubernetes Service (Amazon EKS):

• Amazon EKS는 AWS에서 Kubernetes를 손쉽게 실행할 수 있도록 관리형 Kubernetes 서비스입니다. 그러나 자체 관리형 노드를 구성해야 하므로 관리 오버헤드가 증가할 수 있습니다.

7. Amazon Elastic Container Service (Amazon ECS):

• Amazon ECS는 컨테이너화된 애플리케이션을 쉽게 실행하고 관리할 수 있는 서비스입니다. Docker 컨테이너를 관리하고 실행하는 데 사용됩니다.

8. AWS Fargate:

• AWS Fargate는 Amazon ECS 및 Amazon EKS와 통합하여 서버리스 컴퓨팅을 제공하는 서비스입니다. 사용자는 서버를 프로비저닝하거나 관리할 필요 없이 컨테이너를 실행할 수 있습니다.

스팟 인스턴스 (Spot Instances)

정의:

스팟 인스턴스는 Amazon EC2의 가격 모델 중 하나로, 사용자가 저렴한 가격에 AWS의 여유 용량을 활용하여 인스턴스를 사용할 수 있는 옵션입니다. 스팟 인스턴스는 일반적으로 온디맨드 인스턴스보다 가격이 저렴하지만, AWS가 용량이 필요할 경우 언제든지 인스턴스를 종료할 수 있는 특징이 있습니다.

주요 특징:

1. 가격: 스팟 인스턴스는 EC2의 기본 가격보다 최대 90%까지 저렴하게 제공됩니다.
2. 유연성: 사용자는 스팟 인스턴스를 요청할 때 최대 지불 가격을 설정할 수 있으며, 시장 가격이 이 가격 아래일 때 인스턴스를 사용할 수 있습니다.
3. 중단 가능성: AWS가 용량이 필요할 경우 인스턴스가 중단될 수 있으며, 이 경우 사전 경고가 제공됩니다.

유용한 사용 사례:

1. 배치 처리 작업
2. 데이터 분석
3. 테스트 및 개발 환경
4. 고성능 컴퓨팅(HPC) 워크로드

비슷한 다른 옵션 및 종류

1. 온디맨드 인스턴스 (On-Demand Instances)

1) 정의: 필요할 때마다 인스턴스를 시작하고 종료할 수 있으며, 사용한 시간만큼 요금을 지불합니다.
2) 장점: 유연성과 예측 가능성이 높으며, 인스턴스가 언제든지 실행될 수 있습니다.
3) 단점: 가격이 가장 비쌉니다.

2. 예약 인스턴스 (Reserved Instances)

1) 정의: 특정 인스턴스를 최소 1년 또는 3년 동안 예약하여 사용하는 모델입니다.
2) 장점: 장기 계약을 통해 비용을 절감할 수 있으며, 특정 인스턴스 유형을 보장받을 수 있습니다.
3) 단점: 유연성이 낮고, 계약 기간 중 사용하지 않으면 비용 손실이 발생할 수 있습니다.

3. 저비용 인스턴스 (Savings Plans)

1) 정의: 사용자가 특정 시간 동안 인스턴스를 사용할 것을 약속하고 할인된 요금을 받을 수 있는 프로그램입니다.
2) 장점: 특정 인스턴스 유형이나 운영 체제에 구애받지 않으므로 더 많은 유연성을 제공합니다.
3) 단점: 계약 기간 동안 최소 사용량을 충족해야 하므로 유연성이 다소 낮습니다.

4. 전용 호스트 (Dedicated Hosts)

1) 정의: 특정 물리적 서버를 고객에게 할당하여 다양한 EC2 인스턴스를 실행할 수 있게 해주는 모델입니다.
2) 장점: 소프트웨어 라이선스 요구 사항이나 규정 준수를 충족할 수 있습니다.
3) 단점: 비용이 매우 높으며, 일반적인 인스턴스보다 유연성이 떨어집니다.