이 페이지가 유용했습니까?
이 콘텐츠에 대한 여러분의 의견은 중요합니다. 의견을 알려주십시오.
추가 의견
1500자 남음
큐, 항목 및 구독
Collapse the table of content
Expand the table of content

서비스 버스 큐, 토픽 및 구독

업데이트 날짜: 2015년 5월

Microsoft Azure 서비스 버스는 안정적인 메시지 큐와 지속형 게시/구독 메시징을 포함하는 클라우드 기반의 메시지 지향 미들웨어 기술 집합을 지원합니다. 이러한 "조정된" 메시징 기능은 게시-구독, 임시 분리 및 서비스 버스 메시징 패브릭을 사용한 부하 분산 시나리오를 지원하는 비동기 또는 분리된 메시징 기능으로 간주될 수 있습니다. 분리된 통신에는 많은 장점이 있습니다. 예를 들어 클라이언트와 서버가 필요에 따라 연결하고 비동기 방식으로 작업을 수행할 수 있습니다.

서비스 버스에서 조정된 메시징 기능의 핵심을 구성하는 메시징 엔터티는 , 토픽/구독, 규칙/작업이벤트 허브입니다.

큐는 하나 이상의 경합하는 소비자에게 선입 선출(FIFO) 메시지 전달을 제공합니다. 즉, 메시지는 대개 큐에 추가된 임시 순서로 수신자에 의해 수신 및 처리되며 각 메시지는 메시지 소비자 하나에 의해서만 수신 및 처리됩니다. 큐를 사용하는 경우의 주요 이점은 응용 프로그램 구성 요소를 "일시적으로 분리"할 수 있다는 것입니다. 다시 말해서, 메시지가 큐에 지속적으로 저장되므로 생산자(보낸 사람)와 소비자(받는 사람)가 메시지를 동시에 보내고 받을 필요가 없습니다. 또한 생산자가 메시지를 계속해서 처리하고 보내기 위해 소비자의 회신을 기다릴 필요가 없습니다.

이와 관련된 이점으로 생산자와 소비자가 서로 다른 속도로 메시지를 보내고 받을 수 있도록 하는 "부하 평준화"가 있습니다. 많은 응용 프로그램에서 시스템 부하는 시간에 따라 다르지만 각 작업 단위에 필요한 처리 시간은 일반적으로 일정합니다. 큐를 사용하여 메시지 생산자와 소비자를 조정할 경우 최대 부하 대신 평균 부하만 처리할 수 있도록 소비 응용 프로그램을 프로비전하면 됩니다. 수신 부하가 변경됨에 따라 큐의 깊이가 증가하고 축소됩니다. 따라서 응용 프로그램 부하를 제공하는 데 필요한 인프라의 크기와 관련하여 비용이 직접적으로 절약됩니다. 부하가 증가하면 큐에서 읽을 작업자 프로세스가 더 추가될 수 있습니다. 각 메시지는 하나의 작업자 프로세스를 통해서만 처리됩니다. 또한 이 끌어오기 기반 부하 분산에서는 작업자 컴퓨터가 최대 속도로 메시지를 끌어올 때 처리 능력이 다른 경우에도 작업자 컴퓨터의 최적 사용이 가능합니다. 일반적으로 이 패턴을 "경쟁 소비자" 패턴이라고 합니다.

큐를 사용한 메시지 생산자와 소비자 조정은 구성 요소 간의 기본적인 느슨한 결합을 제공합니다. 생산자와 소비자가 서로 인식하지 못하므로 생산자에 영향을 주지 않고 소비자를 업그레이드할 수 있습니다.

큐를 만드는 작업은 여러 단계로 이루어진 프로세스입니다. 서비스 버스 메시징 엔터티(큐 및 토픽)에 대한 관리 작업은 서비스 버스 네임스페이스의 기준 주소와 사용자 자격 증명을 제공하여 생성된 Microsoft.ServiceBus.NamespaceManager 클래스를 통해 수행됩니다. NamespaceManager는 메시징 엔터티를 만들고 열거 및 삭제하는 메서드를 제공합니다. 발급자 이름 및 공유 키를 통한 Microsoft.ServiceBus.TokenProvider 개체와 서비스 네임스페이스 관리 개체를 만든 후 Microsoft.ServiceBus.NamespaceManager.CreateQueue(Microsoft.ServiceBus.Messaging.QueueDescription) 메서드를 사용하여 큐를 만들 수 있습니다. 예를 들면 다음과 같습니다.

