다음을 통해 공유


Service Bus 가동 중단 및 재해로부터 애플리케이션을 보호하기 위한 모범 사례

중요 업무용 애플리케이션은 갑작스러운 가동 중단이나 재해가 발생하더라도 계속해서 작동해야 합니다. 데이터 처리 리소스의 치명적인 가동 중단에 대한 복원력은 많은 기업에서 요구하는 사항이며, 경우에 따라 업계 규정에도 필요합니다. 이 문서에서는 잠재적 서비스 가동 중단 또는 재해로부터 Service Bus 애플리케이션을 보호하기 위해 사용할 수 있는 기술을 설명합니다.

Azure Service Bus는 이미 개별 머신의 치명적인 오류에 대한 위험을 분산하거나 데이터 센터 내의 여러 오류 도메인에 걸쳐 있는 클러스터 간에 전체 랙을 분산하고, 그러한 오류가 발생하는 경우 서비스가 보장되는 서비스 수준 내에서 일반적으로 눈에 띄게 중단되지 않고 계속 작동하도록 투명한 오류 감지 및 장애 조치(failover) 메커니즘을 구현합니다.

또한 중단 위험은 물리적으로 분리된 세 개의 시설(가용성 영역)에 추가로 분산되며 데이터 센터의 전체적이고 치명적인 손실에 즉각적으로 대처하기에 충분한 용량이 서비스에 예약되어 있습니다. 가용성 영역 지원과 함께 오류 도메인 내의 모든 활성 Azure Service Bus 클러스터 모델은 심각한 하드웨어 오류와 전체 데이터 센터 시설의 치명적인 손실에 대한 복원력 측면에서 모든 온-프레미스 메시지 broker 제품보다 우수합니다. 그러나 이러한 측정값이 충분히 방어될 수 없는 광범위한 물리적 소멸이 있는 경우에도 매우 많은 상황이 발생할 수 있습니다.

Service Bus 지리적 재해 복구 및 지역 복제 기능은 해당 규모의 재해로부터 쉽게 복구하고, 애플리케이션 구성을 변경하지 않고도 실패한 Azure 지역을 중단하는 데 사용할 수 있도록 설계되었습니다.

중단 및 재해

"중단" 및 "재해" 간의 차이점을 참고하는 것이 중요합니다.

중단은 Azure Service Bus를 일시적으로 사용할 수 없는 것으로, 메시징 저장소와 같은 서비스의 일부 구성 요소나 전체 데이터 센터에 영향을 줄 수 있습니다. 그렇지만 문제가 해결되면 Service Bus가 다시 사용할 수 있는 상태가 됩니다. 일반적으로 중단으로 인해 메시지나 기타 데이터가 손실되지는 않습니다. 구성 요소 오류의 예로 특정 메시지 저장소를 사용할 수 없는 경우를 들 수 있습니다. 데이터센터 범위의 가동 중단으로는 데이터센터의 전원 문제나 잘못된 데이터센터 네트워크 전환을 예로 들 수 있습니다. 가동 중단은 몇 분에서 며칠까지 지속될 수 있습니다. 일부 가동 중단은 일시적인 네트워크 문제로 인해 짧은 연결 오류가 발생합니다.

재해는 Service Bus 클러스터, Azure 지역 또는 데이터 센터의 영구적이거나 장기적인 손실을 의미합니다. 지역 또는 데이터 센터는 다시 사용할 수 있게 될 수도, 그렇지 않을 수도 있고 몇 시간 또는 며칠 동안 중지될 수도 있습니다. 재해의 예로는 화재, 홍수 또는 지진이 있습니다. 영구적 재해는 일부 메시지, 이벤트 또는 기타 데이터의 손실을 발생시킬 수 있습니다. 그러나 대부분의 경우에는 데이터 손실이 없으며 메시지는 데이터 센터를 백업하면 복구할 수 있습니다.

중단 및 재해 방지

프리미엄 계층에 대한 Azure Service Bus에서 지역 재해 복구를 제공하는 두 가지 기능이 있습니다. 먼저 메타데이터(엔터티, 구성, 속성)의 복제를 제공하는 메타데이터 DR(지역 재해 복구)이 있습니다. 둘째, 현재 공개 미리 보기로 제공되는 지역 복제가 있으며 메타데이터와 데이터(메시지 데이터 및 메시지 속성/상태 변경) 자체의 복제를 제공합니다. 지리적 재해 복구 기능을 가용성 영역과 혼동해서는 안 됩니다. 메타데이터 DR 또는 지역 복제인지에 관계없이 두 지역 그래픽 복구 기능은 모두 미국 동부 및 미국 서부와 같은 Azure 지역 간에 복원력을 제공합니다.

가용성 영역은 모든 Service Bus 계층에서 사용할 수 있으며, 지원은 미국 동부와 같은 특정 지역 내에서 복원력을 제공합니다. Microsoft Azure의 재해 복구에 대해 자세히 알아보려면 이 문서를 참조하세요.

