0Pricing
Cloud & IT Cert Prep · 강의

가시성 제한 시간, DLQ 및 롱 폴링

메시지가 두 번 처리되지 않도록 가시성 제한 시간을 설정하고 실패한 메시지를 배달 못한 편지 대기열로 라우팅하며 롱 폴링으로 비용을 줄입니다.

가시성 제한 시간, DLQ 및 롱 폴링은(는) CoddyKit의 무료 Cloud & IT Cert Prep 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Cloud & IT Cert Prep 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

가시성 제한 시간 메커니즘

소비자가 SQS에서 메시지를 수신하면 해당 메시지는 가시성 제한 시간이라는 기간 동안 다른 모든 소비자에게 보이지 않습니다. 이 기간에 소비자는 메시지를 처리한 다음 삭제합니다. 소비자가 중단되거나 제때 처리를 완료하지 못하면 가시성 제한 시간이 만료되고 메시지가 다시 표시되어 다른 소비자가 가져갈 수 있습니다. 이것이 SQS의 최소 한 번 전달 보장을 뒷받침하는 핵심 메커니즘입니다.

가시성 제한 시간 구성

기본 가시성 제한 시간은 30초입니다. 0초에서 12시간 사이로 설정할 수 있습니다. 예상되는 최대 처리 시간을 충분히 초과하도록 설정하십시오. 예를 들어 처리에 최대 2분이 걸린다면 제한 시간을 최소 3~4분으로 설정하십시오. change-message-visibility를 사용하여 수신 영수증별로 제한 시간을 변경할 수도 있습니다. 이는 소비자가 특정 메시지의 처리를 완료하는 데 더 많은 시간이 필요하다고 판단했을 때 유용합니다.

# Extend visibility timeout for a specific message
aws sqs change-message-visibility \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --receipt-handle 'AQEBwJnKyrHigUMZj...' \
  --visibility-timeout 300

너무 짧거나 너무 긴 제한 시간

제한 시간을 너무 짧게 설정하면 소비자가 처리를 끝내기 전에 메시지가 다시 나타나 중복 처리가 발생합니다. 제한 시간을 너무 길게 설정하면 원래 소비자가 조용히 실패한 경우(예: 정상적인 정리 과정 없이 EC2 인스턴스가 중단된 경우) 다른 소비자가 메시지를 가져갈 때까지 지연됩니다. 최적의 제한 시간은 처리 시간의 99번째 백분위수보다 약간 길면서도 소비자 장애에서 빠르게 복구할 수 있을 만큼 짧아야 합니다. ApproximateNumberOfMessagesNotVisible CloudWatch 지표를 모니터링하여 제한 시간 문제를 찾아내십시오.

배달 못한 편지 대기열 설명

배달 못한 편지 대기열(DLQ)은 메시지 처리가 구성된 횟수(maxReceiveCount)만큼 실패한 후 메시지가 전송되는 별도의 SQS 대기열입니다. 메시지의 수신 횟수가 maxReceiveCount를 초과하면 SQS가 자동으로 해당 메시지를 DLQ로 이동합니다. DLQ는 항상 실패하는 메시지(독성 메시지)가 대기열을 무기한 차단하는 것을 방지합니다. DLQ의 메시지는 처리 오류를 수정한 후 검사하고, 디버깅하고, 다시 처리할 수 있습니다.

배달 못한 편지 대기열 구성

DLQ는 일반 SQS 대기열일 뿐입니다(소스가 Standard이면 Standard, 소스가 FIFO이면 FIFO를 사용합니다). 소스 대기열에 Redrive Policy를 구성하여 DLQ로 사용할 대기열과 maxReceiveCount 임계값을 지정합니다. 메시지는 늦게 DLQ에 도착하므로 만료되기 전에 조사할 시간이 필요합니다. 따라서 DLQ의 보존 기간을 더 길게 설정하십시오.

aws sqs set-queue-attributes \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123456789012:MyDLQ\", \"maxReceiveCount\": \"5\"}"
  }'

DLQ 모니터링 및 경보 설정

DLQ의 ApproximateNumberOfMessagesVisible 지표에 CloudWatch 경보를 설정하십시오. DLQ에 도착하는 모든 메시지는 주의가 필요한 처리 실패를 의미합니다. 경보가 SNS 알림을 발생시켜 대기 중인 담당 엔지니어에게 즉시 호출 알림을 보내도록 구성하십시오. 모든 DLQ 메시지를 조사가 필요한 오류로 취급하십시오. DLQ 메시지가 아무 알림 없이 쌓여서는 안 됩니다. 오류를 수정한 후에는 DLQ Redrive를 사용하여 메시지를 소스 대기열로 보내 다시 처리하십시오.

DLQ Redrive: 메시지 다시 처리

처리 실패를 일으킨 오류를 수정했다면 SQS DLQ Redrive를 사용하여 DLQ의 메시지를 소스 대기열로 이동하고 다시 처리하십시오. 콘솔에는 기본 제공되는 다시 처리 기능이 있습니다. 메시지 속성으로 필터링하여 특정 메시지만 다시 처리할 수도 있습니다. 사용자 지정 필터링 로직이 필요하다면 Lambda 함수를 작성하여 DLQ를 폴링하고 메시지를 소스 대기열로 전달할 수 있습니다.

