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