영업: 1-800-867-1380

비동기 메시징 패턴 및 고가용성

업데이트 날짜: 2014년 9월

비동기 메시징은 다양한 방식으로 구현될 수 있습니다. Microsoft Azure 서비스 버스는 큐, 항목 및 구독(메시징 엔터티로 총칭함)을 사용하여 축적 전송 메커니즘을 통한 비동기 작업을 지원합니다. 일반(동기) 작업에서는 큐와 항목으로 메시지를 보내고 큐와 구독에서 메시지를 받습니다. 작성하는 응용 프로그램에서는 이러한 엔터티를 항상 사용할 수 있어야 합니다. 다양한 상황으로 인해 엔터티 상태가 변경될 때는 대부분의 요구 사항을 충족할 수 있는 제한된 기능 엔터티를 제공하는 방법이 필요합니다.

응용 프로그램은 보통 비동기 메시징 패턴을 사용해 여러 통신 시나리오를 수행할 수 있도록 합니다. 서비스가 실행되고 있지 않을 때도 클라이언트가 서비스에 메시지를 보낼 수 있는 응용 프로그램을 빌드할 수 있습니다. 통신을 많이 수행하는 응용 프로그램의 경우에는 큐를 통해 통신을 버퍼링하면 부하를 평준화할 수 있습니다. 마지막으로, 단순하지만 효율적인 부하 분산 장치를 사용하면 여러 컴퓨터 간에 메시지를 분산시킬 수 있습니다.

이러한 엔터티의 가용성을 유지 관리하려면 지속형 메시징 시스템에서 이러한 엔터티가 사용할 수 없는 상태로 표시될 수 있는 다양한 방식을 고려합니다. 일반적으로 이러한 엔터티는 사용자가 작성하는 응용 프로그램에서 다음과 같은 방식으로 사용할 수 없는 상태로 표시됩니다.

  1. 메시지를 보낼 수 없습니다.

  2. 메시지를 받을 수 없습니다.

  3. 엔터티를 관리할 수 없습니다(엔터티 만들기, 검색, 업데이트 또는 삭제).

  4. 서비스에 연결할 수 없습니다.

이러한 각 오류에는 응용 프로그램이 일정 수준의 제한된 기능으로 작업을 계속 수행할 수 있도록 하는 서로 다른 오류 모드가 있습니다. 예를 들어 시스템에서 메시지를 보낼 수는 있지만 받을 수는 없는 경우 고객의 주문은 계속 받을 수 있지만 해당 주문을 처리할 수는 없습니다. 이 항목에서는 발생 가능한 문제와 해당 문제를 완화하는 방법을 설명합니다. Service Bus에는 문제 발생 시 옵트인(opt in)해야 하는 여러 완화 기능이 도입되었습니다. 이 항목에서는 이러한 옵트인(opt in) 완화 기능 사용을 규정하는 규칙에 대해서도 설명합니다.

메시지 및 엔터티 문제는 여러 가지 방식으로 처리할 수 있으며 이러한 완화 기능의 적절한 사용을 규정하는 지침이 있습니다. 해당 지침을 파악하려면 먼저 Service Bus에서 발생 가능한 오류를 파악해야 합니다. Azure 시스템의 디자인 특성상 이러한 모든 문제는 일시적인 경우가 많습니다. 사용 불가능 상태의 여러 원인은 대략적으로 다음과 같이 표시됩니다.

  • Service Bus가 사용하는 외부 시스템의 제한. 제한은 저장소 및 계산 리소스와의 상호 작용에서 발생합니다.

  • Service Bus가 사용하는 시스템의 문제. 예를 들어 저장소의 지정된 부분에서 문제가 발생할 수 있습니다.

  • 단일 하위 시스템의 Service Bus 오류. 이러한 상황에서는 계산 노드가 일관성 없는 상태가 될 수 있으며 자체적으로 다시 시작되어야 합니다. 그러면 해당 노드에서 처리하는 모든 엔터티가 다른 노드로 부하 분산됩니다. 이로 인해 잠시 동안 메시지 처리 속도가 느려질 수 있습니다.

  • Azure 데이터 센터 내 Service Bus의 오류. 이러한 오류는 기존의 "치명적인 오류"입니다. 이 오류가 발생한 동안에는 몇 분에서 길게는 몇 시간까지 시스템에 연결할 수 없습니다.