// Create management credentials
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(IssuerName, IssuerKey);
// Create namespace client
namespaceManager namespaceClient = new namespaceManager(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials);

서비스 버스 URI를 인수로 사용하여 큐 개체와 메시징 팩터리를 만들 수 있습니다. 예를 들면 다음과 같습니다.

QueueDescription myQueue;
myQueue = namespaceClient.CreateQueue("TestQueue");
MessagingFactory factory = MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", ServiceNamespace, string.Empty), credentials); 
QueueClient myQueueClient = factory.CreateQueueClient("TestQueue");

그런 다음 메시지를 큐에 보낼 수 있습니다. 예를 들어 MessageList라는 조정된 메시지 목록이 있는 경우 코드는 다음과 같습니다.

for (int count = 0; count < 6; count++)
{
    var issue = MessageList[count];
    issue.Label = issue.Properties["IssueTitle"].ToString();
    myQueueClient.Send(issue);
}

다음과 같이 큐에서 메시지를 받을 수 있습니다.

while ((message = myQueueClient.Receive(new TimeSpan(hours: 0, minutes: 0, seconds: 5))) != null)
    {
        Console.WriteLine(string.Format("Message received: {0}, {1}, {2}", message.SequenceNumber, message.Label, message.MessageId));
        message.Complete();

        Console.WriteLine("Processing message (sleeping...)");
        Thread.Sleep(1000);
    }

ReceiveAndDelete 모드에서는 수신 작업이 1단계입니다. 즉, 서비스 버스가 요청을 받으면 메시지를 사용되는 것으로 표시하고 응용 프로그램에 반환합니다. ReceiveAndDelete 모드는 가장 간단한 모델이며, 응용 프로그램이 실패할 경우 메시지를 처리하지 않아도 안전한 시나리오에서 가장 효과적입니다. 이해를 돕기 위해 소비자가 수신 요청을 실행한 후 처리하기 전에 크래시되는 시나리오를 고려해 보세요. 서비스 버스가 메시지를 사용되는 것으로 표시하기 때문에 응용 프로그램이 다시 시작되고 메시지 사용을 다시 시작할 때 크래시 전에 사용된 메시지는 누락됩니다.

PeekLock 모드에서는 수신 작업이 2단계이며, 메시지가 누락되면 안 되는 응용 프로그램을 지원할 수 있습니다. 서비스 버스가 요청을 받으면 사용할 다음 메시지를 찾아 다른 소비자가 수신할 수 없도록 잠근 다음 응용 프로그램에 반환합니다. 응용 프로그램은 메시지 처리를 완료하거나 나중에 처리하기 위해 안정적으로 저장한 후 받은 메시지에 대해 Microsoft.ServiceBus.Messaging.BrokeredMessage.Complete를 호출하여 수신 프로세스의 두 번째 단계를 완료합니다. 서비스 버스에 Complete가 표시되면 메시지를 사용되는 것으로 표시합니다.

응용 프로그램이 어떤 이유로든 메시지를 처리할 수 없는 경우 수신된 메시지에 대해 Complete 대신 Microsoft.ServiceBus.Messaging.BrokeredMessage.Abandon 메서드를 호출할 수 있습니다. 그러면 서비스 버스에서 메시지를 잠금 해제하여 동일한 소비자나 다른 완료 소비자가 다시 수신할 수 있게 합니다. 두 번째로, 잠금과 관련된 시간 제한이 있으며 잠금 시간 제한이 만료되기 전에 응용 프로그램이 메시지를 처리할 수 없는 경우(예: 응용 프로그램이 크래시되는 경우) 서비스 버스에서 메시지를 잠금 해제하여 다시 수신할 수 있게 합니다.

