[SAP-C02] 퀴즈: 대규모 금융 이벤트 처리를 위한 AWS 메시징 및 통합 아키텍처
작성자: aws | 작성일: 2026년 06월 18일 | 조회: 3 | 좋아요: 0
AWS SAP-C02 | Professional
🏛️ Solutions Architect – Professional
Q. 한 금융 서비스 회사가 초당 수십만 건의 실시간 주식 거래 이벤트를 처리해야 합니다. 이 이벤트 데이터는 다음 요구사항을 충족해야 합니다:
1. **실시간 팬아웃(Fan-out):** 들어오는 모든 이벤트는 여러 다운스트림 마이크로서비스(예: 사기 탐지, 포트폴리오 분석, 알림 서비스)에 즉시 브로드캐스트되어야 합니다. 각 마이크로서비스는 독립적으로 처리하며, 이벤트의 순서는 특정 마이크로서비스 내에서만 중요합니다.
2. **복잡한 상태 기반 워크플로우:** 특정 유형의 거래 이벤트는 승인, 검증, 최종 정산 등 여러 단계를 거치는 복잡한 비즈니스 프로세스를 트리거해야 합니다. 이 워크플로우는 재시도 로직, 시간 초과, 오류 처리, 그리고 필요 시 수동 승인 단계를 포함해야 합니다.
3. **내구성 있는 아카이빙:** 모든 원본 거래 이벤트는 규제 준수를 위해 장기간 안정적으로 저장되어야 합니다.
4. **높은 가용성, 확장성 및 비용 효율성:** 솔루션은 최고 수준의 가용성과 확장성을 제공하며, 운영 오버헤드를 최소화하고 비용을 최적화해야 합니다.
이러한 요구사항을 가장 효율적이고 비용 효과적으로 충족하는 AWS 솔루션은 무엇입니까?
A. Kinesis Data Stream을 사용하여 모든 거래 이벤트를 수집하고, 이벤트를 읽는 AWS Lambda 함수에서 SNS Topic으로 발행하여 여러 마이크로서비스로 팬아웃합니다. 복잡한 상태 기반 워크플로우를 위해 Step Functions 상태 머신을 시작하고, 원본 이벤트 아카이빙을 위해 Kinesis Data Firehose를 구성하여 S3 버킷으로 데이터를 전송합니다.
B. SQS Queue를 사용하여 모든 거래 이벤트를 수집하고 각 다운스트림 마이크로서비스마다 별도의 SQS Queue를 생성하여 이벤트를 복제합니다. 복잡한 상태 기반 워크플로우를 위해 EC2 인스턴스에서 실행되는 커스텀 애플리케이션을 배포하고, 원본 이벤트 아카이빙을 위해 SQS 메시지를 S3로 직접 기록하는 Lambda 함수를 사용합니다.
C. Amazon EventBridge를 사용하여 모든 거래 이벤트를 수집하고 규칙을 통해 여러 마이크로서비스로 이벤트를 라우팅합니다. 복잡한 상태 기반 워크플로우를 위해 EventBridge가 트리거하는 AWS Lambda 함수에서 비즈니스 로직과 상태 관리를 직접 구현하고, 원본 이벤트 아카이빙을 위해 EventBridge 규칙을 S3 버킷으로 구성합니다.
D. SNS Topic을 사용하여 모든 거래 이벤트를 수집하고, 각 마이크로서비스가 SNS Topic을 구독하도록 합니다. 복잡한 상태 기반 워크플로우를 위해 SNS Topic에 구독된 Lambda 함수가 이벤트를 처리하고, DynamoDB를 사용하여 워크플로우 상태를 저장합니다. 원본 이벤트 아카이빙을 위해 SNS 메시지를 S3로 직접 기록하는 Lambda 함수를 사용합니다.
🎯 정답: A
✅ A. Kinesis Data Stream을 사용하여 모든 거래 이벤트를 수집하고, 이벤트를 읽는 AWS Lambda 함수에서 SNS Topic으로 발행하여 여러 마이크로서비스로 팬아웃합니다. 복잡한 상태 기반 워크플로우를 위해 Step Functions 상태 머신을 시작하고, 원본 이벤트 아카이빙을 위해 Kinesis Data Firehose를 구성하여 S3 버킷으로 데이터를 전송합니다.
B. SQS Queue를 사용하여 모든 거래 이벤트를 수집하고 각 다운스트림 마이크로서비스마다 별도의 SQS Queue를 생성하여 이벤트를 복제합니다. 복잡한 상태 기반 워크플로우를 위해 EC2 인스턴스에서 실행되는 커스텀 애플리케이션을 배포하고, 원본 이벤트 아카이빙을 위해 SQS 메시지를 S3로 직접 기록하는 Lambda 함수를 사용합니다.
C. Amazon EventBridge를 사용하여 모든 거래 이벤트를 수집하고 규칙을 통해 여러 마이크로서비스로 이벤트를 라우팅합니다. 복잡한 상태 기반 워크플로우를 위해 EventBridge가 트리거하는 AWS Lambda 함수에서 비즈니스 로직과 상태 관리를 직접 구현하고, 원본 이벤트 아카이빙을 위해 EventBridge 규칙을 S3 버킷으로 구성합니다.
D. SNS Topic을 사용하여 모든 거래 이벤트를 수집하고, 각 마이크로서비스가 SNS Topic을 구독하도록 합니다. 복잡한 상태 기반 워크플로우를 위해 SNS Topic에 구독된 Lambda 함수가 이벤트를 처리하고, DynamoDB를 사용하여 워크플로우 상태를 저장합니다. 원본 이벤트 아카이빙을 위해 SNS 메시지를 S3로 직접 기록하는 Lambda 함수를 사용합니다.
💡 해설:
옵션 A는 각 요구사항에 가장 적합한 AWS 서비스를 효과적으로 조합합니다:
* **Kinesis Data Stream:** 고성능, 대용량 실시간 데이터 스트리밍 및 내구성 있는 보존에 최적입니다.
* **AWS Lambda & SNS Topic:** Kinesis Data Stream에서 이벤트를 읽어 SNS Topic으로 발행함으로써 여러 마이크로서비스로의 효율적인 '팬아웃'을 구현합니다. SNS는 대규모 메시지 전달에 탁월합니다.
* **Step Functions:** 복잡하고 다단계의 상태 기반 워크플로우를 서버리스 방식으로 쉽게 정의, 실행, 모니터링할 수 있도록 하여 재시도, 시간 초과, 오류 처리, 수동 승인 등을 내장합니다. 이는 Lambda에서 직접 상태를 관리하는 것보다 훨씬 효율적입니다.
* **Kinesis Data Firehose & S3:** Kinesis Data Stream의 데이터를 안정적이고 비용 효율적으로 S3로 스트리밍하여 장기 아카이빙을 수행합니다. 이는 Firehose의 주요 기능 중 하나입니다.
다른 옵션들은 다음 이유로 인해 비효율적이거나 요구사항을 완벽히 충족하지 못합니다:
* **옵션 B:** SQS를 통한 팬아웃은 각 마이크로서비스마다 별도의 큐를 생성하고 메시지를 복제해야 하므로 비효율적입니다. EC2 기반의 커스텀 워크플로우는 운영 오버헤드를 증가시키고 서버리스 이점을 상실합니다.
* **옵션 C:** EventBridge는 이벤트 라우팅에 강력하지만, Kinesis Data Stream만큼의 고성능 대용량 실시간 스트리밍에는 최적화되어 있지 않습니다. Lambda 내에서 복잡한 상태 관리를 구현하는 것은 Step Functions 사용에 비해 복잡성이 높고 오류 발생 가능성이 큽니다.
* **옵션 D:** SNS는 팬아웃에 적합하지만, 고용량의 순서 있는 데이터 스트리밍 시작점으로는 Kinesis Data Stream이 더 적합합니다. Lambda와 DynamoDB로 복잡한 워크플로우 상태를 직접 관리하는 것은 Step Functions가 제공하는 기능을 다시 구현하는 것이 되어 비효율적입니다.
옵션 A는 각 요구사항에 가장 적합한 AWS 서비스를 효과적으로 조합합니다:
* **Kinesis Data Stream:** 고성능, 대용량 실시간 데이터 스트리밍 및 내구성 있는 보존에 최적입니다.
* **AWS Lambda & SNS Topic:** Kinesis Data Stream에서 이벤트를 읽어 SNS Topic으로 발행함으로써 여러 마이크로서비스로의 효율적인 '팬아웃'을 구현합니다. SNS는 대규모 메시지 전달에 탁월합니다.
* **Step Functions:** 복잡하고 다단계의 상태 기반 워크플로우를 서버리스 방식으로 쉽게 정의, 실행, 모니터링할 수 있도록 하여 재시도, 시간 초과, 오류 처리, 수동 승인 등을 내장합니다. 이는 Lambda에서 직접 상태를 관리하는 것보다 훨씬 효율적입니다.
* **Kinesis Data Firehose & S3:** Kinesis Data Stream의 데이터를 안정적이고 비용 효율적으로 S3로 스트리밍하여 장기 아카이빙을 수행합니다. 이는 Firehose의 주요 기능 중 하나입니다.
다른 옵션들은 다음 이유로 인해 비효율적이거나 요구사항을 완벽히 충족하지 못합니다:
* **옵션 B:** SQS를 통한 팬아웃은 각 마이크로서비스마다 별도의 큐를 생성하고 메시지를 복제해야 하므로 비효율적입니다. EC2 기반의 커스텀 워크플로우는 운영 오버헤드를 증가시키고 서버리스 이점을 상실합니다.
* **옵션 C:** EventBridge는 이벤트 라우팅에 강력하지만, Kinesis Data Stream만큼의 고성능 대용량 실시간 스트리밍에는 최적화되어 있지 않습니다. Lambda 내에서 복잡한 상태 관리를 구현하는 것은 Step Functions 사용에 비해 복잡성이 높고 오류 발생 가능성이 큽니다.
* **옵션 D:** SNS는 팬아웃에 적합하지만, 고용량의 순서 있는 데이터 스트리밍 시작점으로는 Kinesis Data Stream이 더 적합합니다. Lambda와 DynamoDB로 복잡한 워크플로우 상태를 직접 관리하는 것은 Step Functions가 제공하는 기능을 다시 구현하는 것이 되어 비효율적입니다.
🚀 Tip: SAP-C02 시험에서는 여러 AWS 서비스의 기능을 정확히 이해하고, 주어진 비즈니스 요구사항(고가용성, 확장성, 비용 효율성, 운영 오버헤드 최소화 등)에 맞춰 최적의 서비스 조합을 설계하는 능력을 평가합니다. 각 서비스의 장단점과 사용 사례를 명확히 구분하는 것이 중요합니다.
Amazon Kinesis Data StreamAWS LambdaAmazon SNSAWS Step FunctionsAmazon Kinesis Data FirehoseAmazon S3
🛡️ Deuktem AWS Quiz Bot | 커뮤니티 이동