[SAA-C03] AWS 메시지 관리 정리 & 기출문제

AWS/SAA-C03

[SAA-C03] AWS 메시지 관리 정리 & 기출문제

얼복무 2024. 11. 12. 20:42

Amazon Simple Queue Service (SQS)

완전 관리형 메시지 대기열 서비스로, 애플리케이션 간에 메시지를 안전하게 전송하고 수신할 수 있도록 해줍니다.

SQS는 비동기 메시징을 통해 애플리케이션의 구성 요소 간에 데이터 전달을 처리하고, 메시지가 순차적으로 또는 병렬로 처리되도록 할 수 있습니다.

이를 통해 분산 시스템 간의 느슨한 결합(loose coupling)을 구현할 수 있으며, 확장성과 가용성을 제공하는 데 중요한 역할을 합니다.

SQS의 주요 기능

Queue (대기열): 메시지를 저장하는 공간입니다. SQS에는 두 가지 유형의 대기열이 있습니다.
- Standard Queue: 최대 처리량을 지원하며, 메시지 순서가 보장되지 않으며, 중복이 있을 수 있습니다.
- FIFO Queue: 메시지의 순서 보장 및 중복 제거를 제공합니다. 단, 처리량이 표준 대기열보다 낮습니다.
Message (메시지): SQS 대기열에 전송되는 데이터 단위입니다. 각 메시지는 최대 256KB의 데이터를 포함할 수 있습니다.
Visibility Timeout (가시성 타임아웃): 메시지가 소비된 후 다른 소비자가 같은 메시지를 처리하지 않도록 하기 위한 시간입니다. 소비자가 메시지를 처리하는 동안 다른 소비자가 동일한 메시지를 받지 않도록 보호합니다.
Dead Letter Queue (DLQ): 메시지를 처리할 수 없는 경우, 특정 조건을 만족하는 메시지를 별도의 대기열로 이동시킬 수 있는 기능입니다. 실패한 메시지를 추적하고 분석하는 데 유용합니다.
Message Retention: SQS에서는 메시지를 대기열에 최대 14일까지 보관할 수 있습니다. 기본값은 4일이며, 최대 14일까지 확장 가능합니다.

SQS의 특징

확장성: 대기열의 메시지 수와 처리 능력에 따라 자동으로 확장됩니다. SQS는 분산 시스템에서 높은 성능을 발휘합니다.
가용성: SQS는 고가용성으로 설계되어 있으며, 여러 AWS 리전에서 사용 가능합니다.
내구성: SQS는 메시지를 여러 가용 영역(AZ)에서 복제하여 내구성을 제공합니다.
비동기 처리: 메시지는 비동기적으로 처리되어 시스템의 효율성을 높이고, 애플리케이션이 메시지를 전송한 후에도 계속해서 다른 작업을 수행할 수 있습니다.

SQS 사용 사례

비동기 작업 처리: 긴 시간 동안 실행되는 작업을 큐에 넣어 비동기적으로 처리할 수 있습니다.
애플리케이션 간 통신: 서로 다른 시스템 또는 서비스 간에 데이터를 전송하고 처리할 수 있습니다.
서버리스 아키텍처: AWS Lambda와 결합하여 이벤트 기반으로 메시지를 처리할 수 있습니다.

Amazon Kinesis Data Streams

실시간 스트리밍 데이터 처리 서비스입니다. 데이터를 스트리밍하여 여러 소비자들이 실시간으로 데이터를 읽고 처리할 수 있도록 지원합니다.

주요 기능

실시간 데이터 스트리밍: 대규모 데이터 스트림을 실시간으로 수집하고 처리할 수 있습니다.
샤드(Shards): 스트리밍 데이터를 샤드 단위로 나누어 분산 처리할 수 있습니다. 각 샤드는 최대 1MB의 데이터 수신과 2MB의 데이터 전송을 처리합니다.
데이터 보존: Kinesis는 데이터를 최대 7일 동안 보존할 수 있습니다. 데이터를 스트리밍하며, 데이터를 여러 소비자가 동시에 처리할 수 있습니다.
Lambda 통합: 스트림에서 데이터를 받아 Lambda 함수로 처리할 수 있습니다.

사용 사례

