Azure Event Hubs - 지리적 재해 복구

이 문서에서는 메타데이터를 복제하고 일반적으로 사용할 수 있는 지역 재해 복구 기능을 설명합니다. 데이터와 메타데이터를 모두 복제하는 공개 미리 보기 지역 복제 기능은 설명하지 않습니다. 자세한 내용은 지역에서 복제를 참조하세요.

가용성 영역을 지원하는 전체 활성 Azure Event Hubs 클러스터 모델은 하드웨어 및 데이터 센터 중단에 대한 복원력을 제공합니다. 그러나 전체 지역과 모든 영역을 사용할 수 없는 재해가 발생하는 경우 지리적 재해 복구를 사용하여 워크로드 및 애플리케이션 구성을 복구할 수 있습니다. 지리적 재해 복구를 통해 네임스페이스의 전체 구성(Event Hubs, 소비자 그룹 및 설정)이 쌍을 이룰 때 기본 네임스페이스에서 보조 네임스페이스로 지속적으로 복제됩니다.

Azure Event Hubs의 지역 재해 복구 기능은 재해 복구 솔루션입니다. 이 문서에 설명된 개념과 워크플로는 일시적인 중단이 아닌 재해 시나리오에 적용됩니다. Microsoft Azure의 재해 복구에 대해 자세히 알아보려면 이 문서를 참조하세요. 지리적 재해 복구를 사용하면 언제든지 기본에서 보조로 한 번만 장애 조치(failover) 이동을 시작할 수 있습니다. 장애 조치(failover) 이동은 네임스페이스에 대해 선택한 별칭 이름을 보조 네임스페이스로 가리킵니다. 이동 후에는 페어링이 제거됩니다. 장애 조치가 시작된 후에는 거의 즉시 이루어집니다.

기본 개념 및 용어

재해 복구 기능은 메타데이터 재해 복구를 구현하며 주 및 보조 재해 복구 네임스페이스를 사용합니다. 지리적 재해 복구 기능은 표준 및 프리미엄 및 전용 계층에만 사용할 수 있습니다. 별칭을 통해 연결이 수행되므로 연결 문자열을 변경할 필요가 없습니다.

이 문서에서는 다음 용어가 사용됩니다.

• 별칭: 설정한 재해 복구 구성의 이름입니다. 별칭은 하나의 안정적인 FQDN(정규화된 도메인 이름) 연결 문자열을 제공합니다. 애플리케이션은 이 별칭 연결 문자열을 사용하여 네임스페이스에 연결합니다.
• 주/보조 네임스페이스: 별칭에 해당하는 네임스페이스입니다. 기본 네임스페이스는 “활성”이며 메시지를 수신합니다(기존 또는 새 네임스페이스일 수 있음). 보조 네임스페이스는 수동이며 메시지를 수신하지 않습니다. 둘 간의 메타데이터가 동기화되므로 둘 다 애플리케이션 코드 또는 연결 문자열을 변경하지 않고 메시지를 원활하게 수락할 수 있습니다. 활성 네임스페이스만 메시지를 수신하는지 확인하려면 별칭을 사용해야 합니다.
• 메타데이터: Event Hubs 및 소비자 그룹과 같은 엔터티 및 네임스페이스와 연결된 서비스의 해당 속성입니다. 엔터티 및 해당 설정만이 자동으로 복제됩니다. 메시지 및 이벤트는 복제되지 않습니다.
• 장애 조치(Failover): 보조 네임스페이스를 활성화하는 프로세스입니다.

지원되는 네임스페이스 쌍

기본 및 보조 네임스페이스의 다음과 같은 조합이 지원됩니다.

흐름 설정 및 장애 조치

다음 섹션은 장애 조치 프로세스의 개요이며 초기 장애 조치를 설정하는 방법을 설명합니다.

설정

먼저 기존의 기본 네임스페이스 및 새로운 보조 네임스페이스를 만들거나 사용한 다음 둘을 쌍으로 연결합니다. 이 페어링은 연결하는 데 사용할 수 있는 별칭을 제공합니다. 별칭을 사용하므로 연결 문자열을 변경할 필요가 없습니다. 새 네임스페이스에만 장애 조치(Failover) 페어링에 추가할 수 있습니다.

1. 기본 네임스페이스를 만듭니다.

2. 다른 지역에 보조 네임스페이스를 만듭니다. 이 단계는 선택 사항입니다. 다음 단계에서 페어링을 만드는 동안 보조 네임스페이스를 만들 수 있습니다.

3. Azure Portal에서 기본 네임스페이스로 이동합니다.

4. 왼쪽 메뉴에서 지역 복구를 선택하고 도구 모음에서 페어링 시작을 선택합니다.

   

