내보내기(0) 인쇄
모두 확장

Azure 큐 및 서비스 버스 큐 - 비교 및 대조

업데이트 날짜: 2014년 10월

저자: Valery Mizonov, Seth Manheim 및 Abhishek Lal

참여자: Brad Calder, Jai Haridas, Jason Hogg, Jeff Irwin, Jaganathan Thangavelu, Kartik Paramasivam, Todd Holmquist-Sutherland 및 Ruppert Koch

이 문서에서는 Azure에서 현재 제공하는 두 가지 유형의 큐인 Microsoft Azure 큐와 Microsoft Azure 서비스 버스 큐의 차이점과 비슷한 점을 분석합니다. 이 정보를 사용하면 두 큐를 비교 분석하고 사용자의 요구에 가장 잘 맞는 솔루션을 보다 합리적으로 결정할 수 있습니다.

Microsoft Azure는 두 가지 큐 메커니즘인 Azure 큐Service Bus 큐를 지원합니다.

Azure 큐Azure 저장소 인프라에 포함되어 있고, 단순 REST 기반 Get/Put/Peek 인터페이스 역할을 하며, 서비스 내와 서비스 간에 안정적이고 영구적인 메시징을 제공합니다.

Service Bus 큐는 큐뿐만 아니라 게시/구독, 원격 웹 서비스 및 통합 패턴도 지원하는 더 광범위한 Azure 메시징 인프라에 포함되어 있습니다. 에 대한 자세한 내용은 Service Bus 큐, 항목/구독 및 릴레이는 서비스 버스 메시징 패턴 개요를 참조하세요.

현재는 이 두 기술이 모두 제공되지만 원래는 Azure 큐가 먼저 Azure 저장소 서비스 위에 빌드된 전용 큐 저장소 메커니즘으로 도입되었습니다. 그 후에 광범위한 “조정된 메시징” 인프라 위에 빌드된 Service Bus 큐가 도입되었습니다. 이러한 인프라는 여러 통신 프로토콜, 데이터 계약, 신뢰할 수 있는 도메인 및/또는 네트워크 환경에 걸쳐 있을 수 있는 응용 프로그램 또는 응용 프로그램 구성 요소를 통합하도록 디자인되었습니다.

이 문서에서는 이 두 큐 기술이 각각 제공하는 기능의 동작 및 구현 방식이 어떻게 다른지 설명하는 방식으로 Azure에서 제공하는 이 두 기술을 비교합니다. 또한 이 문서에서는 응용 프로그램 개발 요구에 가장 잘 맞는 기능을 선택하기 위한 지침을 제공합니다.

Azure 큐와 Service Bus 큐는 둘 다 현재 Microsoft Azure에서 제공하는 메시지 큐 서비스의 구현입니다. 이 두 큐는 기능이 크게 다르지 않으므로 특정 솔루션의 요구 사항이나 해결하려는 비즈니스/기술 문제에 따라 둘 중 하나를 선택하거나 둘 다 선택할 수 있습니다.