실시간 로그 분석: 로그 데이터를 실시간으로 스트리밍하여 분석하거나 경고를 발생시키는 시스템.
(예: 애플리케이션 로그 수집 및 실시간 모니터링, 웹사이트 방문자 분석)
IoT 데이터 처리: IoT 디바이스에서 발생한 실시간 데이터를 처리하고 분석할 수 있습니다.
(예: 센서 데이터 수집 및 실시간 분석)
실시간 분석 시스템: 실시간 대시보드에서 데이터를 모니터링하거나, 실시간 이벤트 기반 시스템을 구축할 수 있습니다.
(예: 금융 거래 분석, 실시간 주문 처리 시스템)

SQS와 Kinesis 주요 차이점

목적 및 사용 사례

- SQS: 주로 비동기적인 메시지 전달 및 큐 관리가 필요한 경우에 사용됩니다. 예를 들어, 메시지 큐를 사용하여 작업을 순차적으로 처리하거나, 비즈니스 프로세스에서 느슨한 결합(loose coupling)을 구현할 때 유용합니다.

사용 사례: 애플리케이션 간 메시징, 비동기 작업 처리, 이벤트 기반 아키텍처.

- Kinesis: 실시간 데이터 스트리밍 및 이벤트 처리가 필요한 경우에 사용됩니다. Kinesis는 대규모 실시간 데이터를 빠르게 수집하고 처리할 수 있도록 설계되었습니다.

사용 사례: 로그 스트리밍, IoT 데이터 처리, 실시간 데이터 분석, 실시간 모니터링.

데이터 처리 방식
- SQS는 기본적으로 메시지 단위로 데이터를 처리합니다. 메시지가 큐에 들어가면, 하나의 소비자 또는 여러 소비자가 이를 순차적으로 처리할 수 있습니다. 메시지의 순서를 보장하려면 FIFO 대기열을 사용해야 합니다.

메시지 처리: 메시지는 소비자가 받기 전까지 큐에 저장되며, 가시성 타임아웃(Visibility Timeout)으로 인해 처리 중인 메시지는 다른 소비자가 중복 처리하지 않습니다.
메시지 유실 가능성: 기본적으로 표준 대기열(Standard Queue)에서는 메시지의 중복이 있을 수 있고, 순서가 보장되지 않습니다.

- Kinesis는 스트리밍 데이터를 연속적으로 처리합니다. 데이터를 일정한 시간 간격(샤드 단위)으로 나누어 순차적이고 지속적으로 처리할 수 있습니다. 실시간 스트림 데이터를 여러 소비자가 병렬로 처리할 수 있도록 설계되어 있습니다.

데이터 처리: Kinesis는 데이터를 시간 순으로 분할하여 여러 소비자에게 분배하며, 데이터를 최소 24시간에서 최대 7일 동안 유지할 수 있습니다. 각 스트림은 여러 샤드(shard)로 나누어져 병렬 처리됩니다.

데이터 유지 시간

SQS: 메시지는 최대 14일 동안 대기열에 저장됩니다. 이 기간이 지나면 자동으로 삭제됩니다.
Kinesis: 스트림에 저장된 데이터는 기본적으로 24시간 동안 보관되며, 이를 설정을 통해 최대 7일까지 연장할 수 있습니다. (스트리밍 데이터의 특성상 실시간 처리가 중요하므로 상대적으로 짧은 기간만 저장됩니다.)

데이터 중복 처리

SQS: 표준 대기열에서는 메시지의 중복이 발생할 수 있습니다. FIFO 대기열을 사용할 경우 중복을 제거하고 메시지 순서를 보장할 수 있습니다.
Kinesis: 중복 처리에 대해 특별히 관리하지 않지만, 소비자가 데이터를 처리하는 동안 중복을 처리할 수 있도록 소비자 애플리케이션에서 이를 처리하도록 설계할 수 있습니다. Kinesis 스트림의 소비자는 여러 샤드에서 데이터를 읽으므로 중복된 데이터를 처리할 필요가 있을 수 있습니다.

확장성 및 처리량

SQS는 자동 확장을 제공하며, 메시지 수와 처리량에 맞게 스케일링됩니다. SQS는 수백만 개의 메시지를 효율적으로 처리할 수 있습니다.
Kinesis는 샤드를 사용하여 데이터를 병렬로 처리합니다. 샤드 수를 늘려서 수평 확장이 가능하며, Kinesis의 처리량은 샤드 수에 따라 달라집니다. 각 샤드는 초당 최대 1MB의 입력 및 2MB의 출력을 처리할 수 있습니다.