5. 페어링 시작 페이지에서 다음 단계를 따릅니다.

   1. 기존 보조 네임스페이스를 선택하거나 다른 지역에서 하나를 만듭니다. 이 예제에서는 기존 네임스페이스를 선택합니다.
   2. 별칭에 Geo-DR(지리적 재해 복구) 페어링의 별칭을 입력합니다.
   3. 그런 다음 만들기를 선택합니다.

   

6. Geo-DR(지리적 재해 복구) 별칭 페이지가 표시됩니다. 왼쪽 메뉴에서 지역 복구를 선택하여 기본 네임스페이스에서 이 페이지로 이동할 수도 있습니다.

   

7. Geo-DR(지리적 재해 복구) 별칭 페이지의 왼쪽 메뉴에서 공유 액세스 정책을 선택하여 별칭에 대한 기본 연결 문자열에 액세스합니다. 기본/보조 네임스페이스에 연결 문자열을 직접 사용하는 대신 이 연결 문자열을 사용합니다.

8. 이 개요 페이지에서 다음 작업을 수행할 수 있습니다.

   1. 기본 네임스페이스와 보조 네임스페이스 간의 연결을 끊습니다. 도구 모음에서 연결 끊기를 선택합니다.

   2. 보조 네임스페이스에 수동으로 장애 조치합니다. 도구 모음에서 장애 조치를 선택합니다.

      

      Warning

      장애 조치(failover)를 수행하면 보조 네임스페이스가 활성화되고 지리적 재해 복구 쌍에서 기본 네임스페이스가 제거됩니다. 새 지리적 재해 복구 쌍을 포함하는 다른 네임스페이스를 만듭니다.

마지막으로 장애 조치가 필요한 경우 감지할 몇 가지 모니터링을 추가해야 합니다. 대부분의 경우 서비스는 대규모 에코시스템의 일부입니다. 따라서 장애 조치가 주로 나머지 하위 시스템 또는 인프라와 동기화되어 수행되어야 할 때가 많으므로 자동 장애 조치는 거의 불가능합니다.

예시

이 시나리오의 예로 메시지 또는 이벤트를 내보내는 POS(Point of Sale) 솔루션을 고려합니다. Event Hubs는 일부 매핑 또는 다시 포맷 솔루션에 해당 이벤트를 전달합니다. 그런 다음 추가 처리를 위해 다른 시스템에 매핑된 데이터를 전달합니다. 해당 시점에 이러한 시스템은 모두 같은 Azure 지역에서 호스팅될 수 있습니다. 장애 조치를 수행할 시기 및 부분은 인프라의 데이터 흐름에 따라 결정됩니다.

모니터링 시스템 또는 사용자 빌드 모니터링 솔루션을 사용하여 장애 조치를 자동화할 수 있습니다. 그러나 이러한 자동화에는 추가 계획 및 작업이 필요합니다. 이 부분은 이 문서에서 다루지 않습니다.

흐름 장애 조치(Failover)

장애 조치를 시작하는 경우 다음과 같은 두 단계가 필요합니다.

1. 작동 중단이 발생하면 다시 장애 조치(Failover)할 수 있어야 합니다. 따라서 다른 수동 네임스페이스를 설정하고 페어링을 업데이트합니다.
2. 사용할 수 있으면 이전 기본 네임스페이스에서 메시지를 끌어옵니다. 그 후에 지역 복구 설정의 외부에서 일반 메시징에 해당 네임스페이스를 사용하거나 이전 기본 네임스페이스를 삭제합니다.

수동 장애 조치

이 섹션에서는 Azure Portal, CLI, PowerShell, C# 등을 사용하여 수동으로 장애 조치(failover)하는 방법을 보여줍니다.

관리

예를 들어 초기 설정 작업 중에 잘못된 지역을 페어링하는 실수가 발생한 경우 언제든지 두 네임스페이스의 페어링을 해제할 수 있습니다. 일반 네임스페이스와 페어링된 네임스페이스를 사용하려는 경우 별칭을 삭제합니다.

고려 사항

다음 고려 사항에 유의하세요.

1. 기본적으로 Event Hubs 지리적 재해 복구는 데이터를 복제하지 않으므로 보조 이벤트 허브에서 기본 이벤트 허브의 이전 오프셋 값을 다시 사용할 수 없습니다. 다음 방법 중 하나를 사용하여 이벤트 수신기를 다시 시작하는 것이 좋습니다.

   • EventPosition.FromStart() - 보조 이벤트 허브의 모든 데이터를 읽으려는 경우
   • EventPosition.FromEnd() - 보조 이벤트 허브에 연결된 시간부터 모든 새 데이터를 읽으려는 경우
   • EventPosition.FromEnqueuedTime(dateTime) - 지정된 날짜 및 시간에서 시작하여 보조 이벤트 허브에서 받은 모든 데이터를 읽으려는 경우