# Start DLQ message move task
aws sqs start-message-move-task \
  --source-arn 'arn:aws:sqs:us-east-1:123456789012:MyDLQ' \
  --destination-arn 'arn:aws:sqs:us-east-1:123456789012:MyQueue' \
  --max-number-of-messages-per-second 5

짧은 폴링과 긴 폴링

기본적으로 SQS는 짧은 폴링을 사용합니다. receive-message 호출은 서버의 무작위 하위 집합을 확인한 후 메시지가 없어도 즉시 반환합니다. 이로 인해 빈 응답이 많이 발생하고 API 호출이 낭비됩니다. 긴 폴링은 빈 응답을 반환하기 전에 메시지가 도착할 때까지 최대 20초 동안 기다립니다. 긴 폴링은 API 호출 수를 줄여 비용을 크게 낮추고, 메시지가 도착하는 즉시 수신할 수 있어 지연 시간도 줄입니다(다음 폴링 주기보다 최대 20초 빠릅니다).

긴 폴링 활성화

대기열 수준에서 긴 폴링을 활성화하여 모든 수신 호출에 적용하거나 요청별로 활성화할 수 있습니다. 대부분의 애플리케이션에서는 ReceiveMessageWaitTimeSeconds를 20으로 설정하는 대기열 수준 구성을 권장합니다. Lambda가 SQS를 이벤트 소스로 사용하면 자동으로 긴 폴링을 사용합니다. EC2 기반 소비자에서는 receive-message 호출에 WaitTimeSeconds를 설정하십시오.

# Enable long polling at queue level (recommended)
aws sqs set-queue-attributes \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --attributes '{"ReceiveMessageWaitTimeSeconds": "20"}'

# Or per-request
aws sqs receive-message \
  --queue-url 'https://...' \
  --wait-time-seconds 20 \
  --max-number-of-messages 10

메시지 속성 및 필터링

SQS 메시지에는 메시지 본문과 별개인 메타데이터 키-값 쌍인 메시지 속성을 포함할 수 있습니다. 속성에는 유형(String, Number, Binary)과 값이 있습니다. SQS가 SNS 주제를 구독하는 경우, 메시지 속성에 적용되는 SNS 구독 필터 정책을 사용하여 각 대기열에 관련 메시지만 전달할 수 있습니다. 필터링하지 않으면 모든 SQS 구독자가 내용과 관계없이 모든 SNS 게시물을 수신합니다.

지연 대기열 및 메시지 타이머

지연 대기열은 새 메시지가 전송된 후 지연 기간(0~15분) 동안 모든 새 메시지를 보이지 않게 합니다. 이는 소비자가 메시지를 즉시 처리하지 않고 먼저 종속 프로세스가 완료되기를 기다려야 하는 작업 흐름에 유용합니다. 전송 호출에서 DelaySeconds를 사용하여 메시지별 지연 시간도 설정할 수 있으며, 이 값은 대기열 수준의 지연 시간을 재정의합니다. 참고로 지연 대기열은 FIFO 대기열에서 사용할 수 없습니다.

# Create a delay queue (5 minute delay)
aws sqs create-queue \
  --queue-name 'DelayedProcessingQueue' \
  --attributes '{"DelaySeconds": "300"}'

빠른 확인

이 단원에서 다룬 AWS Solutions Architect (SAA-C03) 개념을 얼마나 이해했는지 확인해 보십시오.

단원 요약

이 단원에서는 다음을 배웠습니다. 가시성 제한 시간은 처리 중인 메시지를 다른 소비자에게 숨겨 최소 한 번 전달을 가능하게 하며, 소비자에 장애가 발생하면 자동으로 다시 전달합니다. 배달 못한 편지 대기열은 반복적으로 처리에 실패하는 메시지를 수집하여 버그 수정 후 디버깅하고 재생할 수 있게 합니다. 또한 롱 폴링은 최대 20초 동안 대기하여 숏 폴링보다 API 비용과 지연 시간을 줄입니다. 다음으로 SNS 토픽과 팬아웃 아키텍처를 살펴보겠습니다.

자주 묻는 질문

“가시성 제한 시간, DLQ 및 롱 폴링” 강의는 무료인가요?

네 — “가시성 제한 시간, DLQ 및 롱 폴링” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Cloud & IT Cert Prep 강의 전체를 잠금 해제할 수 있습니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

“가시성 제한 시간, DLQ 및 롱 폴링”에서 뭘 배우나요?

메시지가 두 번 처리되지 않도록 가시성 제한 시간을 설정하고 실패한 메시지를 배달 못한 편지 대기열로 라우팅하며 롱 폴링으로 비용을 줄입니다. 브라우저에서 직접 실행하는 실습 코드로 Cloud & IT Cert Prep을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Cloud & IT Cert Prep을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Cloud & IT Cert Prep은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“가시성 제한 시간, DLQ 및 롱 폴링” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Cloud & IT Cert Prep 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Cloud & IT Cert Prep 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. SQS Standard와 FIFO 대기열
  2. 가시성 제한 시간, DLQ 및 롱 폴링
  3. SNS 주제 및 팬아웃 아키텍처
  4. SQS 메시지 필터링 및 SNS와 SQS 통합
← Cloud & IT Cert Prep(으)로 돌아가기