Amazon SNS (Simple Notification Service)

Amazon SNS는 Pub/Sub (발행/구독) 모델을 따르는 알림 및 메시징 서비스입니다. SNS는 다양한 채널을 통해 메시지를 전달할 수 있으며, 여러 구독자가 동일한 메시지를 받을 수 있도록 지원합니다.

특징

여러 구독자에게 메시지를 동시에 전송할 수 있습니다.
푸시 알림, 이메일, SMS, HTTP/S endpoint 등 다양한 전달 방법을 지원합니다.
이벤트 기반 애플리케이션에서 메시지나 알림을 전송하는 데 유용합니다.
다른 AWS 서비스와 통합이 용이하여 이벤트 기반 아키텍처에서 많이 사용됩니다.

사용 사례

시스템 알림 및 경고 메시지 전송 (예: 장애 알림)
여러 수신자에게 대량 알림 전송 (예: 모바일 푸시 알림, 이메일)
분산 애플리케이션에서 이벤트를 여러 서비스로 전달 (예: Lambda 함수 트리거)
SQS와 함께 사용하여 메시지를 큐에 추가하거나 처리할 수 있습니다.

SNS와 SQS의 차이점

SNS는 메시지를 다수의 구독자에게 동시에 전송할 수 있지만, SQS는 메시지를 단일 소비자가 처리하는 큐 시스템입니다.

Amazon MQ

관리형 메시지 브로커 서비스로, JMS (Java Message Service), AMQP, MQTT, STOMP 등 다양한 프로토콜을 지원하는 브로커를 제공합니다. Amazon MQ는 Apache ActiveMQ와 RabbitMQ와 같은 오픈 소스 브로커를 관리형 서비스로 제공합니다.

특징

다양한 메시징 프로토콜을 지원하여 기존 애플리케이션과의 통합이 용이합니다.
메시지를 순차적으로 처리하며, 메시지 브로커를 사용하여 비동기적 통신을 관리합니다.
고가용성 및 내구성을 제공하며, 클러스터링 및 메시지 복제를 통해 신뢰성을 보장합니다.

사용 사례

애플리케이션 간의 메시지 통신을 위한 큐 기반 메시징 시스템 (예: 시스템 간 데이터 전달)
기존의 메시지 브로커를 AWS로 마이그레이션 (예: ActiveMQ, RabbitMQ)
트랜잭션 메시징 및 보장된 메시지 처리가 필요한 시스템

메시지 관리 서비스 선택

SNS: 알림 및 이벤트 기반 메시징 시스템에 적합. 다양한 구독자에게 메시지를 전달할 때 유용합니다.
SQS: 비동기 메시징 및 큐 기반 시스템에서 사용. 처리 순서 보장 및 대기열을 사용하여 느슨하게 결합된 시스템에서 사용됩니다.
Kinesis: 실시간 데이터 스트리밍 및 고속 데이터 처리에 적합. 대규모 데이터 스트림을 처리할 때 유리합니다.
Amazon MQ: 기존의 메시지 브로커 시스템을 클라우드로 마이그레이션하거나 JMS, AMQP 등의 프로토콜을 사용하는 시스템에서 사용됩니다.

기출문제

한 회사가 분산 애플리케이션을 AWS로 마이그레이션하고 있습니다. 이 애플리케이션은 가변적인 워크로드를 처리합니다. 레거시 플랫폼은 여러 컴퓨팅 노드에서 작업을 조정하는 기본 서버로 구성됩니다. 이 회사는 복원성과 확장성을 극대화하는 솔루션으로 애플리케이션을 현대화하려고 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떻게 아키텍처를 설계해야 할까요?

A. Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 예약된 스케일링을 사용하도록 EC2 Auto Scaling을 구성합니다.
B. Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 대기열의 크기에 따라 EC2 Auto Scaling을 구성합니다.
C. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨팅 노드를 구현합니다. 작업의 대상으로 AWS CloudTrail을 구성합니다. 기본 서버의 부하에 따라 EC2 Auto Scaling을 구성합니다.
D. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨트 노드를 구현합니다. 작업의 대상으로 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. 컴퓨트 노드의 부하에 따라 EC2 Auto Scaling을 구성합니다.

정답: B

A: 가변적인 요청에 예약된 스케일링은 사용하기 어려움
C: CloudTail은 감사 목적으로 계정의 로깅으로 활용. 용도가 다름.
D: EventBridge는 상황에 맞지 않는다.

41. 회사의 애플리케이션은 데이터 수집을 위해 여러 소프트웨어 즉 서비스(SaaS) 소스와 통합됩니다. 회사는 Amazon EC2 인스턴스를 실행하여 데이터를 수신하고 분석을 위해 Amazon S3 버킷에 데이터를 업로드합니다. 데이터를 수신하고 업로드하는 동일한 EC2 인스턴스는 업로드가 완료되면 사용자에게 알림을 보냅니다. 회사는 애플리케이션 성능이 느린 것을 알아차리고 가능한 한 성능을 개선하고자 합니다.
어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. EC2 인스턴스가 확장될 수 있도록 자동 확장 그룹을 만듭니다. S3 버킷에 업로드가 완료되면 Amazon Simple Notification Service(Amazon SNS) 토픽에 이벤트를 보내도록 S3 이벤트 알림을 구성합니다.
B. 각 SaaS 소스와 S3 버킷 간에 데이터를 전송하기 위한 Amazon AppFlow 흐름을 만듭니다. S3 버킷에 대한 업로드가 완료되면 Amazon Simple Notification Service(Amazon SNS) 토픽에 이벤트를 보내도록 S3 이벤트 알림을 구성합니다.
C. 각 SaaS 소스에 대해 출력 데이터를 전송하기 위한 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 만듭니다. S3 버킷을 규칙의 대상으로 구성합니다. S3 버킷에 대한 업로드가 완료되면 이벤트를 전송하기 위한 두 번째 EventBridge(Cloud Watch Events) 규칙을 만듭니다. 두 번째 규칙의 대상으로 Amazon Simple Notification Service(Amazon SNS) 토픽을 구성합니다.
D. EC2 인스턴스 대신 사용할 Docker 컨테이너를 만듭니다. 컨테이너화된 애플리케이션을 Amazon Elastic Container Service(Amazon ECS)에 호스팅합니다. S3 버킷에 업로드가 완료되면 Amazon Simple Notification Service(Amazon SNS) 토픽에 이벤트를 보내도록 Amazon CloudWatch Container Insights를 구성합니다.

정답: B

A: S3 버킷 알림으로 SNS와 연동 가능하지만 EC2 오토스케일링이 가능한지 불확실함. 그리고 이벤트 처리 기반 서비스에 비해 느리고 효율적이지 않음.
B: Amazon AppFlow는 데이터를 안전하게 전송할 수 있는 완전관리형 통합 서비스. SaaS에서 바로 S3으로 데이터를 전송할 수 있다.
C: 두 번의 이벤트브리지가 필요하며 B보다 복잡도가 증가함.
D: CloudWatch 자체가 알림을 보내는 서비스로 SNS와 연동 여부는 알 수 없음.

45. 한 회사에는 다음으로 구성된 데이터 수집 워크플로가 있습니다.
• 새 데이터 전송에 대한 알림을 위한 Amazon Simple Notification Service(Amazon SNS) 주제
• 데이터를 처리하고 메타데이터를 기록하는 AWS Lambda 함수
이 회사는 네트워크 연결 문제로 인해 수집 워크플로가 가끔 실패하는 것을 관찰합니다. 이러한 실패가 발생하면 회사에서 수동으로 작업을 다시 실행하지 않는 한 Lambda 함수는 해당 데이터를 수집하지 않습니다.
솔루션 아키텍트는 Lambda 함수가 앞으로 모든 데이터를 수집하도록 하기 위해 어떤 작업 조합을 취해야 합니까? (두 가지를 선택하세요.)

A. 여러 가용성 영역에 Lambda 함수를 배포합니다.
B. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성하고 이를 SNS 주제에 구독합니다.
C. Lambda 함수에 할당된 CPU와 메모리를 늘립니다.
D. Lambda 함수에 대한 프로비저닝된 처리량을 늘립니다.
E. Amazon Simple Queue Service(Amazon SQS) 대기열에서 읽도록 Lambda 함수를 수정합니다.

정답: B, E

A: 가용성 영역과는 관련 없음.
B: SQS에는 실패한 메시지를 큐에 담아둘 수 있어 이를 통해 람다를 재시작 시킬 수 있다.
C: 성능이 좋아져도 네트워크 연결 실패할 수 있음.
D: 처리량의 문제 아님.
E: SQS를 사용해서 메시지를 관리하고 람다를 호출해야 된다.