2. 장애 조치 계획에서 시간 요소를 고려해야 합니다. 예를 들어 15~20분이 넘게 연결이 손실된 경우 장애 조치를 시작하기로 결정할 수 있습니다.

3. 데이터가 복제되지 않으면 현재 활성 세션이 복제되지 않습니다. 또한 중복 검색 및 예약된 메시지가 작동하지 않을 수 있습니다. 새 세션, 예약된 메시지 및 새 중복이 작동합니다.

4. 복잡한 분산 인프라를 장애 조치하려면 한 번 이상 예행 연습을 수행해야 합니다.

5. 엔터티를 동기화하는 데 분당 약 50~100개의 엔터티를 처리하므로 다소 시간이 걸릴 수 있습니다.

6. 보조 네임스페이스에 대한 관리 평면의 일부 측면은 지역 복구 페어링이 활성화된 동안 읽기 전용이 됩니다.

7. 보조 네임스페이스의 데이터 평면은 지역 복구 페어링이 활성화된 동안 읽기 전용입니다. 보조 네임스페이스의 데이터 평면은 GET 요청을 수락하여 클라이언트 연결 및 액세스 제어의 유효성을 검사할 수 있도록 합니다.

프라이빗 엔드포인트

이 섹션에서는 프라이빗 엔드포인트를 사용하는 네임스페이스에서 지리적 재해 복구를 사용할 때 추가로 고려해야 할 사항에 대해 설명합니다. 일반적인 Event Hubs에서 전용 엔드포인트를 사용하는 방법에 대한 자세한 내용은 프라이빗 엔드포인트 구성을 참조하세요.

새 페어링

프라이빗 엔드포인트가 없는 보조 네임스페이스와 프라이빗 엔드포인트가 있는 기본 네임스페이스 간에 페어링을 만들려고 시도하면 페어링이 실패합니다. 기본 및 보조 네임스페이스에 모두 프라이빗 엔드포인트가 있는 경우에만 페어링이 성공합니다. 기본 및 보조 네임스페이스와 프라이빗 엔드포인트가 생성되는 가상 네트워크에서 동일한 구성을 사용하는 것이 좋습니다.

기존 페어링

기본 네임스페이스와 보조 네임스페이스 간의 페어링이 이미 있는 경우에는 기본 네임스페이스에서 프라이빗 엔드포인트 만들기가 실패합니다. 이 문제를 해결하려면 먼저 보조 네임스페이스에 프라이빗 엔드포인트를 만든 다음, 기본 네임스페이스에 프라이빗 엔드포인트를 만듭니다.

권장 구성

애플리케이션 및 Event Hubs 네임스페이스에 대한 재해 복구 구성을 만들 때 애플리케이션의 기본 및 보조 인스턴스를 모두 호스트하는 가상 네트워크에 대하여 기본 및 보조 Event Hubs 네임스페이스 둘 다에 대한 프라이빗 엔드포인트를 만들어야 합니다.

두 개의 가상 네트워크(VNET-1, VNET-2)와 기본 및 보조 네임스페이스(EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary)가 있다고 가정해 보겠습니다. 다음 단계를 수행해야 합니다.

• EventHubs-Namespace1-Primary에서 VNET-1 및 VNET-2의 서브넷을 사용하는 두 개의 프라이빗 엔드포인트 만들기
• EventHubs-Namespace2-Secondary에서 VNET-1 및 VNET-2의 동일한 서브넷을 사용하는 두 개의 프라이빗 엔드포인트 만들기

이 방법의 장점은 장애 조치(failover)가 Event Hubs 네임스페이스와 무관한 애플리케이션 계층에서 발생할 수 있다는 것입니다. 다음 시나리오를 고려하세요.

애플리케이션 전용 장애 조치(failover): 여기서 애플리케이션은 VNET-1에 존재하지 않지만 VNET-2로 이동됩니다. 기본 및 보조 네임스페이스 모두에 대해 두 프라이빗 엔드포인트가 VNET-1 및 VNET-2 모두에 구성되어 있으므로 애플리케이션이 제대로 작동합니다.

Event Hubs 네임스페이스 전용 장애 조치(failover): 여기서도 역시 두 프라이빗 엔드포인트는 기본 및 보조 네임스페이스에 대해 두 가상 네트워크 모두에서 구성되므로 응용 프로그램은 작동합니다.

역할 기반 액세스 제어

기본 네임스페이스의 엔터티에 대한 Microsoft Entra RBAC(역할 기반 액세스 제어) 할당은 보조 네임스페이스에 복제되지 않습니다. 보조 네임스페이스에서 수동으로 역할 할당을 만들어 액세스를 보호합니다.

관련 콘텐츠

다음 샘플 또는 참조 설명서를 검토합니다.

• .NET GeoDR 샘플
• Java GeoDR 샘플