소개
작업자가 주문 작업을 수신하지만 확인 처리하기 전에 중단됩니다. 같은 작업이 돌아오는 것을 관찰하고 다음 전달에 더 많은 처리 시간을 부여하며 확인 처리 전에 실제 주문을 확인합니다.
SQS로 작업 전송 및 소비를 먼저 완료하세요. 이 독립적인 VM에는 자체 작업자, 테이블과 참조 데이터가 제공됩니다. 이전 대기열, 메시지와 수신 핸들은 재사용하지 않습니다.
인증 시험 관련 주제
이 실습은 다음 시험 주제에 대한 실습 경험을 제공합니다.
- Solutions Architect – Associate (SAA-C03) · 태스크 2.1: SQS 가시성 시간 초과, 재전달과 수신 핸들.
- Developer – Associate (DVA-C02) · 태스크 1.1: SQS 가시성 시간 초과, 재전달과 수신 핸들.
- DevOps Engineer – Professional (DOP-C02) · 태스크 5.1: 기초 실습: SQS 가시성 시간 초과, 재전달과 수신 핸들.
- Solutions Architect – Professional (SAP-C02) · 태스크 2.4: 기초 실습: SQS 가시성 시간 초과, 재전달과 수신 핸들.
재전달할 작업 준비
이 단계에서는 기본 표시 제한 시간이 짧은 대기열을 만들고 처리하지 않은 채 작업을 전송합니다.
Terminal 옆에서 AWS View를 사용하여 현재 대기열, 작업자 결과와 저장된 주문을 비교하세요. 관련 없는 참조 데이터를 유지하세요.
준비된 프로젝트 디렉터리에서 작업하세요.
cd /home/labex/project
표준 대기열을 만드세요. 기본 표시 제한 시간은 30초이며 수신 요청에 재정의 값이 없을 때 사용됩니다. $(...)는 이후 명령에 사용할 선택된 대기열 주소를 저장합니다.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q02-jobs --attributes VisibilityTimeout=30 --query QueueUrl --output text)
JSON 작업 하나를 전송하세요.
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"redelivery-order","quantity":3}'
기본 제한 시간과 개수를 읽으세요.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
제한 시간은 30, 사용 가능한 메시지는 하나, 처리 중인 메시지는 0이어야 합니다. AWS View에서 작업의 수신 횟수는 0이고 제공된 Lambda에는 실행이 없으며 저장된 주문도 없습니다. 전송은 작업을 대기열에 접수하며 처리하지는 않습니다.
만료와 두 번째 전달 관찰
이 단계에서는 작업을 수신하고 확인 처리하지 않은 채 두며 표시 제한 시간이 만료된 후 두 번째 전달을 관찰합니다.

표시 제한 시간이 만료되면 같은 메시지가 새 수신 핸들과 함께 다시 전달될 수 있습니다.
다음 명령 블록은 시간을 정해 수행하는 하나의 실험입니다. 실행하기 전에 읽어 보세요. 첫 수신은 표시 제한 시간을 10초로 재정의합니다. 즉시 수행하는 두 번째 수신은 작업이 숨겨진 동안 아무것도 찾지 못해야 합니다. sleep 12는 기한이 지날 때까지 기다립니다. 마지막 수신은 돌아온 작업에 120초를 부여하므로 짧은 제한 시간에 쫓기지 않고 확인할 수 있습니다. 각 >는 JSON 응답을 서로 다른 파일에 저장합니다.
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --visibility-timeout 10 --message-system-attribute-names ApproximateReceiveCount --output json > first-delivery.json
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --wait-time-seconds 0 --output json > while-hidden.json
sleep 12
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --visibility-timeout 120 --message-system-attribute-names ApproximateReceiveCount --output json > second-delivery.json
빈 수신은 아무것도 처리하거나 삭제하지 않습니다. 해당 응답을 표시하세요.
cat while-hidden.json
Messages가 없는 빈 응답이 나와야 합니다. jq -s는 저장된 두 응답을 함께 읽습니다. .[0]은 첫 번째 전달이고 .[1]은 두 번째 전달입니다. 핸들을 출력하지 않고 메시지 신원과 전달 수신 핸들을 비교하세요.
jq -s '{
same_message: (.[0].Messages[0].MessageId == .[1].Messages[0].MessageId),
new_receipt: (.[0].Messages[0].ReceiptHandle != .[1].Messages[0].ReceiptHandle),
receive_count: .[1].Messages[0].Attributes.ApproximateReceiveCount
}' first-delivery.json second-delivery.json
same_message와 new_receipt는 true, 수신 횟수는 "2"여야 합니다. 메시지 ID는 여러 시도에 걸쳐 대기열 메시지를 식별합니다. 수신 핸들은 전달 시도 하나를 식별하므로 표시 제한 시간 변경과 삭제에는 항상 최신 핸들을 사용하세요.
AWS View에는 같은 본문이 두 번 수신되어 처리 중인 상태로 표시되며 아직 주문은 없습니다. 이는 확인 처리하지 않은 시도 이후의 실제 재전달입니다. 두 번째 전송은 필요하지 않았습니다. 표준 대기열은 다른 이유로도 중복 메시지를 전달할 수 있습니다. 표시 제한 시간 관리가 정확히 한 번 처리되는 것을 보장하지는 않습니다.

