소개
주문 서비스는 지금 작업을 접수하고 나중에 처리해야 합니다. 대기열을 만들고 작업을 수신하며 제공된 작업자를 실행한 다음 메시지를 확인 처리하기 전에 저장된 주문을 확인합니다.
Lambda에서 DynamoDB 읽기 및 쓰기와 해당 실습의 선행 안내 실습을 먼저 완료하세요. 이 독립적인 VM에는 작업자, 범위가 제한된 역할, 빈 주문 테이블과 참조 데이터가 제공됩니다. 대기열이나 작업은 준비되어 있지 않습니다.
인증 시험 관련 주제
이 실습은 다음 시험 주제에 대한 실습 경험을 제공합니다.
- Cloud Practitioner (CLF-C02) · 태스크 3.8: SQS 메시지 전달, 처리와 확인.
- 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를 사용하여 현재 대기열, 작업자 결과와 저장된 주문을 비교하세요. 관련 없는 참조 데이터를 유지하세요.
**Amazon Simple Queue Service (SQS)**는 소비자를 위해 작업을 메시지로 저장합니다. 생산자는 작업을 전송하고 소비자는 이를 처리합니다. 대기열은 두 주체의 실행 시점을 분리합니다. 생산자는 소비자가 완료할 때까지 기다릴 필요가 없습니다. 표준 대기열은 같은 메시지를 여러 번 전달할 수 있습니다. 수신과 확인 처리는 별개의 작업입니다.
준비된 작업 공간에서 시작하세요.
cd /home/labex/project
제공된 작업자와 빈 주문 테이블을 확인하세요. 작업자는 항목당 250센트에 수수료 100센트를 더하여 계산합니다. 실행 역할은 주문 테이블에만 쓸 수 있습니다. 참조 테이블은 유지해야 하는 관련 없는 데이터입니다.
aws lambda get-function-configuration --function-name labex-q01-worker --query '{Name:FunctionName,Role:Role,Runtime:Runtime}'
aws dynamodb scan --table-name labex-q01-orders --query Items
빈 항목 목록이 나와야 합니다. 본인의 대기열을 만드세요. --query QueueUrl --output text는 주소를 일반 텍스트로 선택합니다. $(...)는 이후 명령에서 사용할 셸 변수 QUEUE_URL에 이 출력을 저장합니다.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q01-jobs --attributes VisibilityTimeout=300 --query QueueUrl --output text)
**표시 제한 시간 (visibility timeout)**은 수신한 메시지가 다시 사용 가능해지기 전까지 소비자에게 300초를 제공합니다. 이는 일시적인 숨김이며 삭제가 아닙니다. 다음 실습에서는 만료와 재전달을 살펴봅니다.
대기열의 신원과 현재 개수를 확인하세요.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
VisibilityTimeout은 300이고 두 메시지 개수는 모두 0이어야 합니다. 개수는 대략적인 운영 신호이며 비즈니스 완료를 보장하지는 않습니다. AWS View에서 대기열의 사용 가능한 작업과 처리 중인 작업은 모두 0입니다. 제공된 Lambda에는 실행이 없고 주문 테이블은 여전히 비어 있습니다.
공식 Console은 CLI로 확인하는 것과 같은 대기열 이름, 유형, URL과 ARN을 보여 줍니다. 이는 예시 값입니다. 계속 본인의 QUEUE_URL을 사용하세요. 이 실습의 리소스는 AWS View로 관찰하세요.
출처: AWS SQS.
주문 작업 전송 및 수신
이 단계에서는 작업을 전송하고 수신하여 사용 가능한 메시지와 처리 중인 메시지의 차이를 관찰합니다.
수신하고 처리한 다음 확인 처리하세요. 저장된 주문을 확인한 후에만 현재 수신 핸들로 대기열 메시지를 삭제합니다.
메시지 본문은 애플리케이션 데이터입니다. SQS는 JSON을 텍스트로 보관하며 소비자가 이를 해석해야 합니다. 작은 테스트용 주문 작업 하나를 전송하세요.
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"queue-order","quantity":2}'
응답에는 MessageId와 MD5OfMessageBody가 포함됩니다. 메시지 ID는 메시지를 식별하며 MD5는 본문 바이트를 요약합니다. 이는 대기열이 접수했음을 확인하는 것이며 주문 완료를 의미하지 않습니다. 이제 AWS View에는 사용 가능한 작업 하나가 표시되지만 주문 테이블은 여전히 비어 있습니다.
메시지 하나를 수신하고 응답을 저장하세요. >는 출력을 표시하는 대신 received.json으로 리디렉션합니다. --wait-time-seconds 5는 즉시 사용 가능한 작업이 없을 때 짧은 롱 폴링 대기를 허용합니다.
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --wait-time-seconds 5 --message-system-attribute-names ApproximateReceiveCount --output json > received.json
JSON에서 필드를 선택하는 jq로 안전한 애플리케이션 본문과 수신 횟수를 읽으세요.
jq '.Messages[0] | {MessageId,Body,Attributes}' received.json
본문에는 queue-order와 수량 2가 포함되어야 하며 첫 수신에서 수신 횟수는 1이어야 합니다. 전체 응답에는 이번 전달 시도를 위한 값인 **수신 핸들 (receipt handle)**도 포함됩니다. 이 메시지를 확인 처리할 때 최신 핸들을 사용합니다.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
사용 가능한 메시지는 0, 보이지 않는 메시지는 1이어야 합니다. AWS View에서 작업은 **처리 중 (in flight)**이지만 주문은 여전히 없습니다. 수신하는 것만으로 처리되거나 삭제되지는 않았습니다. 300초 안에 다음 단계로 진행하세요. 읽는 데 더 오래 걸렸다면 처리하고 삭제하기 전에 같은 파일로 다시 수신하여 최신 수신 핸들을 구하세요.
이 실제 예시는 처리 전 전달 상태를 보여 줍니다. 작업 공간의 메시지 ID는 다릅니다.
확인 처리 전에 작업 처리
이 단계에서는 수신한 본문을 처리하고 영구 저장된 주문을 검증한 다음 메시지를 확인 처리합니다.
실제로 수신한 본문을 작업자 입력으로 사용하세요. fromjson은 SQS 응답 안의 JSON 문자열을 JSON 객체로 변환하며 리디렉션은 이 객체를 job.json에 씁니다.
jq '.Messages[0].Body | fromjson' received.json > job.json
제공된 Lambda는 이 주문 객체를 받습니다. Lambda 과정에서와 같이 fileb://job.json은 파일 바이트를 전송하고 마지막 파일 이름은 함수 응답을 받을 파일을 지정합니다. 작업자를 호출하세요.
aws lambda invoke --function-name labex-q01-worker --payload fileb://job.json worker-response.json
Invoke API 상태가 성공이라는 것만으로 처리 성공이 증명되지는 않습니다. 응답 본문을 확인하세요.
cat worker-response.json
processed: true, 수량 2, total_cents: 600이 나와야 합니다. 다음으로 함수가 반환한 메시지에만 의존하지 말고 저장된 항목을 읽으세요.
aws dynamodb get-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}' --consistent-read --query Item
queue-order, 수량 2와 합계 600이 나와야 합니다. AWS View는 실제 작업자 입력/결과와 동일한 영구 저장 주문을 보여 줍니다. 작업은 확인 처리할 때까지 처리 중 상태로 남습니다. 작업자 응답이나 저장된 항목 중 하나라도 잘못되었다면 삭제하지 말고 진단을 위해 메시지를 유지하세요.
주문을 확인한 후 현재 수신 핸들을 일반 텍스트로 선택하고 대기열에서 해당 전달을 삭제하세요.
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' received.json)
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
삭제가 성공하면 일반적으로 아무것도 출력하지 않습니다. 개수를 다시 읽으세요.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
두 개수 모두 0이어야 합니다. AWS View에는 빈 대기열과 저장된 주문 하나가 표시됩니다. 대기열 접수, 일시적인 전달, 비즈니스 처리와 확인 처리를 구별했습니다. 실제 애플리케이션에서 표준 대기열은 여전히 메시지를 재전달할 수 있습니다. 이 순서가 처음부터 끝까지 정확히 한 번 처리되는 것을 보장하지는 않습니다. 이후 단원에서는 영구적인 중복 방지 장치를 배웁니다.
본인의 대기열과 결과만 정리
이 단계에서는 제공된 리소스를 유지하면서 본인의 대기열, 결과와 로그를 제거합니다.
제공된 작업자, 테이블 구조와 참조 데이터를 유지하면서 대기열과 만든 주문을 제거하세요. 대기열 삭제는 남은 작업을 모두 버리므로 먼저 이전 단계가 성공적으로 완료되었는지 확인하세요.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}'
작업자 실행은 CloudWatch Logs 그룹을 생성했습니다. 정리의 일부로 이 실습의 실행 로그를 삭제하세요.
aws logs delete-log-group --log-group-name /aws/lambda/labex-q01-worker
성공한 서비스 쿼리로 리소스 상태를 확인하세요.
aws sqs list-queues
aws dynamodb scan --table-name labex-q01-orders --query Items
aws dynamodb scan --table-name labex-q01-reference --query Items
대기열 URL은 남아 있지 않아야 하고 주문 항목 목록은 비어 있어야 하며 참조 항목에는 여전히 keep unchanged가 있어야 합니다. AWS View에는 대기열, 주문이나 실행 로그가 없고 제공된 작업자와 참조 리소스는 계속 존재합니다. 인증 오류나 네트워크 오류는 삭제 성공의 증거가 아닙니다.
리소스를 확인한 후 일반 응답 파일을 제거하세요.
rm -f received.json job.json worker-response.json
환경을 종료하기 전에 단계 검사를 사용하세요.
요약
SQS 표준 대기열을 만들고 JSON 주문 작업을 전송하고 수신했으며 실제 Lambda 처리와 영구 저장된 DynamoDB 항목을 검증하고 수신 핸들로 메시지를 확인 처리했습니다. 접수, 처리 중 전달과 비즈니스 완료를 구별한 다음 제공된 리소스를 유지하면서 본인의 대기열, 주문과 실행 로그를 제거했습니다.
