소비자가 느리거나 실패해도 작업을 유지하고 후속 팀에 알림을 보내며 반복 전달로부터 업무 결과를 보호합니다. 작은 주문 처리 흐름으로 SQS와 SNS를 배웁니다.
안내형 실습 5개에서 메시지 소비, 가시성, 데드 레터 큐, SNS 팬아웃, 중복 방지를 다룹니다. 독립 도전 과제에서는 실패한 작업이 복구 큐에 도달하지 않는 사고를 복구합니다.
배울 내용
- SQS 작업을 보내고 수신하고 처리한 뒤 확인하기
- 가시성 기간, 재전달, 현재 수신 핸들 관찰하기
- 데드 레터 큐에 실패한 작업 격리하기
- 필터가 있는 SQS 구독으로 SNS 알림 배포하기
- DynamoDB 조건부 쓰기로 반복되는 업무 작업 보호하기
- 정상 작업을 유지하며 실패한 작업의 경로 복구하기
- 저장된 결과를 확인하고 직접 만든 리소스만 제거하기
이 과정의 대상
서버리스 애플리케이션에 비동기 작업과 실패 처리를 추가할 준비가 된 학습자를 위한 과정입니다.
사전 요구 사항: Lambda–DynamoDB 접근(FN03)과 그 사전 지식을 먼저 학습하세요. Q01 → Q02 → Q03은 처리와 실패 격리를 다룹니다. Q04는 IAM 리소스 정책도 필요한 SNS 분기이며 Q05는 DynamoDB 조건부 쓰기(D04)와 Lambda 코드 업데이트(FN02)가 필요합니다. 서비스 챌린지는 Q03 이후, PS02는 Q05도 사용합니다.
학습 환경: 모든 활동은 브라우저에서 제공되는 LabEx Linux 환경에서 진행합니다. AWS CLI 명령에는 Terminal을 사용하고, 옆의 AWS View에서 동일한 리소스와 애플리케이션 상태를 확인합니다. 도구와 연결은 준비되어 있으므로 개인 AWS 계정이나 액세스 키가 필요하지 않습니다. 각 실습은 새로운 VM에서 독립적으로 시작합니다. AWS View는 큐, 메시지 본문, 시도 횟수, 로그, SNS 봉투, 저장된 주문을 표시합니다. 읽기 전용 관찰은 메시지를 수신하거나 확인하지 않습니다.
자주 묻는 질문
큐 설정이 작업 처리를 증명하나요?
아니요. 실제 처리, 저장된 결과, 확인된 원본 메시지, 보존된 실패 작업을 확인하세요. 제공되는 워커와 참조 데이터를 통해 합성 작업으로 이 결과에 집중할 수 있습니다.
메시지의 수신 핸들이 왜 바뀌나요?
수신 핸들은 한 번의 전달에 속합니다. 가시성 기간이 만료되면 다른 시도가 발생할 수 있고 새로운 현재 핸들이 생깁니다. 확인하려는 전달의 핸들을 사용하세요.
중복 방지가 정확히 한 번의 전달을 뜻하나요?
아니요. 표준 큐는 여러 번 전달할 수 있습니다. 단일 항목에 대한 조건부 쓰기는 배운 업무 효과를 보호하지만 큐 작업과 데이터베이스 쓰기는 별개입니다. 원자적 트랜잭션이나 종단 간 정확히 한 번의 보장이 아닙니다.
메시징 예제의 범위는 무엇인가요?
한 번에 한 메시지를 처리하는 소비자가 있는 표준 큐, 데드 레터 재처리, 동일 계정의 SNS에서 SQS로의 팬아웃, 메시지 속성 필터를 다룹니다. FIFO 순서, 임의 배치, 프로덕션 처리량, 계정 간 정책 설계, 완전한 서비스 재시도 보장은 범위 밖입니다.
다음 프로젝트는 무엇인가요?
Serverless 프로젝트 과정의 Recover Poison Messages Without Duplicating Orders입니다. 서비스 챌린지는 Q03과 사전 단원, 프로젝트는 Q05도 필요합니다. 기능 확인 후 정리하세요.