note참고
저장소라는 용어는 Azure 저장소와 SQL Azure를 모두 의미할 수 있습니다.

Service Bus에는 위의 문제에 대한 여러 완화 기능이 포함되어 있습니다. 다음 섹션에서는 각 문제 및 개별 완화 기능에 대해 설명합니다.

Service Bus의 제한 기능을 통해 협조적 메시지 속도 관리를 수행할 수 있습니다. 개별 Service Bus 노드에는 여러 엔터티가 들어 있습니다. 이러한 각 엔터티는 CPU, 메모리, 저장소 및 기타 패싯과 관련하여 시스템에서 요청을 합니다. 이러한 패싯의 사용량이 정의된 임계값을 초과하는 것으로 검색되면 Service Bus는 지정된 요청을 거부할 수 있습니다. 이 경우 호출자는 ServerBusyException을 수신하며 10초 후에 다시 시도합니다.

이 오류를 완화하려면 코드가 오류를 읽은 다음 최소 10초 동안 메시지 다시 시도를 중지해야 합니다. 고객 응용 프로그램의 여러 부분에서 오류가 발생할 수 있으므로 각 부분은 독립적으로 다시 시도 논리를 실행합니다. 코드는 큐나 항목에서 파티션을 사용하도록 설정함으로써 제한 가능성을 줄일 수 있습니다.

Azure 내의 다른 구성 요소에서도 서비스 문제가 가끔 발생할 수 있습니다. 예를 들어 Service Bus에서 사용하는 시스템을 업그레이드하는 동안에는 해당 시스템의 기능이 일시적으로 제한될 수 있습니다. 이러한 유형의 문제를 해결하기 위해 Service Bus는 완화 기능을 정기적으로 조사하여 구현합니다. 그러나 이러한 완화 기능의 부작용도 나타납니다. 예를 들어 일시적인 저장소 문제를 처리하기 위해 Service Bus는 메시지 보내기 작업이 일관되게 작동할 수 있도록 하는 시스템을 구현합니다. 그러나 이 완화 기능의 특성상 보낸 메시지가 해당하는 큐나 구독에 표시되고 받기 작업을 위해 준비되려면 최대 15분이 걸릴 수 있습니다. 일반적으로 대부분의 엔터티에서는 이 문제가 발생하지 않습니다. 그러나 Azure 내 Service Bus의 엔터티 수를 고려할 때 일부 소수의 Service Bus 고객에게 이 완화 기능이 필요한 경우도 있습니다.

모든 응용 프로그램에서는 Service Bus의 내부 구성 요소가 일치하지 않는 상황이 발생할 수 있습니다. Service Bus는 이러한 상황을 검색하면 발생한 문제를 진단할 수 있도록 응용 프로그램에서 데이터를 수집합니다. 데이터를 수집하고 나면 응용 프로그램을 일치하는 상태로 되돌리기 위해 다시 시작합니다. 이 프로세스는 비교적 빠르게 수행되며 엔터티가 최대 몇 분까지 사용 불가능 상태로 표시됩니다. 그러나 일반적인 가동 중지 시간은 그보다 훨씬 짧습니다.

이러한 경우 클라이언트 응용 프로그램은 TimeoutException 또는 MessagingException 예외를 생성합니다. Service Bus .NET SDK에는 이 문제에 대한 완화 기능이 자동화된 클라이언트 다시 시도 논리 형태로 포함되어 있습니다. 다시 시도 기간이 지났는데 메시지가 배달되지 않은 경우 쌍을 이룬 네임스페이스 등의 기타 기능을 사용하여 문제를 파악할 수 있습니다. 쌍을 이룬 네임스페이스를 사용하는 경우에는 기타 문제점도 고려해야 합니다. 여기에 대해서는 이 문서의 뒷부분에서 설명합니다.

Azure 데이터 센터에서 발생하는 오류의 가장 흔한 원인은 Service Bus 또는 종속 시스템의 업그레이드 배포 실패입니다. 플랫폼의 성숙도가 높아짐에 따라 이러한 유형의 오류가 발생할 가능성은 감소했습니다. 데이터 센터 오류는 다음과 같은 이유로도 발생할 수 있습니다.

  • 정전(전원 공급 장치 및 출력 없음)

  • 연결(클라이언트와 Azure 간의 인터넷 끊김)

