Amazon DVA-C02: 메시징, 스트리밍 및 이벤트 기반 아키텍처 (SNS, SQS, Kinesis, EventBridge, Step Functions) — 학습 가이드

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Developer Associate DVA-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

올바른 메시징 및 스트리밍 기본 요소 선택하기

SNS, SQS(표준 vs FIFO), Kinesis, EventBridge, Step Functions 중에서 선택하는 것은 통신 패턴, 즉 pub/sub, point-to-point, 순서가 있는 스트리밍, 이벤트 버스 라우팅, 워크플로 오케스트레이션 중 무엇인지 파악하는 것에서 시작합니다. SNS는 팬아웃(fan-out) pub/sub 게시자입니다. Publish(SDK 호출: Publish/PublishBatch)를 사용하고 SQS 엔드포인트, Lambda, HTTP/S 또는 모바일 엔드포인트를 구독합니다. SQS는 ReceiveMessage/DeleteMessage 시맨틱을 사용하는 내구성 있는 point-to-point 버퍼입니다. CreateQueue로 대기열을 생성하고 VisibilityTimeout, ReceiveMessageWaitTimeSeconds(롱 폴링), MessageRetentionPeriod 같은 속성과 DLQ를 연결하는 재전송 정책(redrive policy)을 설정합니다. FIFO 대기열은 FifoQueue=true 설정이 필요하며, 순서 보장과 중복 제거를 위해 MessageGroupId와 MessageDeduplicationId(또는 ContentBasedDeduplication)를 사용합니다. Kinesis Data Streams는 순서가 보장되는 샤드 기반 스트리밍입니다. 생산자는 PutRecord/PutRecords를 호출하고, 소비자는 GetShardIterator(TRIM_HORIZON, LATEST, AT_SEQUENCE_NUMBER)를 사용한 다음 GetRecords를 호출합니다. Kinesis Firehose는 S3/Redshift/OpenSearch로의 전송을 관리하며, BufferingHints(SizeInMBs, IntervalInSeconds)와 Lambda 변환 기능을 제공합니다. EventBridge는 PutEvents와 규칙 기반 필터링으로 이벤트를 라우팅하며, 스키마 레지스트리 및 계정 간 버스를 지원합니다. Step Functions는 복잡한 흐름을 오케스트레이션합니다. 표준(Standard) 워크플로의 경우 StartExecution을, 동기식 Express 패턴의 경우 StartSyncExecution을 사용하며, arn:aws:states:::lambda:invoke와 같은 Task 통합을 지원합니다. 처리량, 순서 보장, 전송 보장, 보존 기간, 오케스트레이션 요구사항이 서로 상충될 때 이러한 장단점을 고려해야 합니다.

• SNS: 높은 처리량의 팬아웃, 순서 보장 안 됨, Publish/Subscribe, 라우팅에 MessageAttributes 사용.
• SQS Standard: 최소 한 번 전송(at-least-once), 최선 노력 순서 보장(best-effort ordering), 롱 폴링, 디커플링에 더 저렴함.
• SQS FIFO: MessageGroupId 내에서 정확히 한 번(exactly-once) 순서 보장, 엄격한 순서 보장 및 중복 제거에 사용.
• Kinesis Data Streams: 샤드별 순서 보장, 높은 처리량의 스트리밍, PutRecord/PutRecords, 샤드 스케일링 필요.
• Kinesis Firehose: 관리형 전송 및 버퍼링, 서버 측 암호화 및 Lambda 변환 지원.
• EventBridge: 라우팅 규칙이 있는 이벤트 버스, 스키마 레지스트리, 아카이브 및 재실행(replay), PutEvents API.
• Step Functions: 상태 저장 오케스트레이션, 재시도/Catch, 내구성과 처리량에 대한 표준(Standard)과 Express 워크플로 간의 장단점.

SQS 및 SNS 패턴, 중복 제거, 소비자 확장

