Azure Service Bus의 작업 제한
클라우드 네이티브 솔루션에서는 워크로드에 따라 스케일링할 수 있는 무제한 리소스라는 개념을 제공합니다. 이 개념은 온-프레미스 시스템보다 클라우드에 더 잘 맞지만 클라우드에서도 여전히 제한은 존재합니다. 이러한 제한으로 인해 이 문서에 설명된 대로 표준 계층과 프리미엄 계층 모두에서 클라이언트 애플리케이션 요청이 제한 될 수 있습니다.
표준 계층의 제한
Service Bus의 표준 계층은 종량제 가격 책정 모델을 사용하여 다중 테넌트 설정으로 작동합니다. 여기서는 동일한 클러스터의 여러 네임스페이스가 할당된 리소스를 공유합니다. 표준 계층은 개발자 환경, QA 환경 및 처리량이 낮은 프로덕션 시스템에 권장되는 선택입니다.
이전의 Service Bus 제한은 전적으로 리소스 사용률을 기반으로 하는 정교하지 않은 제한 방식이었습니다. 이제는 제한 논리를 구체화하여 리소스를 공유하는 모든 네임스페이스에 예측 가능한 제한 동작을 제공할 수 있습니다.
동일한 리소스를 사용하는 모든 Service Bus 표준 네임스페이스에서 리소스의 공정한 사용 및 배포를 보장하기 위해 Service Bus 표준은 현재 크레딧 기반 제한 논리를 사용합니다.
참고 항목
제한이 Azure Service Bus 또는 클라우드 네이티브 서비스에 새로운 기능이 아니라는 점에 유의해야 합니다.
크레딧 기반 제한에서는 간단히 다중 테넌트 표준 계층 환경에서 다양한 네임스페이스의 리소스 공유 방식을 구체화하여 리소스를 공유하는 모든 네임스페이스의 공평한 사용을 지원합니다.
크레딧 기반 제한이란 무엇인가요?
크레딧 기반 제한에서는 특정 기간에 지정된 네임스페이스에서 수행할 수 있는 작업의 수를 제한합니다. 크레딧 기반 제한 워크플로는 다음과 같습니다.
- 각 기간의 시작 부분에 Service Bus는 각 네임스페이스에 일부 크레딧을 제공합니다.
- 보낸 사람 또는 수신자 클라이언트 애플리케이션에서 수행하는 모든 작업은 이러한 크레딧에 대해 계산되고 사용 가능한 크레딧에서 빼집니다.
- 크레딧을 모두 사용하면 다음 기간이 시작될 때까지 후속 작업이 제한됩니다.
- 다음 기간이 시작될 때 크레딧이 보충됩니다.
크레딧 한도란 무엇인가요?
크레딧 한도는 현재 네임스페이스 기준으로 초당 1000크레딧으로 설정됩니다. 모든 작업이 동일한 비용으로 만들어지는 것은 아닙니다. 각 작업의 크레딧 비용은 다음과 같습니다.
| 연산 | 크레딧 비용 |
|---|---|
데이터 작업(Send, SendAsync, Receive, ReceiveAsync, Peek) |
메시지당 1크레딧 |
관리 작업(큐, 토픽, 구독, 필터에 대한 Create, Read, Update, Delete) |
10크레딧 |
참고 항목
메시지를 토픽에 보내면 각 메시지가 필터를 기준으로 평가된 후 구독에서 사용할 수 있게 됩니다. 각 필터 평가도 크레딧 한도가 적용됩니다(즉, 필터 평가당 1크레딧).
어떻게 할까요? 내가 제한되고 있다는 것을 알고 있습니까?
클라이언트 애플리케이션 요청이 제한되면 클라이언트 애플리케이션은 다음과 같은 서버 응답을 받습니다.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
작업이 제한되지 않도록 하는 방법은 무엇인가요?
공유 리소스를 사용하는 경우 해당 리소스를 공유하는 다양한 Service Bus 네임스페이스 간에 리소스를 공정하게 사용하도록 적용하는 것이 중요합니다. 제한 기능은 단일 워크로드에 스파이크가 발생해도 동일한 리소스의 다른 워크로드가 제한되지 않도록 합니다. 이 문서의 뒷부분에서 멘션 클라이언트 SDK(소프트웨어 개발 키트) 및 기타 Azure PaaS 제품에 기본 재시도 정책이 기본 제공되므로 제한될 위험이 없습니다. 제한된 요청은 지수 백오프를 사용하여 다시 시도되고 결국 크레딧이 보충될 때 진행됩니다.
당연히 일부 애플리케이션은 제한되는 것에 민감할 수 있습니다. 이 경우 현재 Service Bus 표준 네임스페이 스를 프리미엄으로 마이그레이션하는 것이 좋습니다. 마이그레이션하면 Service Bus 네임스페이스에 전용 리소스를 할당하고 워크로드에 스파이크가 발생하는 경우 리소스를 적절하게 스케일 업하여 제한될 가능성을 줄일 수 있습니다. 워크로드가 정상 수준으로 감소하면 네임스페이스에 할당된 리소스를 스케일 다운할 수도 있습니다.
프리미엄 계층의 제한
Service Bus 프리미엄 계층은 메시징 단위를 기준으로 고객의 각 네임스페이스 설정에 전용 리소스를 할당합니다. 전용 리소스는 예측 가능한 처리량과 대기 시간을 제공하므로 처리량이 높거나 민감한 프로덕션 등급 시스템에 사용하는 것이 좋습니다. 또한 프리미엄 계층을 사용하면 워크로드에 스파이크가 발생하는 경우 고객이 처리량 용량을 스케일 업할 수 있습니다. 자세한 내용은 Azure Service Bus 네임스페이스의 메시징 단위 자동 업데이트를 참조하세요.
Service Bus 프리미엄에서 제한은 어떻게 작동하나요?
프리미엄 계층의 전용 리소스 할당을 사용하면 제한은 전적으로 네임스페이스에 할당된 리소스 제한 사항에 따라 작동합니다. 요청 수가 현재 리소스가 서비스할 수 있는 것보다 많으면 요청이 제한됩니다.
어떻게 할까요? 내가 제한되고 있다는 것을 알고 있습니까?
Service Bus 프리미엄 계층에서 제한을 확인하는 방법은 여러 가지가 있습니다.
- Azure Monitor 요청 메트릭에 제한된 요청이 표시되므로 제한된 요청 수를 확인합니다.
- 높은 CPU 사용량은 현재 리소스 할당이 높고 현재 워크로드가 감소하지 않으면 요청이 제한될 수 있음을 나타냅니다.
- 높은 메모리 사용량 은 현재 리소스 할당이 높고 현재 워크로드가 감소하지 않으면 요청이 제한될 수 있음을 나타냅니다.
작업이 제한되지 않도록 하는 방법은 무엇인가요?
Service Bus 프리미엄 네임스페이스에는 이미 전용 리소스가 있으므로 워크로드에서 스파이크가 발생하는(또는 예상되는) 경우 네임스페이스에 할당된 메시징 단위 수를 스케일 업하여 제한될 가능성을 줄일 수 있습니다. 자세한 내용은 Azure Service Bus 네임스페이스의 메시징 단위 자동 업데이트를 참조하세요.
FAQ
제한은 애플리케이션에 어떤 영향을 주나요?
요청이 제한된 경우 리소스에서 허용하는 것보다 요청 수가 더 많으므로 서비스가 사용 중인 상태임을 의미합니다. 동일한 작업을 잠시 후 다시 시도하면 서비스가 현재 워크로드 처리를 완료한 경우 요청에 대응할 수 있습니다.
제한은 모든 클라우드 네이티브 서비스의 예상되는 동작이므로 재시도 논리가 Service Bus SDK 자체에 기본 제공됩니다. 기본값은 매번 동일한 요청이 제한되지 않도록 지수 백오프를 사용하는 자동 재시도로 설정됩니다. 기본 재시도 논리는 모든 작업에 적용됩니다.
참고 항목
다른 타사 서비스를 호출하는 메시지 처리 코드는 해당하는 다른 서비스에 의해서도 제한될 수 있습니다. 이러한 시나리오를 처리하는 방법에 대한 자세한 내용은 제한 패턴에 대한 설명서를 참조하세요.
제한으로 인해 데이터 손실이 발생하나요?
Azure Service Bus는 지속성에 최적화되어 있습니다. 서비스에서 요청의 성공을 승인하기 전에 Service Bus로 전송된 모든 데이터가 스토리지에 커밋되었는지 확인합니다.
Service Bus가 요청을 성공적으로 승인하면 Service Bus가 요청을 성공적으로 처리했음을 나타냅니다. Service Bus가 실패를 반환하면 Service Bus가 요청을 처리하지 못했으며 클라이언트 애플리케이션에서 요청을 다시 시도해야 함을 나타냅니다.
하지만 요청이 제한된 경우에는 서비스가 리소스 제한으로 인해 현재 요청을 수락하고 처리할 수 없음을 나타냅니다. Service Bus가 단지 요청을 확인하지 않았다고 해서 데이터 손실을 나타내는 것은 아닙니다. 이 경우 Service Bus SDK의 기본 재시도 정책을 사용하면 요청이 결국 처리되도록 할 수 있습니다.
관련 콘텐츠
Service Bus 메시징을 사용하는 방법에 대한 자세한 내용 및 예제는 다음에 나오는 고급 항목을 참조하세요.