Azure Event Grid의 클라이언트 쪽 장애 조치(failover) 구현
재해 복구에는 일반적으로 지역이 비정상이 될 때 중단을 방지하기 위해 백업 리소스를 만드는 작업이 포함됩니다. 이 프로세스 중에는 워크로드에 Azure Event Grid 리소스의 기본 및 보조 지역이 필요합니다.
애플리케이션 기능의 심각한 손실을 복구하는 방법에는 여러 가지가 있습니다. 이 문서에서는 비정상 리소스 또는 지역으로 인한 오류로부터 클라이언트를 복구할 수 있도록 준비하기 위해 따라야 할 검사 목록에 대해 설명합니다.
Event Grid는 서버 쪽에서 수동 및 자동 GeoDR(지역 재해 복구)을 지원합니다. 장애 조치(failover) 프로세스를 더 효과적으로 제어하려는 경우 클라이언트 쪽 재해 복구 논리를 구현할 수 있습니다. 자동 GeoDR에 대한 자세한 내용은 Azure Event Grid의 서버 쪽 지역 재해 복구를 참조하세요.
다음 표에서는 Event Grid의 클라이언트 쪽 장애 조치(failover) 및 지역 재해 복구 지원을 보여 줍니다.
Event Grid 리소스 | 클라이언트 쪽 장애 조치(failover) 지원 | GeoDR(지역 재해 복구) 지원 |
---|---|---|
사용자 지정 토픽 | 지원됨 | 지역 간/지역 |
시스템 토픽 | 지원되지 않음 | 자동으로 사용하도록 설정됨 |
도메인 | 지원됨 | 지역 간/지역 |
파트너 네임스페이스 | 지원됨 | 지원되지 않음 |
네임스페이스 | 지원됨 | 지원되지 않음 |
클라이언트 쪽 장애 조치(failover) 고려 사항
- 기본 Event Grid 리소스를 만들고 구성합니다.
- 보조 Event Grid 리소스를 만들고 구성합니다.
- 두 리소스 모두 동일한 구성, 하위 리소스 및 기능이 사용하도록 설정되어 있어야 한다는 점에 유의해야 합니다.
- Event Grid 리소스는 다른 지역에서 호스트되어야 합니다.
- Event Grid 리소스에 데드레터를 위한 스토리지 리소스와 같은 종속 리소스가 있는 경우 보조 Event Grid 리소스에 사용된 것과 동일한 지역을 사용해야 합니다.
- 복구 계획 리소스가 내부에 있고 올바르게 작동하는지 보증하기 위해 엔드포인트가 정기적으로 테스트되는지 확인합니다.
사용자 지정 토픽에 대한 기본 클라이언트 쪽 장애 조치(failover) 구현 샘플
다음 샘플 코드는 주 토픽을 먼저 게시하려고 하는 간단한 .NET 게시자입니다. 주 토픽을 게시하는 데 실패하면 보조 토픽을 장애 조치합니다. 두 경우 모두 https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health
에서 GET을 수행하여 다른 항목의 상태 api를 확인합니다. 정상적인 항목은 /api/health 엔드포인트에 대해 GET이 수행될 경우 항상 200 OK로 응답해야 합니다.
참고 항목
다음 샘플 코드는 데모용으로만 제공되며 프로덕션 용도로 사용될 수 없습니다.
using System;
using System.Net.Http;
using System.Collections.Generic;
using System.Threading.Tasks;
using Azure;
using Azure.Messaging.EventGrid;
namespace EventGridFailoverPublisher
{
// This captures the "Data" portion of an EventGridEvent on a custom topic
class FailoverEventData
{
public string TestStatus { get; set; }
}
class Program
{
static async Task Main(string[] args)
{
// TODO: Enter the endpoint each topic. You can find this topic endpoint value
// in the "Overview" section in the "Event Grid topics" page in Azure Portal..
string primaryTopic = "https://<primary-topic-name>.<primary-topic-region>.eventgrid.azure.net/api/events";
string secondaryTopic = "https://<secondary-topic-name>.<secondary-topic-region>.eventgrid.azure.net/api/events";
// TODO: Enter topic key for each topic. You can find this in the "Access Keys" section in the
// "Event Grid topics" page in Azure Portal.
string primaryTopicKey = "<your-primary-topic-key>";
string secondaryTopicKey = "<your-secondary-topic-key>";
Uri primaryTopicUri = new Uri(primaryTopic);
Uri secondaryTopicUri = new Uri(secondaryTopic);
Uri primaryTopicHealthProbe = new Uri($"https://{primaryTopicUri.Host}/api/health");
Uri secondaryTopicHealthProbe = new Uri($"https://{secondaryTopicUri.Host}/api/health");
var httpClient = new HttpClient();
try
{
var client = new EventGridPublisherClient(primaryTopicUri, new AzureKeyCredential(primaryTopicKey));
await client.SendEventsAsync(GetEventsList());
Console.Write("Published events to primary Event Grid topic.");
HttpResponseMessage health = httpClient.GetAsync(secondaryTopicHealthProbe).Result;
Console.Write("\n\nSecondary Topic health " + health);
}
catch (RequestFailedException ex)
{
var client = new EventGridPublisherClient(secondaryTopicUri, new AzureKeyCredential(secondaryTopicKey));
await client.SendEventsAsync(GetEventsList());
Console.Write("Published events to secondary Event Grid topic. Reason for primary topic failure:\n\n" + ex);
HttpResponseMessage health = await httpClient.GetAsync(primaryTopicHealthProbe);
Console.WriteLine($"Primary Topic health {health}");
}
Console.ReadLine();
}
static IList<EventGridEvent> GetEventsList()
{
List<EventGridEvent> eventsList = new List<EventGridEvent>();
for (int i = 0; i < 5; i++)
{
eventsList.Add(new EventGridEvent(
subject: "test" + i,
eventType: "Contoso.Failover.Test",
dataVersion: "2.0",
data: new FailoverEventData
{
TestStatus = "success"
}));
}
return eventsList;
}
}
}
체험
모든 구성 요소가 설정되었으므로 장애 조치(failover) 구현을 테스트할 수 있습니다.
장애 조치(failover)가 작동하는지 확인하려면 기본 토픽 키의 문자 몇 개를 변경하여 더 이상 유효하지 않게 하면 됩니다. 게시자를 다시 실행해 보세요. 다음 샘플 이벤트는 Event Grid를 통해 계속 흐르지만 클라이언트를 보면 이제 보조 토픽을 통해 게시되고 있음을 알 수 있습니다.
가능한 확장 방법
필요에 따라 이 샘플을 확장하는 방법은 여러 가지가 있습니다. 대규모 시나리오의 경우 항목의 상태 api에 대한 정기 검사를 별도로 수행하는 것이 좋습니다. 이렇게 하면 항목이 다운될 경우 매번 게시할 때마다 확인할 필요가 없습니다. 항목이 정상 상태가 아니라는 것을 알고 있다면 보조 항목에 게시되도록 기본값을 설정하면 됩니다.
마찬가지로, 특정 요구 사항에 따라 장애 복구(failback) 논리를 구현하는 것이 좋습니다. 대기 시간 단축을 위해 가장 가까운 데이터 센터로 게시하는 것이 중요할 경우에는 장애 조치한 항목의 상태 api를 정기적으로 검사하면 됩니다. 다시 정상 상태가 되면 더 가까운 데이터 센터로 장애 복구(failback)를 수행하는 것이 안전합니다.
다음 단계
- http 엔드포인트에서 이벤트를 수신하는 방법 알아보기
- 하이브리드 연결로 이벤트를 라우팅하는 방법 알아보기
- Azure DNS 및 Traffic Manager를 사용한 재해 복구에 대해 알아보기