Day 5 - Week 11 종합: 메시징의 모델을 가르는 질문들

결제 트랜잭션을 고객별 순서대로, 중복 없이 정확히 한 번 처리해야 한다. 초당 약 4,000건이 발생한다. 적절한 구성은?

• ASQS 표준 큐에 멱등 소비자를 두고 시퀀스 번호로 고객별 순서를 애플리케이션에서 재정렬한다
• B고처리량 FIFO 큐 + 고객 ID를 메시지 그룹 ID로 사용
• C모든 메시지에 동일한 단일 그룹 ID를 부여한 FIFO 큐로 전역 순서를 강제한다
• DKinesis Data Streams 단일 샤드에 고객 ID를 파티션 키로 넣어 순서를 보장한다

S3 객체 업로드 하나에 썸네일 생성·바이러스 검사·검색 색인 세 작업이 독립적으로(한 작업의 실패가 다른 작업에 영향 없이) 반응해야 한다. 가장 정석적인 패턴은?

• AS3 이벤트 → 단일 Lambda에서 썸네일·바이러스 검사·색인을 try/catch로 묶어 순차 실행
• BS3 → SNS → 세 개의 SQS(각각 Lambda) 팬아웃
• CS3 → 단일 SQS → Lambda가 메시지를 받아 세 작업을 모두 수행하고 ack한다
• D동일 객체를 세 버킷에 복제 업로드해 각 버킷 이벤트가 작업 하나씩 트리거하게 한다

클릭스트림을 Lambda로 실시간 이상 탐지하면서, 동시에 모든 원본을 S3에 아카이브해 나중에 Athena로 분석하려 한다. 적절한 구성은?

• ASQS 큐 하나에 이상 탐지 Lambda와 아카이브 Lambda 두 소비자를 붙여 같은 메시지를 둘 다 받게 한다
• BKinesis Data Streams에 Lambda 소비자와 Firehose 소비자를 동시 연결(Firehose→S3)
• CSNS 토픽 → 탐지 SQS와 아카이브 SQS 두 개로 팬아웃해 각각 Lambda·S3로 보낸다
• DDynamoDB Streams로 클릭 테이블 변경을 캡처해 Lambda 탐지와 S3 적재를 동시에 한다

Firehose로 로그를 S3에 적재 중인데 "데이터가 1분 정도 늦게 도착한다"는 불만이 있다. 1초 이내 실시간 처리가 필수라면?

• AFirehose 버퍼 크기를 128MB로 키워 한 번에 더 많이 flush하면 도착이 빨라진다
• BKinesis Data Streams를 직접 소비(Lambda/EFO)하도록 변경한다
• CFirehose 버퍼 간격(buffer interval)을 0초로 설정해 즉시 전달되게 한다
• DFirehose 앞단을 SQS로 전환해 짧은 가시성 타임아웃으로 1초 내 처리한다

SNS를 통해 Lambda로 직접 푸시하던 중, Lambda가 잠시 다운된 사이 발행된 알림이 영구 유실됐다. 내구성을 확보하려면?

• ASNS 토픽에 메시지 보존 기간을 7일로 설정해 Lambda 복구 후 재전달되게 한다
• BSNS → SQS → Lambda로 바꿔 SQS가 메시지를 보존하게 한다
• CLambda 예약 동시성을 높여 다운 시간을 줄이고 재시도 처리량을 확보한다
• DSNS 발행 속도를 스로틀링해 Lambda가 감당할 수 있는 만큼만 보내 유실을 막는다

Kinesis 스트림에서 특정 샤드만 ProvisionedThroughputExceededException이 나고 다른 샤드는 한가하다. 원인과 해결은?