두 가지 경우 모두 자연 재해나 인위적 재해로 인해 문제가 발생했습니다. 이 문제를 해결하고 메시지를 계속 보내려면 쌍을 이룬 네임스페이스를 사용하여 기본 위치를 다시 정상 상태로 만드는 동안 두 번째 위치에 메시지를 보내도록 할 수 있습니다.

쌍을 이룬 네임스페이스 기능은 데이터 센터 내의 Service Bus 엔터티 또는 배포를 사용할 수 없게 되는 시나리오를 지원합니다. 이 이벤트는 자주 발생하지는 않지만 최악의 시나리오를 처리할 수 있도록 분산 시스템을 준비해야 합니다. 일반적으로는 Service Bus가 사용하는 일부 요소에서 일시적인 문제가 발생하면 이 이벤트가 발생합니다. 중단 시간 동안 응용 프로그램 가용성을 유지하려는 Service Bus 사용자는 서로 다른 두 네임스페이스(각기 별도의 데이터 센터에 배치하는 것이 좋음)를 사용하여 메시징 엔터티를 호스트할 수 있습니다. 이 섹션의 나머지 부분에서는 다음과 같은 용어를 사용합니다.

  • 기본 네임스페이스: 응용 프로그램이 보내기 및 작업을 위해 상호 작용하는 네임스페이스입니다.

  • 보조 네임스페이스: 기본 네임스페이스의 백업 역할을 하는 네임스페이스입니다. 응용 프로그램 논리는 이 네임스페이스와는 상호 작용하지 않습니다.

  • 장애 조치(failover) 간격: 응용 프로그램이 기본 네임스페이스에서 보조 네임스페이스로 전환되기 전에 일반적인 오류가 허용되는 시간입니다.

쌍을 이룬 네임스페이스는 보내기 가용성을 지원합니다. 보내기 가용성은 메시지를 보내는 기능을 유지하는 데 주력합니다. 보내기 가용성을 사용하려면 응용 프로그램이 다음 요구 사항을 충족해야 합니다.

  1. 기본 네임스페이스만 메시지를 받습니다.

  2. 지정된 큐/항목으로 보내는 메시지가 다른 순서로 도착할 수 있습니다.

  3. 응용 프로그램에서 세션을 사용하는 경우 다음 사항이 적용됩니다.

    1. 세션 내의 메시지가 다른 순서로 도착할 수 있습니다. 이러한 현상은 정상적인 세션의 기능을 벗어나는 것입니다. 즉, 응용 프로그램이 세션을 사용하여 메시지를 논리적으로 그룹화합니다.

    2. 세션 상태는 기본 네임스페이스에서만 유지됩니다.

  4. 보조 큐가 기본 큐에 모든 메시지를 배달하기 전에 기본 큐가 온라인이 되어 메시지 수락을 시작할 수 있습니다.

이 섹션에서는 API와 API 구현 방법을 설명하고 해당 기능을 사용하는 샘플 코드를 제공합니다. 이 기능을 사용하는 경우 요금이 청구될 수 있습니다.

쌍을 이룬 네임스페이스 기능을 사용하는 경우 MessagingFactory 클래스에 다음과 같은 새 메서드가 포함됩니다.

public Task PairNamespaceAsync(PairedNamespaceOptions options)

작업이 완료되면 네임스페이스 쌍도 완성되어 MessagingFactory를 사용하여 만든 MessageReceiver, QueueClient 또는 TopicClient에 대해 작업을 수행할 수 있도록 준비됩니다. PairedNamespaceOptionsMessagingFactory에서 사용 가능한 여러 쌍 유형의 기본 클래스입니다. 현재 제공되는 유일한 파생 클래스는 보내기 가용성 요구 사항을 구현하는 SendAvailabilityPairedNamespaceOptions 클래스입니다. SendAvailabilityPairedNamespaceOptions에는 서로를 기반으로 작성되는 생성자 집합이 포함되어 있습니다. 매개 변수가 가장 많은 생성자를 확인하면 다른 생성자의 동작을 파악할 수 있습니다.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

