영업: 1-800-867-1380

서비스 버스 항목 및 구독을 사용하는 응용 프로그램 만들기

업데이트 날짜: 2015년 2월

Microsoft Azure 서비스 버스는 안정적인 메시지 큐와 지속형 게시/구독 메시징을 포함하는 클라우드 기반의 메시지 지향 미들웨어 기술 집합을 지원합니다. 이 문서는 Service Bus 큐를 사용하는 응용 프로그램 만들기에서 제공하는 정보를 기반으로 작성되었으며, 서비스 버스 항목이 제공하는 게시/구독 기능을 소개합니다. 이 문서에서 서비스 버스의 모든 기능에 대해 다루는 것은 아니지만 이 기능을 사용하기 시작하는 데 충분한 정보를 제공합니다.

이 문서에서는 Service Bus 큐를 사용하는 응용 프로그램 만들기에서 사용하던 소매점 시나리오를 계속 사용합니다. 이 시나리오에서는 개별 POS(Point of Sale) 터미널의 판매 데이터를 재고 관리 시스템으로 라우팅하여 해당 데이터로 재고를 보충해야 하는 시기를 확인합니다. 각 POS 터미널은 DataCollectionQueue 큐에 메시지를 보내 판매 데이터를 보고합니다. 이러한 메시지는 아래에 나와 있는 것처럼 재고 관리 시스템에서 수신할 때까지 큐에 유지됩니다.

Service-Bus1

이 시나리오를 보다 구체화하기 위해 새로운 요구 사항이 시스템에 추가되었습니다. 즉, 소매점 소유주가 매장 실적을 실시간으로 모니터링하고자 합니다.

이 요구 사항을 처리하려면 시스템이 판매 데이터 스트림을 전송해야 합니다. POS 터미널에서 보내는 각 메시지는 이전처럼 재고 관리 시스템으로 계속 전송하되, 각 메시지의 다른 복사본을 사용하여 소매점 소유자에게 대시보드 보기를 제공하고자 합니다.

여러 당사자가 각 메시지를 사용해야 하는 이러한 상황에서는 서비스 버스 항목 기능을 사용할 수 있습니다. 항목은 게시되는 각 메시지를 항목에 등록된 하나 이상의 구독이 사용할 수 있는 게시/구독 패턴을 제공합니다. 반면 큐를 사용하는 경우에는 단일 소비자가 각 메시지를 받습니다.

메시지는 큐로 전송되는 것과 같은 방식으로 항목에 전송되지만 항목에서 직접 수신되지는 않으며 구독에서 수신됩니다. 항목에 대한 구독은 항목에 전송되는 메시지의 복사본을 받는 가상 큐라고 볼 수 있습니다. 메시지는 큐에서 수신되는 것과 같은 방식으로 구독에서 수신됩니다.

시나리오로 돌아가서 먼저 항목의 큐를 제거한 다음 재고 관리 시스템 구성 요소에서 사용할 구독을 추가합니다. 그러면 시스템이 다음과 같이 표시됩니다.

Service-Bus2

위의 구성은 이전의 큐 기반 디자인과 동일하게 작동합니다. 즉, 항목으로 전송되는 메시지는 재고 구독으로 라우팅되며 이 구독에서 재고 관리 시스템이 해당 메시지를 사용합니다.

관리 대시보드를 지원하려면 다음과 같이 항목에 두 번째 구독을 만들어야 합니다.

Service-Bus3

이 구성에서는 대시보드재고 구독에서 모두 POS 터미널의 각 메시지를 사용할 수 있습니다.

