次の方法で共有

Azure Event Grid と Event Grid 名前空間の信頼性

  • [アーティクル]

この記事には、可用性ゾーンを持つ Event Grid と Event Grid 名前空間のリージョンの回復性と、リージョン間のディザスター リカバリーおよび事業継続に関する詳細情報が含まれています。

Azure における信頼性のアーキテクチャ概要については、「Azure の信頼性」を参照してください。

可用性ゾーンのサポート

可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure の可用性ゾーンの詳細情報については、「可用性ゾーンとは」を参照してください。

トピック、システム トピック、ドメイン、イベント サブスクリプションとイベント データの Event Grid リソース定義は、3 つの可用性ゾーンに自動的にレプリケートされます。 いずれかの可用性ゾーンでリージョン障害が発生した場合、Event Grid リソースは、ユーザーの介入なしに別の可用性ゾーンに自動的にフェールオーバーします。 現時点では、この機能を制御 (有効化または無効化) することはできません。 既存のリージョンが可用性ゾーンのサポートを開始すると、既存の Event Grid リソースが自動的にフェールオーバーされ、この機能が利用されます。 お客様による対応は必要ありません。

Azure Event Grid 名前空間も、可用性ゾーンを使用してリージョン内の高可用性を実現します。

前提条件

可用性ゾーンをサポートするには、お使いの Event Grid のリソースが可用性ゾーンをサポートするリージョン内にある必要があります。 可用性ゾーンをサポートしているリージョンを確認するには、サポートされているリージョンの一覧を参照してください。

価格

Event Grid は、可用性ゾーンをサポートするリージョンの可用性ゾーンを自動的にサポートするため、価格に変更はありません。

可用性ゾーンが有効になっているリソースを作成する

Event Grid は、可用性ゾーンをサポートするリージョンの可用性ゾーンを自動的にサポートするため、必要なセットアップ構成はありません。

可用性ゾーン サポートに移行する

可用性ゾーンをサポートするリージョンに Event Grid リソースを再配置すると、可用性ゾーンのサポートが自動的に受けられます。 可用性ゾーンをサポートする別のリージョンにリソースを再配置する方法については、次を参照してください。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

ディザスター リカバリーには、通常、リージョンが異常になったときの中断を防ぐためのバックアップ リソースの作成が含まれます。 このプロセス中は、ワークロードに Azure Event Grid リソースのプライマリとセカンダリのリージョンが必要になります。

アプリケーション機能の重大な損失から復旧するには、さまざまな方法があります。 このセクションでは、異常なリソースまたはリージョンによる障害から復旧するためのクライアントの準備で従う必要があるチェックリストについて説明します。

Event Grid は、サーバー側で手動と自動両方の geo ディザスター リカバリー (GeoDR) をサポートしています。 フェールオーバー プロセスをさらに細かく制御したい場合には、クライアント側のディザスター リカバリー ロジックを実装することもできます。 自動 GeoDR の詳細については、「Server-side geo disaster recovery in Azure Event Grid (Azure Event Grid 内のサーバー側 geo ディザスター リカバリー)」を参照してください。 クライアント側でディザスター リカバリーを実装する方法の詳細については、「Azure Event Grid でのクライアント側フェールオーバー実装」を参照してください。

Event Grid でのクライアント側フェールオーバーと geo ディザスター リカバリーのサポートを次の表に示します。

Event Grid リソース クライアント側フェールオーバーのサポート geo ディザスター リカバリー (GeoDR) のサポート
カスタム トピック サポートされています 地域をまたがる/地域内
システム トピック サポートされていません 自動的に有効化
ドメイン サポートされています 地域をまたがる/地域内
パートナー名前空間 サポートされています サポートされていません
名前空間 サポートされています サポートされていません

Event Grid 名前空間

Event Grid 名前空間ではリージョン間 DR がサポートされていません。 しかし、プライマリとセカンダリの名前空間を作成することで、クライアント側のフェールオーバー実装を通じてリージョン間の高可用性を実現できます。

クライアント側のフェールオーバー実装によって、次のことが可能になります。

  • 名前空間、クライアント ID、その他の構成** (CA 証明書、クライアント グループ、トピック スペース、アクセス許可バインド、ルーティングなど) をプライマリとセカンダリのリージョン間でレプリケートするカスタム (手動または自動) プロセスを実装する。

  • エンドポイントの正常性チェックを実行して、クライアントにプライマリとセカンダリのエンドポイントを提供するコンシェルジェ サービスを実装する。 このコンシェルジェ サービスは、たとえば Azure Traffic Manager を使用した DNS リダイレクト手法を使用してレプリケートされ到達可能な状態が維持される Web アプリケーションである場合もあります。

  • メタデータをレプリケートし、名前空間の間で負荷を分散することで、アクティブ/アクティブ DR ソリューションを実現する。 アクティブ/パッシブ DR ソリューションは、メタデータをレプリケートすることでセカンダリ名前空間を対応可能状態に維持し、プライマリ名前空間が使用できないときにトラフィックをセカンダリ名前空間に転送できるようにすることで実現できます。

ディザスター リカバリーを設定する

