【ITニュース解説】Why Round-Robin Load Balancing Breaks WebSockets at Scale

Webアプリケーションを支える技術の一つに、多くのユーザーからのアクセスを複数のサーバーに効率良く分散させる「ロードバランサ」という仕組みがある。これは、ウェブサイトへの大量の交通を管理し、特定のサーバーに負荷が集中するのを防ぎ、システム全体の安定稼働とパフォーマンスを維持する重要な役割を担っている。

一般的なウェブ通信であるHTTPでは、クライアントがサーバーにリクエストを送り、サーバーがそのリクエストを処理して応答を返すと、その接続はすぐに切断される。このような一連のやり取りは非常に短時間で完了し、それぞれの通信は互いに独立しているため、「ステートレス（状態を持たない）」な性質を持つ。このHTTP通信において、ロードバランシングの最も一般的で効果的な手法の一つが「ラウンドロビン」方式である。ラウンドロビンは、クライアントからのリクエストをサーバー1、サーバー2、サーバー3、そして再びサーバー1といったように、順番に均等に振り分ける単純な方法だ。この方式は設定が容易で、サーバーの利用率を均一に保ちやすいという利点があるため、多くのHTTPベースのシステムで採用されている。

しかし、現代のウェブサービスでは、チャットアプリケーション、オンラインゲーム、リアルタイム通知など、即座に情報のやり取りが必要な「リアルタイム機能」が不可欠になっている。これらの機能を実現するために、「WebSocket」という技術が広く利用されている。WebSocketはHTTPとは根本的に異なる特性を持つため、ラウンドロビン方式のロードバランシングをそのまま適用すると、システムは予測不能な問題に直面し、最終的には安定したサービス提供が困難になる可能性がある。

WebSocketとHTTPの最も大きな違いは、接続の持続性にある。HTTPが短命なリクエスト・レスポンスモデルであるのに対し、WebSocketは一度クライアントとサーバーの間で接続が確立されると、そのTCP接続が何時間も継続的に維持される「永続的な接続」を提供する。この永続性が、ラウンドロビン方式の弱点を引き出すことになる。

ラウンドロビン方式のロードバランサは、新しいWebSocket接続の開始処理（ハンドシェイク）を、順番に各サーバーに振り分ける。しかし、一度確立された接続が長時間維持されることを考慮しないため、接続が確立された後の負荷を均等に分散することはできない。結果として、時間が経つにつれて、特定の少数のサーバーにのみ大量のアクティブなWebSocket接続が集中する現象が発生する。これは「ホットスポット」と呼ばれ、一部のサーバーが数千もの接続を抱え込み、メモリやCPUに過大な負荷がかかる一方で、他の多くのサーバーはほとんどアイドル状態になる。負荷が集中したサーバーは、やがて処理能力の限界を超え、応答不能になったり、クラッシュしたりする可能性があり、これが引き金となってシステム全体が連鎖的にダウンする「カスケード障害」を引き起こす危険性がある。

この問題を解決するための最初のステップは、ロードバランサのルーティング戦略を変更することである。ラウンドロビン方式の代わりに、「Least Connections（最小接続数）」方式を採用する必要がある。この戦略では、ロードバランサが各バックエンドサーバーが現在処理しているアクティブな接続数を常に監視する。そして、新しいWebSocket接続の要求が来た際には、現在最も接続数が少なく、つまり最も負荷が低いサーバーにその接続を振り分ける。これにより、接続の負荷がサーバー間でより均等に分散され、ホットスポットの発生を大幅に抑制することができる。例えば、広く利用されているウェブサーバーであるNginxでは、least_conn;という一行をupstream設定に追加するだけで、この最小接続数による負荷分散を簡単に実装できる。

