永続的な接続 (WebSocket を介して維持される接続など) は、本質的に中断の影響を受けます。 Azure SignalR Service は高い信頼性とスケーラビリティを実現するように設計されていますが、インターネットに接続されているすべてのアプリケーションが考慮する必要があるクライアント切断が時折発生することがあります。
この記事では、クライアントの切断の性質、Azure SignalR Service がそれらを処理する方法 (特にサービス メンテナンス中) と、再接続の影響を最小限に抑えるようにアプリケーションを設計する方法について説明します。
高水準の指針
1. 接続の中断は避けられない
クライアントの切断は、ネットワークの不安定性、ブラウザー タブの中断、ロード バランサーの再構成、定期的なサービス メンテナンスなど、さまざまな理由とソースで発生する可能性があります。 これらは、すべてのリアルタイム アプリケーションで通常発生します。
開発者は、切断 が発生することを 想定してアプリケーションを設計し、接続ライフサイクルの標準的な部分として 再試行と再接続のロジック を実装する必要があります。
2. 再接続を軽量にする
再接続は軽量である必要があり、エンド ユーザーは可能な限り再接続が行われることさえ気付くべきではありません。 ユーザーの観点から見ると、アプリはスムーズに機能し続けます。
現在のフローを確認して、アクティブな WebSocket 接続に関連付けられているすべての操作が、その接続に本当に依存しているかどうかを判断します。 通知、オークション、チャット、ダッシュボード、コラボレーション エクスペリエンスなどの多くのアプリケーションでは、再接続は ( 通常は数秒以内に) 迅速に 行われ、影響が少なくなります。 機密性の高いデータやトランザクション データを含むアプリケーションの場合、再接続フローは重くなる可能性がありますが、永続的な接続ではなく、REST API を使用して特定の操作を切り離して実行できるかどうかを検討してください。
3. 再接続を効果的に処理する
通常、接続が切断されると、クライアントは新しい接続を確立し、通信を再開します。 この再接続プロセスの処理方法は、ユーザー エクスペリエンスとシステムの信頼性に大きく影響します。
該当する場合はステートフル再接続を使用する
Azure SignalR Service では ステートフル再接続がサポート されています。これにより、クライアントは状態を失うことなく以前の接続を再開できます。 これは、 クライアントが同じ接続 ID を 使用して再接続する場合に機能します。たとえば、一時的なネットワーク障害が発生し、クライアントが迅速に回復する場合などです。
ステートフル再接続を有効にすると、クライアントは短時間の切断期間中 (30 秒) に不在着信したメッセージを受信し続け、データ損失を減らし、エンド ユーザーが認識する中断を最小限に抑えることができます。
新しい接続 ID で再接続する場合
再接続の結果、アプリケーションの完全な再起動後など、別の接続 ID が生じる場合、クライアントは Azure SignalR Service によって新しい接続として扱われます。 開発者は、このシナリオを明示的に計画する必要があります。
考えてみてください。
- クライアントが以前に参加していたグループの再参加
- 信頼できるストアからセッション状態 (例えば、サブスクリプション) を復元すること
- メッセージ配信の保証が重要な場合は、アプリケーション レベルのストアまたはイベント ログから取得して、見落とされたメッセージを処理します。
4. 大規模な再接続中に負荷を管理する
多数のクライアントが切断され、同時に再接続しようとすると、ダウンストリーム コンポーネント (認証、状態ストア、アプリケーション サーバーなど) に余分な負荷が発生する可能性があります。 再接続トラフィックの一時的な急増を吸収するために、これらのコンポーネントを特定し、 自動スケーリング ポリシー を実装することをお勧めします。
多くのクライアントが一度に接続を交渉しようとすると、サービスによってそれらの要求の一部が制限される可能性があります。 この制限は単位数に比例します。単位数が多いほど、しきい値が高くなります。 SignalR リソースにユニットを追加する方法の詳細については、こちらをご覧ください。 さらに、スロットリングの可能性を減らすために、各再接続の試行前に少しランダムな遅延を導入します。 再試行の例については、こちらをご覧ください。
5. トランスポート オプションとホスティング モデルを慎重に検討する
- 長いポーリング および Server-Sent イベント (SSE) は、WebSocket がサポートされていない環境のフォールバックですが、通常は信頼性は 向上しません。
- セルフホスティング SignalR を使用すると、メンテナンスのタイミングとライフサイクル管理を完全に制御できるだけでなく、運用とスケーリングの責任をチームに移すこともできます。
- Azure SignalR Service のサーバーレス モードでは、切断はクライアント側のネットワーク レベルの動作であるため、接続の切断の可能性や影響は軽減されません。
サービスメンテナンス中の切断
Azure SignalR Service チームは、パフォーマンス、信頼性、セキュリティ、および機能の向上のために定期的にメンテナンスを実行します。
計画メンテナンス中、Azure SignalR Service では、接続されたクライアントへの影響を最小限に抑えるために 、グレースフル シャットダウン戦略 が採用されています。接続は設定された時間枠で 徐々に切断され 、クライアントは段階的に再接続できます。
このアプローチは、ほとんどのお客様の運用効率とユーザー エクスペリエンスのバランスを取ります。