【ITニュース解説】Design a Scalable Chat Application Combine everything into one architecture

チャットアプリケーションの構築は一見シンプルに見えるが、ユーザーが数人から数百万人に増えると、その裏側の仕組みは非常に複雑になる。システムエンジニアにとって、ユーザーがリアルタイムでどう接続するか、メッセージはどのように届けられるか、どこに保存されるか、サーバーが故障したときに何が起こるか、数百万の同時接続をどう支えるか、オフラインのユーザーがメッセージを受け取るにはどうするか、システム全体をどう監視するかといった課題を考える必要がある。これら全ての要素が組み合わさって、大規模なシステム設計が実現する。

まず、システムを設計する前に、何を構築するのかを明確にする必要がある。WhatsAppやDiscordのようなチャットシステムを想定すると、機能面では1対1のメッセージ、グループチャット、リアルタイム配信、メッセージ履歴、オンライン/オフラインステータス、既読表示、タイピングインジケーター、メディアメッセージ、プッシュ通知のサポートが求められる。非機能面では、低い遅延、高い可用性、拡張性、メッセージの耐久性、耐障害性、監視性が重要となる。これらの要件が、システムのアーキテクチャを決定する指針となる。

次に、予想されるトラフィック量を推定する。例えば、1日1000万人のアクティブユーザーが1人あたり1日100メッセージを送る場合、1日あたり10億メッセージが発生する計算になる。これは平均で毎秒約1万1500メッセージに相当するが、ピーク時にはその数倍に跳ね上がる可能性があり、毎秒5万以上のメッセージを処理できるよう設計する必要がある。この時点で、単一のサーバーやデータベースでは処理しきれないことが明らかになる。

これらの要件とトラフィック見積もりを踏まえると、システムは複数のコンポーネントに分かれた高レベルなアーキテクチャとなる。ユーザーからの接続を受け付けるロードバランサーが、複数のチャットノードにトラフィックを分散する。チャットノードはメッセージを処理し、メッセージバス（キューやPub/Subシステム）を通じて他のサービスと連携する。メッセージはメッセージストアに保存され、プレゼンスサービスがユーザーのオンライン状態を管理し、通知サービスがプッシュ通知を送信する。このように各コンポーネントが特定の役割を持つことで、システムは独立して拡張できるようになる。

チャットアプリケーションでは、クライアントとサーバー間で常に接続を維持するリアルタイム通信が不可欠だ。従来のHTTPリクエストを繰り返し送るポーリング方式では非効率なため、WebSocketという技術を用いる。WebSocketは一度接続が確立されると、クライアントとサーバーのどちらからでも瞬時にデータを送受信できるため、新しいメッセージ、タイピングインジケーター、既読表示、オンラインプレゼンスなどのリアルタイム更新に適している。単一のチャットサーバーでは数百万ものWebSocket接続を維持できないため、ロードバランサーが複数のチャットノードに接続を分散させ、各ノードが接続の一部を管理する。ユーザーが増えれば、チャットノードを追加することで水平にスケーリングできる。

メッセージを送信する際の流れは次のようになる。ユーザーAがメッセージを送ると、まずチャットサーバーがそのメッセージを受け取る。サーバーは、ユーザーの認証状態、会話への参加権限、メッセージ内容の有効性などを検証する。メッセージは一意の「messageId」を持つことで、重複排除や冪等性を保証する。検証後、メッセージはまずメッセージデータベースに確実に保存される。これにより、たとえチャットサーバーがメッセージを処理中にクラッシュしても、メッセージが失われることはない。メッセージの保存が成功した後、そのメッセージはメッセージサービスを通じて受信者への配信や会話の更新、プッシュ通知のトリガーへと進む。

メッセージのリアルタイム配信では、受信者であるユーザーBが異なるチャットサーバーに接続している可能性があるため、チャットサーバー間でメッセージを効率的にやり取りする仕組みが必要だ。ここでメッセージブローカーが活用される。送信側のチャットノードはメッセージをメッセージブローカーに発行し、受信側のチャットノードがそれを購読してユーザーBに届ける。ユーザーのオンライン状態はプレゼンスサービスによって管理される。これは高速なインメモリストアで、どのユーザーがどのチャットノードに接続しているかを把握する。ユーザーが接続すると「オンライン」、接続が閉じると「オフライン」と記録される。

もしユーザーBがオフラインの場合、メッセージはデータベースに保存されたままとなり、システムはプッシュ通知サービスを通じてユーザーBのスマートフォンに通知を送る。その後、ユーザーBがアプリを再開し接続すると、チャットサービスは未読メッセージをフェッチし、会話履歴を表示する。これにより、オフラインのユーザーもメッセージを失うことなく受け取れる。

グループチャットはさらに複雑だ。例えば1万人のメンバーがいるグループで1人がメッセージを送る場合、そのメッセージをどう配信するかには2つの主要なアプローチがある。「ファンアウト・オン・ライト」は、メッセージが送信された時点で、グループの全メンバーの受信トレイにメッセージのコピーを書き込む方式である。読み込みは高速になるが、大人数グループでは書き込みコストが高くなる。「ファンアウト・オン・リード」は、メッセージを一度だけグループ用のストレージに保存し、メンバーが会話を開いたときに読み込む方式である。書き込みは効率的だが、読み込みコストは高くなる。実際のシステムでは、これらのハイブリッドなアプローチが採用されることもある。