고가용성 및 재해 복구 개념은 동일한 지역(가용성 영역을 통해) 내 및 서로 다른 지역(지리적 재해 복구 및 지역 복제를 통해)에서 모두 Azure Service Bus 프리미엄 계층으로 바로 빌드됩니다.

지리적 재해 복구 옵션

지리적 재해 복구

Service Bus 프리미엄 계층은 네임스페이스 수준에서 지리적 재해 복구를 지원합니다. 자세한 내용은 Azure Service Bus 지리적 재해 복구를 참조하세요. 프리미엄 계층에서만 사용할 수 있는 지리적 재해 복구 기능은 메타데이터 재해 복구를 구현하며 주 및 보조 네임스페이스를 사용합니다. 지리적 재해 복구를 사용하면 기본 및 보조 네임스페이스 간에 엔터티의 메타데이터만 복제됩니다.

지역 복제

Service Bus 프리미엄 계층은 네임스페이스 수준에서 지역 복제도 지원합니다. 자세한 내용은 Azure Service Bus 지역 복제(공개 미리 보기)를 참조하세요. 프리미엄 계층에만 사용할 수 있고 현재 공개 미리 보기로 제공되는 지역 복제 기능은 메타데이터 및 데이터 재해 복구를 구현하며 주 및 보조 지역에 의존합니다. 지역 복제를 사용하면 엔터티에 대한 메타데이터와 데이터가 모두 주 및 보조 지역 간에 복제됩니다.

상위 수준의 기능 차이

지리적 재해 복구(메타데이터 DR) 기능은 기본 네임스페이스에서 보조 네임스페이스로 네임스페이스에 대한 메타데이터를 복제합니다. 보조 지역에 대한 일회성 장애 조치(failover)를 지원합니다. 고객이 시작한 장애 조치(failover) 중에 네임스페이스의 별칭 이름이 보조 네임스페이스로 다시 지정되고 페어링이 끊어집니다. 메타데이터 이외의 데이터는 복제되지 않으며 RBAC 할당도 복제되지 않습니다.

지역 복제 기능은 메타데이터와 모든 데이터를 주 지역에서 하나 이상의 보조 지역으로 복제합니다. 고객이 장애 조치(failover)를 수행하면 선택한 보조가 기본이 되고 이전 기본이 보조가 됩니다. 사용자는 원하는 경우 원래의 기본으로 장애 조치(failover)를 다시 수행할 수 있습니다.

가용성 영역

모든 Service Bus 계층은 동일한 Azure 지역 내에서 오류가 없는 위치를 제공하는 가용성 영역을 지원합니다. Service Bus는 메시징 저장소의 복사본 3개(기본 1개와 보조 2개)를 관리합니다. Service Bus는 데이터 및 관리 작업을 위해 3개의 복사본을 모두 동기화된 상태로 유지합니다. 기본 복사본이 실패하는 경우 보조 복사본 중 하나가 가동 중지 시간 없이 기본 복제본으로 승격됩니다. 애플리케이션이 Service Bus에서 일시적인 연결 끊기를 확인하는 경우 SDK의 다시 시도 논리가 자동으로 Service Bus에 다시 연결됩니다.

가용성 영역을 사용하는 경우 메타데이터와 데이터(메시지)가 모두 가용성 영역의 데이터 센터에 복제됩니다.

참고 항목

가용성 영역 지원은 가용성 영역이 있는 Azure 지역에서만 사용할 수 있습니다.

네임스페이스를 만들 때 가용성 영역에 대한 지원(선택한 지역에서 사용할 수 있는 경우)이 네임스페이스에 대해 자동으로 사용하도록 설정됩니다. 이 기능을 사용하는 데 드는 추가 비용은 없으며 네임스페이스를 만든 후에는 이 기능을 사용 안 함 또는 사용으로 설정할 수 없습니다.

참고 항목

이전에는 가용성 영역을 사용하도록 설정하려면 속성 zoneRedundant을(를) true(으)로 설정해야 했지만 이 동작은 기본적으로 가용성 영역을 사용하도록 변경되었습니다. 가능한 경우 기존 네임스페이스가 가용성 영역으로 마이그레이션되며 zoneRedundant 속성은 더 이상 사용되지 않습니다. 가용성 영역을 사용하도록 설정한 경우에도 속성 zoneRedundant이(가) 여전히 false(으)로 표시될 수 있습니다. 마이그레이션 중인 기존 네임스페이스:

재해 방지 - 표준 계층

Service Bus 표준 계층을 사용하여 재해에 대한 복원력을 달성하기 위해 활성 또는 수동 복제를 사용할 수 있습니다. 각 방식에서, 지정된 큐 또는 항목이 데이터센터 가동 중단 상태에서도 액세스 가능하려면 양쪽 네임스페이스에서 큐 또는 항목을 모두 만들어야 합니다. 두 엔터티는 동일한 이름을 가질 수 있습니다. 예를 들어, 기본 큐는 contosoPrimary.servicebus.windows.net/myQueue에서 연결할 수 있고 이에 상응하는 보조 큐는 contosoSecondary.servicebus.windows.net/myQueue에서 연결할 수 있습니다.

참고 항목