지정된 솔루션의 목적에 맞는 큐 기술을 결정할 때 솔루션 설계자 및 개발자는 다음과 같은 권장 사항을 고려해야 합니다. 자세한 내용은 다음 섹션을 참조하십시오.

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

  • 응용 프로그램에서 메시지의 수명이 7일 미만인 큐에 80GB의 메시지를 저장해야 하는 경우

  • 응용 프로그램에서 큐 내부의 메시지를 처리하는 작업의 진행 상황을 추적하려고 하는 경우. 이 정보는 메시지를 처리하는 작업자가 충돌할 경우 유용합니다. 이후 작업자는 이 정보를 사용하여 이전 작업자가 종료한 위치에서 작업을 계속할 수 있습니다.

  • 큐에 대해 실행되는 모든 트랜잭션의 서버 쪽 로그가 필요한 경우

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

  • 솔루션에서 큐를 폴링하지 않고도 메시지를 수신할 수 있어야 하는 경우. Service Bus를 사용하는 경우 Service Bus를 지원하는 TCP 기반 프로토콜을 사용하여 긴 폴링 수신 작업을 통해 이렇게 할 수 있습니다.

  • 솔루션에서 FIFO(선입선출) 순서로 메시지를 배달하는 큐를 필요로 하는 경우

  • Azure 및 Windows Server(사설 클라우드)에서 대칭 환경을 원하는 경우 자세한 내용은 TechNet의 Service Bus for Windows Server

  • 솔루션에서 자동 중복 검색을 지원할 수 있어야 하는 경우

  • 응용 프로그램에서 메시지를 병렬 장기 실행 스트리밍으로 처리하기 원하는 경우(메시지는 SessionId 속성을 사용한 스트리밍으로 연결됨). 이 모델에서 사용 중인 응용 프로그램의 각 노드는 메시지와는 반대로 스트리밍을 완료합니다. 스트리밍이 사용 중인 노드에 지정되었을 때 노드는 트랜잭션을 사용하여 응용 프로그램 스트리밍 상태를 조사할 수 있습니다.

  • 큐에서 여러 메시지를 보내고 받을 때 솔루션에 트랜잭션 동작 및 원자성이 필요한 경우

  • 응용 프로그램 관련 작업의 TTL(Time-To-Live) 특성이 7일을 초과할 수 있는 경우

  • 응용 프로그램에서 64KB를 초과할 수 있지만 256KB까지 커질 가능성이 낮은 메시지를 처리하는 경우

  • 큐에 대한 역할 기반 액세스 모델을 제공하고 보낸 사람 및 받는 사람에 대해 서로 다른 권한/사용 권한을 제공하기 위한 요구 사항을 처리하는 경우

  • 큐 크기가 80 GB 이상 커지지 않는 경우

  • AMQP 1.0 표준 기반 메시지 브로커 사용을 원하는 경우. 에 대한 자세한 내용은 AMQP는 Service Bus AMQP 개요를 참조하세요.

  • 큐 기반 지점 간 통신에서 큐에 전송된 일부 또는 모든 메시지의 독립 복사본을 각각 수신하는 추가 받는 사람(구독자)의 원활한 통합을 허용하는 메시지 교환 패턴으로의 최종 마이그레이션을 계획할 수 있는 경우. 나중에 설명된 기능은 원래 Service Bus에서 제공하는 게시/구독 기능을 나타냅니다.

  • 메시징 솔루션에서 추가 인프라 구성 요소를 빌드하지 않고도 “최대 1회” 배달 보증을 지원할 수 있어야 하는 경우

  • 메시지 일괄 처리를 게시 및 사용할 수 있게 되기를 원하는 경우

  • WCF(Windows Communication Foundation)의 .NET Framework 통신 스택과의 완벽한 통합이 필요한 경우

다음 섹션의 표에서는 큐 기능을 논리적으로 그룹화하고 Azure 큐와 Service Bus 큐에서 제공하는 기능을 한 눈에 비교할 수 있습니다.

이 섹션에서는 Microsoft Azure 큐와 Microsoft Azure 서비스 버스 큐에서 제공하는 몇 가지 기본 큐 기능을 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

순서 보증

아니요

자세한 내용은 "추가 정보" 섹션의 첫 번째 참고 항목을 참조하세요.

예 - FIFO(선입선출)

(메시징 세션을 사용하여)

배달 보증

최소 1회

최소 1회

최대 1회

트랜잭션 지원

아니요

(로컬 트랜잭션을 사용하여)

수신 동작

비차단

(새로운 메시지가 발견되지 않을 경우 즉시 완료)

차단(시간 제한 사용/사용 안 함)

(긴 폴링 또는 “Comet 기술” 제공)

비차단

(.NET 관리형 API만 사용하여)

푸시 스타일 API

아니요

OnMessageOnMessage 세션 관리(.NET) API

수신 모드

피킹 및 임대

피킹 및 잠금

수신 및 삭제

단독 액세스 모드

임대 기반

잠금 기반

임대/잠금 기간