응용 프로그램이 메시지를 처리한 후 Complete 요청이 실행되기 전에 크래시될 경우 응용 프로그램이 다시 시작되면 메시지가 다시 배달됩니다. 일반적으로 이를 최소 한 번 이상 처리라고 합니다. 즉, 각 메시지가 최소 한 번 이상 처리됩니다. 그러나 특정 상황에서는 동일한 메시지가 다시 배달될 수 있습니다. 중복 처리가 허용되지 않는 시나리오에서는 응용 프로그램에 중복 항목을 검색하는 추가 논리가 필요합니다. 배달 시도 간에 일정하게 유지되는 메시지의 MessageId 속성을 사용하면 중복 항목을 검색할 수 있습니다. 일반적으로 이를 정확히 한 번 처리라고 합니다.

메시지를 만들고 큐로 보내거나 큐에서 메시지를 보내는 방법에 대한 자세한 내용과 예제는 서비스 버스 조정된 메시징 .NET 자습서를 참조하세요.

단일 소비자가 각 메시지를 처리하는 큐와 반대로 토픽 및 구독은 "게시/구독" 패턴으로 일대다 형식의 통신을 제공합니다. 받는 사람 수가 많을 경우 크기를 조정하는 데 유용하며, 토픽에 등록된 각 구독이 게시된 각 메시지를 사용할 수 있습니다. 메시지는 구독 단위로 설정할 수 있는 필터 규칙에 따라 항목으로 전송되고 하나 이상의 연결된 구독으로 배달됩니다. 구독은 추가 필터를 사용하여 받을 메시지를 제한할 수 있습니다. 메시지가 큐에 전송될 때와 동일한 방식으로 토픽에 전송되지만 토픽에서 직접 메시지를 받지는 않습니다. 대신 구독에서 메시지를 받습니다. 토픽 구독은 토픽에 전송된 메시지의 복사본을 받는 가상 큐와 유사합니다. 큐에서 받는 것과 동일한 방식으로 구독에서 메시지를 받습니다.

비교를 위해 큐의 메시지 전송 기능은 토픽에 직접 매핑되고 메시지 수신 기능은 구독에 매핑됩니다. 이는 특히 이 섹션의 앞부분에서 큐에 대해 설명한 것과 동일한 패턴(경쟁 소비자, 임시 분리, 부하 평준화 및 부하 분산)을 구독이 지원함을 의미합니다.

이전 섹션의 예제에 표시된 대로 토픽을 만드는 작업은 큐와 유사합니다. 서비스 URI를 만든 후 NamespaceManager 클래스를 사용하여 네임스페이스 클라이언트를 만듭니다. 그런 다음 Microsoft.ServiceBus.NamespaceManager.CreateTopic(System.String) 메서드를 사용하여 토픽을 만들 수 있습니다. 예를 들면 다음과 같습니다.

TopicDescription dataCollectionTopic = namespaceClient.CreateTopic("DataCollectionTopic");

원하는 대로 구독을 추가합니다.

SubscriptionDescription myAgentSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Inventory");
SubscriptionDescription myAuditSubscription = namespaceClient.CreateSubscription(myTopic.Path, "Dashboard");

그런 다음 토픽 클라이언트를 만듭니다. 예를 들면 다음과 같습니다.

MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider);
TopicClient myTopicClient = factory.CreateTopicClient(myTopic.Path)

메시지 보낸 사람을 사용하여 이전 섹션에 표시된 대로 메시지를 토픽에 보내고 토픽에서 메시지를 받을 수 있습니다. 예를 들면 다음과 같습니다.