능동 복제수동 복제 설정은 범용 솔루션이며 Service Bus의 특정 기능이 아닙니다. 복제 논리(2개의 다른 네임스페이스에 보내는)는 보낸 사람 애플리케이션에 있으며 수신자는 중복 검색에 대한 사용자 지정 논리를 포함해야 합니다.

애플리케이션에 영구적인 발신자-수신자 통신이 필요하지 않을 경우, 메시지 손실을 막고 일시적 Service Bus 오류로부터 발신자를 보호하기 위해 내구성이 우수한 클라이언트 쪽 큐를 구현할 수 있습니다.

활성 복제

능동 복제는 모든 작업에서 양쪽 네임스페이스의 엔터티를 사용합니다. 메시지를 보내는 클라이언트는 동일한 메시지의 두 복사본을 보냅니다. 첫 번째 복사본은 기본 엔터티(예: contosoPrimary.servicebus.windows.net/sales)로 전송되고, 메시지의 두 번째 복사본은 보조 엔터티(예: contosoSecondary.servicebus.windows.net/sales)로 전송됩니다.

클라이언트는 두 큐에서 모두 메시지를 받습니다. 수신자는 메시지의 첫 번째 복사본을 처리하고 두 번째 복사본은 표시하지 않습니다. 중복 메시지를 표시하지 않기 위해 발송자는 각 메시지에 고유 식별자로 태그를 지정해야 합니다. 메시지의 두 복사본 모두 동일한 식별자로 태그가 지정되어야 합니다. ServiceBusMessage.MessageId 또는 ServiceBusMessage.Subject 속성이나 사용자 지정 속성을 사용하여 메시지에 태그를 지정할 수 있습니다. 수신자는 이미 받은 메시지의 목록을 유지해야 합니다.

참고 항목

능동 복제 방식은 작업의 수가 두 배이므로 그만큼 비용이 많이 소요됩니다.

수동 복제

오류가 없는 경우 수동 복제는 두 메시징 엔터티 중 하나만 사용합니다. 클라이언트는 활성 엔터티로 메시지를 보냅니다. 활성 엔터티를 호스팅하는 데이터센터를 사용할 수 없음을 나타내는 오류 코드와 함께 활성 엔터티의 작업에 실패하는 경우 클라이언트는 메시지의 복사본을 백업 엔터티로 보냅니다. 이때 활성 및 백업 엔터티는 역할을 전환합니다. 전송 클라이언트에서는 이전 활성 엔터티를 새 백업 엔터티로 간주하고 이전 백업 엔터티를 새 활성 엔터티로 간주합니다. 두 보내기 작업이 모두 실패하면, 두 엔터티의 역할이 바뀌지 않고 유지되며 오류가 반환됩니다.

클라이언트는 두 큐에서 모두 메시지를 받습니다. 수신자가 동일한 메시지의 두 복사본을 받을 가능성이 있기 때문에, 수신자는 중복 메시지를 표시하지 않아야 합니다. 능동 복제에서 설명한 것과 동일한 방법으로 중복 메시지를 숨길 수 있습니다.

일반적으로 대부분의 경우 하나의 작업만 수행되기 때문에 수동 복제가 능동 복제보다 더 경제적입니다. 대기 시간, 처리량 및 금전적 비용은 비복제 시나리오와 동일합니다.

수동 복제를 사용하면 다음 시나리오에서 메시지가 두 번 손실되거나 수신될 수 있습니다.

  • 메시지 지연 또는 손실: 발신자가 메시지 m1을 기본 큐로 보내고, 수신자가 m1을 받기 전에 큐가 사용할 수 없는 상태가 되었다고 가정해 보겠습니다. 발신자는 후속 메시지 m2를 보조 큐로 보냅니다. 기본 큐가 일시적으로 사용할 수 없는 상태였다면 수신자는 큐가 다시 사용 가능하게 된 후에 m1을 받게 됩니다. 재해가 발생하면 수신기는 결코 m1을 수신하지 못할 수도 있습니다.
  • 중복 수신: 발신자가 메시지 m을 기본 큐로 보냈다고 가정해 보겠습니다. Service Bus에서 성공적으로 m을 처리했지만 응답을 보내는 데는 실패합니다. 보내기 작업 시간이 초과된 후, 발신자는 m의 동일한 복사본을 보조 큐에 보냅니다. 기본 큐가 사용할 수 없는 상태가 되기 전에 수신자가 m의 첫 번째 복사본을 받을 수 있었다면, 수신자는 거의 동일한 시기에 두 복사본을 받게 됩니다. 기본 큐가 사용할 수 없는 상태가 되기 전에 수신자가 m의 첫 번째 복사본을 받을 수 없었다면, 수신자는 먼저 m의 두 번째 복사본만 받게 되고, 기본 큐가 다시 사용할 수 있게 되면 m의 두 번째 복사본도 받게 됩니다.

.NET Core를 사용한 Azure 메시징 복제 작업 샘플은 네임스페이스 간 메시지 복제를 보여 줍니다.

다음 단계

재해 복구에 대한 자세한 내용은 다음 문서를 참조하세요.