30초(기본값)

7일(최대), UpdateMessage API를 사용하여 메시지 임대를 갱신하거나 릴리스할 수 있습니다.

60초(기본값)

RenewLock API를 사용하여 메시지 잠금을 갱신할 수 있습니다.

임대/잠금 세분성

메시지 수준

(각 메시지는 서로 다른 시간 제한 값을 가질 수 있으며 메시지를 처리하는 동안 필요한 경우 UpdateMessage API를 사용하여 업데이트할 수 있음)

큐 수준

(각 큐에 해당 큐의 모든 메시지에 적용되는 잠금 세분성이 있지만 RenewLock API를 사용하여 잠금을 갱신할 수 있음)

일괄 수신

(메시지를 수신할 대 메시지 수를 최대 32개까지 명시적으로 지정)

(암시적으로 프리페치 속성을 사용하도록 설정하거나 트랜잭션을 명시적으로 사용하여)

일괄 전송

아니요

(트랜잭션 또는 클라이언트 쪽 일괄 처리를 사용하여)

  • Azure 큐의 메시지는 보통 FIFO(선입 선출) 방식으로 정렬되지만 순서가 달라지는 경우도 있습니다. 메시지를 처리하는 중에 클라이언트 응용 프로그램이 중단되어 메시지의 가시성 제한 시간 기간이 만료되는 경우를 예로 들 수 있습니다. 가시성 제한 시간이 만료되면 메시지가 큐에 다시 표시되므로 다른 작업자가 해당 메시지를 큐에서 제거할 수 있습니다. 그러면 새로 표시된 메시지가 원래 이 메시지 다음으로 큐에 추가된 메시지 뒤의 위치에 배치될 수 있습니다(나중에 다시 큐에서 제거될 수 있음).

  • 이미 Azure 저장소 Blob나 테이블을 사용하고 있고 큐 사용을 시작했으면 99.9% 가용성이 보장된 것입니다. Service Bus 큐와 함께 Blob 또는 Table을 사용하면 가용성이 낮아집니다.

  • Service Bus 큐의 보증된 FIFO 패턴을 사용하려면 메시징 세션을 사용해야 합니다. Peek & Lock 모드에서 수신한 메시지를 처리하는 동안 응용 프로그램이 충돌할 경우 다음에 큐 받는 사람이 메시징 세션을 허용하면 해당 세션은 TTL(Time-To-Live) 기간이 만료된 후 실패한 메시지로 시작됩니다.

  • Azure 큐는 확장성을 증가하기 위한 응용 프로그램 구성 요소 분리, 오류에 대한 내결함성, 부하 평준화 및 워크플로 프로세스 빌드와 같이 표준 큐 시나리오를 지원하도록 설계되었습니다.

  • Service Bus 큐는 최소 1회 배달 보증을 지원합니다. 또한 세션 상태를 사용하여 응용 프로그램 상태를 저장하고 트랜잭션을 사용하여 자동으로 메시지 수신 및 세션 상태 업데이트를 수행하여 최대 1회 의미 체계도 지원할 수 있습니다. Azure 워크플로 서비스는 이 방법을 사용하여 최대 1회 배달을 보증합니다.

  • Azure 큐는 개발자와 운영 팀을 위해 큐, 테이블 및 BLOB에 걸쳐 균일하고 일관성 있는 프로그래밍 모델을 제공합니다.

  • Service Bus 큐는 단일 큐 컨텍스트에서 로컬 트랜잭션을 지원합니다.

  • Service Bus에서 지원하는 수신 및 삭제 모드를 사용하면 배당 보증 수준은 낮은 대신 메시징 작업 수 및 연결된 비용을 줄일 수 있습니다.

  • Azure 큐는 메시지 임대를 연장할 수 있는 기능과 함께 임대를 제공합니다. 그러면 작업자가 메시지에 대한 짧은 임대를 유지 관리할 수 있습니다. 따라서 작업자가 충돌할 경우 다른 작업자가 메시지를 신속하게 다시 처리할 수 있습니다. 또한 메시지를 처리하는 데 현재 임대 시간보다 더 많은 시간이 필요할 경우 작업자가 메시지에 대한 임대를 연장할 수 있습니다.

  • Azure 큐는 메시지를 큐에 저장하거나 메시지를 큐에서 제거하는 작업에 대해 설정할 수 있는 표시 시간 제한을 제공합니다. 또한 런타임에 다른 임대 값으로 메시지를 업데이트하고 동일한 큐에 있는 여러 메시지에 대한 다양한 값을 업데이트할 수 있습니다. Service Bus 잠금 시간 제한은 큐 메타데이터에 정의되지만 RenewLock 메서드를 호출하여 잠금을 갱신할 수 있습니다.

  • Service Bus의 차단 수신 작업에 대한 최대 시간 제한은 24일입니다. 하지만 REST 기반의 제한 시간은 최대 55초입니다.

  • Service Bus에서 제공하는 클라이언트 쪽 일괄 처리를 사용하면 큐 클라이언트에서 여러 메시지를 단일 전송 작업으로 일괄 처리할 수 있습니다. 일괄 처리는 비동기 전송 작업에만 사용할 수 있습니다.

  • Azure 큐의 200TB 한계(계정을 가상화하면 그 이상) 및 제한 없는 큐와 같은 기능으로 SaaS 공급자에게 이상적인 플랫폼이 되었습니다.

  • Azure 큐는 유연하고 적절하게 위임된 액세스 제어 메커니즘을 수행합니다.