내구성 있는 디커플링이 필요할 때 SQS는 최고의 선택입니다. 생산자는 SendMessage/SendMessageBatch를 구현하고, 소비자는 WaitTimeSeconds와 함께 ReceiveMessage를 사용하여 롱 폴링을 활성화하고 빈 수신(empty receive)을 줄입니다. 엄격한 순서 보장과 중복 제거를 위해서는 CreateQueue(FifoQueue=true)로 FIFO 대기열을 생성하고, 순서가 지정된 파티션을 위해 MessageGroupId를 설정합니다. MessageDeduplicationId를 사용하거나 ContentBasedDeduplication을 활성화하여 중복 제거 기간 내의 동일한 페이로드가 억제되도록 합니다. 표준 대기열은 메시지를 중복 전송할 수 있으므로, 데이터베이스 조건부 쓰기(예: ConditionExpression attribute_not_exists(pk)를 사용한 DynamoDB PutItem)나 트랜잭션 내에서 RDS 고유 제약 조건 및 upsert를 통해 소비자를 멱등성(idempotent) 있게 만들어야 합니다. maxReceiveCount 이후에 실패한 메시지를 DLQ로 라우팅하도록 재전송 정책(redrive policy)을 구성하고, GetQueueAttributes를 통해 ApproximateNumberOfMessages와 ApproximateNumberOfMessagesNotVisible를 모니터링합니다. Lambda 통합은 SQS에 대해 CreateEventSourceMapping을 사용합니다. BatchSize, MaximumBatchingWindowInSeconds를 설정하고, FunctionResponseTypes = [“ReportBatchItemFailures”]를 활성화하여 부분 배치 응답(partial-batch-response) 시맨틱을 사용하고 성공한 레코드의 재처리를 방지합니다. FIFO Lambda 시맨틱에 주의해야 합니다. 메시지 그룹 순서 보장은 MessageGroupId별로 단일 스레드 처리를 강제하여 그룹별 동시성을 제한합니다. 많은 그룹 ID로 파티셔닝하거나 SNS를 사용하여 여러 대기열에 병렬 소비자를 연결하여 확장할 수 있습니다. 또한 처리 시간이 길어지거나 중복 처리의 위험이 있는 경우, ChangeMessageVisibility를 설정하여 가시성 제한 시간(visibility timeout)을 조정해야 합니다.

Kinesis Data Streams 및 Firehose: 순서 보장, 보존, 역압(back-pressure) 처리

Kinesis Data Streams는 스트리밍 사용 사례를 위해 샤드별 순서 보장과 내구성 있는 보존 기능을 제공합니다. 생산자는 샤드에 매핑되는 PartitionKey와 함께 PutRecord 또는 PutRecords(배치)를 호출합니다. 소비자는 GetShardIterator와 GetRecords를 호출한 다음, KCL(Kinesis Client Library)이나 사용자 지정 DynamoDB 체크포인트 테이블을 사용하여 오프셋을 체크포인트합니다. 기본 보존 기간은 24시간이며(스트림 구성에 따라 더 긴 기간으로 조정 가능하고, 사용 가능한 경우 확장 보존 기능도 있음), 쓰기 처리량과 리더 병렬성에 맞게 UpdateShardCount로 샤드 수를 계획해야 합니다. 소비자 확장은 제약이 있습니다. 단일 Lambda 이벤트 소스 매핑은 하나의 샤드를 하나의 Lambda 동시성에 매핑하므로, 소비자 동시성을 높이려면 샤드를 늘리거나, 향상된 팬아웃(enhanced fan-out)을 활성화하여 각 소비자에게 자체 2MB/초 파이프를 제공하고 SubscribeToShard API(소비자 등록)를 사용하여 독립적으로 확장해야 합니다. 효율적인 배치를 위해 PutRecords를 사용하세요. 소비자가 지연되면 역압(back-pressure)이 발생합니다(GetRecords.IteratorAgeMilliseconds를 모니터링). 급증(spike)을 처리하려면 Kinesis에서 버퍼링하거나 앞에 SQS를 두거나, 지수 백오프(exponential backoff)를 사용한 생산자 재시도를 사용하고, PII(개인 식별 정보)를 위해 KMS로 스트림 수준 암호화를 사용하세요. Kinesis Data Firehose는 전송을 단순화합니다. BufferingHints(SizeInMBs, IntervalInSeconds), CompressionFormat, Lambda 데이터 변환을 구성하세요. Firehose는 대상으로의 재시도/백오프를 처리하며 실패한 레코드를 백업 S3 버킷에 쓸 수 있습니다. 일반적인 함정은 샤드를 불충분하게 프로비저닝하는 것입니다. 이 경우 소비자는 데이터를 받지 못하고(starve) 지연 시간이 급증합니다. 사전에 측정하고 확장해야 합니다.

라우팅 및 오케스트레이션을 위한 EventBridge와 Step Functions