51. 한 회사가 REST API에서 검색할 수 있는 주문 배송 통계를 제공하는 애플리케이션을 개발하고 있습니다. 이 회사는 배송 통계를 추출하고, 데이터를 읽기 쉬운 HTML 형식으로 구성하고, 매일 아침 여러 이메일 주소로 동시에 보고서를 보내려고 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 취해야 합니까? (두 가지를 선택하세요.)

A. Amazon Kinesis Data Firehose로 데이터를 전송하도록 애플리케이션을 구성합니다.
B. Amazon Simple Email Service(Amazon SES)를 사용하여 데이터를 형식화하고 이메일로 보고서를 보냅니다.
C. AWS Glue 작업을 호출하여 애플리케이션의 API에 데이터를 쿼리하는 Amazon EventBridge(Amazon CloudWatch Events) 예약 이벤트를 생성합니다.
D. AWS Lambda 함수를 호출하여 애플리케이션의 API에 데이터를 쿼리하는 Amazon EventBridge(Amazon CloudWatch Events) 예약 이벤트를 생성합니다.
E. Amazon S3에 애플리케이션 데이터를 저장합니다. Amazon Simple Notification Service(Amazon SNS) 토픽을 S3 이벤트 대상으로 생성하여 이메일로 보고서를 보냅니다.

정답: B, D

A: Kinesis는 실시간 메시지 전송에 적합.
B: SES는 Email이란 단어를 포함하고 있는 것처럼 이메일 서식을 지정해서 보낼 수 있다.
C: AWS Glue는 사용자가 주로 검색을 하거나 데이터 정체에 사용한다.
D: 이벤트브리지를 통해 맹리 아침 람다를 호출하도록 예약 이벤트를 생성할 수 있다.
E: S3 이벤트 대상이면 매일 아침이 아니라 데이터가 추가될 때마다 발송

75. 한 회사가 온프레미스에서 AWS 클라우드로 다중 계층 애플리케이션을 이전하여 애플리케이션의 성능을 개선하고자 합니다. 애플리케이션은 RESTful 서비스를 통해 서로 통신하는 애플리케이션 계층으로 구성되어 있습니다. 한 계층이 과부하되면 트랜잭션이 삭제됩니다. 솔루션 아키텍트는 이러한 문제를 해결하고 애플리케이션을 현대화하는 솔루션을 설계해야 합니다.
이러한 요구 사항을 충족하고 가장 운영 효율적인 솔루션은 무엇입니까?

A. Amazon API Gateway를 사용하고 AWS Lambda 함수에 대한 직접 거래를 애플리케이션 계층으로 사용합니다. Amazon Simple Queue Service(Amazon SQS)를 애플리케이션 서비스 간의 통신 계층으로 사용합니다.
B. Amazon CloudWatch 메트릭을 사용하여 애플리케이션 성능 기록을 분석하여 성능 실패 중 서버의 최대 사용률을 확인합니다. 최대 요구 사항을 충족하도록 애플리케이션 서버의 Amazon EC2 인스턴스 크기를 늘립니다.
C. Amazon Simple Notification Service(Amazon SNS)를 사용하여 Auto Scaling 그룹의 Amazon EC2에서 실행되는 애플리케이션 서버 간의 메시징을 처리합니다. Amazon CloudWatch를 사용하여 SNS 대기열 길이를 모니터링하고 필요에 따라 확장 및 축소합니다.
D. Amazon Simple Queue Service(Amazon SQS)를 사용하여 Auto Scaling 그룹에서 Amazon EC2에서 실행되는 애플리케이션 서버 간의 메시징을 처리합니다. Amazon CloudWatch를 사용하여 SQS 대기열 길이를 모니터링하고 통신 오류가 감지되면 확장합니다.

정답: A

A: RESTful = API. 운영이 효율적이라면 서버리스=Lambda 그리고 SQS로 애플리케이션과 상관없이 통신을 분리하고 트랙잭션을 삭제되지 않도록 유지.
B: 매트릭을 추적하여 확장할 수 있지만 삭제된 트랜잭션 문제는 해결되지 않음.
C: 오버헤드 및 SNS는 내구성이 떨어짐.
D: 오류가 감지된 후에 확장하면 늦다.