서비스 버스 계정을 신청하고 서비스 네임스페이스를 만드는 방법은 Service Bus 큐를 사용하는 응용 프로그램 만들기에 설명되어 있습니다. 서비스 버스 서비스 네임스페이스를 사용하려면 응용 프로그램이 서비스 버스 어셈블리(구체적으로는 Microsoft.ServiceBus.dll)를 참조해야 합니다. 서비스 버스 종속성을 참조하는 가장 쉬운 방법은 서비스 버스 Nuget 패키지를 설치하는 것입니다. 이 어셈블리는 .NET용 Azure 클라이언트 라이브러리에서 Azure SDK의 일부분으로도 제공됩니다. 다운로드는 Azure SDK 다운로드 페이지에서 제공됩니다.

서비스 버스 메시징 엔터티(큐 및 게시/구독 항목)에 대한 관리 작업은 NamespaceManager 클래스를 통해 수행됩니다. 서비스 버스에서는 Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)를 사용하여 구현되는 클레임 기반 보안 모델을 사용합니다. 특정 서비스 네임스페이스에 대한 NamespaceManager 인스턴스를 만들려면 적절한 자격 증명이 필요합니다. TokenProvider 클래스는 몇 가지 잘 알려진 토큰 공급자를 반환하는 기본 제공 팩터리 메서드로 보안 토큰 공급자를 나타냅니다. 여기서는 CreateSharedAccessSignatureTokenProvider 메서드를 사용하여 SAS(공유 액세스 서명) 자격 증명을 저장합니다. 그런 다음 서비스 버스 서비스 네임스페이스 및 토큰 공급자의 기준 주소로 NamespaceManager 인스턴스를 구성합니다.

NamespaceManager 클래스는 메시징 엔터티를 만들고, 열거하고, 삭제하는 메서드를 제공합니다. 여기에 표시된 코드 조각은 NamespaceManager 인스턴스를 만든 다음 DataCollectionTopic 항목을 만드는 데 사용하는 방법을 보여 줍니다.

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "RootManageSharedAccessKey";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

항목의 속성을 설정하는 데 사용할 수 있는 CreateTopic 메서드의 오버로드가 있습니다. 예를 들어 항목으로 보낸 메시지에 대해 기본 TTL(Time-To-Live) 값을 설정할 수 있습니다. 그런 다음 재고대시보드 구독을 추가합니다.

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

예를 들어 메시지 보내기 및 받기와 같은 서비스 버스 엔터티의 런타임 작업을 위해 응용 프로그램은 먼저 MessagingFactory 개체를 만들어야 합니다. NamespaceManager 클래스와 마찬가지로 MessagingFactory 인스턴스는 서비스 네임스페이스 및 토큰 공급자의 기준 주소로 만듭니다.

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

서비스 버스 항목으로 보내거나 항목에서 받은 메시지는 BrokeredMessage 클래스의 인스턴스입니다. 이 클래스는 표준 속성 집합(예: LabelTimeToLive), 응용 프로그램 속성을 저장하는 데 사용되는 사전 및 임의 응용 프로그램 데이터의 본문으로 구성됩니다. 응용 프로그램은 직렬화된 개체(다음 예제에서는 POS 터미널의 판매 데이터를 나타내는 SalesData 개체를 전달)를 전달하여 본문을 설정할 수 있으며, DataContractSerializer를 사용하여 개체를 직렬화합니다. 또는 Stream을 제공할 수 있습니다.

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

항목으로 메시지를 보내는 가장 간단한 방법은 CreateMessageSender를 사용하여 MessagingFactory 인스턴스에서 직접 MessageSender 개체를 만드는 것입니다.

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

큐를 사용할 때와 마찬가지로 구독에서 메시지를 받는 가장 간단한 방법은 CreateMessageReceiver를 사용하여 MessagingFactory에서 직접 만들 수 있는 MessageReceiver 개체를 사용하는 것입니다. Service Bus 큐를 사용하는 응용 프로그램 만들기에서 설명하는 것처럼 두 가지 수신 모드(ReceiveAndDeletePeekLock) 중 하나를 사용할 수 있습니다.

