비동기 메시징 패턴 및 고가용성
비동기 메시징은 다양한 방법으로 구현할 수 있습니다. 큐, 토픽 및 구독을 통해 Azure Service Bus는 저장소 및 전달 메커니즘을 통한 비동기 사용을 지원합니다. 일반(동기) 작업에서는 큐 및 토픽에 메시지를 보내고 큐 및 구독에서 메시지를 받습니다. 작성하는 애플리케이션은 항상 사용할 수 있는 이러한 엔터티에 따라 달라집니다. 엔터티 상태가 변경될 때 다양한 상황으로 인해 대부분의 요구를 충족할 수 있는 감소된 기능 엔터티를 제공하는 방법이 필요합니다.
애플리케이션은 일반적으로 비동기 메시징 패턴을 사용하여 다양한 통신 시나리오를 사용하도록 설정합니다. 서비스가 실행되고 있지 않은 경우에도 클라이언트가 서비스에 메시지를 보낼 수 있는 애플리케이션을 빌드할 수 있습니다. 통신의 버스트를 경험한 애플리케이션의 경우 큐는 통신을 버퍼링할 장소를 제공하여 부하를 일정하게 할 수 있습니다. 마지막으로 간단하지만 효과적인 부하 분산 장치를 사용하여 여러 컴퓨터에 메시지를 배포할 수 있습니다.
이러한 엔터티의 가용성을 기본 위해 이러한 엔터티가 지속성 메시징 시스템에 사용할 수 없는 것처럼 보일 수 있는 다양한 방법을 고려합니다. 일반적으로 말해서 다음의 다른 방법으로 작성한 애플리케이션에서 사용할 수 없게 되는 엔터티를 봅니다.
- 메시지를 보낼 수 없습니다.
- 메시지를 받을 수 없습니다.
- 엔터티를 관리할 수 없습니다(엔터티 만들기, 검색, 업데이트 또는 삭제).
- 서비스에 연결할 수 없습니다.
이러한 각 오류에 대해 애플리케이션이 일정 수준의 축소된 기능에서 작업을 계속 수행할 수 있도록 하는 다양한 오류 모드가 있습니다. 예를 들어 메시지를 보낼 수 있지만 받을 수 없는 시스템은 여전히 고객으로부터 주문을 받을 수 있지만 해당 주문을 처리할 수는 없습니다. 이 항목에서는 발생할 수 있는 잠재적인 문제와 해당 문제를 완화하는 방법에 대해 설명합니다. Service Bus는 옵트인해야 하는 여러 가지 완화 방법을 도입했으며, 이 항목에서는 이러한 옵트인 완화의 사용을 제어하는 규칙에 대해서도 설명합니다.
Service Bus의 안정성
메시지 및 엔터티 문제를 처리하는 방법에는 여러 가지가 있으며 이러한 완화의 적절한 사용을 제어하는 지침이 있습니다. 지침을 이해하려면 먼저 Service Bus에서 실패할 수 있는 항목을 이해해야 합니다. Azure 시스템의 설계로 인해 이러한 모든 문제는 수명이 짧은 경향이 있습니다. 높은 수준에서 사용할 수 없는 다양한 원인은 다음과 같이 표시됩니다.
- Service Bus가 종속된 외부 시스템에서 제한합니다. 제한은 스토리지 및 컴퓨팅 리소스와의 상호 작용에서 발생합니다.
- Service Bus가 의존하는 시스템에 대한 문제입니다. 예를 들어 스토리지의 지정된 부분에 문제가 발생할 수 있습니다.
- 단일 하위 시스템의 Service Bus 실패 이 경우 컴퓨팅 노드는 일관성 없는 상태가 될 수 있으며 자체적인 다시 시작해야 하므로 해당 노드가 다른 노드에 부하를 분산하는 데 사용되는 모든 엔터티가 발생합니다. 단기간 동안 차례로 메시지 처리 속도가 느려질 수 있습니다.
- Azure 데이터 센터 내 Service Bus의 오류 이는 시스템이 몇 분 또는 몇 시간 동안 연결할 수 없는 "치명적인 오류"입니다.
참고 항목
스토리지라는 용어는 Azure Storage와 SQL Azure를 모두 의미할 수 있습니다.
Service Bus에는 이러한 문제에 대한 여러 가지 완화 방법이 포함되어 있습니다. 다음 섹션에서는 각 문제 및 해당 완화 방법을 설명합니다.
제한
Service Bus를 사용하면 제한을 통해 협조적인 메시지 속도 관리를 수행할 수 있습니다. 각 개별 Service Bus 노드가 여러 엔터티가 있습니다. 이러한 각 엔터티는 CPU, 메모리, 스토리지 및 기타 패싯 측면에서 시스템에 요구합니다. 패싯이 정의된 임계값을 초과하는 사용을 감지하면 Service Bus는 지정된 요청을 거부할 수 있습니다. 호출자는 서버 사용 중 예외를 수신하고 10초 후에 다시 시도합니다.
완화를 위해 코드는 오류를 읽고 메시지의 재시도를 10초 이상 중지해야 합니다. 오류는 고객 애플리케이션의 조각에 발생할 수 있으므로 각 조각이 재시도 논리를 독립적으로 실행한다고 예상됩니다. 코드는 네임스페이스, 큐 또는 토픽에서 분할을 사용하여 제한될 가능성을 줄일 수 있습니다.
애플리케이션 코드가 제한 문제를 처리하는 방법에 대한 자세한 내용은 제한 패턴에 대한 설명서를 참조하세요.
Azure 종속성 문제
Azure 내의 다른 구성 요소에는 때때로 서비스 문제가 있을 수 있습니다. 예를 들어 Service Bus에서 사용하는 시스템을 업그레이드하는 경우 해당 시스템에서 일시적으로 기능이 감소할 수 있습니다. 이러한 유형의 문제를 해결하기 위해 Service Bus는 정기적으로 완화를 조사하고 구현합니다. 이러한 완화의 부작용이 나타납니다. 예를 들어 스토리지에서 발생하는 일시적인 문제를 처리하려면 Service Bus가 일관되 게 작동하도록 메시지 보내기 작업을 허용하는 시스템을 구현합니다. 완화의 특성으로 인해 보낸 메시지는 영향을 받는 큐 또는 구독에 표시되고 수신 작업을 준비하는 데 최대 15분이 걸릴 수 있습니다. 일반적으로 엔터티에는 대부분 이 문제가 발생하지 않습니다. 그러나 Azure 내 Service Bus의 엔터티 수를 고려할 때 Service Bus 고객의 작은 하위 집합에 대해 이 완화가 필요한 경우가 있습니다.
단일 하위 시스템의 Service Bus 오류
애플리케이션의 경우 Service Bus의 내부 구성 요소가 일치하지 않는 상황이 발생할 수 있습니다. Service Bus가 이를 감지하면 애플리케이션에서 데이터를 수집하여 발생한 문제를 진단합니다. 데이터가 수집되면 애플리케이션은 일관된 상태로 반환하기 위해 다시 시작됩니다. 이 프로세스는 상당히 빠르게 수행되며, 일반적인 가동 중지 시간은 훨씬 짧지만 엔터티를 최대 몇 분 동안 사용할 수 없는 것처럼 보입니다.
이러한 경우 클라이언트 애플리케이션은 시간 제한 예외 또는 메시징 예외를 생성합니다. Service Bus는 자동화된 클라이언트 재시도 논리의 형태로 이 문제에 대한 완화를 포함합니다. 재시도 기간이 소진되고 메시지가 전달되지 않으면 중단 및 재해 처리에 관한 문서에 멘션 다른 항목을 사용하여 탐색할 수 있습니다.
다음 단계
이제 Service Bus에서 비동기 메시징의 기본 사항을 배웠으므로 중단 및 재해 처리에 대한 자세한 내용을 읽어보세요.