Azure Event Grid は、サービスとアプリケーション間のイベント ベースの通信を可能にするフル マネージド メッセージング サービスです。 これは、イベントドリブン アーキテクチャの構築や、Azure サービスとカスタム アプリケーションの統合に一般的に使用されます。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害など、さまざまな潜在的な障害や問題に対して Azure Event Grid の回復性を確保する方法について説明します。 また、Azure Event Grid サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。
運用環境のデプロイに関する推奨事項
Azure Well-Architected Framework は、信頼性、セキュリティ、コスト、運用、パフォーマンスに関する推奨事項を提供します。 これらの領域が互いに及ぼす影響を理解し、信頼性の高い Azure Event Grid ソリューションに貢献するには、 Azure Event Grid の Azure Well-Architected Framework ガイダンスを参照してください。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
Azure Event Grid は、イベント 発行元 からイベント コンシューマーにイベントをルーティング します。 これは、お客様のアプリケーションと Azure サービスの両方で、リソースの作成、更新、削除時の通知などのイベントを生成および使用するために使用されます。
Event Grid では、複数のリソースの種類とデプロイ モデルがサポートされています。
トピック は、イベントを受信して格納する主要なエンティティです。
システム トピック は、特定の Azure リソースの種類のイベントを生成するために、Azure サービスによって自動的に作成されます。 カスタム トピック は、ユーザーが作成および管理します。
トピックでは、 プッシュ配信とプル配信の両方をサポートできます。
イベント ドメインは、 1 つのエンドポイントの下に複数のカスタム トピックをグループ化し、イベントの発行を簡略化します。 詳細については、「 Event Grid トピックを管理するためのイベント ドメインについて」を参照してください。
名前空間は Standard レベルで使用され、複数の Event Grid リソースのコンテナーを提供します。 詳細については、「 Azure Event Grid 名前空間の概念」を参照してください。
Event Grid では、Basic レベルと Standard レベルを含む複数のレベルがサポートされています。 これらのレベルにはさまざまな機能が用意されており、リソースのデプロイと管理方法が異なります。 詳細については、「 ソリューションに適した Event Grid レベルを選択する」を参照してください。
物理アーキテクチャ
Azure Event Grid はフル マネージド サービスです。 Microsoft は、コンピューティング リソースやストレージ リソースなど、基になるインフラストラクチャを管理します。 サポートされているリージョンでは、Event Grid によって 可用性ゾーン間でリソースが自動的に分散 され、組み込みのゾーン冗長性が提供されます。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Event Grid を使用する場合は、ソリューションが一時的な障害に対する回復性を確保するために、次のプラクティスを検討してください。
イベント発行元: クライアント アプリケーションが Event Grid にイベントを発行する場合は、一時的なエラーを処理します。 アプリケーションでは、イベントを発行するときに再試行ロジックを実装する必要があります。 詳細については、「 一時的な接続の問題のトラブルシューティング」を参照してください。
一時的な障害処理を自動的に提供する Event Grid データ プレーン SDK を使用することをお勧めします。
イベント コンシューマー: Event Grid は、構成された宛先にイベントを配信します。 これらの送信接続では、イベント サブスクリプションに対して再試行ポリシーを構成します。 これらのポリシーは、一時的な障害を含め、障害が発生したときに Event Grid が配信を再試行する頻度と期間を定義します。 詳細については、メッセージ プッシュ配信と名前空間での再試行に関するトピックを参照してください。
べき等性: イベントを安全に受信し、複数回処理できるように、べき等性を考慮したイベントアーキテクチャの設計をお勧めします。 たとえば、アプリケーションがイベントを処理しているときに一時的な障害や別の問題が発生した場合、冪等性アプローチによって、アプリケーションはメッセージを再処理して回復することができます。
べき等性をサポートするようにイベント アーキテクチャとアプリケーションを設計する責任があります。 一般的な情報については、「べき等性」を参照してください。
デッドレタリング: Event Grid では、配信不能イベントに対する デッドレタリング がサポートされています。これは、イベントコンシューマーの障害が長引く際にデータを保持する上で役立ちます。 詳細については、「 Azure Event Grid の名前空間に対するイベント サブスクリプションの配信不能」トピックを参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure Event Grid リソースは、可用性ゾーンをサポートするリージョンではゾーン冗長です。 ゾーンの冗長性とは、可用性ゾーンに問題がある場合でも、Event Grid リソースが他のゾーンのインフラストラクチャを使用して引き続き機能することを意味します。 イベント データは、リージョン内の回復性のために 3 つの可用性ゾーン間で自動的にレプリケートされ、ゾーン全体の停止中に Event Grid が自己修復されます。 この機能を有効または構成する必要はありません。
この図は、それぞれ 3 つの可用性ゾーンに分散されたさまざまな Event Grid リソースを示しています。
必要条件
リージョンのサポート: ゾーンの冗長性は、 可用性ゾーンをサポートするすべての Azure リージョンで使用できます。
Cost
ゾーン冗長性の追加コストは発生しません。 この機能を有効または無効にすることはできません。これは、サポートされているリージョンに既定で含まれています。
可用性ゾーンのサポートを設定する
構成は必要ありません。 サポートされているリージョン内のすべての Event Grid リソースは、自動的にゾーン冗長になります。
すべてのゾーンが正常な場合の動作
このセクションでは、Event Grid リソースがゾーン冗長であり、すべてのゾーンが動作している場合に想定される内容について説明します。
ゾーン間操作: Event Grid は、可用性ゾーン間でアクティブ/アクティブ モデルで動作します。 クライアント接続はゾーン間で自動的に負荷分散され、サービスはゾーンに関係なく、使用可能なメッセージング インフラストラクチャに操作をルーティングします。
ゾーン間データ レプリケーション: Event Grid は、回復性を維持するために、可用性ゾーン間でメタデータとイベント データを自動的にレプリケートします。
ゾーン障害時の動作
このセクションでは、Event Grid リソースがゾーン冗長であり、いずれかのゾーンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Event Grid は、ゾーンの障害を自動的に検出し、正常なゾーンへのフェールオーバーを開始します。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
- 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Service Health を使用して、ゾーン障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することができます。
アクティブな要求: ゾーン障害時に、Event Grid によってアクティブな要求が削除される場合があります。 クライアントが 一時的な障害 を適切に処理する場合 (短時間の再試行など)、通常は重大な影響を回避します。
予想されるデータ損失: Event Grid ゾーン冗長モデルは、影響を最小限に抑えてゾーン障害に対する回復性を有効にするように設計されています。 ただし、ゾーンの障害時には、データが失われる可能性があります。
ゾーン障害が発生してもアプリケーションでデータが失われないことを確認する必要がある場合は、次の手順を実行する必要があります。
- 再試行や冪等性など、一時的な障害処理の推奨事項に従って、イベントプロデューサーおよびコンシューマーを設計します。
- ソースまたは永続的なイベント ストアでのイベントの持続性を計画します。
予想されるダウンタイム: ゾーン障害が発生すると、数秒のダウンタイムが発生する可能性があります。 クライアントが 一時的な障害 を適切に処理する場合 (短時間の再試行など)、通常は重大な影響を回避します。
トラフィックの再ルーティング: Event Grid はゾーンの損失を検出し、正常な可用性ゾーンの 1 つにあるインフラストラクチャに新しい要求を自動的にリダイレクトします。
ゾーンの回復
影響を受けるゾーンが復旧すると、Event Grid は顧客の操作を必要とせずに自動的にサービスに再統合します。 回復されたゾーンは、新しい接続を受け入れ、他のゾーンと共にメッセージを処理します。 停止中に存続中のゾーンにレプリケートされたデータはそのまま残り、通常のレプリケーションはすべてのゾーンで再開されます。 ゾーンの回復または再統合に対してアクションを実行する必要はありません。
ゾーンエラーのテスト
Event Grid では、ゾーン障害のトラフィック ルーティング、フェールオーバー、ゾーン回復を管理するため、可用性ゾーンの障害プロセスを検証したり、さらに入力を提供したりする必要はありません。
リージョン全体の障害に対する回復性
Event Grid リソースは、1 つのリージョンにデプロイされます。 リージョン全体の障害が発生した場合、Event Grid リソースは使用できません。
ペアの Azure リージョンでは、Event Grid リソースのメタデータに対して限られた地理的災害復旧が提供されます。 また、ディザスター リカバリー計画をサポートできる独自のマルチリージョン ソリューションを設計および構築することもできます。 次の表は、さまざまな種類の Event Grid リソースが各モデルをサポートする方法を示しています。
| Event Grid リソース | ジオディザスターリカバリーをサポートします | カスタム ソリューションをサポート |
|---|---|---|
| カスタム トピック | サポートされています | サポートされています |
| システム トピック | 自動的に有効化 | サポートされていません |
| ドメイン | サポートされています | サポートされています |
| 名前空間 | サポートされていません | サポートされています |
| パートナー名前空間 | サポートされていません | サポートされています |
地質災害復旧
geo ディザスター リカバリーでは、サポートされているリソースについて、Event Grid メタデータがプライマリ リージョンのペアリージョンにレプリケートされます。 イベント データはレプリケートされません。
ジオディザスターリカバリーは、重大な地域障害に対するベストエフォートで、Microsoftが管理するフォールバックとして設計されていますが、迅速かつ予測可能な復旧時間を提供することを目的としていません。 Microsoft が開始するフェールオーバーは、Event Grid リソースを、影響を受けるリージョンから、対応する geo ペア リージョンにフェールオーバーするまれな状況において、Microsoft によって実行されます。 Microsoft は、このオプションを実行するタイミングを決定する権利を留保します。 このメカニズムでは、トラフィックがフェールオーバーされる前に顧客の同意は必要ありません。
Important
Microsoft は、Microsoft が管理するフェールオーバーをトリガーします。 これは、大幅な遅延の後に発生する可能性が高く、ベスト エフォートベースで実行されます。 Event Grid リソースのフェールオーバーは、他の Azure サービスのフェールオーバー時刻とは異なる時点で発生する可能性があります。
リージョンの停止に対する回復性が必要な場合は、 回復性のためにカスタムのマルチリージョン ソリューションの 1 つを使用することを検討してください。
必要に応じて、geo ディザスター リカバリーを無効にし、リージョンの選択、フェールオーバー時間などの要件を満たす独自の カスタム マルチリージョン ソリューション を使用できます。 geo ディザスター リカバリーを無効にすると、Microsoft によってイベント データは別のリージョンにレプリケートされません。
この機能は、ペアのリージョンがないリージョンでは使用できません。
必要条件
リージョンのサポート: ジオディザスターリカバリーは、ペアのあるAzureリージョンでのみ使用できます。
リソースの種類: カスタム トピックとドメインでは、geo ディザスター リカバリーがサポートされます。 システム トピックは、ジオディザスター復旧のために自動的に有効化されます。 名前空間やパートナー名前空間など、他のリソースの種類はサポートされていません。
Cost
ジオディザスタリカバリーの追加コストは発生しません。
複数リージョンのサポートを構成する
サポートされているリージョンでは、システム トピックは地理的障害復旧用に自動的に構成されます。 その他の Event Grid リソースの種類:
ジオディザスターリカバリーを有効にするには: トピックまたはドメインの設定を更新して、クロスジオ（デフォルト）を選択します。
geo-diaster の回復を無効にするには: トピックまたはドメインの構成を更新し、[ 地域] を選択します。
すべてのリージョンが正常な場合の動作
このセクションでは、Event Grid リソースが geo ディザスター リカバリー用に構成されていて、すべてのリージョンが動作している場合に想定される内容について説明します。
リージョン間操作: すべてのトラフィックはプライマリ リージョンにルーティングされます。
リージョン間データ レプリケーション: メタデータは、ペアになっているリージョンに同期的にレプリケートされます。 イベント データはレプリケートされません。
リージョン障害時の動作
このセクションでは、Event Grid リソースが geo ディザスター リカバリー用に構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Microsoft は、リージョンの障害を検出し、フェールオーバーを開始するかどうかとタイミングを決定します。
- 通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: プライマリ リージョンへのアクティブな要求は終了します。 クライアント アプリケーションは、フェールオーバーの完了後にこれらの要求を再試行する必要があります。
予想されるデータ損失:
メタデータ： Event Grid は、フェールオーバー中にメタデータを保持します。 すべてのメタデータ変更は同期的にレプリケートされるため、メタデータの損失は予想されません。
イベント データ: プライマリ リージョンのイベント データは使用できず、リージョンが回復不能な場合は失われる可能性があります。
フェールオーバーが発生すると、ペアになっているリージョンから新しいデータが処理されます。 処理されていないイベントは、停止が軽減されるとすぐにプライマリ リージョンからディスパッチされます。 プライマリ リージョンの復旧に 、イベントに設定された Time to Live 値よりも長い時間が必要な場合は、プライマリ リージョン内のデータが削除される可能性があります。 このデータ損失を軽減するには、イベント サブスクリプションにデッドレター キューを設定することをお勧めします。
影響を受けるリージョンが失われ、復旧できない場合は、データの損失が発生します。 最良のシナリオでは、コンシューマーは発行率に追いついているので、わずか数秒のデータが失われます。 最悪のシナリオは、コンシューマーがアクティブにイベントを処理していない場合であり、最大有効期間が 24 時間の場合、データ損失は最大 24 時間になる可能性があります。
注
Event Grid では、リージョンの停止中にデータの保持を保証することはできません。 保証されたリテンション期間が必要な場合は、イベントを別のデータ ストアに永続的に格納するようにアプリケーションを設計する必要があります。
予想されるダウンタイム: ダウンタイムの量は、停止の重大度と、Microsoft がフェールオーバーを評価して開始するために必要な時間によって異なります。 ダウンタイムは少なくとも 1 時間、長くなる可能性があります。
フェールオーバーが開始されると、5 分以内に、Event Grid は、作成、更新、削除の操作など、トピックとサブスクリプションのトラフィックの受け入れを開始します。
再 分配： フェールオーバーが完了すると、トラフィックはセカンダリ リージョンに自動的にルーティングされます。
リージョンの復旧
Microsoft はリージョンの復旧を管理し、復旧プロセスは特定の停止シナリオに依存します。 通常、フェールオーバーは一方向操作として扱われます。
リージョン障害のテスト
Azure Event Grid は、geo ディザスター リカバリーのトラフィック ルーティング、フェールオーバー、復旧を管理します。 何も開始する必要はありません。 この機能は完全に管理されているため、リージョンの障害プロセスを検証する必要はありません。
回復性のためのカスタム マルチリージョン ソリューション
次のいずれかの理由で、Microsoft が開始するフェールオーバーを無効にするか、または信頼しない場合があります。
- メタデータだけでなく、リージョン間でイベント データをレプリケートする必要があります。
- 特定のフェールオーバー時間または方法を保証する必要があります。 Microsoft が開始するフェールオーバーは、ベストエフォート ベースで実行されます。
- お使いのリージョンは、別の Azure リージョンとペアリングされていません。
- あなたの地域のペアは、組織のデータ居住要件を満たしていません。
より高いレベルの制御と予測可能性のために、カスタムのマルチリージョン アーキテクチャを実装できます。 このアプローチでは、複数のリージョンに個別の Event Grid リソースをデプロイし、アプリケーション レベルでフェールオーバーを管理します。 このモデルを使用する場合は、リージョン間でリソースのデプロイ、構成、同期を行う責任があります。
マルチリージョン ソリューションを設計する場合は、次の要因を考慮してください。
レプリケーション： Event Grid リソースとその構成をプライマリ リージョンとセカンダリ リージョン間でレプリケートするカスタム プロセスを実装する必要があります。 必要に応じて、クライアント ID、CA 証明書、クライアント グループ、トピックスペース、およびアクセス許可バインドをレプリケートすることを忘れないでください。 手動レプリケーションと自動レプリケーションのどちらを実装するかを決定できます。
フェールオーバーの方法: アクティブ-アクティブ ソリューションを作成するか、アクティブ-パッシブ ソリューションを作成するかを選択できます。
- アクティブ/アクティブ ソリューション は、メタデータをレプリケートし、名前空間全体の負荷を分散することで実現できます。
- アクティブ/パッシブ ソリューション を実現するには、メタデータをレプリケートしてセカンダリ名前空間を準備し、プライマリ名前空間が使用できない場合は、トラフィックをセカンダリ名前空間に転送できるようにします。
正常性の監視: Event Grid によって提供される組み込みの正常性 API を使用して、トピックの正常性を監視できます。
クライアント アプリケーションは、リージョンの障害を検出し、イベントを別の適切なリージョンにルーティングする必要があります。
または、それらのエンドポイントに対して正常性チェックを実行することで、クライアントをトピックまたは名前空間のプライマリまたはセカンダリ エンドポイントに誘導する コンシェルジェ サービス を実装することもできます。 コンシェルジェ サービスは、GEO レプリケートされ、DNS リダイレクト手法や Azure Traffic Manager などのサービスを使用して到達可能な状態を維持する Web アプリケーションにすることができます。
コード例を含む 1 つの方法の詳細については、「 Azure Event Grid でのクライアント側フェールオーバーの実装」を参照してください。
バックアップと復元
Event Grid は主にイベント ルーティング サービスであり、ネイティブのバックアップ機能や復元機能はありません。
バックアップ機能を実装する必要がある場合、または長期保有のニーズがある場合は、アプリケーションでアーカイブを実行することをお勧めします。 そのためには、プライマリ配信パスと並行して、Azure Blob Storage などの永続ストアにイベントをルーティングまたはコピーするロジックを構築する必要があります。 ダウンストリーム システムが使用できない場合、アプリケーションはアーカイブを使用してイベントを再生できます。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、 オンライン サービスの SLA を参照してください。
Event Grid 可用性 SLA では、イベントの発行について説明します。