foreach (BrokeredMessage message in messageList)
{
    myTopicClient.Send(message);
    Console.WriteLine(
    string.Format("Message sent: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

큐와 마찬가지로 QueueClient 개체 대신 SubscriptionClient 개체를 사용하여 구독에서 메시지를 받습니다. 토픽 이름, 구독 이름 및 (선택적으로) 수신 모드를 매개 변수로 전달하여 구독 클라이언트를 만듭니다. 예를 들어 Inventory 구독을 사용하는 경우 다음과 같습니다.

// Create the subscription client
MessagingFactory factory = MessagingFactory.Create(serviceUri, tokenProvider); 

SubscriptionClient agentSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Inventory", ReceiveMode.PeekLock);
SubscriptionClient auditSubscriptionClient = factory.CreateSubscriptionClient("IssueTrackingTopic", "Dashboard", ReceiveMode.ReceiveAndDelete); 

while ((message = agentSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Inventory...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
    message.Complete();
}          

// Create a receiver using ReceiveAndDelete mode
while ((message = auditSubscriptionClient.Receive(TimeSpan.FromSeconds(5))) != null)
{
    Console.WriteLine("\nReceiving message from Dashboard...");
    Console.WriteLine(string.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
}

Important중요
방법: 서비스 버스 레지스트리에 서비스 게시 항목에 설명된 대로 Microsoft.ServiceBus.ServiceRegistrySettings를 사용하여 서비스 버스에서 서비스를 검색할 수 있도록 할지 여부를 나타냅니다. 서비스가 비공개이면 특정 URI를 알고 있는 개인만 연결할 수 있습니다. 공개이면 모든 사용자가 서비스 버스 계층 구조를 탐색하고 해당 수신기를 찾을 수 있습니다. 그러나 큐, 토픽 및 구독은 서비스 레지스트리를 통해 노출할 수 없습니다.

많은 시나리오에서는 특정 특성을 가진 메시지를 특정 방식으로 처리해야 합니다. 이 작업을 위해 원하는 속성을 가진 메시지를 찾은 다음 해당 속성을 특정 방식으로 수정하도록 구독을 구성할 수 있습니다. 토픽에 전송된 모든 메시지가 서비스 버스 구독에 표시되지만 해당 메시지 중 일부만 가상 구독 큐에 복사할 수 있습니다. 이 작업을 위해 구독 필터를 사용합니다. 이러한 수정을 필터 동작이라고 합니다. 구독을 만들 때 메시지의 속성에 대해 작동하는 필터 식을 제공할 수 있습니다. 이러한 속성에는 시스템 속성(예: Label) 및 응용 프로그램 속성(예: 이전 예제의 StoreName)이 모두 포함됩니다. 이 경우 SQL 필터 식은 선택 사항입니다. SQL 필터 식이 없으면 구독에 정의된 모든 필터 동작이 해당 구독의 모든 메시지에 대해 수행됩니다.

이전 예제를 사용하여 Store1에서 들어오는 메시지만 필터링하려면 다음과 같이 Dashboard 구독을 만듭니다.

namespaceManager.CreateSubscription("IssueTrackingTopic", "Dashboard", new SqlFilter("StoreName = 'Store1'"));

이 구독 필터를 적용하면 StoreName 속성이 Store1로 설정된 메시지만 Dashboard 구독의 가상 큐에 복사됩니다.

가능한 필터 값에 대한 자세한 내용은 Microsoft.ServiceBus.Messaging.SqlFilterMicrosoft.ServiceBus.Messaging.SqlRuleAction 클래스에 대한 설명서를 참조하세요. 또한 조정된 메시징: 고급 필터 샘플을 참조하세요.

이벤트 허브는 이벤트 수집기 서비스이며 낮은 대기 시간과 높은 안정성으로 이벤트 및 원격 분석 수신을 Azure에 대량으로 제공하는 데 사용됩니다. 이 서비스를 다른 다운스트림 서비스와 함께 사용할 경우 응용 프로그램 계측, 사용자 환경 또는 워크플로 처리 및 IoT(사물 인터넷) 시나리오에서 특히 유용합니다.

이벤트 허브는 메시지 스트리밍 구문으로, 큐 및 토픽과 유사하게 표시될 수도 있지만 전혀 다른 특성을 갖습니다. 예를 들어 이벤트 허브는 스트리밍 기능이 아니라 기존의 조정된 메시징 기능인 메시지 TTL, 배달 못 한 편지, 트랜잭션 또는 승인을 제공하지 않습니다. 이벤트 허브는 분할, 순서 유지, 스트림 재생 등 다른 스트림 관련 기능을 제공합니다.

참고 항목

표시:
© 2015 Microsoft