Azure Event Hubs ジオレプリケーション

Event Hubs geo レプリケーション機能は、名前空間のメタデータ (エンティティ、構成、プロパティ) とデータ (イベント ペイロード) の両方のレプリケーションを提供し、ビジネス継続性とディザスター リカバリーを可能にします。

この機能により、名前空間のメタデータとデータがプライマリ リージョンからセカンダリ リージョンに継続的にレプリケートされます。 名前空間は複数のリージョンに拡張され、1 つのリージョンがプライマリ、もう 1 つはセカンダリと考えることができます。

セカンダリ リージョンはいつでもプライマリ リージョンに昇格できます。 セカンダリを昇格すると、選択したセカンダリ リージョンに名前空間 FQDN (完全修飾ドメイン名) が再ポイントされ、前のプライマリ リージョンがセカンダリ リージョンに降格されます。

シナリオ

ここで説明するように、Event Hubs geo レプリケーションは複数の異なるシナリオで使用できます。

ビジネス継続性とディザスター リカバリーの確保

geo レプリケーションにより、名前空間上のすべてのストリーミング データに対するディザスター リカバリーとビジネス継続性が保証されます。 リージョン間でデータをレプリケートすることで、組織はデータ損失から保護し、リージョンの障害が発生した場合でもアプリケーションが動作し続けられるようにすることができます。 この機能は、高可用性と最小限のダウンタイムを必要とするミッション クリティカルなアプリケーションにとって非常に重要です。

グローバル データ分散

geo レプリケーションを使用すると、データをグローバルに分散できるため、アプリケーションは最も近いリージョンのデータにアクセスできます。 これにより、待機時間が短縮され、世界各地にあるワークロードのパフォーマンスが向上します。

データ主権とコンプライアンス

多くの場合、複数の国/地域で活動する組織は、特定の地理的境界内にデータを格納する必要があるデータ主権の法律に準拠する必要があります。 geo レプリケーションを使用すると、これらの組織は、ローカルの規制に準拠しているリージョンにデータをレプリケートし、統一されたデータ プラットフォームを維持しながら法的要件を満たすことができます。

移行とアップグレード

geo レプリケーションを使用して、データの移行、メンテナンス、システムのアップグレードを容易にすることもできます。 組織は、プライマリ リージョンからセカンダリ リージョンに名前空間を事前に移行して、プライマリ リージョンでのメンテナンスとアップグレードを可能にすることができます。

基本的な概念

geo レプリケーション機能は、プライマリ/セカンダリ レプリケーション モデルにおいて、メタデータとデータのレプリケーションを実装します。 特定の時点では、プロデューサーとコンシューマーの両方にサービスを提供する、1 つのプライマリ Azure リージョンがあります。 セカンダリはホット スタンバイ リージョンとして機能します。つまり、これらのセカンダリ リージョンと対話することはできません。 ただし、プライマリ リージョンと同じ構成で実行されるため、昇格が完了した後にステップ インする準備が整い、迅速な昇格が可能になります。

geo データ レプリケーション機能の主な側面は次のとおりです。

• プライマリ セカンダリ レプリケーション モデル – geo レプリケーションはプライマリ セカンダリ レプリケーション モデルを基にしています。このモデルでは、どのような時にもイベント プロデューサーとイベント コンシューマーにサービスを提供するプライマリ名前空間は 1 つしか存在しません。
• Event Hubs は、構成された整合性レベルを使用して、複数のセカンダリにわたってメタデータ、イベント データ、コンシューマー オフセットのフル マネージド バイト間レプリケーションを実行します。
• 単一の名前空間ホスト名 - Geo-Replication 有効な名前空間が正常に構成されると、ユーザーはクライアント アプリケーションで名前空間のホスト名を使用できます。 ホスト名は、構成されたプライマリとセカンダリの Azure リージョンに依存せずに動作し、常にプライマリ Azure リージョンを指します。
• 顧客が昇格を開始すると、ホスト名は新しいプライマリ Azure リージョンとして選択された Azure リージョンを指します。 古いプライマリがセカンダリ Azure リージョンになります。
• セカンダリ Azure リージョン上で読み取りまたは書き込みはできません。
• プライマリからセカンダリのリージョンへのカスタマー マネージドの昇格により、完全な所有権と、停止解決の可視性が提供されます。 メトリックを使用できます。これは、顧客側からの昇格を自動化するのに役立ちます。 セカンダリ Azure リージョンは、顧客の裁量で追加または削除できます。
• レプリケーションの整合性 - レプリケーションの整合性の設定には同期と非同期の 2 つが存在します。