이 섹션에서는 Azure 큐와 Service Bus 큐에서 제공하는 고급 기능을 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

예약된 배달

자동 배달 못 한 편지 처리

아니요

큐 TTL(time-to-live) 값 증가

(표시 시간 제한의 내부 업데이트를 통해)

(전용 API 함수를 통해 제공됨)

포이즌 메시지 지원

내부 업데이트

서버 쪽 트랜잭션 로그

아니요

저장소 메트릭

분 메트릭: 가용성, TPS, API 호출 횟수, 오류 개수 등에 대한 실시간 통계를 제공합니다(생산과 관련해 어떤 일이 일어났는지 분 단위로 집계하여 몇 분 내에 보고). 자세한 내용은 TechNet의 저장소 분석 통계 정보

(GetQueues 호출로 인한 대량 쿼리)

상태 관리

아니요

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

메시지 자동 전달

아니요

큐 비우기 기능

아니요

메시지 그룹

아니요

(메시징 세션을 사용하여)

메시지 그룹당 응용 프로그램 상태

아니요

중복 검색

아니요

(보낸 사람 쪽에서 구성 가능)

WCF 통합

아니요

(기본 WCF 바인딩 제공)

WF 통합

사용자 지정

(사용자 지정 WF 작업을 빌드해야 함)

네이티브

(기본 WF 작업 제공)

메시지 그룹 찾아보기

아니요

ID로 메시지 세션 가져오기

