Azure Service Bus 지리적 재해 복구
Service Bus 지리적 재해 복구 기능은 Azure Service Bus 애플리케이션을 중단 및 재해로부터 보호하는 옵션 중 하나이며 주로 복합 애플리케이션 구성의 무결성을 유지하는 데 도움을 줍니다.
참고 항목
이 기능은 Azure Service Bus의 프리미엄 계층에서 사용할 수 있습니다.
지리적 재해 복구 기능을 사용하면 네임스페이스(엔티티, 구성, 속성)의 전체 구성이 기본 네임스페이스에서 쌍을 이루는 보조 네임스페이스로 지속적으로 복제되고, 언제든지 기본 데이터베이스에서 보조 데이터베이스로 한 번만 장애 조치(failover) 이동을 시작할 수 있습니다. 장애 조치(failover) 이동은 네임스페이스에 대해 선택한 별칭 이름을 보조 네임스페이스로 다시 지정한 다음 쌍을 끊습니다. 장애 조치가 시작된 후에는 거의 즉시 이루어집니다.
고려할 중요한 사항
- 이 기능을 사용하면 같은 구성을 사용하여 작업을 즉각적으로 연속할 수 있지만, 큐, 토픽 구독 또는 배달되지 않은 편지 큐에 보관된 메시지를 복제하지 않습니다. 큐 의미 체계를 보존하기 위해 이러한 복제에는 메시지 데이터의 복제뿐만 아니라 브로커의 모든 상태 변경도 필요합니다. 이는 지역 복제 기능(공개 미리 보기)에서 제공됩니다.
- 기본 네임스페이스의 Service Bus 엔터티에 대한 Microsoft Entra RBAC(역할 기반 액세스 제어) 할당은 보조 네임스페이스에 복제되지 않습니다. 보조 네임스페이스에서 수동으로 역할 할당을 만들어 액세스를 보호합니다.
- 다음 구성은 복제되지 않습니다.
- 가상 네트워크 구성
- 프라이빗 엔드포인트 연결
- 모든 네트워크 액세스 사용
- 신뢰할 수 있는 서비스 액세스 사용
- 공용 네트워크 액세스
- 기본 네트워크 작업
- ID 및 암호화 설정(고객 관리형 키 암호화 또는 BYOK(Bring Your Own Key) 암호화)
- 자동 크기 조정 사용
- 로컬 인증 사용 안 함
- Azure Event Grid 구독
- 분할된 네임스페이스와 분할되지 않은 네임스페이스의 쌍은 지원되지 않습니다.
- 엔터티에 대해
AutoDeleteOnIdle
이 사용하도록 설정된 경우 장애 조치(failover)가 발생할 때 엔터티가 보조 네임스페이스에 존재하지 않을 수 있습니다. 보조가 기본이 되면 메타데이터의 일부가 아닌 마지막 액세스 상태는 새 기본에 사용할 수 없으며 엔터티는AutoDeleteOnIdle
정리의 일부로 삭제될 수 있습니다.
팁
큐와 토픽 구독의 콘텐츠를 복제하고 활성/활성 구성에서 해당 네임스페이스를 운영하여 중단 및 재해를 처리할 수 있도록 하려면 이러한 지리적 재해 복구 기능 세트를 사용하지 않고, 지역 복제 기능을 사용하거나 복제 지침을 따릅니다.
기본 개념 및 용어
지리적 재해 복구 기능은 메타데이터 재해 복구를 구현하며 기본 및 보조 재해 복구 네임스페이스를 사용합니다. 지리적 재해 복구 기능은 프리미엄 계층에서만 사용할 수 있습니다. 별칭을 통해 연결이 수행되므로 연결 문자열을 변경할 필요가 없습니다.
이 문서에서는 다음 용어가 사용됩니다.
별칭: 설정한 재해 복구 구성의 이름입니다. 별칭은 하나의 안정적인 FQDN(정규화된 도메인 이름) 연결 문자열을 제공합니다. 애플리케이션은 이 별칭 연결 문자열을 사용하여 네임스페이스에 연결합니다. 별칭을 사용하면 장애 조치가 트리거될 때 연결 문자열이 변경되지 않습니다.
주/보조 네임스페이스: 별칭에 해당하는 네임스페이스입니다. 기본 네임스페이스는 “활성”이며 메시지를 수신합니다(기존 또는 새 네임스페이스일 수 있음). 보조 네임스페이스는 “수동”이며 메시지를 수신하지 않습니다. 둘 간의 메타데이터가 동기화되므로 둘 다 애플리케이션 코드 또는 연결 문자열을 변경하지 않고 메시지를 원활하게 수락할 수 있습니다. 활성 네임스페이스만 메시지를 수신하는지 확인하려면 별칭을 사용해야 합니다.
메타데이터: 큐, 항목 및 구독과 같은 엔터티 및 네임스페이스와 연결된 서비스의 해당 속성입니다. 엔터티 및 해당 설정만이 자동으로 복제됩니다. 메시지는 복제되지 않습니다.
장애 조치(Failover): 보조 네임스페이스를 활성화하는 프로세스입니다.
설정
다음 섹션에서는 네임스페이스 간에 페어링을 설정하는 방법에 관해 간략히 설명합니다.
먼저 기존의 기본 네임스페이스 및 새로운 보조 네임스페이스를 만들거나 사용한 다음 둘을 쌍으로 연결합니다. 이 페어링은 연결하는 데 사용할 수 있는 별칭을 제공합니다. 별칭을 사용하므로 연결 문자열을 변경할 필요가 없습니다. 새 네임스페이스에만 장애 조치(Failover) 페어링에 추가할 수 있습니다.
기본 프리미엄 계층 네임스페이스를 만듭니다.
다른 지역에 보조 프리미엄 계층 네임스페이스를 만듭니다. 이 단계는 선택 사항입니다. 다음 단계에서 페어링을 만드는 동안 보조 네임스페이스를 만들 수 있습니다.
Azure Portal에서 기본 네임스페이스로 이동합니다.
왼쪽 메뉴에서 지역 복구를 선택하고 도구 모음에서 페어링 시작을 선택합니다.
페어링 시작 페이지에서 다음 단계를 따릅니다.
기존 보조 네임스페이스를 선택하거나 다른 지역에서 하나를 만듭니다. 이 예제에서는 기존 네임스페이스를 보조 네임스페이스로 사용합니다.
별칭에 지리적 재해 복구 쌍의 별칭을 입력합니다.
그런 다음 만들기를 선택합니다.
다음 이미지와 같이 Service Bus Geo-DR(지리적 재해 복구) 별칭 페이지가 표시됩니다. 왼쪽 메뉴에서 지역 복구를 선택하여 기본 네임스페이스 페이지에서 Geo-DR(지리적 재해 복구) 별칭 페이지로 이동할 수도 있습니다.
Geo-DR(지리적 재해 복구) 별칭 페이지의 왼쪽 메뉴에서 공유 액세스 정책을 선택하여 별칭에 대한 기본 연결 문자열에 액세스합니다. 기본/보조 네임스페이스에 연결 문자열을 직접 사용하는 대신 이 연결 문자열을 사용합니다. 처음에는 별칭에서 기본 네임스페이스를 가리킵니다.
개요 페이지로 전환합니다. 사용할 수 있는 작업은 다음과 같습니다.
- 기본 네임스페이스와 보조 네임스페이스 간의 연결을 끊습니다. 도구 모음에서 연결 끊기를 선택합니다.
- 보조 네임스페이스에 수동으로 장애 조치합니다.
도구 모음에서 장애 조치를 선택합니다.
별칭을 입력하여 보조 네임스페이스로 장애 조치할지 확인합니다.
안전 장애 조치 옵션을 설정하여 보조 네임스페이스로 안전하게 장애 조치합니다.
참고 항목
- 안전한 장애 조치(failover)는 보류 중인 지리적 재해 복구 복제가 보조 복제로 전환되기 전에 완료되었는지 확인합니다. 또는 강제 또는 수동 장애 조치(failover)는 보조 복제로 전환하기 전에 보류 중인 복제가 완료될 때까지 기다리지 않습니다.
- 현재 기본 및 보조 네임스페이스가 동일한 Azure 구독에 없으면 안전한 장애 조치(failover)가 실패합니다.
그런 다음 장애 조치를 선택합니다.
Important
장애 조치(failover)를 수행하면 보조 네임스페이스가 활성화되고 지리적 재해 복구 쌍에서 기본 네임스페이스가 제거됩니다. 새 지리적 재해 복구 쌍을 포함하는 다른 네임스페이스를 만듭니다.
마지막으로 장애 조치가 필요한 경우 감지할 몇 가지 모니터링을 추가해야 합니다. 대부분의 경우 서비스는 대규모 에코시스템의 일부입니다. 따라서 장애 조치가 주로 나머지 하위 시스템 또는 인프라와 동기화되어 수행되어야 할 때가 많으므로 자동 장애 조치는 거의 불가능합니다.
Service Bus 표준에서 프리미엄으로
Azure Service Bus 표준 네임스페이스를 Azure Service Bus 프리미엄으로 마이그레이션한 경우 기존 별칭(즉, Service Bus 표준 네임스페이스 연결 문자열)을 사용하여 PS/CLI 또는 REST API를 통해 재해 복구 구성을 만들어야 합니다.
마이그레이션 중에 Azure Service Bus 표준 네임스페이스 연결 문자열/DNS 이름 자체가 Azure Service Bus 프리미엄 네임스페이스의 별칭이 되기 때문입니다.
클라이언트 애플리케이션은 이 별칭(즉, Azure Service Bus 표준 네임스페이스 연결 문자열)을 사용하여 재해 복구 페어링이 설정된 프리미엄 네임스페이스에 연결해야 합니다.
Azure Portal을 사용하여 재해 복구 구성을 설정하는 경우 포털은 이 경고를 추상화합니다.
흐름 장애 조치(Failover)
장애 조치는 고객이 명시적으로 명령 또는 명령을 트리거하는 클라이언트 소유 비즈니스 논리를 통해 수동으로 트리거되며, Azure에서는 트리거되지 않습니다. 그러면 고객이 Azure의 백본에서 가동 중단 해결에 대한 완전한 소유권과 가시성을 확보할 수 있습니다.
장애 조치가 트리거되면,
별칭 연결 문자열이 보조 프리미엄 네임스페이스를 가리키도록 업데이트됩니다.
클라이언트(발신자 및 수신자)가 보조 네임스페이스에 자동으로 연결됩니다.
기본 및 보조 프리미엄 네임스페이스 간의 기존 페어링이 끊어집니다.
장애 조치가 시작되면,
작동 중단이 발생하면 다시 장애 조치(Failover)할 수 있어야 합니다. 따라서 다른 보조 네임스페이스를 설정하고 페어링을 업데이트합니다.
사용할 수 있으면 이전 기본 네임스페이스에서 메시지를 끌어옵니다. 그 후에 지리적 재해 복구 설정의 외부에서 일반 메시징에 해당 네임스페이스를 사용하거나 이전 기본 네임스페이스를 삭제합니다.
참고 항목
실패 전달 의미 체계만이 지원됩니다. 이 시나리오에서는 새 네임스페이스를 사용하여 장애 조치하고 다시 페어링합니다. 장애 복구는 지원되지 않습니다(예: SQL 클러스터에서 장애 복구 등).
모니터링 시스템 또는 사용자 빌드 모니터링 솔루션을 사용하여 장애 조치를 자동화할 수 있습니다. 그러나 이러한 자동화에는 추가 계획 및 작업이 필요합니다. 이 부분은 이 문서에서 다루지 않습니다.
관리
예를 들어 초기 설정 작업 중에 잘못된 지역을 페어링하는 실수가 발생한 경우 언제든지 두 네임스페이스의 페어링을 해제할 수 있습니다. 일반 네임스페이스와 페어링된 네임스페이스를 사용하려는 경우 별칭을 삭제합니다.
기존 네임스페이스를 별칭으로 사용
생산자와 소비자의 연결을 변경할 수 없는 시나리오를 사용하는 경우 네임스페이스 이름을 별칭 이름으로 다시 사용할 수 있습니다. 여기에서 GitHub의 샘플 코드를 참조하세요.
샘플
GitHub의 샘플에서는 장애 조치를 설정하고 시작하는 방법을 보여줍니다. 이러한 예제는 다음과 같은 개념을 보여줍니다.
- Service Bus와 함께 Azure Resource Manager를 사용하고 지리적 재해 복구를 설정 및 사용하도록 설정하기 위해 Microsoft Entra ID에 필요한 .NET 샘플 및 설정입니다.
- 샘플 코드를 실행하는 데 필요한 단계
- 기존 네임스페이스를 별칭으로 사용하는 방법
- PowerShell 또는 CLI를 통해 지리적 재해 복구를 사용하는 단계
- 별칭을 사용하여 현재 기본 또는 보조 네임스페이스에서 전달 및 수신
고려 사항
이 릴리스에서 고려할 다음과 같은 고려 사항에 유의하세요.
- 장애 조치 계획에서 시간 요소를 고려해야 합니다. 예를 들어 15~20분이 넘게 연결이 손실된 경우 장애 조치를 시작하기로 결정할 수 있습니다.
- 데이터가 복제되지 않으면 현재 활성 세션이 복제되지 않습니다. 또한 중복 검색 및 예약된 메시지가 작동하지 않을 수 있습니다. 새 세션, 새 예약 메시지, 새 중복 항목이 작동합니다.
- 복잡한 분산 인프라를 장애 조치하려면 한 번 이상 예행 연습을 수행해야 합니다.
- 엔터티를 동기화하는 데 분당 약 50~100개의 엔터티를 처리하므로 다소 시간이 걸릴 수 있습니다. 구독 및 규칙은 엔터티로 계산합니다.
프라이빗 엔드포인트
이 섹션에서는 프라이빗 엔드포인트를 사용하는 네임스페이스에서 지리적 재해 복구를 사용할 때 추가로 고려해야 할 사항에 관해 설명합니다. 일반적으로 Service Bus에서 프라이빗 엔드포인트를 사용하는 방법에 대한 자세한 내용은 Azure Private Link와 Azure Service Bus 통합을 참조하세요.
새 페어링
프라이빗 엔드포인트가 없는 보조 네임스페이스와 프라이빗 엔드포인트가 있는 기본 네임스페이스 간에 페어링을 만들려고 시도하면 페어링이 실패합니다. 기본 및 보조 네임스페이스 모두에 프라이빗 엔드포인트가 있는 경우에만 페어링이 성공합니다. 기본 및 보조 네임스페이스와 프라이빗 엔드포인트가 생성되는 가상 네트워크에서 동일한 구성을 사용하는 것이 좋습니다.
참고 항목
프라이빗 엔드포인트가 있는 기본 네임스페이스를 보조 네임스페이스와 페어링하려고 시도하면 유효성 검사 프로세스에서는 보조 네임스페이스에 프라이빗 엔드포인트가 있는지만 검사합니다. 엔드포인트가 작동하는지 또는 장애 조치(failover) 후 작동하는지는 검사하지 않습니다. 장애 조치(failover) 후 프라이빗 엔드포인트가 있는 보조 네임스페이스가 예상대로 작동하는지 확인하는 것은 사용자의 책임입니다.
프라이빗 엔드포인트 구성이 동일한지 테스트하려면 가상 네트워크 외부에서 보조 네임스페이스로 큐 가져오기 요청을 보내고 서비스에서 오류 메시지를 수신하는지 확인합니다.
기존 페어링
기본 네임스페이스와 보조 네임스페이스 간의 페어링이 이미 있는 경우에는 기본 네임스페이스에서 프라이빗 엔드포인트 만들기가 실패합니다. 이 문제를 해결하려면 먼저 보조 네임스페이스에 프라이빗 엔드포인트를 만든 다음, 기본 네임스페이스에 프라이빗 엔드포인트를 만듭니다.
참고 항목
보조 네임스페이스에는 읽기 전용 액세스가 허용되며 프라이빗 엔드포인트 구성에 대한 업데이트가 허용됩니다.
권장 구성
애플리케이션 및 Service Bus에 대한 재해 복구 구성을 만들 때 애플리케이션의 기본 및 보조 인스턴스를 모두 호스팅하는 가상 네트워크에 대하여 기본 및 보조 Service Bus 네임스페이스 둘 다에 대한 프라이빗 엔드포인트를 만들어야 합니다.
두 개의 가상 네트워크(VNET-1, VNET-2)와 기본 및 보조 네임스페이스(ServiceBus-Namespace1-Primary
, ServiceBus-Namespace2-Secondary
)가 있다고 가정해 보겠습니다. 다음 단계를 수행해야 합니다.
ServiceBus-Namespace1-Primary
에서 VNET-1 및 VNET-2의 서브넷을 사용하는 두 개의 프라이빗 엔드포인트를 만듭니다.ServiceBus-Namespace2-Secondary
에서 VNET-1 및 VNET-2의 동일한 서브넷을 사용하는 두 개의 프라이빗 엔드포인트를 만듭니다.
이 방법의 장점은 장애 조치(failover)가 Service Bus 네임스페이스와 무관한 애플리케이션 계층에서 발생할 수 있다는 것입니다. 다음 시나리오를 고려하세요.
애플리케이션 전용 장애 조치(failover): 여기서 애플리케이션은 VNET-1에 존재하지 않지만 VNET-2로 이동합니다. 두 프라이빗 엔드포인트 모두 기본 및 보조 네임스페이스에 대해 VNET-1과 VNET-2 모두에 구성되어 있으므로 애플리케이션은 작동합니다.
Service Bus 네임스페이스 전용 장애 조치(failover): 여기서도 두 프라이빗 엔드포인트가 기본 및 보조 네임스페이스 모두에 대해 두 가상 네트워크에 구성되어 있으므로 애플리케이션이 제대로 작동합니다.
참고 항목
가상 네트워크의 지리적 재해 복구에 대한 지침은 Virtual Network - 비즈니스 연속성을 참조하세요.
역할 기반 액세스 제어
기본 네임스페이스의 Service Bus 엔터티에 대한 Microsoft Entra RBAC(역할 기반 액세스 제어) 할당은 보조 네임스페이스에 복제되지 않습니다. 보조 네임스페이스에서 수동으로 역할 할당을 만들어 액세스를 보호합니다.
다음 단계
- 지리적 재해 복구를 참조합니다REST API 참조.
- 지리적 재해 복구를 실행합니다GitHub의 샘플.
- 지리적 재해 복구를 참조합니다별칭으로 메시지를 전송하는 샘플.
Service Bus 메시징에 대해 자세히 알아보려면 다음 문서를 참조하세요.