状態	ダイアグラム
フェールオーバー前 (セカンダリの昇格)
フェールオーバー後 (セカンダリの昇格)

レプリケーション モード

レプリケーションの整合性の構成には、同期と非同期の 2 つが存在します。 これら 2 つの構成はアプリケーションとデータの整合性に影響を与えるので、これらの違いを理解しておくことが重要です。

非同期レプリケーション

非同期レプリケーションを使用すると、すべての要求がプライマリ上でコミットされ、その後、確認がクライアントに送信されます。 セカンダリ Azure リージョンへのレプリケーションは非同期的に行われます。 ユーザーは、許容される最大ラグ タイム (プライマリ リージョンとセカンダリ リージョンの最新のアクション間のサービス側オフセット) を構成できます。 サービスはデータとメタデータを継続的にレプリケートし、ラグが可能な限り小さいままであることを確認します。 アクティブなセカンダリのラグが、ユーザーが構成したレプリケーションの最大ラグを超えると、プライマリは受信要求の調整を開始します。

同期レプリケーション

同期レプリケーションを使用すると、すべての要求がセカンダリにレプリケートされるため、その操作をコミットして確認してからプライマリ上でコミットする必要があります。 そのため、アプリケーションは、発行、レプリケート、確認、コミットにかかる速度で発行されます。 さらに、これはアプリケーションが両方の Azure リージョンの可用性に関連付けられていることも意味します。 セカンダリ リージョンが遅延したり利用できなくなったりすると、メッセージは確認およびコミットされず、プライマリ リージョンは受信要求を調整します。

レプリケーションの整合性の比較

同期レプリケーション使用する場合:

• 分散コミット操作に起因して、待機時間がより長くなります。
• 可用性は、2 つのリージョンの可用性に関係します。 1 つのリージョンがダウンすると、名前空間は利用できなくなります。

一方、同期レプリケーションは、データが安全であることを最も確実に保証します。 同期レプリケーションがある場合、それをコミットすると、geo レプリケーション用に構成したすべての Azure リージョン内にコミットされ、最適なデータ保証が提供されます。

非同期レプリケーションの場合:

• 待機時間への影響は最小限になります。
• セカンダリ Azure リージョンの損失は、可用性にすぐに影響を与えるわけではありません。 ただし、構成された最大レプリケーション ラグに達すると、可用性が影響を受けます。

そのため、同期レプリケーションで行われるような、コミットする前にすべての Azure リージョンにデータがあるという絶対的な保証はありません。また、データの損失や重複が発生する場合があります。 ただし、1 つの Azure リージョンでラグが発生した、または使用できなくなった場合にすぐに影響を受けることがなくなるため、より低遅延になることに加えて、アプリケーションの可用性も向上します。

レプリケーション モードは、geo レプリケーションの構成後に変更できます。 同期から非同期、または非同期から同期に変更できます。 非同期から同期に変更すると、ラグが 0 に達した後にセカンダリは同期として構成されます。 何らかの理由で継続的なラグを伴って実行されている場合、ラグがゼロに達してモードを同期に切り替えるには、パブリッシャーを一時停止する必要がある可能性があります。 非同期レプリケーションではなく、同期レプリケーションを有効にする理由は、アプリケーションの可用性ではなく、データの重要性、特定のビジネス ニーズ、またはコンプライアンス上の理由に関連しています。

副次リージョンの選択

geo レプリケーション機能を有効にするには、この機能が有効なプライマリとセカンダリのリージョンを使用する必要があります。 geo レプリケーション機能は、発行されたメッセージをプライマリからセカンダリの Azure リージョンにレプリケートできるかどうかによって異なります。 セカンダリ Azure リージョンが別の大陸上にある場合、プライマリからセカンダリの Azure リージョンへのレプリケーション ラグに大きな影響があります。 可用性の理由で geo レプリケーションを使用する場合は、可能な限りセカンダリ Azure リージョンを、少なくとも同じ大陸上に展開するのが最善です。 地理的な距離によって引き起こされる待機時間について理解を深めるために、Azure ネットワークラウンドトリップ待機時間の統計情報からさらに学習できます。

ジオレプリケーションの管理

geo レプリケーション機能を使用すると、顧客はメタデータとデータをレプリケートするセカンダリ Azure リージョンを構成できます。 そのため、顧客は次の管理タスクを実行できます。

• geo レプリケーションの構成 - セカンダリ リージョンは、Geo-Replication 機能が有効になっているリージョン内の任意の新規または既存の名前空間で構成できます。
• レプリケーションの整合性を構成する - 同期レプリケーションと非同期レプリケーションは、Geo-Replication が構成されたときに設定されますが、後で切り替えることもできます。
• 昇格/フェイルオーバーを起動する - すべての昇格は顧客が開始します。
• セカンダリを削除する - セカンダリ リージョンをいつでも削除する場合は、セカンダリ リージョン内のデータが削除された後に削除できます。