이러한 매개 변수의 의미는 다음과 같습니다.

  • secondaryNamespaceManager: PairNamespaceAsync 메서드가 보조 네임스페이스를 설정하는 데 사용할 수 있는 보조 네임스페이스의 초기화된 NamespaceManager 인스턴스입니다. 관리자를 사용하여 네임스페이스의 큐 목록을 가져오며 필요한 백로그 큐가 있는지 확인합니다. 해당 큐가 없는 경우 작성됩니다. NamespaceManager를 사용하려면 Manage 클레임이 포함된 토큰을 만들 수 있어야 합니다.

  • messagingFactory: 보조 네임스페이스의 MessagingFactory 인스턴스입니다. MessagingFactory는 백로그 큐로 메시지를 보내는 데 사용되며 EnableSyphon 속성이 true로 설정되어 있으면 백로그 큐에서 메시지를 받는 데도 사용됩니다.

  • backlogQueueCount: 만들 백로그 큐의 수입니다. 이 값은 1 이상이어야 합니다. 백로그로 메시지를 보낼 때는 이러한 큐 중 하나가 임의로 선택됩니다. 값을 1로 설정하면 큐를 하나만 사용할 수 있습니다. 이러한 경우 해당 백로그 큐 하나에서 오류가 생성되면 클라이언트는 다른 백로그 큐 사용을 시도할 수 없으므로 메시지를 보내지 못할 수 있습니다. 그러므로 이 값을 1보다 큰 값으로 기본값을 10으로 설정하는 것이 좋습니다. 응용 프로그램이 매일 보내는 데이터의 양에 따라 이 값을 더 크거나 작게 변경할 수 있습니다. 각 백로그 큐는 메시지를 5GB까지 포함할 수 있습니다.

  • failoverInterval: 단일 엔터티를 보조 네임스페이스로 전환할 때까지 기본 네임스페이스에서 오류를 허용할 시간입니다. 장애 조치(failover)는 엔터티 단위로 수행됩니다. 단일 네임스페이스의 엔터티가 Service Bus 내의 여러 노드에 있는 경우를 흔히 볼 수 있습니다. 그러므로 엔터티 하나에 오류가 발생한다고 해서 다른 엔터티에도 오류가 발생하는 것은 아닙니다. 이 값을 System.TimeSpan.Zero로 설정하면 일시적이지 않은 첫 번째 오류 발생 직후 보조 네임스페이스로 장애 조치(failover)할 수 있습니다. 장애 조치(failover) 타이머를 트리거하는 오류는 IsTransient 속성이 false인 모든 MessagingException 또는 TimeoutException입니다. UnauthorizedAccessException 등의 기타 예외에서는 장애 조치(failover)가 수행되지 않습니다. 이러한 예외는 클라이언트가 잘못 구성되었음을 나타내기 때문입니다. 올바른 패턴은 10초 동안 기다렸다가 메시지를 다시 보내는 것이므로 ServerBusyException이 발생해도 장애 조치(failover)는 수행되지 않습니다.

  • enableSyphon: 특정 쌍이 보조 네임스페이스에서 기본 네임스페이스로도 메시지를 다시 사이펀해야 함을 나타냅니다. 일반적으로 메시지를 보내는 응용 프로그램에서는 이 값을 false로 설정해야 하고 메시지를 받는 응용 프로그램에서는 이 값을 true로 설정해야 합니다. 메시지 발신자보다 수신자가 더 적은 경우가 많기 때문입니다. 수신자의 수에 따라 단일 응용 프로그램 인스턴스가 사이펀 작업을 수행하도록 선택할 수 있습니다. 여러 수신자를 사용하는 경우 각 백로그 큐에 대해 요금이 청구될 수 있습니다.

코드를 사용하려면 기본 MessagingFactory 인스턴스, 보조 MessagingFactory 인스턴스, 보조 NamespaceManager 인스턴스 및 SendAvailabilityPairedNamespaceOptions 인스턴스를 만듭니다. 다음과 같이 단순한 호출을 사용할 수 있습니다.

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

PairNamespaceAsync 메서드가 반환한 작업이 완료되면 모든 항목이 설정되어 사용할 수 있는 준비가 됩니다. 작업이 반환되기 전에 쌍이 올바르게 작동하도록 하는 데 필요한 백그라운드 작업을 모두 완료하지 않았을 수도 있습니다. 따라서 작업이 반환될 때까지는 메시지 보내기를 시작하면 안 됩니다. 잘못된 자격 증명 등의 오류나 백로그 큐 만들기 오류가 발생하면 작업이 완료된 후에 해당 예외가 throw됩니다. 작업이 반환되면 SendAvailabilityPairedNamespaceOptions 인스턴스에서 BacklogQueueCount 속성을 검사하여 큐가 발견되었거나 작성되었는지 확인합니다. 위의 코드에서 해당 작업은 다음과 같이 표시됩니다.

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

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