Azure Web PubSub Service は、WebSocket プロトコルを使用してサーバーとクライアント間の双方向通信を可能にする、フル マネージドのリアルタイム メッセージング サービスです。 1 つの Web PubSub リソースを 100 万の同時 WebSocket 接続にスケーリングできます。 このサービスでは、サーバー間ブロードキャスト、名前付きグループへのメッセージング、クライアントからクライアントへの pub/sub、AI トークン ストリーミングなど、いくつかのメッセージング パターンがサポートされています。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害など、さまざまな潜在的な障害や問題に対して、Azure Web PubSub サービスに回復性を持たせる方法について説明します。 また、サービスがメンテナンスをどのように処理するかについても説明し、Azure Web PubSub サービス レベル アグリーメント (SLA) に関する重要な情報を強調表示します。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境のワークロードの場合は、次の推奨事項に従います。
- Premium レベルを使用します。 Premium レベルは、サポートされているリージョンでの可用性ゾーンの障害に対する回復性があり、geo レプリケーションを構成できます。
- Azure Web PubSub Client SDK を使用してクライアント アプリケーションを構築するか、安全に再接続して一時的な障害処理のガイダンスに従います。 ゾーン フェールオーバー、リージョン フェールオーバー、一時的な障害はすべてアクティブな接続をドロップします。
- geo レプリケーションを有効にして、リージョン全体の障害から保護します。 フェールオーバー イベント中に予想されるトラフィックの負荷全体を処理するのに十分な単位で各レプリカのサイズを設定します。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
作成するリソースは Web PubSub リソースです。 同時接続の最大数を含め、リソースの容量を表す ユニット数でリソースを構成します。 詳細については、「Azure Web PubSub Service の
Web PubSub リソースには、 contoso.webpubsub.azure.comのようなグローバルに一意のエンドポイントがあります。 クライアントは、このエンドポイントへの WebSocket 接続を確立します。 アプリケーション サーバーは、同じエンドポイントに接続してメッセージを送信し、クライアントからイベントを受信します。
詳細については、Azure Web PubSub サービス内部を参照してください。
物理アーキテクチャ
Azure Web PubSub Service は、一連のコンピューティング リソースにわたる WebSocket 接続状態とメッセージ ルーティングを管理します。 Microsoftは、基になるインフラストラクチャを管理します。 サービスが使用する個々の VM や、その他のインフラストラクチャ コンポーネントを直接表示したり、操作したりすることはありません。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
WebSocket は、有効期間が長い接続プロトコルです。 一時的なネットワーク イベント、バックエンド インフラストラクチャの再起動、サービス メンテナンス操作によって、アクティブな接続が切断される可能性があります。 基本的な再接続では接続が復元されますが、追加のロジックがないと、クライアントは停止中またはキューに入っていたメッセージを失います。
Azure Web PubSub サービスは、生の WebSocket 接続の上に配置される実行可能なサブプロトコルを通じてこの問題に対処します。 サブプロトコルはメッセージ シーケンスと接続状態を追跡するため、接続が切断されると、クライアントはサービスと再ネゴシエーションを行い、中断したところから再開します。
通常、接続が切断されて再接続された後にメッセージが失われることはありません。 ただし、メッセージの損失が発生する場合があります。 たとえば、クライアントが 1 分以上切断した後、同じ接続 ID で再接続すると、再接続操作でエラー状態が表示され、メッセージが失われる可能性があることを示します。
信頼性の高いサブプロトコルを利用するには、次の推奨事項に従います。
可能であれば、Azure Web PubSub クライアント SDK を使用します。 SDK は、信頼できるサブプロトコルを自動的に実装します。 その他の構成は必要ありません。 詳細については、以下を参照してください。
- JavaScript 用 Web PubSub クライアント側 SDK
- Azure Web PubSub クライアント ライブラリ（.NET 用）
- Azure Web PubSub クライアント ライブラリ for Python
- Azure WebPubSub クライアント ライブラリ for Java
SDK を使用できない場合は、信頼性の高いサブプロトコルの 1 つ を WebSocket クライアント コードに直接実装します。 完全な仕様と実装のガイダンスについては、 信頼性の高い WebSocket クライアントの作成に関するページを参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure Web PubSub サービスでは、Premium レベルを使用する場合にゾーン冗長デプロイがサポートされます。 可用性ゾーンをサポートするリージョンで Premium レベルの Web PubSub リソースを作成またはアップグレードすると、ゾーンの冗長性が自動的に有効になります。 このサービスは、そのインフラストラクチャをリージョン内の複数の可用性ゾーンに分散します。 1 つのゾーンで障害が発生した場合、サービスはトラフィックを正常なゾーン内のインフラストラクチャにルーティングします。
Requirements
リージョンのサポート: ゾーン冗長は、両方の条件が適用されるほとんどのリージョンでサポートされています。
- Azure Web PubSubサービスを利用できます。 サービスが利用可能なリージョンの一覧については、「 リージョン別の製品の可用性」を参照してください。
- リージョンは可用性ゾーンをサポートしています。 可用性ゾーンを持つリージョンの一覧については、「Azure リージョンの一覧」を参照してください。
ただし、現在、西日本では、Azure Web PubSubのゾーン冗長はサポートされていません。
層： ゾーン冗長は Premium レベルで利用できます。
Cost
ゾーン冗長ではコストは追加されません。Standard Premium レベルの料金を支払います。 詳細については、「Azure Web PubSub サービスの価格」を参照してください。
可用性ゾーンのサポートを設定する
ゾーン冗長では、Premium レベルを選択する以外の構成は必要ありません。 どちらの場合も、自動的に有効になります。
新しいゾーン冗長 Web PubSub リソースを作成します。 リソースの作成時に Premium レベルの SKU を選択します。 詳細については、「
Azure Web PubSub リソースの作成。 既存のリソースを Premium レベルにアップグレードします。 既存のリソースを Premium レベルの SKU にアップグレードすると、ゾーン冗長が自動的に有効になります。 Standard から Premium にアップグレードしても、サービスのダウンタイムは発生しません。 詳細については、「Azure Web PubSub サービス インスタンスのスケーリングを参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、ゾーン冗長性のためにAzure Web PubSub リソースを構成し、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
Cross-zone operation: Azure Web PubSub Service は、可用性ゾーン間での接続と操作の分散方法を自動的に管理します。 複数のゾーンのインフラストラクチャは、アクティブ/アクティブ モデルでトラフィックを処理します。 この動作を利用するために何も構成する必要はありません。 サービスは複数のゾーン間でメッセージを自動的にルーティングするため、1 つのゾーン内のクライアントによって送信されたメッセージは、他のゾーンに接続されているクライアントに配信されます。
クロス ゾーン データ レプリケーション: Azure Web PubSub サービスは顧客データを保持しません。 サービスは、アクティブな接続の接続状態やメッセージ シーケンス情報などのセッション メタデータを保持します。 このメタデータは、可用性ゾーン間で同期的にレプリケートされます。
ゾーン障害時の動作
このセクションでは、ゾーンの冗長性のためにAzure Web PubSub リソースを構成し、可用性ゾーンのいずれかで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Azure Web PubSub サービス プラットフォームは、可用性ゾーンでの障害の検出を担当します。 ゾーンのフェールオーバーを開始するためのアクションを実行する必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: ゾーン障害が発生すると、影響を受けるゾーン内のインフラストラクチャへのアクティブな WebSocket 接続が削除されます。 クライアントが短時間後に再接続するなどして 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。
Expected data loss: Azure Web PubSub Service はメッセージを保持しないため、ゾーン障害によってAzure Web PubSub サービス内でデータ損失が発生することは想定されません。 ただし、アクティブな接続はゾーンダウン イベント中に削除されるため、アクティブに送信されているデータは失われる可能性があります。
発行元が Azure Web PubSub Client SDK を使用するか、信頼できるサブプロトコルを実装する場合、サービスが受信した後、そのメッセージはサービスによって確認されます。 メッセージが確認されると、すべての可用性ゾーンにレプリケートされるため、発行元のゾーンが失敗してもメッセージが失われることはありません。 ただし、サブスクライバーが削除される前にメッセージを受信しない場合は、メッセージを受信しない可能性があります。
予想されるダウンタイム: 通常、切断されたアクティブな接続の再接続には数秒かかります。 再接続ロジックを実装するクライアントでは、中断が最小限に抑えられます。
Redistribution: Azure Web PubSub Service はゾーンの損失を検出し、正常なゾーン間でトラフィックを自動的に再配布します。 何らかのアクションをとる必要はありません。
ゾーンの回復
可用性ゾーンが復旧すると、Azure Web PubSub サービスによって自動的にアクティブなサービス トポロジに再統合されます。 ゾーンの回復に対して何らかのアクションを実行する必要はありません。
ゾーンの復旧後、復旧されたゾーン内のインフラストラクチャに新しい接続が送信される可能性があります。 既存の接続は復旧されたゾーンに移動または再調整されませんが、既存の接続が削除され、時間の経過と同時に再接続されると、徐々に再調整されます。 ゾーン間の接続の不均衡は、ワークロードに影響しません。
ゾーンエラーのテスト
Azure Web PubSub サービスは、ゾーン冗長 Premium レベルリソースのトラフィック ルーティング、フェールオーバー、ゾーン復旧を自動的に管理します。 何も開始する必要はありません。 ゾーンの冗長性はフル マネージドであるため、可用性ゾーンの障害プロセスを検証する必要はありません。
リージョン全体の障害に対する回復性
Azure Web PubSub サービスは、単一リージョンのサービスです。 リージョンが使用できなくなった場合、Web PubSub リソースも使用できなくなります。
リージョン全体の障害からアプリケーションを保護するには、Premium レベルで使用できる geo レプリケーションを使用できます。 または、複数の Web PubSub リソースを異なるリージョンにデプロイすることで、カスタム マルチリージョン ソリューションを構築することもできます。
geo レプリケーション
geo レプリケーションを使用すると、Web PubSub リソースの replicas を他のAzure リージョンに追加できます。 すべてのレプリカは、単一のエンドポイント (contoso.webpubsub.azure.com) を共有します。 このエンドポイントの背後では、Azure Traffic Managerは DNS ベースのルーティングを使用して、各クライアントを最も近い正常なリージョン レプリカに転送します。 リージョンで障害が発生した場合、Traffic Manager は正常性チェックによってエラーを検出し、そのレプリカへのクライアントの転送を停止します。 新しいクライアント接続は、最も近い正常なレプリカに自動的にルーティングされます。
Web PubSub リソースを作成したリージョンは プライマリ リージョンと呼ばれ、そのレプリカは プライマリ レプリカです。 プライマリ リソースのコントロール プレーンは、Web PubSub リソースの構成を管理します。
Requirements
- Region support: Azure Web PubSub Service が利用可能な任意のリージョンにレプリカを追加できます。
- 層： geo レプリケーションを有効にするには、Premium レベルを使用する必要があります。
- レプリカの制限: 各プライマリ Web PubSub リソースは、最大 8 つのレプリカをサポートします。
考慮事項
構成の継承: レプリカは、プライマリ リソースからほとんどの構成設定を継承します。 特定の設定は、各レプリカで個別に構成する必要があります。 継承されない設定の完全な一覧については、「Azure Web PubSub の
Geo-replication」を参照してください。 構成の変更: プライマリ コントロール プレーンは、プライマリ リージョンで、Web PubSub リソースへの構成変更を処理します。 プライマリ コントロール プレーンが使用できない場合、リソース構成を更新することはできませんが、既存のレプリカは中断することなくデータ トラフィックを処理し続けます。
Cost
各レプリカは、独自のユニット数と送信メッセージ ボリュームに基づいて個別に課金されます。 レプリカ間でメッセージが転送され、別のリージョンのクライアントまたはサーバーに配信された場合、送信メッセージとして課金されます。 詳細については、「Azure Web PubSub サービスの価格」を参照してください。
ジオレプリケーションの構成
Web PubSub リソースにレプリカを追加または削除するには、Azure Web PubSub での
容量の計画と管理
各レプリカは、トラフィックを個別に処理します。 リージョンフェールオーバー中、障害が発生したリージョンのクライアントは、最も近い正常なレプリカに再接続します。 残っているレプリカがこの余分な負荷を吸収するのに十分な容量を確保するには、ワークロードが通常提供する部分だけでなく、ワークロードの予想される完全なトラフィックを処理できるユニットで各レプリカを構成します。
または、各レプリカで自動スケールを有効にして、負荷の増加に応じてユニットが自動的にスケールアウトできるようにします。 セカンダリ レプリカが使用できない場合でも自動スケールは引き続き機能しますが、プライマリ コントロール プレーンが使用できない場合、自動スケールは機能しません。 自動スケールの詳細については、「Azure Web PubSub サービスの自動スケール ユニットを参照してください。
戦略としてのオーバープロビジョニングに関する一般的なガイダンスについては、「 オーバープロビジョニングによる容量の管理」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、geo レプリケーション用に Azure Web PubSub Service を構成し、すべてのリージョンが運用可能な場合に想定される内容について説明します。
リージョン間の操作: Azure Traffic Managerは、各クライアントを最も近い正常なリージョン レプリカにルーティングします。 異なる地理的領域のクライアントは、異なるレプリカに接続する場合があります。 Web PubSub サービスは、レプリカ間でメッセージを同期して、任意のレプリカに接続されているクライアントが相互に通信できるようにします。
リージョン間データ レプリケーション: メッセージがレプリカに送信されると、サービスはそのメッセージを他のレプリカに同期的に転送し、他の場所に接続されているクライアントがメッセージを受信できるようにします。 大規模なグループへのブロードキャストや単一の接続のメッセージングなど、最も一般的なメッセージング パターンでは、同期のオーバーヘッドは最小限です。 小規模なグループ (メンバーが 10 人未満) へのメッセージングでは、同期のオーバーヘッドが若干高くなる可能性があります。
Azure Web PubSub サービスはメッセージを保持しません。アクティブな配信のみがレプリカ間で同期されます。
リージョン障害時の動作
このセクションでは、geo レプリケーション用に Azure Web PubSub Service を構成し、いずれかのレプリカ リージョンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Web PubSub Service は、リージョンの障害を検出し、構成した他のいずれかのリージョンのレプリカに着信トラフィックを自動的に再ルーティングする役割を担います。
Notification: Microsoftは、リージョンがダウンしたときに自動的にユーザーに通知しません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
アクティブな要求: 障害が発生したリージョン内のレプリカへのアクティブな WebSocket 接続が削除されます。 レプリカのフェールオーバー後、クライアントは再接続する必要があります。
Expected data loss: Azure Web PubSub Service はメッセージを保持しません。 障害発生時に障害が発生したリージョン内のクライアントに転送されていたメッセージが失われる可能性があります。 サービスでは顧客データが格納されないため、永続的なデータ損失は予想されません。
予想されるダウンタイム: Azure Traffic Managerは、各レプリカに対してヘルスチェックを実行します。 リージョンの停止によってレプリカの正常性チェックが失敗すると、Traffic Manager はそのレプリカのエンドポイントを DNS 解決の結果から削除します。 エンドポイントを削除した後、クライアントに更新された DNS レコードが表示されるまでに 90 秒の DNS TTL が経過する必要があります。 全体として、移行には通常数分かかります。 再接続ロジックを実装する適切に設計されたクライアントは、正常なレプリカに再接続した後、通常の操作を再開できます。
プライマリ コントロール プレーンが使用できない場合、Web PubSub リソースまたはそのレプリカの構成を変更することはできません。 ただし、WebSocket 接続は正常なレプリカで引き続き機能します。
Redistribution: Azure Traffic Manager は、受信要求を正常なレプリカに送信します。 ただし、レプリカのフェールオーバー Azure Traffic Managerが検出され、更新された DNS エントリがクライアントに反映される前にクライアントが再接続を試みると、クライアントの再接続試行が引き続き使用できないリージョンをターゲットにし、失敗する可能性があります。
DNS 更新が反映されると、再接続するクライアントは、最も近い正常なレプリカに自動的にルーティングされます。
リージョンの復旧
障害が発生したリージョンが復旧すると、Traffic Manager の正常性チェックによって復元されたレプリカが検出され、そのエンドポイントが DNS 解決に再度含まれます。 現在他のレプリカに接続されているクライアントは影響を受けず、切断されるまで接続されたままです。 最も近い正常なレプリカである場合、新しい接続は復旧されたリージョンのレプリカに再びルーティングされます。
リージョン障害のテスト
リージョンのフェールオーバーをシミュレートし、クライアント アプリケーションの再接続動作をテストするには、レプリカのエンドポイントを無効にします。 このアクションにより、Traffic Manager はそのレプリカへのトラフィックのルーティングを停止します。これにより、接続先のレプリカが使用できなくなった場合のクライアントの動作を確認できます。 詳細な手順については、 レプリカ エンドポイントの無効化または有効化に関する記事を参照してください。
回復性のためのカスタム マルチリージョン ソリューション
リージョン間の回復性が必要であっても、geo レプリケーションを使用していない場合は、複数のリージョンに個別の Web PubSub リソースをデプロイして管理し、アプリケーション サーバーに独自のフェールオーバー ロジックを実装できます。 この方法は geo レプリケーションよりも複雑であり、クライアント間接続のダウンタイムなしのフェールオーバーはサポートされません。 アーキテクチャの概要、フェールオーバー パターン、テストのガイダンスの詳細については、「Azure Web PubSub Service の
バックアップと復元
Azure Web PubSub サービスはステートレス メッセージング サービスです。 お客様のメッセージは保持せず、バックアップまたは復元の機能もありません。
リソース構成を保護するには、コードとしてのインフラストラクチャ (Bicep や ARM テンプレートなど) を使用して Web PubSub リソースを定義し、それらの定義をソース管理に格納します。 リソースを再作成する必要がある場合は、格納されている構成からリソースを再デプロイします。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス レベル アグリーメント
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。