AmazonAmazon Solution Architect Professional SAP-C02 Certification·KO·업데이트됨 1 Aug 2026
한 회사에서 전 세계적으로 최대 10,000명의 사용자가 피크 시간에 이미지를 업로드할 수 있는 글로벌 이미지 서비스를 계획하고 있습니다. 업로드된 각 이미지에는 텍스트 오버레이가 있어야 하며, 그 후에 웹사이트에 게시되어야 합니다. 솔루션스 아키텍트는 업로드 및 처리를 대규모로 처리하기 위해 어떤 아키텍처를 구현해야 할까요?
정답 선택
옵션을 탭하여 정답을 확인하세요.
정답: 업로드를 Amazon S3 버킷에 저장하고 S3 이벤트 알림을 구성하여 Amazon SQS 대기열로 메시지를 보냅니다. SQS 대기열을 폴링하여 이미지를 처리하고 결과를 별도의 S3 버킷에 쓰는 EC2 인스턴스 플릿을 실행합니다. 대기열 깊이에 대한 CloudWatch 지표를 사용하여 EC2 플릿을 확장합니다. 처리된 이미지를 담고 있는 S3 버킷을 오리진으로 CloudFront를 구성합니다..
이것이 정답인 이유
이 아키텍처는 대규모 이미지 업로드 및 처리에 적합합니다. Amazon S3는 무제한 스토리지와 높은 가용성을 제공하며, S3 이벤트 알림을 Amazon SQS와 연동하여 이미지 처리 작업을 비동기적으로 분리합니다. SQS는 메시지 큐를 통해 처리 부하를 분산하고, EC2 인스턴스 플릿은 SQS 대기열을 폴링하여 이미지를 처리합니다. CloudWatch 지표를 사용하여 SQS 대기열 깊이에 따라 EC2 플릿을 자동으로 확장함으로써, 피크 시간에도 효율적인 처리가 가능합니다. 처리된 이미지를 별도의 S3 버킷에 저장하고 CloudFront를 사용하여 전 세계 사용자에게 빠르게 배포할 수 있습니다.
다른 옵션들은 다음과 같은 이유로 적합하지 않습니다.
첫 번째 옵션: Amazon EFS는 파일 시스템이므로 대규모 동시 쓰기 작업에 S3만큼 적합하지 않으며, CloudWatch Logs를 사용하여 처리할 이미지를 결정하는 것은 비효율적입니다.
두 번째 옵션: Amazon SNS는 구독자에게 메시지를 푸시하는 서비스로, SQS처럼 메시지를 큐에 저장하고 폴링하여 처리 부하를 조절하는 데는 적합하지 않습니다. 또한 처리된 이미지를 EFS에 저장하는 것은 S3보다 확장성이 떨어집니다.
네 번째 옵션: 공유 Amazon EBS 볼륨은 단일 가용 영역 내에서만 사용 가능하며, 여러 EC2 인스턴스에 걸쳐 대규모 동시 액세스를 처리하기 어렵습니다. EventBridge 규칙으로 EC2 인스턴스를 확장하는 것은 SQS 대기열 깊이 기반의 자동 확장보다 유연성이 떨어집니다.