昇格をトリガーする条件

セカンダリからプライマリへの昇格がトリガーされる場合を次に示します。

• リージョンの停止: プライマリ リージョンに影響を与えるリージョンの停止がある場合は、ビジネス継続性を確保し、ダウンタイムを最小限に抑えるために、セカンダリ リージョンを昇格させる必要があります。

• メンテナンス アクティビティ: プライマリ リージョンでの計画メンテナンス アクティビティ中に、セカンダリ リージョンを昇格すると、ミッション クリティカルなアプリケーションの高可用性を維持するのに役立ちます。

• ディザスター リカバリー: プライマリ リージョンに影響を与える障害が発生した場合、セカンダリ リージョンを昇格することで、データへのアクセスが維持され、アプリケーションが引き続き機能するようになります。

• パフォーマンスの問題: プライマリ リージョンで、Event Hubs の可用性または信頼性に影響するパフォーマンスの問題が発生している場合は、セカンダリ リージョンを昇格することで、これらの問題を軽減できます。

フェールオーバー メカニズムをテストして、ビジネス継続性計画が有効であることを確認し、必要に応じてアプリケーションをシームレスにセカンダリ リージョンに切り替えることをお勧めします。

データ レプリケーションの監視

ユーザーは、アプリケーション メトリック ログのレプリケーション ラグ メトリックを監視することで、レプリケーション ジョブの進行状況を監視できます。

• 「Azure Event Hubs の監視 - Azure Event Hubs | Microsoft Learn」に従って Event Hubs 名前空間のアプリケーション メトリック ログを有効にします。

• アプリケーション メトリック ログが有効になったら、ログが確認できるようになるまで数分間にわたって名前空間からデータを生成してそれを消費する必要があります。

• アプリケーション メトリック ログを表示するには、Event Hubs ページの [監視] セクションに移動し、左側にあるメニューの [ログ] を選択します。 次のクエリを使用することで、プライマリとセカンダリ名前空間の間のレプリケーション ラグ (秒単位) を確認することができます。

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• count_d 列は、プライマリとセカンダリ リージョン間の秒単位のレプリケーション ラグを表しています。

データの公開

アプリケーションを発行すると、geo レプリケーションが有効な名前空間の名前空間ホスト名を使用して、geo レプリケートされた名前空間にデータを発行できます。 発行のアプローチは geo レプリケーション以外のケースと同じであり、データ プレーン SDK またはクライアント アプリケーションを変更する必要はありません。

イベントの発行は、以下の状況では利用できない場合があります。

• セカンダリ リージョンの昇格を要求した後、既存のプライマリ リージョンは、イベント ハブに発行された新しいイベントをすべて拒否します。
• プライマリとセカンダリ リージョン間のレプリケーション ラグが最大レプリケーション ラグの時間に達すると、パブリッシャーのイングレス ワークロードが制限される場合があります。

パブリッシャー アプリケーションは、セカンダリ リージョン内の名前空間に直接アクセスすることができません。

データの消費

アプリケーションを使用すると、geo レプリケーション機能が有効な名前空間の名前空間ホスト名を使用してデータを使用できます。 昇格が開始された時点から昇格が完了するまで、コンシューマーの操作はサポートされません。

チェックポイント機能/オフセット管理

イベントを消費するアプリケーションは、geo 以外のレプリケートされた名前空間を使用する場合と同様に、オフセット管理を維持し続けることができます。 geo レプリケーションが有効な名前空間のオフセット管理に特別な考慮事項は必要ありません。

Kafka

オフセットは Event Hubs に直接コミットされるため、オフセットは複数のリージョンにわたってレプリケートされます。 そのため、コンシューマーはプライマリ リージョンで中断した場所から消費を開始できます。

サポートされている Apache Kafka クライアントの一覧を次に示します。

他のライブラリの場合は、以下の API バージョンを使用しているライブラリがサポートされています。

Event Hubs SDK/AMQP

AMQP の場合、チェックポイントは、Azure Blob Storage やカスタム ストレージ ソリューションなどのチェックポイント ストアを持つユーザーによって管理されます。 フェールオーバーがある場合は、クライアントがチェックポイント データを取得してメッセージの損失を回避できるように、セカンダリ リージョンからチェックポイント ストアを利用できる必要があります。

Event Hubs SDK の最新バージョンでは、フェールオーバーをサポートするためにチェックポイント表現にいくつかの変更が加えられます。 最新バージョンの SDK を使用することをお勧めしますが、以下の SDK の以前のバージョンもサポートされています。