아니요

  • 두 큐 기술을 사용해 메시지를 나중에 전달하도록 예약할 수 있습니다.

  • 큐 자동 전달 기능을 사용하면 수천 개의 큐에 있는 메시지를 하나의 큐에 자동으로 전달하거나 메시지를 사용하는 수신 응용 프로그램에서 자동으로 전달할 수 있습니다. 각 메시지 게시자 간의 저장소를 보안, 흐름 제어 및 격리하는 데 이 메커니즘을 사용할 수 있습니다.

  • Azure 큐는 메시지 콘텐츠 업데이트를 지원합니다. 이 기능을 사용하면 메시지를 처음부터 처리하는 것이 아니라 마지막으로 알려진 검사점부터 처리할 수 있도록 상태 정보 및 증분 진행률 업데이트를 메시지에 유지할 수 있습니다. Service Bus 큐로 메시지 세션을 통해 동일한 시나리오를 사용할 수 있습니다. 세션을 사용하여 응용 프로그램 처리 상태를 저장하고 검색할 수 있습니다(SetStateGetState 사용).

  • Service Bus 큐에서만 지원되는 배달 못 한 편지 처리를 사용하면 수신 응용 프로그램에서 성공적으로 처리할 수 없는 메시지나 만료된 TTL(Time-To-Live) 속성으로 인해 대상에 도달할 수 없는 메지지를 격리할 수 있습니다. TTL 값은 메시지가 큐에 유지되는 시간을 지정합니다. Service Bus를 사용할 경우 TTL 기간이 만료되면 메시지가 $LetterQueue라고 하는 특수 큐로 이동합니다.

  • Azure 큐에서 "포이즌" 메시지를 찾기 위해 메시지를 큐에서 제거할 때 응용 프로그램은 메시지의 DequeueCount 속성을 검사합니다. DequeueCount가 지정된 임계값보다 클 경우 응용 프로그램은 메시지를 정의된 “배달 못 한 편지” 큐로 이동합니다.

  • Azure 큐를 사용하면 집계된 메트릭뿐 아니라 큐에 대해 실행된 모든 트랜잭션에 대한 자세한 로그를 볼 수 있습니다. 두 옵션 모두 응용 프로그램에서 Azure 큐를 사용하는 방법을 디버깅 및 이해하는 데 유용합니다. 또한 응용 프로그램 성능을 조정하고 큐 사용 비용을 줄이는 데도 유용합니다.

  • Service Bus에서 지원하는 "메시지 세션"의 개념을 사용하면 특정 논리 그룹에 속한 메시지를 지정된 받는 사람과 연결하고 메시지와 각 받는 사람 간의 세션 선호도를 만들 수 있습니다. Service Bus에서 이 고급 기능을 사용하도록 설정하려면 메시지에서 SessionID 속성을 설정하면 됩니다. 그러면 받는 사람은 특정 세션 ID를 수신 대기하고 지정된 세션 식별자를 공유하는 메시지를 수신할 수 있습니다.

  • Service Bus 큐에서 지원하는 중복 검색 기능은 MessageID 속성의 값을 기반으로 큐 또는 항목에 전송된 중복 메시지를 제거합니다.

이 섹션에서는 적용 가능한 용량 및 할당량 관점에서 Azure 큐와 Service Bus 큐를 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

최대 큐 크기

200TB

(단일 저장소 계정 용량으로 제한됨)

1GB - 80 GB

(큐를 만들고 파티션 사용 시에 정의됨)

최대 메시지 크기

64 KB

(48KB, Base64 인코딩을 사용할 경우)

Azure에서는 큐와 blob를 결합하여 대용량 메시지를 지원합니다. 단일 항목으로 최대 200GB까지 큐에 보관할 수 있습니다.

256 KB

(헤더와 본문 모두 포함, 최대 헤더 크기: 64KB)

최대 메시지 TTL

7일

제한 없음

최대 큐 수

제한 없음

10,000

(서비스 네임스페이스별로 증가시킬 수 있음)

최대 동시 클라이언트 수

제한 없음

제한 없음