ペアになっているリージョンのため、Event Grid には、カスタム トピック、システム トピック、ドメインに対してペアのリージョンに発行トラフィックをフェールオーバーする機能が用意されています。 Event Grid は、バックグラウンドでトピック、システム トピック、ドメイン、イベント サブスクリプションのリソース定義をペアのリージョンに自動的に同期します。 ただし、イベント データはペアのリージョンにはレプリケートされません。 通常の状態では、イベントは、そのリソースに対して選択したリージョンに格納されます。 リージョンの停止が発生し、Microsoft がフェールオーバーを開始すると、新しいイベントが geo ペアのリージョンに流れ始め、そこからユーザーの介入なしでディスパッチされます。 障害が軽減された後、元のリージョンで発行および受け入れられたイベントは、そこからディスパッチされます。

Microsoft が開始するフェールオーバーと顧客が開始するものの 2 つのフェールオーバー オプションから選択できます。 これら両方の設定を構成する詳細なステップについては、「データ所在地を構成する」を参照してください。

  • Microsoft が開始するフェールオーバーは、Event Grid リソースを、影響を受けるリージョンから、対応する geo ペア リージョンにフェールオーバーするまれな状況において、Microsoft によって実行されます。 Microsoft は、このオプションを実行するタイミングを決定する権利を留保します。 このメカニズムでは、ユーザーのトラフィックがフェールオーバーされる前にユーザーの同意を必要としません。

    この機能を有効にするには、トピックまたはドメインの構成を更新します。 Microsoft が開始するフェールオーバーを有効にするには [Cross-Geo]\(クロス Geo\) (既定) を選択します。

  • 顧客が開始するフェールオーバーは、Azure Event Grid のトピックとドメインのカスタム ディザスター リカバリー 計画によって定義されます。Microsoft によって別のリージョンにデータがレプリケートされることはありません。 このフェールオーバー オプションではある程度の作業を実施する必要がありますが、高速フェールオーバーが可能になり、セカンダリ リージョンの選択を制御できます。 Azure Event Grid トピックのクライアント側ディザスター リカバリーを実装する場合は、Azure Event Grid トピックに対してクライアント側ディザスター リカバリーを独自に構築するをご覧ください。

    Microsoft が開始するフェールオーバー機能を無効にするのが適しているのには、いくつかの理由があります。

    • Microsoft が開始するフェールオーバーは、ベストエフォート ベースで実行されます。
    • 一部の地域のペアは、組織のデータ所在地の要件を満たしていません。

    この機能を有効にするには、トピックまたはドメインの構成を更新します。 [Regional](地域) を選択します。

    Event Grid カスタム トピックの [構成] ページを示すスクリーンショット。

ペアでないリージョンを使用する場合、選択したデータ所在地の構成に関係なく、メタデータはリージョン内でのみレプリケートされます。

ディザスター リカバリーのフェールオーバー エクスペリエンス

ディザスター リカバリーは、回復ポイントの目標 (RPO) と回復時間の目標 (RTO) という 2 つのメトリックで測定されます。

Event Grid の自動フェイルオーバーでは、ご利用のメタデータ (トピック、ドメイン、イベント サブスクリプション) およびデータ (イベント) に対してさまざまな RPO と RTO が用意されています。 以下の仕様とは異なる仕様が必要な場合でも、独自のクライアント側フェイルオーバーをトピックの正常性 API を使用して実装することができます。

目標復旧時点 (RPO)

  • メタデータの RPO: 0 分 該当するリソースの場合、リソースが作成、更新、または削除されると、リソース定義が geo ペアに同期的にレプリケートされます。 フェイルオーバーが発生しても、メタデータは失われません。

  • データ RPO: フェールオーバーが発生すると、ペアのリージョンから新しいデータが処理されます。 影響を受けるリージョンの停止が軽減されるとすぐに、未処理のイベントがそこからディスパッチされます。 リージョンの回復に、イベントに設定された Time to Live の値よりも長い時間が必要な場合、データの損失が発生する可能性があります。 このデータ損失を軽減するには、イベント サブスクリプションに対して配信不能の宛先を設定することをお勧めします。 影響を受けるリージョンが失われ、復旧できない場合は、データの損失が発生します。 最良のシナリオでは、サブスクライバーは発行速度に追いついており、データ損失は数秒間で済みます。 最悪のシナリオは、サブスクライバーがイベントをアクティブに処理しておらず、最大有効期間が 24 時間の場合、データ損失は最大 24 時間に及ぶ可能性があります。

目標復旧時間 (RTO)

  • メタデータ RTO: フェールオーバーの意思決定は、ペアのリージョンで使用可能な容量などの要因に基づいており、60 分以上の範囲で実行できます。 フェールオーバーが開始されると、5 分以内に、Event Grid はトピックとサブスクリプションの作成、更新、削除の呼び出しの受け入れを開始します。

  • データ RTO: 上記の情報と同じです。

重要

  • サーバー側ディザスター リカバリーの場合、ペアのリージョンに追加のトラフィックを処理する追加の容量がないと、Event Grid はフェールオーバーを開始できません。 復旧はベストエフォート ベースで行われます。
  • この機能の使用には料金はかかりません。
  • geo ディザスター リカバリーは、パートナー名前空間とパートナー トピックではサポートされていません。

次のステップ