EventBridge는 스키마 기반 이벤트 라우팅과 계정 간/이벤트 파트너 통합에 탁월합니다. PutEvents를 사용하여 이벤트를 주입하고 PutRule/PutTargets를 사용하여 SQS, Lambda, Kinesis, Step Functions 또는 HTTP 엔드포인트로 라우팅합니다. EventBridge는 필터링을 위해 이벤트 패턴을 사용하며, 상태 재구축을 위한 아카이빙 및 리플레이를 지원합니다. 규칙에 대한 데드-레터 큐(Target의 SqsParameters 또는 DeadLetterConfig)를 사용하고, EventBridge가 실패 시 지수 백오프를 사용한 재시도 후 DLQ로 보낸다는 점을 인지해야 합니다. 오케스트레이션에는 Step Functions를 선택하세요. 장기 실행 영속성 워크플로우에는 실행 기록과 내장된 재시도/Catch 기능이 있는 Standard 상태 머신을, 높은 처리량의 단기 실행 워크플로우에는 더 낮은 비용과 최선 노력(best-effort) 실행을 제공하는 Express를 사용합니다. 서비스 통합(arn:aws:states:::lambda:invoke 또는 arn:aws:states:::aws-sdk:apigateway:invoke)을 사용한 Task 통합과 “waitForTaskToken"을 사용한 콜백 패턴으로 비동기 외부 승인을 구현합니다. 지수 백오프를 사용한 재시도 및 Catch를 구현하고, 장기 작업에는 HeartbeatSeconds를 사용합니다. 대규모 컬렉션을 병렬 처리하기 위해 Map 상태를 사용하되, 동시성 및 다운스트림 스로틀을 주의 깊게 살펴보세요. 일반적인 함정은 정확히 한 번의 영속성 있는 기록이 필요한 워크플로우에 Express를 잘못 선택하는 것입니다. 감사 가능성을 위해서는 Standard를 선택하세요. 또한, 멱등성 토큰을 전달하고 대상 서비스가 쓰기 시점에 고유성을 강제하도록 하여 Step Functions에 의해 호출되는 작업의 멱등성을 보장해야 합니다.

실제 문제: 사용 사례 시나리오

시나리오: StreamlyGames는 다중 계정 AWS 환경에서 글로벌 게임 백엔드를 운영합니다. 플레이어들이 10MB 크기의 게임플레이 클립을 S3에 업로드하면, 처리 파이프라인이 비디오를 트랜스코딩하고, ML 분석을 실행하며, 그 결과를 순서가 보장되고 중복이 제거된 처리를 통해 Aurora Serverless에 기록해야 합니다. 또한 소비자는 확장 가능해야 합니다.

과제: 각 업로드된 파일이 플레이어별로 순서에 따라 정확히 한 번만 처리되도록 보장하고, 이벤트 손실 없이 스파이크 트래픽을 처리하며, 중복된 DB 쓰기를 방지하면서 ML 추론을 위한 소비자를 확장해야 합니다.

권장 접근 방식:

1. S3 이벤트 알림을 생성하여 객체 생성(object-created) 이벤트를 EventBridge 사용자 지정 버스(PutEvents)와 SQS FIFO 큐(CreateQueue, FifoQueue=true 설정) 양쪽에 게시합니다. SQS FIFO 큐는 PlayerID를 MessageGroupId로 사용하고 S3 ETag 기반의 MessageDeduplicationId를 사용합니다.
2. SQS 이벤트 소스 매핑(CreateEventSourceMapping)을 사용하는 Lambda 소비자를 구성합니다. 이때 BatchSize=1, FunctionResponseTypes=[“ReportBatchItemFailures”]로 설정하고, VisibilityTimeout을 최대 처리 시간보다 길게 설정합니다. 서드파티 ML API를 호출할 때는 ChangeMessageVisibility를 사용합니다.
3. Lambda는 결정론적 멱등성 키(INSERT … ON CONFLICT DO NOTHING 또는 고유 제약 조건)를 사용하여 Aurora에 멱등성 있는 DB 쓰기를 수행하고 진행 상황을 체크포인트합니다. 긴 ML 호출에는 태스크 토큰(arn:aws:states:::lambda:invoke.waitForTaskToken)을 사용하는 비동기 Step Functions를 사용하거나, 높은 처리량을 위해 Step Functions Express를 사용합니다.
4. 추론을 확장하기 위해, 중간 이벤트를 리전별 샤드당 Kinesis Data Streams에 기록하여 높은 처리량의 소비자를 지원하고, 전용 ML 워커 플릿을 위해 향상된 팬아웃 소비자(SubscribeToShard)를 활성화합니다. 확장을 위해 IteratorAgeMilliseconds를 모니터링하고 UpdateShardCount를 사용합니다.

근거: SQS FIFO를 사용하여 플레이어별 순서 보장 및 수집 시 중복 제거를 보장하고, 멱등성 있는 DB 쓰기로 정확히 한 번(exactly-once) 의미론을 강제하며, Kinesis와 향상된 팬아웃 또는 Step Functions를 사용하여 소비자를 분리되고 확장 가능하게 유지하면서 폭발적이고 높은 처리량의 ML 처리를 처리합니다.

← 데이터베이스 및 캐싱 (RDS · 모든 도메인

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →