Service Bus 배달 못 한 편지 큐의 개요
Azure Service Bus 큐 및 토픽 구독은 DLQ(배달 못한 편지 큐)라고 하는 보조 하위 큐를 제공합니다. 배달 못 한 편지 큐는 명시적으로 만들 필요가 없으며 주 엔터티와 독립적으로 삭제하거나 관리할 수 없습니다.
이 문서에서는 Service Bus에서 배달하지 못한 편지 큐에 대해 설명합니다. 대부분의 토론은 GitHub의 배달하지 못한 편지 큐 샘플에서 설명합니다.
배달하지 못한 편지 큐
배달 못한 편지 큐의 목적은 수신기에 배달할 수 없는 메시지 또는 처리할 수 없는 메시지를 보관하는 것입니다. 그런 다음 DLQ에서 메시지를 제거하여 검사할 수 있습니다. 애플리케이션으로 사용자가 문제를 수정하고 메시지를 다시 제출할 수 있습니다.
API 및 프로토콜의 관점에서, 부모 엔터티의 배달하지 못한 편지 작업을 통해 메시지를 제출할 수 있다는 점만 제외하면 DLQ는 다른 큐와 거의 비슷합니다. 또한 TTL(Time to Live)이 확인되지 않으며, DLQ에서 메시지를 배달 못한 편지로 처리할 수 없습니다. 배달 못 한 편지 큐는 피킹 잠금 배달, 수신 및 삭제 및 트랜잭션 작업과 같은 정상적인 작업을 완벽하게 지원합니다.
DLQ는 자동으로 정리되지 않습니다. 사용자가 DLQ에서 명시적으로 메시지를 검색하고 배달 못한 메시지를 완료할 때까지 메시지는 DLQ에 남아 있습니다.
배달 못한 편지 큐의 경로
다음 구문을 사용하여 배달 못한 편지 큐에 액세스할 수 있습니다.
<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue
.NET에서는 FormatDeadLetterPath 메서드를 사용할 수 있습니다.
QueueClient.FormatDeadLetterPath(queuePath)
SubscriptionClient.FormatDeadLetterPath(topicPath, subscriptionName)
DLQ 메시지 수
토픽 수준에서 배달 못 한 편지 큐의 메시지 수를 가져오는 것은 메시지가 토픽 수준에 있지 않기 때문에 적용할 수 없습니다. 대신 발신기에서 토픽에 메시지를 보낼 때 메시지는 수 밀리초 내에 해당 토픽에 대한 구독에 전달되므로 더 이상 토픽 수준에 있지 않습니다. 따라서 DLQ에서 해당 토픽의 구독과 연결된 메시지를 볼 수 있습니다. 다음 예에서는 Service Bus Explorer에서 "test1" 구독에 대한 62개의 메시지가 현재 DLQ에 있음을 보여 줍니다.
또한 az servicebus topic subscription show Azure CLI 명령을 사용하여 DLQ 메시지 수를 가져올 수도 있습니다.
DLQ로 메시지 이동
Service Bus의 여러 활동에 의해 메시징 엔진 자체 내에서 DLQ로 메시지가 푸시됩니다. 또한 애플리케이션이 명시적으로 메시지를 DLQ로 이동시킬 수 있습니다. 다음 두 가지 속성(배달 못한 편지 이유 및 배달 못한 편지 설명)이 배달 못한 편지 메시지에 추가됩니다. 애플리케이션에서 배달 못한 편지 이유 속성에 대한 고유의 코드를 정의할 수는 있지만, 시스템에서 다음 값을 설정합니다.
| 배달 못한 편지 이유 | 배달 못한 편지 오류 설명 |
|---|---|
HeaderSizeExceeded |
이 스트림의 크기 할당량이 한도를 초과했습니다. |
TTLExpiredException |
메시지가 만료되어 배달 못 한 편지로 처리되었습니다. 자세한 내용은 Time to Live 섹션을 참조하세요. |
Session ID is null; |
세션이 활성화된 엔터티가 세션 식별자가 null인 메시지를 허용하지 않습니다. |
MaxTransferHopCountExceeded |
큐 간에 전달할 때 허용되는 최대 홉 수가 한도를 초과했습니다. 이 값은 4로 설정됩니다. |
MaxDeliveryCountExceeded |
최대 배달 시도 후에는 메시지를 사용할 수 없습니다. 자세한 내용은 최대 배달 횟수 섹션을 참조하세요. |
TTL(Time to Live)
큐 또는 구독에서 배달 못한 편지 설정을 사용할 경우 모든 만료된 메시지가 DLQ로 이동합니다. 데드레터 이유 코드는 TTLExpiredException으로 설정되었습니다. 지연된 메시지는 만료된 후에도 제거되지 않고 데드레터 큐로 이동됩니다. 이 동작은 의도된 것입니다.
최대 배달 횟수
Service Bus 큐 및 구독에 대한 메시지 배달 시도 횟수에는 제한이 있습니다. 기본값은 10입니다. 메시지가 피킹 잠금 상태로 배달되었지만 명시적으로 중단되었거나 잠금이 만료될 때마다 메시지의 배달 수가 증가합니다. 배달 수가 제한을 초과하면 메시지가 DLQ로 이동됩니다. DLQ의 메시지에 대한 데드레터 이유는 MaxDeliveryCountExceeded로 설정됩니다. 이 동작을 사용하지 않도록 설정할 수 없지만 최대 배달 횟수를 큰 값으로 설정할 수 있습니다.
구독 규칙을 처리하는 동안 오류 발생
필터 평가 예외에서 배달 못한 편지 설정을 사용할 경우 구독의 SQL 필터 규칙이 실행되는 동안 발생하는 모든 오류가 잘못된 메시지와 함께 DLQ에 캡처됩니다. 구독자가 없는 토픽으로 전송되는 메시지 유형이 있는 프로덕션 환경에서는 이 옵션을 사용하지 마세요. 이로 인해 DLQ 메시지가 많이 로드될 수 있습니다. 따라서 토픽에 전송된 모든 메시지에 하나 이상의 일치하는 구독이 있는지 확인합니다.
애플리케이션 수준에서 배달 못 한 편지 처리
시스템에서 제공하는 배달 못 한 편지 처리 기능 외에도 애플리케이션에서 DLQ를 사용하여 허용할 수 없는 메시지를 명시적으로 거부할 수 있습니다. 여기에는 모든 종류의 시스템 문제로 인해 제대로 처리할 수 없는 메시지, 잘못된 페이로드가 포함된 메시지 또는 메시지 수준 보안 체계가 사용될 때 인증에 실패한 메시지가 포함될 수 있습니다.
.NET에서는 ServiceBusReceiver.DeadLetterMessageAsync 메서드를 호출하여 수행할 수 있습니다.
메시지가 데드레터링되는 문제의 원인을 더 쉽게 해결할 수 있도록 DeadLetterReason에 예외 형식을 포함하고 DeadLetterDescription에 예외의 스택 추적을 포함하는 것이 좋습니다. 일부 메시지는 Azure Service Bus의 표준 계층에 대한 256KB 할당량 한도를 초과할 수 있습니다. Service Bus 네임스페이스를 표준 계층에서 프리미엄 계층 업그레이드하여 더 높은 할당량 및 한도를 가질 수 있습니다.
자동 전달 시나리오의 데드레터링
메시지는 다음 조건에서 데드레터 큐로 전송됩니다.
- 메시지는 모두 체인으로 연결된 4개를 초과하는 큐 또는 토픽을 통과합니다.
- 대상 큐 또는 항목은 사용되지 않도록 설정되거나 삭제됩니다.
- 대상 큐 또는 항목이 최대 엔터티 크기를 초과합니다.
시나리오를 통한 전송 시 데드레터링
- 대상 큐 또는 항목이 사용하지 않도록 설정된 경우 메시지는 원본 큐의 전송 데드레터 큐(TDLQ)로 전송됩니다.
- 대상 큐 또는 엔터티가 엔터티 크기를 초과하는 경우 메시지는 원본 큐의 TDLQ로 전송됩니다.
배달 못한 편지 메시지를 다시 처리하도록 보내기
메시지를 배달 못 한 편지로 만든 문제를 해결하면 메시지를 다시 처리할 큐 또는 토픽에 다시 제출할 수 있습니다.
Azure Service Bus Explorer 같은 도구를 사용하면 큐와 토픽 간에 메시지를 수동으로 이동할 수 있습니다. 배달 못한 편지 큐에 이동해야 하는 메시지가 많은 경우 모두 한 번에 이동하는 데 이와 같은 코드가 유용할 수 있습니다. 운영자는 어떤 메시지 유형이 어떤 소스 대기열에서 어떤 이유로 처리에 실패했는지 문제를 해결할 수 있도록 사용자 인터페이스를 사용하는 것을 선호하는 한편, 재처리할 메시지의 일괄 처리를 여전히 다시 제출할 수 있습니다. NServiceBus를 사용하는 ServicePulse와 같은 도구는 이러한 기능을 제공합니다.
관련 콘텐츠
큐 또는 구독에 배달 못한 편지 사용에서 메시지 만료 시 배달 못한 편지 설정의 다양한 구성 방법에 대해 알아보세요.