77. 회사는 애플리케이션을 위한 실시간 데이터 수집 아키텍처를 구성해야 합니다. 회사에는 API, 데이터가 스트리밍될 때 데이터를 변환하는 프로세스, 그리고 데이터를 위한 스토리지 솔루션이 필요합니다.
어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. Amazon Kinesis 데이터 스트림으로 데이터를 전송하는 API를 호스팅하기 위해 Amazon EC2 인스턴스를 배포합니다. Kinesis 데이터 스트림을 데이터 소스로 사용하는 Amazon Kinesis Data Firehose 전송 스트림을 만듭니다. AWS Lambda 함수를 사용하여 데이터를 변환합니다. Kinesis Data Firehose 전송 스트림을 사용하여 데이터를 Amazon S3로 전송합니다.
B. AWS Glue로 데이터를 전송하는 API를 호스팅하기 위해 Amazon EC2 인스턴스를 배포합니다. EC2 인스턴스에서 소스/대상 확인을 중지합니다. AWS Glue를 사용하여 데이터를 변환하고 Amazon S3로 전송합니다.
C. Amazon API Gateway API를 구성하여 Amazon Kinesis 데이터 스트림으로 데이터를 전송합니다. Kinesis 데이터 스트림을 데이터 소스로 사용하는 Amazon Kinesis Data Firehose 전송 스트림을 만듭니다. AWS Lambda 함수를 사용하여 데이터를 변환합니다. Kinesis Data Firehose 전송 스트림을 사용하여 데이터를 Amazon S3로 전송합니다.
D. Amazon API Gateway API를 구성하여 AWS Glue로 데이터를 전송합니다. AWS Lambda 함수를 사용하여 데이터를 변환합니다. AWS Glue를 사용하여 데이터를 Amazon S3로 전송합니다.

정답: C

API Gateway를 사용하면 API를 위해 따로 EC2를 배포할 필요가 없다. 따라서 A와 B는 오답.

AWS Glue는 실시간 데이터 스트림에 적합하지 않음.

94. 어떤 회사에서 사용자가 작은 파일을 Amazon S3에 업로드하는 애플리케이션을 설계하고 있습니다. 사용자가 파일을 업로드한 후, 해당 파일은 데이터를 변환하고 JSON 형식으로 저장하여 나중에 분석하기 위해 한 번의 간단한 처리가 필요합니다.
각 파일은 업로드 후 가능한 한 빨리 처리해야 합니다. 수요는 다양합니다. 어떤 날에는 사용자가 많은 수의 파일을 업로드합니다. 다른 날에는 사용자가 몇 개의 파일을 업로드하거나 전혀 업로드하지 않습니다.
어떤 솔루션이 운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족할까요?

A. Amazon S3에서 텍스트 파일을 읽도록 Amazon EMR을 구성합니다. 처리 스크립트를 실행하여 데이터를 변환합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.
B. Amazon S3를 구성하여 Amazon Simple Queue Service(Amazon SQS) 대기열에 이벤트 알림을 보냅니다. Amazon EC2 인스턴스를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.
C. Amazon S3를 구성하여 Amazon Simple Queue Service(Amazon SQS) 대기열에 이벤트 알림을 보냅니다. AWS Lambda 함수를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.
D. 새 파일이 업로드되면 Amazon Kinesis Data Streams에 이벤트를 보내도록 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. AWS Lambda 함수를 사용하여 스트림에서 이벤트를 소비하고 데이터를 처리합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.

정답: C

A: EMR은 방대한 데이터처리, 빅데이터처리에 적합. 여기선 작은 파일이니 오답.
B: EC2는 Lambda보다 오버헤드가 큼.
C: Lambda는 간단한 처리가 가능하며 SQS는 확장성이 용이하다.
D: Kinesis는 실시간 데이터처리에 적합.

98. 이미지 처리 회사에 사용자가 이미지를 업로드하는 데 사용하는 웹 애플리케이션이 있습니다. 이 애플리케이션은 이미지를 Amazon S3 버킷에 업로드합니다. 이 회사는 S3 이벤트 알림을 설정하여 객체 생성 이벤트를 Amazon Simple Queue Service(Amazon SQS) 표준 대기열에 게시합니다. SQS 대기열은 이미지를 처리하고 결과를 이메일을 통해 사용자에게 보내는 AWS Lambda 함수의 이벤트 소스 역할을 합니다.
사용자는 업로드된 모든 이미지에 대해 여러 이메일 메시지를 받는다고 보고합니다. 솔루션 아키텍트는 SQS 메시지가 Lambda 함수를 두 번 이상 호출하여 여러 이메일 메시지를 생성한다는 것을 확인합니다.
솔루션 아키텍트는 최소한의 운영 오버헤드로 이 문제를 해결하기 위해 무엇을 해야 할까요?