(100개의 동신 연결 제한은 TCP 프로토콜 기반 통신에만 적용됨)

  • Azure 큐를 사용할 경우 메시지의 XML 콘텐츠가 안전하지 않으면 해당 메시지를 Base64로 인코딩해야 합니다. 메시지를 Base64로 인코딩하면 사용자 페이로드가 64KB가 아니라 48KB까지만 증가할 수 있습니다.

  • Service Bus 큐를 사용할 경우 큐에 저장되는 각 메시지는 헤더와 본문이라는 두 부분으로 구성됩니다. 메시지의 총 크기는 256KB를 초과할 수 없습니다.

  • 클라이언트가 TCP 프로토콜을 통해 Service Bus 큐와 통신할 때 단일 Service Bus 큐에 대한 최대 동시 연결 수는 100개로 제한됩니다. 이 숫자는 보낸 사람과 받는 사람 간에 공유됩니다. 이 할당량에 도달하면 추가 연결을 위한 이후 요청이 거부되고 호출 코드에서 예외가 수신됩니다. 이 제한은 REST 기반 API를 사용하여 큐에 연결하는 클라이언트에는 적용되지 않습니다.

  • Service Bus는 큐 크기 제한을 강제로 적용합니다. 최대 큐 크기는 큐를 만들 때 지정되며 1GB와 80GB 사이의 값을 지정할 수 있습니다. 큐를 만들 때 설정한 큐 크기 값에 도달하면 추가로 수신되는 메시지가 거부되고 호출 코드에서 예외를 수신합니다. Service Bus의 에 대한 자세한 내용은 할당량은 서비스 버스 할당량를 참조하세요.

  • 단일 Service Bus 서비스 네임스페이스에 10,000개 이상의 큐가 필요한 경우 Azure 팀에 연락하여 이 수를 늘려줄 것을 요청할 수 있습니다. Service Bus에서 큐를 10,000개 이상으로 늘리려면 Microsoft Azure 관리 포털을 사용하여 추가 서비스 네임스페이스를 만들 수도 있습니다.

이 섹션에서는 Azure 큐와 Service Bus 큐에서 제공하는 관리 기능을 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

관리 프로토콜

REST over HTTP/HTTPS

REST over HTTPS

런타임 프로토콜

REST over HTTP/HTTPS

REST over HTTPS

AMQP 1.0 표준(TLS가 포함된 TCP)

.NET 관리형 API

(.NET 관리형 저장소 클라이언트 API)

(.NET 관리되는 브로커 메시징 API)

네이티브 C++

아니요

Java API

PHP API

Node.js API

임의의 메타데이터 지원

아니요

큐 이름 지정 규칙

최대 63자

(큐 이름은 소문자여야 함)

최대 260자

(큐 이름은 대/소문자를 구분하지 않음)

큐 길이 함수 가져오기

(메시지가 삭제되지 않고 TTL 이후에 만료되면 근사값)

(정확한 지정 시간 값)

피킹 함수

  • Azure 큐는 큐 설명에 적용할 수 있는 이름/값 쌍 형식으로 된 임의의 특성을 지원합니다.

  • 두 큐 기술은 메시지를 잠그지 않고도 메시지를 피킹할 수 있는 기능을 제공합니다. 이 기능은 큐 탐색기/브라우저 도구를 구현할 때 유용할 수 있습니다.

  • Service Bus .NET 관리되는 조정된 메시징 API는 REST over HTTP보다 향상된 성능을 제공하기 위해 전이중 TCP 연결을 활용하고 AMQP 1.0 표준 프로토콜을 지원합니다.

  • Azure 큐 이름은 3자에서 63자 사이여야 하고 소문자, 숫자 및 하이픈을 사용할 수 있습니다. 자세한 내용은 TechNet의 큐 및 메타데이터 이름 지정

  • Service Bus 큐 이름은 최대 260자까지 사용할 수 있으며 제한된 이름 규칙보다 작아야 합니다. Service Bus 큐 이름에는 문자, 숫자, 마침표(.), 하이픈(-) 및 밑줄(_)을 사용할 수 있습니다.

이 섹션에서는 성능 관점에서 Azure 큐와 Service Bus 큐를 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

최대 처리량

초당 최대 2,000개의 메시지

(1KB의 메시지가 있는 벤치마크를 기반으로 함)

초당 최대 2,000개의 메시지

(1KB의 메시지가 있는 벤치마크를 기반으로 함)

평균 대기 시간

10ms

(TCP Nagle이 사용하지 않도록 설정됨)

20-25ms

제한 동작

HTTP 503 코드로 거부

(제한된 요청은 청구 가능한 작업으로 처리되지 않음)

예외/HTTP 503으로 거부