• A보존 기간이 짧아 레코드가 만료된 것 — 보존을 24시간에서 7일로 늘려 해결한다
• B파티션 키 편향으로 핫 샤드 발생 — 키 카디널리티를 높여 고르게 분산
• C소비자가 EFO를 안 써서 읽기 경합 발생 — EFO를 활성화해 쓰기 스로틀을 해소한다
• DOn-Demand 모드가 아니라 용량이 막힌 것 — On-Demand에서 Provisioned로 전환한다

여러 Lambda를 순서대로 실행하고, 중간 실패 시 이전 단계를 보상(롤백)하며, 운영자가 전체 흐름을 시각적으로 추적해야 한다. 적절한 서비스는?

• ALambda가 다음 Lambda를 직접 호출하는 체인 + 실패 시 역순 보상 Lambda 호출
• BStep Functions (Retry/Catch + Saga 보상)
• C단계마다 SQS 큐를 두고 한 Lambda가 끝나면 다음 큐로 메시지를 넘기는 체인
• DEventBridge 규칙으로 각 단계 완료 이벤트를 다음 단계 Lambda에 라우팅하는 체인

환불 워크플로에서 고액 건은 관리자 승인을 받아야 하며, 승인까지 며칠이 걸릴 수 있다. 적절한 구성은?

• AExpress 워크플로 + Wait 상태로 승인이 올 때까지 며칠간 대기시킨다
• BStandard 워크플로 + .waitForTaskToken으로 승인 콜백 대기
• CStandard 워크플로 + .sync로 승인 작업이 완료될 때까지 동기 대기한다
• DSQS 지연 큐에 환불 메시지를 넣고 며칠 뒤 자동 처리되게 한다

모바일 앱이 한 화면에 사용자(DynamoDB)·주문(Lambda)·추천(OpenSearch)을 한 번에 가져오고, 주문 상태 변경을 실시간으로 받아야 한다. 적절한 서비스는?

• AAPI Gateway REST에 통합 백엔드 Lambda를 두어 세 소스를 합쳐 응답하고 상태 변경은 주기 폴링한다
• BAWS AppSync (다중 리졸버 + @aws_subscribe 실시간 구독)
• C사용자·주문·추천 각각의 REST 엔드포인트 3개를 호출하고 상태 변경은 클라이언트 폴링으로 받는다
• DKinesis Firehose로 세 소스를 모아 S3에 적재한 뒤 클라이언트가 조회하게 한다

Lambda가 SQS 큐를 소비하는데 같은 메시지가 중복 처리된다. 함수 타임아웃은 60초다. 가장 적절한 조치는?

• A가시성 타임아웃을 30초로 줄인다
• B가시성 타임아웃을 함수 타임아웃의 6배 이상(약 360초)으로 설정
• C롱 폴링을 끈다
• DFIFO로 바꾸면 무조건 해결된다

SNS가 HTTPS 엔드포인트로의 전달에 반복 실패한 메시지를 보존해 분석하려 한다. 적절한 방법은?

• ASNS 토픽에 메시지 보존을 켜서 전달 실패분이 토픽에 남도록 한다
• B해당 구독에 redrive policy로 SNS DLQ(SQS 큐)를 설정한다
• C구독 대상 함수에 Lambda DLQ를 붙여 비동기 호출 실패 메시지를 보존한다
• DHTTPS 엔드포인트 앞에 SQS를 두고 maxReceiveCount 초과분을 SQS DLQ로 보낸다

세 소비자가 같은 Kinesis 스트림을 각각 수십 ms 지연으로 읽어야 하고 서로 처리량을 빼앗으면 안 된다. 적절한 기능은?

• A클래식 공유 읽기에 GetRecords 폴링 간격을 줄여 세 소비자가 충분히 빠르게 읽게 한다
• BEnhanced Fan-Out으로 소비자별 전용 2 MB/s를 HTTP/2 푸시 제공
• C샤드를 3배로 늘려 소비자마다 사실상 전용 처리량을 확보하고 지연을 낮춘다
• DFirehose로 전환해 세 소비자가 각자 버퍼링된 배치를 받게 한다