구독에 대해 MessageReceiver를 만들 때 entityPath 매개 변수는 topicPath/subscriptions/subscriptionName 형식입니다. 그러므로 DataCollectionTopic 항목의 재고 구독에 대해 MessageReceiver를 만들려면 entityPathDataCollectionTopic/subscriptions/Inventory여야 합니다. 해당 코드는 다음과 같이 표시됩니다.

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

지금까지 이 문서에서 항목에 전송된 모든 메시지는 등록된 모든 구독에서 사용할 수 있게 되었습니다. 여기서 핵심 문구는 "사용할 수 있게 되었다"입니다. 서비스 버스 구독은 항목에 전송된 모든 메시지를 볼 수는 있지만 해당 메시지 중 일부만을 가상 구독 큐에 복사할 수 있습니다. 구독 필터를 사용하여 이 작업을 수행합니다. 구독을 만들 때는 메시지의 속성에 대해 작동하는 SQL92 스타일 조건자 형식의 필터 식을 제공할 수 있습니다. 이러한 속성에는 시스템 속성(예: Label) 및 응용 프로그램 속성(예: 이전 예제의 StoreName)이 모두 포함됩니다.

이 기능을 설명하기 위해 소매점 시나리오에 두 번째 매장을 추가하여 시나리오를 확장합니다. 두 매장의 모든 POS 터미널에서 생성되는 판매 데이터는 중앙의 재고 관리 시스템으로 계속 라우팅해야 합니다. 그러나 대시보드 도구를 사용하는 매장 관리자는 해당 매장의 실적만 확인하고자 합니다. 이러한 경우 구독 필터링을 사용할 수 있습니다. POS 터미널은 메시지를 게시할 때 메시지에 대해 StoreName 응용 프로그램 속성을 설정합니다. 매장이 RedmondSeattle의 두 개라고 가정할 때 Redmond 매장의 POS 터미널은 StoreName=Redmond로 판매 데이터 메시지를 스탬프 처리하는 반면 Seattle 매장의 POS 터미널은 StoreName=Seattle을 사용합니다. Redmond 매장의 매장 관리자는 해당 매장 POS 터미널의 데이터만 확인하고자 합니다. 이 경우 시스템은 다음과 같이 표시됩니다.

Service-Bus4

이러한 라우팅을 설정하려면 다음과 같이 대시보드 구독을 만듭니다.

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

이 구독 필터를 적용하면 StoreName 속성이 Redmond로 설정된 메시지만 대시보드 구독의 가상 큐로 복사됩니다. 구독 필터링은 다른 방식으로도 폭넓게 활용할 수 있습니다. 응용 프로그램은 메시지가 구독 가상 큐를 통과할 때 메시지 속성을 수정하는 기능에 대해 구독을 추가할 때마다 여러 필터 규칙을 적용할 수 있습니다.

이 문서에서는 서비스 버스에 도입된 항목 기반 게시/구독 기능 사용을 시작하는 방법을 살펴보았습니다.

Service Bus 큐를 사용하는 응용 프로그램 만들기에서 설명한 큐를 사용해야 하는 모든 이유가 항목에도 적용됩니다. 구체적으로 설명하자면 다음과 같습니다.

  • 일시적 분리 - 메시지 생산자와 소비자가 동시에 온라인 상태일 필요가 없습니다.

  • 부하 평준화 - 항목을 통해 최고 부하가 아닌 평균 부하에 맞게 소비 응용 프로그램을 프로비전하여 대량의 부하를 원활하게 평준화할 수 있습니다.

  • 부하 분산 - 큐와 마찬가지로 여러 경합 소비자가 단일 구독에서 수신하도록 하고 각 메시지를 소비자 중 하나에만 전달하여 부하를 분산할 수 있습니다.

  • 느슨한 결합 - 새 소비자를 추가하기 위해 구독을 추가하거나 항목에 대한 필터를 변경하는 등 기존 끝점에 영향을 주지 않고도 메시징 네트워크를 개선할 수 있습니다.

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2015 Microsoft