(제한된 요청은 청구 가능한 작업으로 처리되지 않음)

  • 하나의 Azure 큐는 초당 최대 2,000개의 트랜잭션을 처리할 수 있습니다. 트랜잭션은 Put, Get 또는 Delete 작업입니다. 단일 메시지를 큐에 전송하는 작업(Put)은 하나의 트랜잭션으로 계산되지만 메시지 수신 작업은 대개 검색 단계(Get)와 큐에서 메시지를 제거하도록 요청하는 단계(Delete)로 이루어집니다. 따라서 성공적인 큐에서 제거 작업은 일반적으로 두 개의 트랜잭션으로 구성됩니다. 일괄 작업에서 여러 메시지를 검색하면 단일 트랜잭션에서 최대 32개의 메시지를 Get할 수 있고 각각 순서대로 Delete되기 때문에 이에 대한 영향을 줄일 수 있습니다. 원활한 처리를 위해 큐를 여러 개 만들 수 있습니다(저장소 계정은 큐 개수 제한 없음).

  • 일반적으로 응용 프로그램이 Azure 큐에 대한 최대 처리량에 도달하면 큐 서비스에서 “HTTP 503 서버 작업 중” 응답이 반환됩니다. 이 경우 응용 프로그램은 지수 백오프 지연을 사용하여 재시도 논리를 트리거해야 합니다.

  • 저장소 계정과 동일한 위치(지역)에 있는 호스팅된 서비스에서 작은 메시지(10KB 미만)를 처리할 때 Azure 큐의 평균 대기 시간은 10밀리초입니다.

  • Azure 큐와 Service Bus 큐는 둘 다 제한하려는 큐에 대한 요청을 거부하는 방식으로 제한 동작을 강제로 적용합니다. 그러나 두 큐 모두 제한된 요청을 청구 가능한 트랜잭션으로 처리하지 않습니다.

  • Service Bus 큐에 대한 벤치마크는 단일 큐에서 크기가 대략 1KB인 메시지를 초당 2,000개까지 처리할 수 있음을 증명했습니다. 처리량을 늘리려면 여러 개의 큐를 사용합니다. Service Bus를 사용한 성능 최적화에 대한 자세한 내용은 Service Bus 조정된 메시징을 사용한 성능 개선 모범 사례를 참조하십시오.

  • Service Bus 큐에 대한 최대 처리량에 도달하면 큐가 제한되었음을 나타내는 ServerBusyException(.NET 관리되는 조정된 메시징 API를 사용하는 경우) 또는 HTTP 503(REST 기반 API를 사용하는 경우) 응답이 큐 클라이언트에 반환됩니다.

이 섹션에서는 Azure 큐와 Service Bus 큐에서 지원하는 인증 및 권한 부여 기능에 대해 설명합니다.

 

비교 기준 Azure 큐 Service Bus 큐

인증

대칭 키

대칭 키

액세스 제어 모델

SAS 토큰을 통해 액세스를 위임합니다.

ACS릍 통한 RBAC

ID 공급자 페더레이션

아니요

  • 이러한 큐에 대한 모든 요청은 인증을 받아야 합니다. 익명 액세스를 사용하는 공개 큐는 지원되지 않습니다. SAS를 사용하면 쓰기 전용 SAS, 읽기 전용 SAS 또는 모든 액세스 권한 SAS를 게시하여 이 시나리오 문제를 해결할 수 있습니다.

  • Azure 큐에서 제공하는 인증 체계를 사용하려면 HMAC(해시 기반 메시지 인증 코드)가 있는 SHA-256 알고리즘을 사용하여 계산되고 Base64 문자열로 인코딩되는 대칭 키를 사용해야 합니다. 각 프로토콜에 대한 자세한 내용은 저장소 계정에 대한 액세스 인증을 참조하세요. Service Bus 큐는 대칭 키를 사용하는 비슷한 모델을 지원합니다. 자세한 내용은 TechNet의 Service Bus의 공유 액세스 서명 인증.

  • Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)에서 지원하는 Service Bus는 세 가지 고유한 역할인 관리자, 보낸 사람, 받는 사람을 제공합니다. Azure 큐는 현재 이러한 역할을 지원하지 않습니다.

  • Service Bus에서는 ACS 통합을 제공하므로 Active Directory(ADFS를 사용하여) 및 Live ID, Google, Facebook, Yahoo 등과 같은 공용 웹 ID 공급자와 페더레이션할 수 있습니다.