考慮事項

この機能に留意する必要がある考慮事項は次のとおりです。

• 昇格の計画では、時間的な要因も考慮する必要があります。 たとえば、接続が切れて 15 から 20 分間を超えた場合は、昇格を開始する判断を下すかもしれません。
• 複雑な分散インフラストラクチャの昇格は、少なくとも 1 回はリハーサルを行う必要があります。

価格

価格は選択したレベルによって異なりますが、一般的には 2 つのパラメーターがあります。

• クラスターまたは名前空間のコンピューティング料金。
• プライマリ リージョンとセカンダリ リージョンの間でレプリケートされるデータの帯域幅料金。

専用クラスター

Event Hubs 専用で geo レプリケーションを使用するには、少なくとも 2 つの専用クラスターを別々のリージョンに配置する必要があります。これは、geo レプリケートされる名前空間以外の名前空間をホストするために使用できます。 これらの専用クラスターは、それぞれに割り当てられた容量ユニット (CU) の数に基づいて個別に課金されます。

geo レプリケーションが有効になっている場合、唯一の追加料金は、プライマリからセカンダリにレプリケートされたデータの帯域幅料金です。 この料金は、プライマリ リージョンの場所によって異なります。

Premium 名前空間

Premium 名前空間の場合、geo レプリケーションを有効にすると、セカンダリ リージョンで同じ数の処理ユニット (CU) がプロビジョニングされます。 そのため、使用している RU の数 と 、プライマリ リージョンとセカンダリ リージョンの間で転送されたデータの帯域幅に対して料金が発生します。

たとえば、 4 つの PU でプロビジョニングされた Premium 名前空間で geo レプリケーションを有効にした場合、料金が発生します。

• プライマリ リージョン内の 4 つの PU、
• セカンダリ リージョン内の 4 つの PU、
• ジオレプリケーションされたデータの料金は、GBあたりで計算されます。

帯域幅は、プライマリ リージョンとセカンダリ リージョンの間で転送されたデータに基づいて課金されます。

価格メーター

geo のデータ転送帯域幅料金に関する価格メーターは、次の詳細と共に表示されます。

プライベート エンドポイント

このセクションでは、プライベート エンドポイントを使用する名前空間で Geo-Replication を使用する場合の追加の考慮事項について説明します。 Event Hubs でのプライベート エンドポイントの使用に関する一般的な情報については、「 Azure Event Hubs と Azure Private Link の統合」を参照してください。

プライベート エンドポイントを使用する Event Hubs 名前空間の Geo-Replication を実装する場合は、プライマリ リージョンとセカンダリ リージョンの両方にプライベート エンドポイントを作成することが重要です。 これらのエンドポイントは、アプリケーションのプライマリ インスタンスとセカンダリ インスタンスの両方をホストする仮想ネットワークに対して構成する必要があります。 たとえば、VNET-1 と VNET-2 の 2 つの仮想ネットワークがある場合は、それぞれ VNET-1 と VNET-2 のサブネットを使用して、Event Hubs 名前空間に 2 つのプライベート エンドポイントを作成する必要があります。 さらに、VNET は、クライアントがいずれかのプライベート エンドポイントと通信できるように、 リージョン間ピアリングを使用して設定する必要があります。 最後に、すべてのクライアントが DNS 情報を取得するように DNS を管理する必要があります。DNS 情報は、名前空間エンドポイント (namespacename.servicebus.windows.net) を現在のプライマリ リージョンのプライベート エンドポイントの IP アドレスにポイントする必要があります。

この方法の利点は、フェールオーバーがアプリケーション レイヤーまたは Event Hubs 名前空間で個別に発生する可能性があるということです。

• アプリケーションのみのフェールオーバー: このシナリオでは、アプリケーションは VNET-1 から VNET-2 に移行します。 プライベート エンドポイントはプライマリ名前空間とセカンダリ名前空間の両方に対して VNET-1 と VNET-2 の両方で構成されるため、アプリケーションは引き続きシームレスに機能します。
• Event Hubs 名前空間のみのフェールオーバー: 同様に、フェールオーバーが Event Hubs 名前空間レベルでのみ発生する場合、プライベート エンドポイントは両方の仮想ネットワークで構成されているため、アプリケーションは動作したままです。

これらのガイドラインに従うことで、プライベート エンドポイントを使用して、Event Hubs 名前空間の堅牢で信頼性の高いフェールオーバー メカニズムを確保できます。

関連するコンテンツ

geo レプリケーション機能の使用方法については、「geo レプリケーションの使用方法」を参照してください。