Azure Notification Hubsは、Apple Push Notification Service (APNs)、Firebase Cloud Messaging (FCM)、Windows プッシュ通知サービス (WNS) など、複数のプラットフォーム通知システム (PNS) 間でプッシュ通知を管理するのに役立ちます。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害、サービス メンテナンスなど、さまざまな潜在的な障害や問題に対して Notification Hubs に回復性を持たせる方法について説明します。 また、バックアップと復元のオプションと、Notification Hubs サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。
運用環境のデプロイに関する推奨事項
運用環境のワークロードの場合は、次の推奨事項に従います。
名前空間が SLA の対象になるように、Basic レベルまたは Standard レベルを使用します。
可能な場合は、デバイス アプリケーションでの登録の代わりにインストールを使用します。
Microsoft提供の SDK を使用して Notification Hubs と対話します。
ゾーン冗長を有効にします。
リージョン全体の停止に備えて、別のAzure リージョンへのメタデータ ディザスター リカバリーを有効にします。 デバイスの登録とインストールをバックアップおよび復元する方法を計画します。
信頼性アーキテクチャの概要
Azure Notification Hubsは、名前空間と通知ハブを中心に編成されています。 名前空間は、1 つ以上のハブを含む管理境界です。 ハブは、アプリケーションのエンドポイントを表します。 デバイスは、登録またはインストールを使用してこれらのエンドポイントに 登録 します。この 場合、サービスはデバイスにプッシュ通知を送信できます。 詳細については、「 登録管理」を参照してください。
Notification Hubs は、Apple Push Notification Service (APNs) や Firebase Cloud Messaging (FCM) などのプラットフォーム通知システム (PNS) にプッシュ通知を送信します。 エンドツーエンドの通知配信は、Notification Hubs の可用性とダウンストリーム PNS プロバイダーの動作によって異なります。
信頼性の計画では、Notification Hubs が管理する次の種類のデータを区別することが重要です。
- メタデータ: 名前空間とハブの構成 (接続情報とディザスター リカバリーの構成を含む)。
- 登録データ: ユーザーとデバイスをタグとテンプレートにマップするデバイスの登録とインストール。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。
Notification Hubs は、PNS への接続時に発生する一時的な障害を自動的に処理します。 ただし、サービスまたはユーザーのデバイスが Notification Hubs と対話するときの一時的な障害を処理する責任があります。 登録操作、通知送信操作、および管理操作中に一時的なエラーが発生する可能性があります。 このガイダンスに従ってください。
登録とインストール: デバイス上のアプリケーションは、一時的な障害のために失敗した登録とインストール操作を再試行する必要があります。 Microsoft提供される SDK は再試行を自動的に処理します。 提供されている SDK を使用できない場合は、指数バックオフとジッターを用いた再試行ロジックを実装し、可能な限り登録処理が冪等になるようにしてください。
インストールを作成または更新しても冪等であるため、その操作は安全に再試行できます。 可能であれば、登録の代わりにインストールを使用します。
通知の送信と管理の操作:Microsoft提供の SDK を使用してプッシュ通知を送信し、管理操作を実行します。 これらの SDK は、一時的な障害が発生したときに自動的に再試行します。
提供されているSDKを使用できない場合は、指数バックオフとジッターを用いたリトライ ロジックを実装し、可能な場合は通知の送信処理を冪等にしてください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
可用性ゾーンをサポートするリージョンでは、Notification Hubs 名前空間は ゾーン冗長 構成をサポートします。 Notification Hubs では、一部のリージョンのすべての名前空間に対してゾーン冗長性が自動的に有効になります。 ゾーン冗長が有効になっている場合、Microsoftは、リージョン内のすべての可用性ゾーンにメタデータと登録データの両方をレプリケートします。
Requirements
リージョンのサポート:
Notification Hubs では、次のリージョン内のすべての名前空間に対してゾーン冗長性が自動的に有効になります。 次のリージョンでは、ゾーンの冗長性を無効にすることはできません。
ヨーロッパ 中東 Africa アジア太平洋 フランス中部 カタール中部 南アフリカ北部 中国北部 3 イタリア北部 韓国中部 ノルウェー東部 ポーランド中部 スウェーデン中部 スイス北部 Notification Hubs をサポートし、可用性ゾーンがある他のリージョンでは、ゾーンの冗長性は省略可能です。 これを有効にできるのは、名前空間を作成する場合のみです。
階層のサポート: 可用性ゾーンは、Notification Hubs のすべてのレベルで使用できます。
Cost
ゾーン冗長では、レベルの価格を超える追加料金が発生します。 詳細については、「 Notification Hubs の価格」を参照してください。
可用性ゾーンのサポートを設定する
新しいゾーン冗長名前空間を作成します。 新しいゾーン冗長名前空間を作成するプロセスは、使用するリージョンによって異なります。
Notification Hubs によってゾーンの冗長性が自動的に有効になっているリージョンでは、構成する必要はありません。
Important
これらのリージョンでは、Bicep ファイルやAzure Resource Manager テンプレートなどのコード ベースのデプロイでゾーン冗長性が無効に指定されている場合でも、Notification Hubs は常にゾーン冗長性を有効にして名前空間を作成します。
ゾーン冗長名前空間が不要な場合は、オプションのゾーン冗長性をサポートするリージョンに作成します。
ゾーン冗長が省略可能なリージョンでは、名前空間を作成する場合にのみ有効にすることができます。 ゾーン冗長を使用して新しい名前空間を設定する方法については、Azure ポータルでのAzure通知ハブの作成に関するページを参照してください。
既存の名前空間ゾーンを冗長にする: Notification Hubs では、既存の名前空間から可用性ゾーンへのインプレース移行はサポートされていません。 新しい名前空間をデプロイし、その名前空間に登録を移動する必要があります。 「Azure リージョン間でリソースを移動する」のガイダンスに従います。これは、同じリージョンに新しい名前空間をデプロイする場合にも適用されます。
すべてのゾーンが正常な場合の動作
このセクションでは、ゾーンの冗長性のために Notification Hubs 名前空間を構成し、すべてのゾーンが動作する場合に想定される内容について説明します。
ゾーン間操作: Notification Hubs は、リージョン内の任意のゾーンのインフラストラクチャを使用して、要求を自動的に分散して処理します。
ゾーン間データ レプリケーション: 登録データとメタデータの両方が、指定したリージョン内のすべてのゾーンに同期的にレプリケートされます。
ゾーン障害時の動作
このセクションでは、ゾーンの冗長性のために Notification Hubs 名前空間を構成し、いずれかのゾーンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Microsoftはゾーンの障害を検出し、リージョン内のフェールオーバーを管理します。 フェールオーバーを開始する必要はありません。
- 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Service Health を使用して、ゾーン障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することができます。
アクティブな要求: 処理中の管理操作、デバイスの登録、および通知を送信する新しい要求は、フェールオーバー中に失敗する可能性があります。 アプリケーションでは、 一時的な障害処理ガイダンスに従って、失敗した操作を再試行する必要があります。
予想されるデータ損失: Notification Hubs は名前空間とハブの構成と登録データを可用性ゾーン間で同期的にレプリケートするため、単一ゾーンの停止中にデータ損失が発生することは予想されません。
このレプリケーションはバックアップではありません。 共有責任モデルでは、登録データとインストール データをバックアップする責任があります。 詳細については、「 バックアップと復元」を参照してください。
予想されるダウンタイム:Microsoftがトラフィックを再ルーティングしている間は、サービスの中断が短時間発生する可能性があります。 一時的な障害処理のガイダンスに従って、これらの中断に備えてアプリケーションを準備します。
再配布: サービスは、要求を正常なゾーンに自動的にリダイレクトします。
ゾーンの回復
影響を受けるゾーンが回復したら、何もする必要はありません。 Microsoft は、復旧したゾーンを使用するように Notification Hubs インフラストラクチャを復元し、再調整します。
ゾーンエラーのテスト
Notification Hubs ゾーンのフェールオーバーを直接トリガーすることはできません。 ワークロードの動作をテストするには、非運用環境での再試行、べき等性、および依存関係の失敗に関する回復性テストを実行します。 Azure Chaos Studioを使用して、周囲のアプリケーション コンポーネントをテストすることもできます。
リージョン全体の障害に対する回復性
Notification Hubs では、 リージョン間で名前空間メタデータをレプリケートすることでメタデータのディザスター リカバリーが提供されますが、デバイス登録データはレプリケートされません。 この機能では、リージョンの停止中に手動で介入する必要があり、通知ハブのダウンタイムが発生します。
フェールオーバー中のダウンタイムと手動介入を減らす必要がある場合は、 カスタム マルチリージョン ソリューションの使用を検討してください。
Microsoft 管理のメタデータの地理的ディザスター リカバリー
Notification Hubs では、セカンダリ Azure リージョンへのMicrosoft管理されたメタデータディザスター リカバリーがサポートされます。 プライマリ リージョンにペアになっているリージョンがある場合は、そのペアになっているリージョンを選択できます。 プライマリ リージョンのペアリング状態に関係なく、 柔軟な復旧リージョンの一覧からセカンダリ リージョンを選択することもできます。 その後、Notification Hubs は名前空間のメタデータ (名前空間名、接続文字列、その他の重要な情報など) をレプリケートします。
Important
メタデータ geo ディザスター リカバリーでは、登録データはレプリケートされません。 ディザスター リカバリー シナリオがトリガーされると、登録とインストールのデータが失われる可能性があります。 復旧後にハブに登録データを再作成するソリューションを実装する責任があります。
Microsoftは、障害の宣言とフェールオーバーの開始を担当します。 その場合、Microsoftはセカンダリ リージョンに新しい名前空間を作成します。 プライマリ リージョンのメタデータを使用するため、アプリケーションは既存の名前空間名、接続文字列、ハブ名を使用してその名前空間に接続できます。
Requirements
リージョンのサポート:ペアのAzureリージョンでは、名前空間はセカンダリ リージョンとしてAzureペアリージョンを使用できます。
名前空間がペアになっていないリージョンにある場合、または別のリージョンにデータをレプリケートする場合は、次のいずれかの柔軟な復旧リージョンをセカンダリ リージョンとして選択できます。
南北アメリカ ヨーロッパ Africa アジア太平洋 ブラジル南部 北ヨーロッパ 南アフリカ北部 オーストラリア東部 米国西部 2 東南アジア 階層のサポート: メタデータディザスター リカバリー オプションは、すべての Notification Hubs レベルで使用できます。
Cost
Notification Hubs では、メタデータ geo ディザスター リカバリーを構成または使用するために追加料金は発生しません。 ただし、メタデータのレプリケートに使用されるリージョン間帯域幅に対して料金が発生します。 価格の詳細については、 帯域幅の価格 と Notification Hubs の価格に関するページを参照してください。
マルチリージョンのサポートを構成する
新しい名前空間のメタデータ geo ディザスター リカバリーを有効にします。Azure ポータルの「Azure通知ハブの作成」の手順に従います。 名前空間を作成するときに、ディザスター リカバリー構成を選択します。
既存の名前空間のメタデータ geo ディザスター リカバリーを有効または無効にします。「既存のAzure Notification Hubs名前空間のディザスター リカバリーを有効にする」の手順に従います。
デバイス登録データをバックアップします。「Azure Notification Hubs登録を一括でエクスポートおよびインポートする」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、メタデータ geo ディザスター リカバリー用に Notification Hubs 名前空間を構成し、プライマリ リージョンとセカンダリ リージョンの両方が運用可能な場合に想定される内容について説明します。
リージョン間操作: プライマリ リージョンはすべての要求を処理します。 セカンダリ リージョンは、フェールオーバーが発生しない限り、要求を処理しません。
リージョン間データ レプリケーション: 名前空間名、ハブ構成、接続文字列、その他の重要な情報などのメタデータは、リージョン間で非同期的にレプリケートされます。 登録データはレプリケートされません。 バックアップを維持するには、定期的にエクスポートする必要があります。
リージョン障害時の動作
このセクションでは、メタデータ geo ディザスター リカバリー用に Notification Hubs 名前空間を構成し、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Microsoftは、リージョンの障害を検出し、構成されたセカンダリ リージョンへのフェールオーバーをトリガーするかどうかを決定します。
- Notification: Microsoft は、リージョンがダウンしたときに自動的にあなたに通知しません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: リージョンがオフラインになると、プライマリ リージョン内の名前空間へのインフライト要求が失敗する可能性があります。 クライアントは、フェールオーバーの完了後に操作を再試行する必要があります。
予想されるデータ損失: メタデータは保持されます。 登録データは自動的にバックアップされませんが、自分でバックアップできます。 詳細については、「Azure Notification Hubs登録を一括でエクスポートおよびインポートする」を参照してください。 そうしないと、プライマリ リージョンが復旧するまで、登録データは使用できません。
予想されるダウンタイム:Microsoftがメタデータのフェールオーバーをトリガーしてから、フェールオーバーが完了するまでに時間がかかります。 時間はさまざまですが、通常は数時間かかります。
フェールオーバーが完了したら、登録データのバックアップを復元する必要があります。
再配布: フェールオーバー後、要求は、プライマリ リージョンからレプリケートされたデータを使用するセカンダリ リージョン内の名前空間にルーティングされます。 フェールオーバーが完了すると、クライアントはセカンダリ リージョンの名前空間に自動的に接続します。
リージョンの復旧
プライマリ リージョンが復旧すると、プライマリ リージョンのプライマリ名前空間にフェールバックできる可能性があります。 プライマリ名前空間は、停止前の登録データを保持します。 これは手動のプロセスであり、Microsoftはこれがどのように機能するかを説明するためにあなたと通信します。
プライマリ リージョンが復旧したら、次の操作を行う必要があります。
- 名前空間とそのデータの状態を検証します。
- 最近の登録データの変更をセカンダリ リージョンからプライマリ リージョンに同期するかどうかを決定します。
リージョン障害のテスト
geoフェールオーバーを実行することはできません。 ただし、独自のディザスター リカバリー手順をテストする必要があります。 登録がバックアップされていること、および新しい名前空間に復元できることを確認します。
回復性のためのカスタム マルチリージョン ソリューション
Microsoft管理されたメタデータ geo ディザスター リカバリーでは、メタデータのみがレプリケートされます。 この機能では、そのメタデータをセカンダリ名前空間に回復できますが、アプリケーションが引き続き動作できるように、デバイス登録をその名前空間にインポートする必要があります。 この方法では、障害発生時に手動で介入する必要があり、ダウンタイムが伴います。
復旧目標で必要なダウンタイムや手動介入が少ない場合は、カスタムのアクティブ/アクティブマルチリージョン ソリューションを実装できます。 事前に別のAzure リージョンに 2 つ目の Notification Hubs 名前空間をデプロイします。
注
このセクションでは、この種類のソリューションを設計するための基本的なガイダンスを提供します。 ソリューションの設計、実装、テスト、デプロイ、フェールオーバー、管理を担当します。
フェールオーバー: 2 番目の名前空間は作業リソースであるため、リージョンの障害を検出してその名前空間に切り替えるロジックを実装できます。
同期: 2 つ目の通知ハブをプライマリ通知ハブと同期するには、次のいずれかのオプションを使用します。
インストールの場合: 両方の通知ハブでインストールを同時に作成および更新するアプリ バックエンドを使用します。 インストールを使用すると、このレプリケーション シナリオをサポートする独自の一意のデバイス識別子を指定できます。 詳細については、 RedundantHub サンプルを参照してください。
登録の場合: プライマリ通知ハブから登録をバックアップとして定期的にエクスポートし、セカンダリ通知ハブに一括インポートするアプリ バックエンドを使用します。 詳細については、「Azure Notification Hubs登録を一括でエクスポートおよびインポートする」を参照してください。
または、バックエンドがない場合は、アプリがターゲット デバイスで起動したときに両方のハブにインストールを作成するようにアプリを構成します。 デバイスは、両方の通知ハブに新しい登録を作成します。 最終的に、セカンダリ通知ハブには、アクティブなすべてのデバイスが登録されます。
期限切れの登録とインストール: セカンダリ通知ハブの登録とインストールの有効期限が切れている可能性があります。 有効期限が切れたハンドルにプッシュされると、Notification Hubs は、PNS サーバーから受信した応答に基づいて、通知ハブに関連付けられている登録またはインストール レコードを自動的にクリーンアップします。 各送信からのフィードバックを処理し、期限切れの登録とインストールを削除するカスタム ロジックを追加することで、選択したバックアップ ソリューションから期限切れのレコードを消去できます。
未開封のアプリ: アプリが開かれていないデバイスが通知を受信しない期間があります。
コスト: 独自のセカンダリ ハブを使用して登録データを保護する場合、そのハブには通常のサービス料金が発生します。 同様に、復旧をサポートするために他のAzure リソースをセカンダリ リージョンにデプロイする場合は、通常のサービス料金で支払います。
バックアップと復元
Notification Hubs では、名前空間に格納されているすべてのデータに対して 1 つの組み込みのバックアップと復元機能は提供されません。 次のアプローチを組み合わせる必要があります。
- Bicepなどのコードとしてのインフラストラクチャ (IaC) を使用して、名前空間、ハブ、ポリシーの構成を定義します。 必要に応じてリソースを再デプロイできるように、これらの定義をソース管理に格納します。
- Azure Notification Hubs登録を一括エクスポートして、デバイス登録データをバックアップします。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Notification Hubs の場合、可用性 SLA は Basic レベルと Standard レベルを使用する名前空間に適用されます。