이 섹션에서는 비용 관점에서 Azure 큐와 Service Bus 큐를 비교합니다.

 

비교 기준 Azure 큐 Service Bus 큐

큐 트랜잭션 비용

$0.0005

(10,000개의 트랜잭션당)

$0.01

(10,000개의 메시지당)

청구 가능한 작업

모두

보내기/받기만

(기타 작업에 대해 요금을 청구하지 않음)

유휴 트랜잭션

청구 항목

(빈 큐 쿼리도 청구 가능한 트랜잭션으로 계산됨)

청구 항목

(빈 큐에 대한 수신도 청구 가능한 메시지로 간주됨)

저장소 비용

$0.07

(GB/월당)

$0.00

아웃바운드 데이터 전송 비용

$0.12 - $0.19

(지역에 따라 다름)

$0.12 - $0.19

(지역에 따라 다름)

  • 데이터 전송 요금은 지정된 요금 청구 기간 동안 인터넷을 통해 Azure 데이터 센터에서 나가는 총 데이터 양을 기반으로 청구됩니다.

  • 동일한 지역에 위치한 Azure 서비스 간의 데이터 전송에 대해서는 요금이 청구되지 않습니다.

  • 이 문서를 작성하는 당시에는 모든 인바운드 데이터 전송에 대해 요금이 청구되지 않습니다.

  • Service Bus 큐에 대한 메시징 작업을 수행할 때 ACS 트랜잭션의 비용은 많지 않습니다. Service Bus는 메시징 팩터리 개체의 단일 인스턴스당 하나의 ACS 토큰을 획득합니다. 그러면 이 토큰을 약 20분 후 만료될 때까지 다시 사용할 수 있습니다. 따라서 Service Bus의 메시징 작업 볼륨은 이러한 작업을 지원하는 데 필요한 ACS 트랜잭션의 양에 비례하지 않습니다.

  • 긴 폴링을 지원하므로 Service Bus 큐를 사용하면 대기 시간이 짧은 배달이 필요할 때 비용 효율적일 수 있습니다.

note참고
모든 비용은 변경될 수 있습니다. 위의 표에 나온 가격은 이 문서를 작성할 당시의 가격을 반영한 것이므로 현재 제공되는 홍보용 제안이 포함되지 않았습니다. 최신 가격 정보를 보려면 가격 책정 개요 페이지를 참조하십시오.

Azure 큐 또는 Service Bus 큐를 언제 사용할지는 다양한 요인에 의해 결정됩니다. 이러한 요인은 주로 응용 프로그램 및 해당 아키텍처에 대한 개별 요구 사항에 따라 달라질 수 있습니다. 응용 프로그램에서 Microsoft Azure의 핵심 기능을 이미 사용하고 있는 경우, 특히 서비스 간 기본 통신 및 메시징이 필요하거나 80 GB보다 큰 큐가 필요한 경우에는 Azure 큐를 사용할 수 있습니다.

Service Bus 큐는 세션, 트랜잭션, 중복 검색, 자동 배달 못 한 편지 처리 및 지속적인 게시/구독 기능과 같은 다양한 고급 기능을 제공하므로 하이브리드 응용 프로그램을 빌드하거나 응용 프로그램에서 이러한 기능을 필요로 하는 경우 사용할 수 있습니다.

이 문서에서는 먼저 일반적인 권장 사항을 간단히 살펴본 다음 현재 Azure에서 제공하는 각 큐 기술의 기능을 나열하고 비교했습니다. 또한 Azure 큐와 Service Bus 큐의 비슷한 점과 차이점을 이해하는 데 도움이 되도록 이 두 기술의 기능을 기능 그룹별로 나란히 놓고 분석했습니다. 이 두 기술을 더 깊이 이해하면 언제, 어떤 큐 기술을 사용할지를 보다 합리적으로 결정할 수 있습니다.

참고 항목

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2014 Microsoft