チャットアプリケーションは膨大な量のデータを生成するため、データベース設計が重要だ。メッセージは「message_id」「conversation_id」「sender_id」「content」「created_at」「status」などの情報を持つテーブルに保存される。特定の会話の最新メッセージを効率的に取得するためには、「conversation_id」と「timestamp」で効率的に整理されている必要がある。メッセージ数が増えれば、単一のデータベースでは限界が来るため、データを複数のパーティションに分割したり、複数のデータベースサーバーに「シャーディング」したりする必要がある。「conversation_id」をシャーディングキーに使うことで、同じ会話のメッセージが同じシャードに保持され、メッセージの取得が容易になる。

頻繁にアクセスされるデータ（ユーザープロファイル、会話メタデータ、プレゼンス情報など）については、データベースへの問い合わせを減らすためにキャッシュを導入する。これにより、データベースの負荷を軽減し、レイテンシを低く抑えることができる。

分散システムでは故障は避けられないため、信頼性と耐障害性の設計が必須だ。例えばチャットノードの一つがクラッシュした場合、ロードバランサーはそのノードへのルーティングを停止し、他の健全なサーバーにユーザーを再接続させる。重要なコンポーネントには「冗長性」を持たせ、複数のレプリカを運用する。さらに「ヘルスチェック」「タイムアウト」「リトライ」「サーキットブレーカー」「データベースレプリカ」「自動フェイルオーバー」といった仕組みを導入し、個々の障害がシステム全体に与える影響を最小限に抑える。

また、分散システムでは同じメッセージが複数回配信される可能性がある。クライアントがメッセージを送信した後、ネットワークタイムアウトなどでサーバーが受け取ったか不明な場合、クライアントは再試行するかもしれない。これを防ぐために、クライアントはメッセージごとにユニークな「messageId」を生成し、サーバー側でこのIDをチェックして既に処理済みのメッセージであれば無視する、という「冪等性」の仕組みを導入する。メッセージの順序も重要で、複数のサーバーがメッセージを処理する中で順序が入れ替わらないよう、会話ごとにシーケンス番号を割り当て、クライアント側で正しい順序で表示する工夫が必要である。

セキュリティも最重要だ。すべての接続は認証されなければならない。ユーザーがログインすると認証サービスからアクセストークンが付与され、そのトークンを使ってWebSocket接続を確立する。サーバーはこのトークンを検証し、ユーザーが会話に参加する権限があるか、グループにアクセスする許可があるかなどを確認する。セキュリティはクライアント側ではなく、常にサーバー側で厳密に実施されるべきである。

多数のサービスとサーバーで構成されるシステムでは、問題発生時のデバッグが困難になるため、「監視性（オブザーバビリティ）」が不可欠だ。具体的には、メッセージの受信、保存、配信、失敗といったイベントを記録する「ログ」、毎秒のメッセージ数、配信遅延、アクティブなWebSocket接続数、エラー率、データベースのレイテンシ、キューのサイズなどを追跡する「メトリクス」、そしてクライアントからメッセージがシステム全体をどのように流れていくかを追跡する「トレース」を収集し、ダッシュボードでの可視化やアラート設定に活用する。

これら全ての要素を組み合わせた全体的なアーキテクチャでは、ユーザーからのメッセージはロードバランサーを介してチャットノードに到達し、認証・検証後にメッセージサービスによってデータベースに保存される。その後、メッセージイベントはメッセージブローカーに発行され、プレゼンスサービスで取得した受信者の接続情報に基づいて、適切なチャットノードからユーザーにリアルタイムで配信される。オフラインの受信者にはプッシュ通知が送られ、ログ、メトリクス、トレースによってこの一連の流れが常時監視される。

このシステムが拡張性を実現するのは、各コンポーネントが独立してスケールできるためである。接続数が増えればチャットノードを追加し、メッセージ処理量が増えればメッセージ処理ワーカーを増やし、データベース負荷が高まればレプリカを追加したりシャーディングしたり、キャッシュ負荷が高まればキャッシュクラスターを拡張するといった対応が可能だ。これにより、システム全体のボトルネックとなっている部分だけを効率的にスケールできる。

システム設計には常にトレードオフが存在する。WebSocketはリアルタイム通信を実現するが、接続管理が複雑になる。メッセージブローカーはサービス間の疎結合を促進するが、追加のインフラが必要となる。キャッシュはレイテンシを削減するが、キャッシュの一貫性を維持する課題がある。シャーディングはデータベースの水平拡張を可能にするが、運用が複雑になる。リトライは一時的な障害に対処するが、リトライの連鎖でシステムに過負荷をかける可能性もある。完璧なアーキテクチャは存在せず、システム設計はこれらのトレードオフを理解し、要件に合わせて最適な選択をすることに他ならない。

大規模でスケーラブルなチャットアプリケーションの設計は、システム設計の主要な概念のほとんどを網羅する。要件定義とトラフィック見積もりから始まり、WebSocketによるリアルタイム通信、ロードバランシングによる接続のスケーリング、メッセージブローカーによるサーバー間配信、データベースによるメッセージ永続化、キャッシュによる低遅延アクセス、パーティショニングとシャーディングによる大規模データセット対応、冗長性とフェイルオーバーによる信頼性、リトライと冪等性による安全なメッセージ配信、ログ・メトリクス・トレースによる監視性といった要素を組み合わせていく。最終的なアーキテクチャは、あらゆる最新技術を使うことではなく、リアルタイム性、拡張性、信頼性、運用性を兼ね備えたシステムを構築するために、適切なコンポーネントを組み合わせることで成立する。システム設計は、要件理解から始まり、規模の見積もり、アーキテクチャの選択、ボトルネックの特定、キャッシュの導入、コンポーネントのスケーリング、障害への対応、監視機能の追加、そして継続的な改善という一連のプロセスで構成される。