메시지 큐 솔루션 선택

Storage 큐와 Service Bus 큐에는 약간 다른 기능 집합이 있습니다. 특정 솔루션의 요구 사항에 따라 둘 중 하나 또는 둘 다를 선택할 수 있습니다.

주어진 솔루션의 목적에 어떤 큐 기술이 적합한지 결정할 때, 솔루션 설계자와 개발자는 이러한 권장 사항을 고려해야 합니다.

Service Bus 큐 사용 고려

솔루션 설계자/개발자라면 다음과 같은 경우 Service Bus 큐를 사용하는 것을 고려해야 합니다.

솔루션이 큐를 폴링하지 않고도 메시지를 수신할 수 있어야 하는 경우. Service Bus를 사용하면 Service Bus에서 지원하는 TCP 기반 프로토콜을 사용한 긴 폴링 수신 작업을 통해 달성할 수 있습니다.
솔루션에서 큐가 보장된 FIFO(선입선출) 순차적 전달을 제공해야 하는 경우.
솔루션에서 자동 중복 검색을 지원할 수 있어야 하는 경우.
애플리케이션이 메시지를 병렬 장기 실행 스트리밍으로 처리하려고 합니다(메시지는 메시지의 세션 ID 특성을 사용하여 스트리밍과 연관됨). 이 모델에서는 소비 애플리케이션의 각 노드가 메시지가 아니라 스트림에 대해 경쟁합니다. 소비 노드에 스트림이 전달되면 해당 노드는 트랜잭션을 사용하여 애플리케이션 스트림 상태를 검사할 수 있습니다.
큐에서 여러 메시지를 송신 또는 수신할 경우 솔루션에 트랜잭션 동작 및 원자성이 필요합니다.
애플리케이션은 64KB를 초과할 수 있는 메시지를 처리하지만 선택한 서비스 계층에 따라 256KB 또는 1MB 제한에 접근할 가능성은 없습니다(Service Bus 큐는 최대 100MB의 메시지를 처리할 수 있음).
큐에 대한 역할 기반 액세스 모델, 보낸 사람과 받는 사람에 대해 서로 다른 권한을 제공해야 하는 조건을 처리해야 합니다.

솔루션 설계자/개발자라면 다음과 같은 경우 Storage 큐의 사용을 고려해야 합니다.

애플리케이션은 80GB보다 많은 메시지는 큐에 저장해야 합니다.
애플리케이션에서 큐 내부의 메시지 처리 진행률을 추적하려는 경우. 이는 작업자가 메시지 충돌을 처리하는 경우에 유용합니다. 그러면 다른 작업자가 해당 정보를 사용하여 이전 작업자가 중단한 부분부터 작업을 계속할 수 있습니다.
큐에 대해 실행된 모든 트랜잭션의 서버 측 로그가 필요합니다.