Azure Service Bus 문제 해결 가이드

아티클
02/23/2024

이 문서에서는 Azure Service Bus를 사용할 때 표시되는 몇 가지 문제에 대한 문제 해결 팁과 권장 사항을 제공합니다.

연결 문제

서비스에 연결할 때 제한 시간

호스트 환경 및 네트워크에 따라 클라이언트가 서비스에 대한 네트워크 경로를 찾을 수 없을 때 연결 문제가 애플리케이션TimeoutExceptionOperationCanceledException에 존재할 ServiceBusExceptionReasonServiceTimeout 수 있습니다.

문제 해결 방법:

클라이언트를 만들 때 지정한 연결 문자열 또는 정규화된 do기본 이름이 올바른지 확인합니다. 연결 문자열 획득하는 방법에 대한 자세한 내용은 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 및 메모리 사용을 효율적으로 관리하여 비활성 기간 동안 미치는 영향을 최소화합니다. 또한 네트워크 리소스가 CloseAsyncDisposeAsync 제대로 클린 위해 클라이언트가 더 이상 필요하지 않을 때 호출되거나 호출되는 것도 중요합니다.

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

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 하거나 옵트인하여 원본을 옵트인하여 사용할 EventListener 수 있습니다AzureEventSource. Azure 클라이언트 라이브러리에서 로그를 더 Azure.Core 쉽게 캡처할 수 있도록 Service Bus에서 사용하는 라이브러리는 다음을 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의 예제는 다음과 같습니다.

Image showing a sample distributed trace.

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

참고 항목

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

보낸 사람 문제 해결

여러 파티션 키를 사용하여 일괄 처리를 보낼 수 없습니다.

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

Batch를 보내지 못함

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

수신자 문제 해결

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

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

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

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

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

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

토픽을 사용하는 경우 예약된 큐에 넣기 시간이 될 때까지 메시지가 토픽에 다시 기본 구독에서 예약된 메시지를 피킹할 수 없습니다. 해결 방법으로 이러한 메시지를 피킹하기 위해 토픽 이름을 전달하는 ServiceBusReceiver를 생성할 수 있습니다. 토픽 이름을 사용할 때는 받는 사람의 다른 작업이 작동하지 않습니다.

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

일반 ServiceBusReceiver 를 사용하여 모든 세션을 피킹할 수 있습니다. 특정 세션을 피킹하려면 ServiceBusSessionReceiver를 사용할 수 있지만 세션 잠금을 가져와야 합니다.

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

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

프로세서 문제 해결

자동 잠금 갱신이 작동하지 않음

자동 잠금 갱신은 시스템 시간을 사용하여 메시지 또는 세션에 대한 잠금을 갱신할 시기를 결정합니다. 시스템 시간이 정확하지 않은 경우(예: 시계가 느리면 잠금이 손실되기 전에 잠금 갱신이 발생하지 않을 수 있습니다. 자동 잠금 갱신이 작동하지 않는 경우 시스템 시간이 정확한지 확인합니다.

높은 동시성을 사용할 때 프로세서가 중단되거나 대기 시간 문제가 있는 것 같습니다.

이 동작은 특히 세션 프로세서를 사용하고 컴퓨터의 코어 수에 비해 MaxConcurrentSessions에 매우 높은 값을 사용하는 경우 스레드 부족으로 인해 발생하는 경우가 많습니다. 가장 먼저 검사 것은 이벤트 처리기에서 동기화 오버 비동기를 수행하지 않는지 확인하는 것입니다. 동기화 오버 비동기는 교착 상태와 스레드 부족의 원인이 되는 쉬운 방법입니다. 비동기를 통해 동기화를 수행하지 않더라도 처리기의 순수 동기화 코드는 스레드 부족이 발생할 수 있습니다. 예를 들어 순수한 비동기 코드가 있으므로 문제가 되지 않는다고 판단한 경우 [TryTimeout][TryTimeout]을 늘려 볼 수 있습니다. 특히 세션 프로세서를 사용할 때 발생하는 컨텍스트 스위치 및 시간 제한을 줄여 스레드 풀에 대한 압력을 완화합니다. [TryTimeout][TryTimeout]의 기본값은 60초이지만 최대 1시간까지 설정할 수 있습니다. 시작점으로 5분으로 설정한 상태에서 테스트 TryTimeout 하고 여기에서 반복하는 것이 좋습니다. 이러한 제안 중 어느 것도 작동하지 않는 경우 애플리케이션의 동시성을 줄이면서도 원하는 전체 동시성을 달성하기 위해 여러 호스트에서 애플리케이션을 실행하여 여러 호스트로 확장하면 됩니다.

추가 참고 자료:

스레드 풀 고갈 디버그
PerfView를 사용하여 .NET Core 스레드 풀 고갈 진단(내 서비스가 모든 코어를 포화하지 않거나 중단된 것 같은 이유)
.NET Core 앱에서 스레드 풀 고갈 문제 진단(비디오)

세션 프로세서가 세션을 전환하는 데 너무 오래 걸립니다.

이는 세션으로부터 메시지를 받을 때까지 대기하는 시간을 프로세서에 알려주는 [SessionIdleTimeout][SessionIdleTimeout]을 사용하여 구성할 수 있습니다. 이 기능은 각 세션에 몇 개의 메시지만 있는 빈도가 낮은 세션이 많은 경우에 유용합니다. 각 세션에 많은 메시지가 있을 것으로 예상하는 경우 너무 낮게 설정하면 세션이 불필요하게 종료되므로 생산성이 저하될 수 있습니다.

프로세서가 즉시 중지됩니다.

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

트랜잭션 문제 해결

Service Bus의 트랜잭션에 대한 일반적인 내용은 [Service Bus 트랜잭션 처리 개요][트랜잭션]을 참조하세요.

지원되는 작업

트랜잭션을 사용할 때 모든 작업이 지원되는 것은 아닙니다. 지원되는 트랜잭션 목록을 보려면 [트랜잭션 범위 내의 작업][TransactionOperations]을 참조하세요.

시간 제한

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

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

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

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

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

할당량

Service Bus 할당량에 대한 정보는 [여기][ServiceBusQuotas]에서 찾을 수 있습니다.

커넥트성, 인증서 또는 시간 제한 문제

다음 단계는 *.servicebus.windows.net 아래의 모든 서비스에 대한 연결/인증서/시간 제한 문제를 해결하는 데 도움이 됩니다.

이동하거나 wgethttps://<yournamespace>.servicebus.windows.net/합니다. 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     
```
등과 같은 tncping다른 도구를 사용하는 경우 동등한 명령을 사용할 수 있습니다.
이전 단계가 도움이 되지 않는 경우 네트워크 추적을 가져와서 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 예외: 토큰 배치 실패

증상

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

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 호출이 있는지 확인합니다. 운영 로그를 수집하는 방법을 알아보려면 수집 및 라우팅을 참조하세요. 스키마 및 작업 로그의 예제는 작업 로그를 참조하세요.
작업 로그를 확인하여 autodeleteonidle 관련 삭제가 있는지 확인합니다.

다음 단계

다음 문서를 참조하세요.

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