이 실제 예시는 비즈니스 처리 전 수신 횟수가 2인 상태를 보여 줍니다. 메시지 식별자는 작업 공간마다 다릅니다.
처리 시간 연장 및 작업 완료
이 단계에서는 현재 전달의 처리 시간을 연장하고 제공된 작업자를 완료하며 저장된 데이터를 검증한 후에만 확인 처리합니다.
두 번째 응답에서 최신 수신 핸들을 선택하세요. jq -r은 명령 인수에 적합한 일반 문자열을 출력합니다.
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' second-delivery.json)
이번 특정 전달의 표시 제한 시간을 300초로 변경하세요.
aws sqs change-message-visibility --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE" --visibility-timeout 300
이 새 구간은 변경이 성공할 때 시작됩니다. 대기열의 기본 30초 설정은 변경하지 않으며 작업을 확인 처리하지도 않습니다. 120초 확인 시간이 이미 만료되었다면 작업을 다시 second-delivery.json으로 수신하고 최신 핸들을 선택한 후 표시 제한 시간을 변경하세요. 추가 시도는 수신 횟수를 늘립니다. 정확히 두 번 전달되는 관찰을 반복해야 한다면 새 작업 공간에서 시간 실험을 다시 수행하세요.
수신한 본문을 JSON 텍스트에서 작업 객체로 변환하세요.
jq '.Messages[0].Body | fromjson' second-delivery.json > job.json
제공된 Lambda를 실행한 다음 결과를 확인하세요.
aws lambda invoke --function-name labex-q02-worker --payload fileb://job.json worker-response.json
cat worker-response.json
processed: true, 수량 3과 합계 850센트가 나와야 합니다. 영구 저장된 항목을 독립적으로 읽으세요.
aws dynamodb get-item --table-name labex-q02-orders --key '{"id":{"S":"redelivery-order"}}' --consistent-read --query Item
실제 저장된 결과를 확인한 후에만 현재 수신 핸들로 삭제하세요.
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
기본 제한 시간은 30, 사용 가능한 메시지와 처리 중인 메시지는 모두 0이어야 합니다. AWS View는 빈 대기열, 실제 작업자 입력/결과와 주문 redelivery-order/3/850을 보여 줍니다. 표시 제한 시간 연장은 이번 시도가 작업하는 동안 다른 작업자가 작업을 수신할 가능성을 줄였습니다. 비즈니스 작업을 멱등하게 만든 것은 아닙니다. 이후 단원에서는 중복 효과를 막는 영구적인 방지 장치를 배웁니다.
대기열과 소유한 결과 제거
이 단계에서는 제공된 준비물과 참조 데이터를 유지하면서 본인의 대기열, 주문과 실행 로그를 제거합니다.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q02-orders --key '{"id":{"S":"redelivery-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-q02-worker
성공한 서비스 쿼리로 리소스가 없고 참조 리소스를 사용할 수 있는지 확인하세요.
aws sqs list-queues
aws dynamodb scan --table-name labex-q02-orders --query Items
aws dynamodb scan --table-name labex-q02-reference --query Items
대기열 URL이나 주문 항목은 남아 있지 않습니다. 참조 항목에는 여전히 keep unchanged가 있습니다. AWS View는 동일한 정리 상태를 보여 주며 제공된 작업자는 계속 사용할 수 있습니다. 네트워크 오류나 인증 오류는 삭제를 증명할 수 없습니다.
로컬 전달 및 응답 파일을 제거하세요.
rm -f first-delivery.json while-hidden.json second-delivery.json job.json worker-response.json
환경을 종료하기 전에 단계 검사를 실행하세요.
요약
확인 처리하지 않은 SQS 작업이 표시 제한 시간 만료 후 다시 사용 가능해지는 것을 관찰하고 새 수신 핸들과 더 높은 수신 횟수로 같은 메시지를 수신했으며 현재 전달의 처리 시간을 연장했습니다. 확인 처리 전에 실제 저장된 주문을 검증하고 제공된 리소스를 유지하면서 본인의 대기열, 결과와 로그를 정리했습니다.