A. ReceiveMessage 대기 시간을 30초로 늘려 SQS 대기열에서 롱 폴링을 설정합니다.
B. SQS 표준 큐를 SQS FIFO 큐로 변경합니다. 메시지 중복 제거 ID를 사용하여 중복 메시지를 삭제합니다.
C. SQS 대기열의 가시성 시간 초과를 함수 시간 초과와 일괄 처리 창 시간 초과의 합계보다 큰 값으로 늘립니다.
D. 메시지를 읽은 후 처리하기 전에 SQS 대기열에서 각 메시지를 즉시 삭제하도록 Lambda 함수를 수정합니다.

정답: C

중복을 제거하여 중복 메시지를 삭제하는 SQS FIFO가 맞다고 생각했지만...

문제는 동일한 메시지를 여러 번 보내는 것. 즉 대기열의 가시성 타임아웃을 늘려야 한다.

그리고 SQS FIFO는 S3 이벤트 알림을 대상으로 지원하지 않는다.

(https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html)

롱 폴링은 대기열에서 메시지를 가져오는 시간을 말한다.

대기열에 메시지가 아무 것도 없을 경우 폴링 시간이 짧으면 빈 메시지가 반환되며

이걸 효율적으로 관리하기 위해 폴링 시간을 늘려 더 긴 텀으로 가져오게 한다.

111. 한 회사가 최근 메시지 처리 시스템을 AWS로 마이그레이션했습니다. 이 시스템은 Amazon EC2 인스턴스에서 실행되는 ActiveMQ 대기열로 메시지를 수신합니다. 메시지는 Amazon EC2에서 실행되는 소비자 애플리케이션에서 처리합니다. 소비자 애플리케이션은 메시지를 처리하고 Amazon EC2에서 실행되는 MySQL 데이터베이스에 결과를 씁니다. 이 회사는 이 애플리케이션이 운영 복잡성이 낮고 가용성이 높기를 원합니다.
어떤 아키텍처가 가장 높은 가용성을 제공합니까?

A. 다른 가용성 영역에 두 번째 ActiveMQ 서버를 추가합니다. 다른 가용성 영역에 추가 소비자 EC2 인스턴스를 추가합니다. MySQL 데이터베이스를 다른 가용성 영역에 복제합니다.
B. 두 개의 가용성 영역에 걸쳐 구성된 활성/대기 브로커와 함께 Amazon MQ를 사용합니다. 다른 가용성 영역에 추가 소비자 EC2 인스턴스를 추가합니다. MySQL 데이터베이스를 다른 가용성 영역에 복제합니다.
C. 두 개의 가용성 영역에 걸쳐 구성된 활성/대기 브로커와 함께 Amazon MQ를 사용합니다. 다른 가용성 영역에 추가 소비자 EC2 인스턴스를 추가합니다. Multi-AZ가 활성화된 MySQL용 Amazon RDS를 사용합니다.
D. 두 개의 가용성 영역에 걸쳐 구성된 활성/대기 브로커와 함께 Amazon MQ를 사용합니다. 두 개의 가용성 영역에 걸쳐 소비자 EC2 인스턴스에 대한 자동 확장 그룹을 추가합니다. 다중 AZ가 활성화된 MySQL용 Amazon RDS를 사용합니다.

정답: D

Amazon MQ는 오토 스케일링을 지원하기 때문에 운영 복잡성이 낮고 확장이 편리하다.

ActiveMQ를 추가하겠다는 A는 오답. 추가 소비자를 구현하는 B와 C보다는.

EC2의 자동 확장 그룹의 복장성이 낮아 정답은 D이다.

결국 문제는 고가용성이면서 엔지니어가 추가적인 작업을 하지 않아도 되는 자동 확장을 추구한다.

Multi-AZ와 다중 AZ 역시 고가용성이지만 이중화를 해야 되는 Multi-AZ와 비교하면 다중 AZ의 복잡성이 낮다.