次に、接続の偏りを解消しようとして「IPハッシュ」によるルーティングを採用してしまうケースがあるが、これは現代のネットワーク環境では危険な手法である。IPハッシュは、クライアントのIPアドレスに基づいて、特定のクライアントからの接続を常に同じサーバーに送ることで、いわゆる「スティッキーセッション」を実現する。しかし、多くのユーザーが同じグローバルIPアドレスを共有する「CGNAT（Carrier-Grade NAT）」環境や大規模な企業ネットワークでは、IPハッシュを使用すると、その一つのIPアドレスに紐づく全てのユーザーが特定の単一サーバーに集中してしまう。これは負荷の偏りを解消するどころか、さらに深刻なホットスポットを作り出すリスクがあり、ロードバランシングの問題をネットワーク構成の問題にすり替えるだけで、根本的な解決にはならない。

もう一つの見落とされがちな問題は、ロードバランサの「アイドルタイムアウト」の設定である。多くのロードバランサは、デフォルトでHTTP通信向けに設定されており、例えば60秒といった比較的短いアイドルタイムアウトが適用されていることが多い。これは短命なHTTP接続には適しているが、WebSocket接続にとっては「サイレントキラー」となり得る。WebSocketでは、クライアントが長時間メッセージを送受信しないアイドル状態になることは珍しくない。このような状況でロードバランサがデフォルトの短いアイドルタイムアウトでWebSocket接続を一方的に切断してしまうと、クライアント側では接続が突然切れたことを検知し、頻繁に再接続を試みることになる。これにより、サーバーは本来の処理以外に、切断と再接続の処理に多大なリソースを浪費し、システム全体のパフォーマンスが著しく低下する。この問題に対処するためには、ロードバランサのproxy_read_timeoutなどのタイムアウト値を、例えば3600秒（1時間）のように十分に長く設定することが必須である。さらに、アプリケーションレベルで「ハートビート（ping/pong）メカニズム」を実装することも重要である。これは、クライアントとサーバーが定期的に小さな信号を送り合うことで、接続がアクティブであることを相互に確認し、ロードバランサに接続が生きていることを伝えたり、ネットワークの異常で切断された接続を能動的に検知して再接続を促したりする仕組みだ。

最後の、そして最も重要な解決策は、「ソケット状態の外部化」である。リアルタイムシステムで真の「水平スケーリング」、つまり必要に応じてサーバーを増やして処理能力を柔軟に向上させることを目指すなら、各サーバーが自分のメモリ内にクライアントの接続情報や関連する「状態」を保持する「ステートフル」な設計から脱却し、「ステートレス」な設計にする必要がある。もし、あるクライアントがサーバー1に接続していて、別のクライアントがサーバー2に接続している場合、これら二つのクライアントが直接通信しようとしても、それぞれのサーバーが互いのクライアントの状態を知らないため、直接メッセージをやり取りすることはできない。これを解決するために、クライアントの接続状態や、クライアント間で共有されるべきデータを、RedisのPub/Sub機能のような「メッセージブローカー」と呼ばれる外部のシステムに集約する。これにより、どのサーバーにクライアントが接続しているかに関わらず、メッセージを送りたいサーバーはメッセージブローカーに「このユーザーにメッセージを送ってほしい」と発行（publish）し、実際にそのユーザーが接続しているサーバーがメッセージブローカーからそのメッセージを受信（subscribe）してクライアントに届けるという仕組みが実現する。これにより、各サーバーはクライアントの接続状態そのものを持つ必要がなくなり、完全にステートレスになる。システムに新しいサーバーを追加する際も、複雑な状態同期を考慮する必要がなくなるため、システムの拡張性が飛躍的に向上する。

結論として、WebSocketのような永続的な接続を扱うリアルタイムシステムのスケーリングは、単にサーバーの数を増やすだけでは解決しない。従来のHTTP通信を前提としたロードバランシングの仮定を捨て、接続の永続性を考慮した設計が不可欠である。具体的には、最小接続数によるルーティング、適切なアイドルタイムアウトの設定とハートビートの実装、そして最も重要なソケット状態の外部化を通じてサーバーをステートレスに保つことだ。これらの対策を講じることで、大量の同時接続にも耐えうる、安定したリアルタイムシステムを構築できるようになる。