Azure Service Bus 문제 해결 가이드

아티클
07/17/2024

이 문서에서는 Azure Service Bus를 사용할 때 나타날 수 있는 몇 가지 문제에 대한 문제 해결 팁 및 권장 사항을 설명합니다.

연결 문제

서비스에 연결하는 중 시간 초과

호스트 환경 및 네트워크에 따라 연결 문제는 ServiceTimeout의 Reason으로 인한 TimeoutException, OperationCanceledException 또는 ServiceBusException으로 애플리케이션에 나타날 수 있으며 이 문제는 클라이언트가 서비스에 대한 네트워크 경로를 찾을 수 없을 때 가장 자주 발생합니다.

문제 해결 방법:

클라이언트를 만들 때 지정한 연결 문자열 또는 정규화된 도메인 이름이 올바른지 확인합니다. 연결 문자열을 가져오는 방법에 대한 자세한 내용은 Service Bus 연결 문자열 가져오기를 참조하세요.
호스팅 환경에서 방화벽 및 포트 권한을 확인합니다. AMQP(고급 메시지 큐 프로토콜) 포트 5671 및 5672가 열려 있고 방화벽을 통해 엔드포인트가 허용되는지 확인합니다.
포트 443을 통해 연결하는 웹 소켓 전송 옵션을 사용해 보세요. 자세한 내용은 전송 구성을 참조하세요.
네트워크에서 특정 IP 주소를 차단하고 있는지 확인합니다. 자세한 내용은 허용해야 하는 IP 주소는 무엇인가요?를 참조하세요.
해당하는 경우 프록시 구성을 확인합니다. 자세한 내용은 전송 구성을 참조하세요.
네트워크 연결 문제 해결에 대한 자세한 내용은 [연결, 인증서 또는 시간 초과 문제][#connectivity-certificate-or-timeout-issues]를 참조하세요.

SSL(Secure Socket Layer) 핸드셰이크 오류

이 오류는 가로채는 프록시를 사용할 때 발생할 수 있습니다. 확인하려면 프록시를 사용하지 않도록 설정하고 호스트 환경에서 애플리케이션을 테스트하는 것이 좋습니다.

소켓 고갈 오류

애플리케이션은 Service Bus 유형을 싱글톤으로 처리하고 애플리케이션의 수명 동안 단일 인스턴스를 만들고 사용하는 것을 선호합니다. 새로 만든 각 ServiceBusClient는 소켓을 사용하는 새 AMQP 연결을 생성합니다. ServiceBusClient 유형은 해당 인스턴스에서 만든 모든 유형에 대한 연결을 관리합니다. 각 ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender, ServiceBusProcessor는 연결된 Service Bus 엔터티에 대한 자체 AMQP 링크를 관리합니다. ServiceBusSessionProcessor를 사용하는 경우 동시에 처리되는 세션 수에 따라 여러 AMQP 링크가 설정됩니다.

클라이언트는 유휴 상태일 때 캐시하는 것이 안전합니다. 네트워크, CPU, 메모리 사용을 효율적으로 관리하여 비활성 기간 동안 미치는 영향을 최소화합니다. 또한 네트워크 리소스가 제대로 정리되었는지 확인하기 위해 클라이언트가 더 이상 필요하지 않을 때 CloseAsync 또는 DisposeAsync를 호출해야 합니다.

연결 문자열에 구성 요소를 추가하면 작동하지 않음

Service Bus 클라이언트 라이브러리의 현재 세대는 Azure Portal에서 게시한 양식에서만 연결 문자열을 지원합니다. 연결 문자열은 기본 위치와 공유 키 정보만 제공하기 위한 것입니다. 클라이언트의 동작 구성은 해당 옵션을 통해 수행됩니다.

Service Bus 클라이언트의 이전 세대는 연결 문자열에 키/값 구성 요소를 추가하여 일부 동작을 구성할 수 있었습니다. 이러한 구성 요소는 더 이상 인식되지 않으며 클라이언트 동작에 영향을 주지 않습니다.

"TransportType=AmqpWebSockets" 대체

웹 소켓을 전송 유형으로 구성하려면 전송 구성을 참조하세요.

"Authentication=Managed Identity" 대체

관리 ID를 사용하여 인증하려면 ID 및 공유 액세스 자격 증명을 참조하세요. Azure.Identity 라이브러리에 대한 자세한 내용은 인증 및 Azure SDK를 참조하세요.

로깅 및 진단

Service Bus 클라이언트 라이브러리는 .NET EventSource를 사용하여 정보를 내보내는 다양한 수준의 세부 정보로 정보를 로깅하기 위해 완벽하게 계측됩니다. 로깅은 각 작업에 대해 수행되며 작업의 시작점, 완료, 발생한 예외를 표시하는 패턴 다음에 기록됩니다. 인사이트를 제공할 수 있는 추가 정보는 연결된 작업의 컨텍스트에도 기록됩니다.

로깅 사용

Service Bus 클라이언트 로그는 Azure-Messaging-ServiceBus로 시작하는 원본을 옵트인하거나 AzureEventSource 특성이 있는 모든 원본으로 옵트인하여 EventListener에서 확인할 수 있습니다. Azure 클라이언트 라이브러리에서 로그를 보다 쉽게 캡처할 수 있도록 Service Bus에서 사용하는 Azure.Core 라이브러리는 AzureEventSourceListener를 제공합니다.

자세한 내용은 .NET용 Azure SDK로 로깅을 참조하세요.

분산 추적

Service Bus 클라이언트 라이브러리는 Application Insights SDK와 통합하여 분산 추적을 지원합니다. 또한 .NET 5에 도입된 .NET ActivitySource 유형을 통해 OpenTelemetry 사양에 대한 실험적 지원을 제공합니다. OpenTelemetry에서 사용할 수 있도록 ActivitySource 지원을 활성화하려면 ActivitySource 지원을 참조하세요.

GA DiagnosticActivity 지원을 사용하려면 Application Insights SDK와 통합하면 됩니다. 자세한 내용은 Azure Monitor를 사용하는 ApplicationInsights를 확인하세요.

라이브러리에서 다음 범위를 만듭니다.

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

대부분의 범위는 따로 설명이 필요없으며 해당 이름이 있는 작업 중에 시작 및 중지됩니다. 다른 사용자를 연결하는 범위는 Message입니다. 메시지가 추적되는 방식은 보내기 및 예약 작업 중에 라이브러리에서 ServiceBusMessage.ApplicationProperties 속성에 설정된 Diagnostic-Id를 통해 수행됩니다. Application Insights에서 Message 범위는 메시지와 상호 작용하는 데 사용된 다양한 다른 범위(예: ServiceBusReceiver.Receive 범위, ServiceBusSender.Send 범위, ServiceBusReceiver.Complete 범위)로 표시되며 해당 범위는 모두 Message 범위에서 연결됩니다. Application Insights의 예제는 다음과 같습니다.

샘플 분산 추적을 보여 주는 이미지입니다.

위의 스크린샷에는 포털의 Application Insights에서 볼 수 있는 엔드투엔드 트랜잭션이 표시됩니다. 이 시나리오에서 애플리케이션은 메시지를 보내고 ServiceBusSessionProcessor를 사용하여 메시지를 처리합니다. Message 작업은 ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage, ServiceBusReceiver.Complete에 연결됩니다.

참고 항목

자세한 내용은 Service Bus 메시징을 통한 분산 추적 및 상관 관계를 참조하세요.

송신기 문제 해결

여러 파티션 키를 사용하여 일괄 처리로 보낼 수 없음

앱이 파티션 사용 엔터티에 일괄 처리로 보내는 경우 단일 전송 작업에 포함된 모든 메시지에는 동일한 PartitionKey가 있어야 합니다. 엔터티가 세션 사용이 가능한 경우 SessionId 속성에 대해 동일한 요구 사항이 적용됩니다. 여러 PartitionKey 값 또는 SessionId 값이 있는 메시지를 보내려면 별도의 ServiceBusMessageBatch 인스턴스에서 메시지를 그룹화하거나 ServiceBusMessage 인스턴스 집합을 사용하는 SendMessagesAsync 오버로드에 대한 각 호출에 메시지를 포함합니다.

일괄 처리로 보내지 못함

메시지 일괄 처리는 둘 이상의 메시지가 포함된 ServiceBusMessageBatch 또는 둘 이상의 메시지가 전달되는 SendMessagesAsync에 대한 호출입니다. 서비스에서는 1MB를 초과하는 메시지를 일괄 처리로 보낼 수 없습니다. 이 동작은 프리미엄 대용량 메시지 지원 기능을 사용할 수 있는지 여부에 관계없이 적용됩니다. 1MB보다 큰 메시지를 보내려면 다른 메시지와 그룹화하지 않고 개별적으로 보내야 합니다. 크키는 서비스에 의해 제한되고 변경될 수 있으므로 아쉽게도 ServiceBusMessageBatch 유형은 현재 일괄 처리에 1MB보다 큰 메시지가 포함되어 있지 않은지 확인하는 기능을 지원하지 않습니다. 따라서 프리미엄 대용량 메시지 지원 기능을 사용하려는 경우 1MB가 넘는 메시지는 개별적으로 보내야 합니다.

수신기 문제 해결

반환된 메시지 수가 일괄 처리 수신에서 요청된 수와 일치하지 않음

일괄 처리 수신 작업을 시도할 때, 즉 ReceiveMessagesAsync 메서드에 2개 이상의 maxMessages 값을 전달하는 경우, 큐 또는 구독에 해당 시점에 사용할 수 있는 메시지가 많거나 구성된 전체 maxWaitTime이 아직 경과되지 않았더라도 요청된 메시지 수를 받을 수 있다는 보장이 없습니다. 처리량을 최대화하고 잠금 만료를 방지하기 위해 첫 번째 메시지가 유선으로 전달되면 수신기는 처리할 메시지를 디스패치하기 전에 추가 메시지를 20밀리초 더 기다립니다. maxWaitTime은 수신기가 첫 번째 메시지를 받기 위해 대기하는 시간을 제어합니다. 후속 메시지는 20밀리초 동안 대기됩니다. 따라서 애플리케이션에서 사용 가능한 메시지를 호출 한 번으로 모두 받는다고 가정해서는 안 됩니다.

잠금 만료 시간 전에 메시지 또는 세션 잠금이 손실됨

Service Bus 서비스는 상태 저장인 AMQP 프로토콜을 사용합니다. 프로토콜의 특성으로 인해 메시지를 받은 후 클라이언트와 서비스를 연결하는 링크는 분리되지만 메시지가 합의되기 전에 링크를 다시 연결할 때는 메시지를 합의할 수 없습니다. 링크가 분리되는 이유는 단기 일시적인 네트워크 오류나 네트워크 중단으로 인해 또는 서비스에 10분 유휴 시간 제한이 적용되는 경우입니다. 링크 다시 연결은 링크가 필요한 작업, 즉 메시지 해결 또는 수신 과정으로 자동 수행됩니다. 이 경우 잠금 만료 시간이 아직 경과되지 않았어도 MessageLockLost의 Reason으로 인한 ServiceBusException 또는 SessionLockLost를 수신합니다.

예약된 메시지 또는 지연된 메시지를 찾아보는 방법

예약된 메시지와 지연된 메시지는 메시지를 피킹할 때 포함됩니다. 이는 ServiceBusReceivedMessage.State 속성으로 식별할 수 있습니다. 지연된 메시지의 SequenceNumber가 있으면 ReceiveDeferredMessagesAsync 메서드를 통해 잠금 상태로 받을 수 있습니다.

토픽으로 작업하는 경우 큐에 넣기로 예약된 시간까지 메시지가 토픽에 남아 있으므로 구독에서 예약된 메시지를 피킹할 수 없습니다. 이 문제를 해결하려면 해당 메시지를 피킹할 수 있도록 토픽 이름을 전달하는 ServiceBusReceiver를 구성하면 됩니다. 토픽 이름을 사용할 때는 수신기를 사용하는 다른 작업이 작동하지 않습니다.

모든 세션에서 세션 메시지를 찾아보는 방법

일반 ServiceBusReceiver를 사용하여 모든 세션을 피킹할 수 있습니다. 특정 세션을 피킹하기 위해 ServiceBusSessionReceiver를 사용해도 되지만 이러한 경우 세션 잠금을 가져와야 합니다.

메시지 본문에 액세스할 때 NotSupportedException이 throw됨

이 문제는 다른 AMQP 메시지 본문 형식을 사용하는 다른 라이브러리에서 보낸 메시지를 수신할 경우에 interop 시나리오에서 가장 자주 발생합니다. 이러한 유형의 메시지와 상호 작용하는 경우 AMQP 메시지 본문 샘플을 참조하여 메시지 본문에 액세스하는 방법을 알아보세요.

프로세서 문제 해결

자동 잠금 갱신이 수행되지 않음

자동 잠금 갱신은 시스템 시간에 따라 메시지 또는 세션 잠금을 갱신할 시기를 결정합니다. 시스템 시간이 정확하지 않은 경우(예: 시계가 느림) 잠금이 종료되기 전에 잠금이 갱신되지 않을 수 있습니다. 자동 잠금 갱신이 수행되지 않는 경우 시스템 시간이 정확한지 확인합니다.

높은 동시성을 사용할 때 프로세서가 중단되거나 대기 시간 문제가 있는 것으로 보임

이 동작은 특히 세션 프로세서를 사용하고 컴퓨터의 코어 수에 비해 MaxConcurrentSessions에 매우 높은 값을 사용하는 경우 스레드 부족으로 인해 발생하는 경우가 많습니다. 가장 먼저 이벤트 처리기에서 sync-over-async를 수행하지 않는지 확인해야 합니다. sync-over-async는 교착 상태와 스레드 부족을 손쉽게 유발하는 방식입니다. sync-over-async를 수행하지 않더라도 처리기의 순수 동기화 코드로 인해 스레드 부족이 발생할 수 있습니다. 예를 들어 순수한 비동기 코드가 있으므로 문제가 되지 않는다고 판단되면 [TryTimeout][TryTimeout] 값을 늘려볼 수 있습니다. 이는 특히 세션 프로세서를 사용할 때 발생하는 컨텍스트 전환 및 시간 초과 횟수가 줄어들어 스레드 풀에 대한 부담이 완화됩니다. [TryTimeout][TryTimeout]의 기본값은 60초이지만 최대 1시간까지 설정할 수 있습니다. 시작점으로 5분이 설정된 TryTimeout을 사용하여 테스트하고 해당 단계부터 반복하는 것이 좋습니다. 이러한 제안이 모두 효과가 없는 경우, 애플리케이션의 동시성을 줄이면서도 원하는 전체 동시성을 달성하기 위해 여러 호스트에서 애플리케이션을 실행하기 위해 여러 호스트로 스케일 아웃하면 됩니다.

추가 참고 자료:

세션 프로세서에서 세션을 전환하는 데 너무 오래 걸림

이는 포기하고 다른 세션으로 이동하기 전에 세션으로부터 메시지를 받을 때까지 대기해야 하는 시간을 프로세서에 알려주는 [SessionIdleTimeout][SessionIdleTimeout]을 사용하여 구성할 수 있습니다. 이 기능은 각 세션에 몇 개의 메시지만으로 희박하게 채워진 세션이 많은 경우에 유용합니다. 각 세션에 많은 메시지가 흘러들어올 것으로 예상하는 경우 이 값을 너무 낮게 설정하면 세션이 불필요하게 종료되어 생산성이 저하될 수 있습니다.

프로세서가 즉각 중지됨

이 문제는 데모 또는 테스트 시나리오에서 자주 관찰됩니다. StartProcessingAsync는 프로세서가 시작된 직후에 반환됩니다. 이 메서드를 호출해도 프로세서가 실행되는 동안 애플리케이션이 차단되고 활성 상태로 유지되지 않으므로 다른 메커니즘이 필요합니다. 데모 또는 테스트의 경우 프로세서를 시작한 후에 Console.ReadKey() 호출을 추가하는 것으로 충분합니다. 프로덕션 시나리오의 경우 [BackgroundService][BackgroundService]와 같은 일종의 프레임워크 통합을 사용하여 프로세서를 시작하고 삭제하는 데 사용할 수 있는 편리한 애플리케이션 수명 주기 후크를 제공할 수 있습니다.

트랜잭션 문제 해결

Service Bus의 트랜잭션에 대한 전체적인 정보는 [Service Bus 트랜잭션 처리 개요][트랜잭션]을 참조하세요.

지원되는 작업

트랜잭션을 사용할 때 일부 작업은 지원되지 않습니다. 지원되는 트랜잭션 목록을 보려면 [트랜잭션 범위 내의 작업][TransactionOperations]를 참조하세요.

시간 제한

트랜잭션은 [기간][TransactionTimeout]이 지나면 시간 초과되므로 트랜잭션 범위 내에서 수행되는 처리는 이 시간 제한을 준수해야 합니다.

트랜잭션의 작업이 다시 시도되지 않음

이것은 의도적인 것입니다. 다음 시나리오를 고려합니다. 트랜잭션 내에서 메시지를 완료하려고 하지만 일시적인 오류(예: ServiceCommunicationProblem의 Reason으로 인한 ServiceBusException)가 발생합니다. 요청이 실제로 서비스에 전달된다고 가정합니다. 클라이언트가 다시 시도하는 경우 서비스에 두 개의 완료 요청이 표시됩니다. 첫 번째 완료는 트랜잭션이 커밋될 때까지 마무리되지 않습니다. 두 번째 완료는 첫 번째 완료가 마무리되기 전까지 평가할 수도 없습니다. 클라이언트의 트랜잭션이 완료가 마무리되기를 기다리고 있습니다. 이렇게 하면 서비스는 클라이언트가 트랜잭션을 완료하기를 기다리고 있지만 클라이언트는 서비스가 두 번째 완료 작업을 승인하기를 기다리는 교착 상태가 발생합니다. 트랜잭션은 결국 2분 후에 시간이 초과되며 이는 좋지 않은 사용자 환경입니다. 따라서 트랜잭션 내에서 작업을 다시 시도하지 않습니다.

엔터티 간 트랜잭션이 작동하지 않음

여러 엔터티를 포함하는 트랜잭션을 수행하려면 ServiceBusClientOptions.EnableCrossEntityTransactions 속성을 true로 설정해야 합니다. 자세한 내용은 [엔터티 간 트랜잭션][CrossEntityTransactions] 샘플을 참조하세요.

할당량

Service Bus 할당량에 대한 정보는 [여기][ServiceBusQuotas]에서 확인하세요.

연결, 인증서 또는 시간 초과 문제

다음 단계는 *.servicebus.windows.net에 있는 모든 서비스의 연결/인증서/시간 초과 문제를 해결하는 데 유용합니다.

https://<yournamespace>.servicebus.windows.net/으로 이동하거나 wget합니다. Java SDK를 사용할 때 일반적인 IP 필터링, 가상 네트워크 또는 인증서 체인 문제가 있는지 여부를 확인하는 데 도움이 됩니다.

성공 메시지의 예:

<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

실패 오류 메시지의 예:

<Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

다음 명령을 실행하여 방화벽에서 차단된 포트가 있는지 확인합니다. 사용되는 포트는 443(HTTPS), 5671 및 5672(AMQP) 및 9354(Net Messaging/SBMP)입니다. 사용하는 라이브러리에 따라 다른 포트도 사용됩니다. 다음은 5671 포트가 차단되었는지 여부를 확인하는 샘플 명령입니다. C
```
tnc <yournamespacename>.servicebus.windows.net -port 5671
```
Linux:
```
telnet <yournamespacename>.servicebus.windows.net 5671
```
일시적인 연결 문제가 있는 경우 다음 명령을 실행하여 드롭된 패킷이 있는지 확인합니다. 이 명령은 1초마다 서비스와 25개의 서로 다른 TCP 연결을 구축하려고 시도합니다. 그 후 성공/실패 횟수를 확인하고 TCP 연결 대기 시간을 확인할 수도 있습니다. psping 도구를 여기에서 다운로드할 수 있습니다.
```
.\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner     
```
tnc, ping 등과 같은 다른 도구를 사용하는 경우 동등한 명령을 사용할 수 있습니다.
이전 단계가 도움이 되지 않는 경우 네트워크 추적을 가져와서 Wireshark와 같은 도구를 사용하여 분석합니다. 필요한 경우 Microsoft 지원에 문의하세요.
연결 허용 목록에 추가할 올바른 IP 주소를 찾으려면 허용 목록에 추가해야 하는 IP 주소를 참조하세요.

2026년 9월 30일에 Azure Service Bus에 대한 SBMP 프로토콜 지원이 사용 중지되므로 2026년 9월 30일 이후에는 더 이상 이 프로토콜을 사용할 수 없습니다. 해당 날짜 이전에 중요한 보안 업데이트와 개선된 기능을 제공하는 AMQP 프로토콜을 사용하여 최신 Azure Service Bus SDK 라이브러리로 마이그레이션하세요.

자세한 내용은 사용 중지 공지 지원을 참조하세요.

서비스 업그레이드/다시 시작 시 발생할 수 있는 문제

증상

요청이 일시적으로 제한될 수 있습니다.
들어오는 메시지/요청이 끊길 수 있습니다.
로그 파일에 오류 메시지가 포함될 수 있습니다.
몇 초 동안 애플리케이션과 서비스의 연결이 끊어질 수 있습니다.

원인

백 엔드 서비스 업그레이드 및 다시 시작으로 인해 애플리케이션에서 이러한 문제가 발생할 수 있습니다.

해결

애플리케이션 코드에서 SDK를 사용하는 경우 재시도 정책이 이미 기본 제공되며 활성 상태입니다. 애플리케이션/워크플로에 큰 영향 없이 애플리케이션이 다시 연결됩니다.

무단 액세스: 클레임 보내기가 필요합니다.

증상

보내기 권한이 있는 사용자가 할당한 관리 ID를 사용하여 온-프레미스 컴퓨터의 Visual Studio에서 Service Bus 토픽에 액세스하려고 할 때 이 오류가 표시될 수 있습니다.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

원인

ID에 Service Bus 토픽에 액세스할 수 있는 권한이 없습니다.

해결

이 오류를 해결하려면 Microsoft.Azure.Services.AppAuthentication 라이브러리를 설치하세요. 자세한 내용은 로컬 개발 인증을 참조하세요.

역할에 권한을 할당하는 방법을 알아보려면 Microsoft Entra ID에 관리 ID를 인증하여 Azure Service Bus 리소스에 액세스를 참조하세요.

Service Bus 예외: Put 토큰이 실패했습니다.

증상

다음과 같은 오류 메시지가 표시됩니다.

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

2026년 9월 30일에 Azure SDK 지침을 따르지 않는 Azure Service Bus SDK 라이브러리 WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus 및 com.microsoft.azure.servicebus를 사용 중지합니다. 또한 SBMP 프로토콜에 대한 지원이 종료되므로 2026년 9월 30일 이후에는 더 이상 이 프로토콜을 사용할 수 없습니다. 해당 날짜 마이그레이션에 중요한 보안 업데이트와 개선된 기능을 제공하는 최신 Azure SDK 라이브러리로 마이그레이션합니다.

이전 라이브러리는 2026년 9월 30일 이후에도 계속 사용할 수 있지만 더 이상 Microsoft로부터 공식 지원 및 업데이트를 받을 수 없습니다. 자세한 내용은 사용 중지 공지 지원을 참조하세요.

원인

Service Bus 네임스페이스에 대한 단일 연결의 동시 링크에 대한 인증 토큰 수가 한도인 1000을 초과했습니다.

해결

다음 단계 중 하나를 수행합니다.

단일 연결의 동시 링크 수를 줄이거나 새 연결을 사용합니다.
이 상황이 발생하지 않도록 하는 Azure Service Bus에 대한 SDK 사용(권장)

데이터 평면 SDK를 사용할 때 리소스 잠금이 작동하지 않음

증상

Service Bus 네임스페이스에서 삭제 잠금을 구성했지만 Service Bus Explorer를 사용하여 네임스페이스(큐, 토픽 등)의 리소스를 삭제할 수 있습니다.

원인

리소스 잠금은 Azure Resource Manager(컨트롤 플레인)에서 유지되며 데이터 평면 SDK 호출이 네임스페이스에서 직접 리소스를 삭제하는 것을 방지하지 않습니다. 독립 실행형 Service Bus Explorer는 데이터 평면 SDK를 사용하므로 삭제가 진행됩니다.

해결

리소스 잠금으로 인해 리소스가 실수로 삭제되지 않도록 Azure Portal, PowerShell, CLI 또는 Resource Manager 템플릿을 통해 Azure Resource Manager 기반 API를 사용하여 엔터티를 삭제하는 것이 좋습니다.

엔터티를 더 이상 사용할 수 없음

증상

엔터티를 더 이상 사용할 수 없는 오류가 표시됩니다.

원인

리소스가 삭제되었을 수도 있습니다. 다음 단계에 따라 엔터티가 삭제된 이유를 식별합니다.

활동 로그를 확인하여 Azure Resource Manager에서 삭제 요청이 있는지 확인합니다.
운영 로그를 확인하여 삭제를 위한 직접 API 호출이 있는지 확인합니다. 작업 로그를 수집하는 방법에 대한 자세한 내용은 Azure Service Bus 모니터링을 참조하세요. 스키마 및 작업 로그의 예제는 작업 로그를 참조하세요.
작업 로그를 확인하여 autodeleteonidle 관련 삭제가 있는지 확인합니다.

다음 단계

다음 문서를 참조하세요.

Azure Resource Manager 예외. 템플릿 또는 직접 호출을 통해 Azure Resource Manager를 사용하여 Azure Service Bus와 상호 작용할 때 생성되는 예외가 나열되어 있습니다.
메시징 예외 Azure Service Bus용 .NET Framework에서 생성된 예외 목록을 제공합니다.

다음을 통해 공유