両方式の違いは、通信遅延や通信帯域、クライアント側の処理負荷といった点にある。P2P方式は通信遅延を抑えやすい一方、参加者同士が互いに通信するため、参加人数が増えるほど通信量が増加し、端末側のエンコード・デコード処理の負荷も大きくなる。一方、SFU方式はサーバを経由するため一定の通信遅延は発生するものの、各クライアントは1本のアップロードで済み、サーバが各参加者へ映像・音声を転送する。通信帯域や端末側の処理負荷を抑えやすいというメリットがある。

　ゲームチャットでは、最大12人の同時接続とゲームプレイへの影響を最小限に抑えるという要件を踏まえ、最終的にSFU方式を採用した。

　SFUサーバはWebRTCによる音声・映像の転送に特化させ、チャットグループの作成や利用履歴の管理といった周辺機能は別のシステムへ切り分けている。これらはREST APIを提供するグループサーバが担当し、データベースにはKey-Value型NoSQLの「Amazon DynamoDB」を採用した。さらに、チャット内容のリアルタイム文字起こしには「Amazon Transcribe」を利用している。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

システム構成図（出典：講演資料）

「遅延は防ぎ、運用は楽に」をかなえるリージョンの割り切り

　SFU方式ではサーバを経由して通信するため、クライアントとの通信遅延がそのままユーザー体験に影響する。そこでゲームチャットでは、SFUサーバを複数の「Amazon Web Services」（AWS）リージョンに配置するマルチリージョン構成を採用し、通信遅延の低減を図った。

　もっとも、マルチリージョン化には運用負荷が増大するという課題もある。リリースやデプロイ、モニタリング、リソースの増強といった運用作業は、リージョン数に応じて複雑さを増していく。

　そこで採用したのが、「選択的なリージョン運用」という設計だ。マルチリージョンが不可欠なSFUサーバと、グループサーバやSFUインスタンスマネジャーをマイクロサービスとして分離し、前者のみをマルチリージョンで運用。後者は単一リージョンに集約する構成とした。

　この構成では、各サービスの変更頻度も考慮している。高橋氏は「変更頻度が高いサーバを単一リージョン、低いサーバをマルチリージョンとすることで、リリース後の運用負荷を軽減しています」と説明する。変更頻度に応じて配置を最適化することで、全リージョンへの展開が必要となるケースを最小限に抑え、運用効率の向上につなげる考えだ。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

選択的なリージョン運用（出典：講演資料）

　こうした構成を採用するに当たっては、幾つかの設計上の工夫も必要だった。

　1つは、クライアントが接続するSFUサーバを決定する「ディスカバリー」の仕組みだ。チャット開始時、クライアントはグループサーバへ問い合わせ、最適な接続先を取得する。この応答が遅れるとユーザー体験に直結するため、SFUインスタンスの一覧は独自実装のSFUインスタンスマネジャーが「Amazon DynamoDB」に集約した。グループサーバは一覧の参照と接続先の選定だけを担い、負荷の大きい処理をバックエンドへ切り出すことで、応答性能を高めている。

　もう一つのポイントは、リージョンをまたぐ認証と状態同期の実装だ。これらはSFUサーバのWebhook機能を利用して処理するが、特に工夫したのが負荷分散の仕組みだ。接続時に実行される認証Webhookは、遅延がそのまま接続時間に影響するため同期処理とした。一方、即時性が求められないイベントWebhookは、「Amazon API Gateway」と「Amazon SQS」を経由する非同期処理とし、処理を担う「Amazon ECS」も認証系とは分離した。高橋氏は「認証Webhookに負荷が集中しないよう、イベント側は経路そのものを分けています」と説明する。

　加えて、リージョンをまたぐ通信が頻繁に発生することから、システム全体のトレーサビリティーも重視した。「AWS X-Ray」を利用し、両サーバで発行したトレースIDをサービス間で引き継ぐことで、リクエストの流れを一貫して追跡できるようにした。インフラは「Terraform」でコードとして管理し、リージョンごとのリソースをモジュール化。提供地域の追加や変更にも、設定を切り替えるだけで柔軟に対応できる構成とした。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

ウェブフックによるサーバ間運用（出典：講演資料）

スケーラビリティを引き出す、DynamoDB設計の「3つの鉄則」

　続いて吉岡氏は、アプリケーション開発の視点から「Amazon DynamoDB」の活用について説明した。

　採用の決め手は、高いスケーラビリティと安定した低レイテンシだ。大規模なアクセスが見込まれるゲームチャットにおいて、これらの特性は大きなメリットになると判断したという。一方で、その性能を十分に引き出すためには、データ設計にも工夫が求められる。吉岡氏は設計上のポイントとして3点を挙げた。

　1点目はコスト効率だ。「Amazon DynamoDB」ではデータの読み書きごとにキャパシティーユニットを消費し、同じデータ量でも書き込みの方がコストは高くなる。そのため、必要最小限のデータをシンプルなクエリで取得できるよう設計することが、コスト削減につながる。

　2点目は、ユースケースを起点としたテーブル設計だ。1つの画面表示のために複数のクエリを発行するとキャパシティーユニットを余分に消費するため、どのようなデータアクセスが発生するかを設計段階で洗い出すことが重要となる。今回はまずリレーショナルデータベースでデータ構造を整理し、必要なAPIからアクセスパターンを分析した上で、取得に必要なキーやパラメーターを設計した。

　3点目は非正規化だ。「Amazon DynamoDB」にはJOIN機能がないため、必要なデータを1回のクエリで取得できるよう、あらかじめ関連データを集約し、重複を許容した形で保持する。一方で、その分データの整合性維持はアプリケーション側の責任となる。

アプリケーション側で遅延を吸収するアプローチ

　ゲームチャットでは、接続状態を「予約済み」（reserved）、「認証済み」（authenticated）、「接続済み」（connected）の3段階で管理している。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

ゲームチャットの状態遷移（出典：講演資料）

　1つ目は、状態遷移に伴う結果整合性の問題だ。画面共有やカメラ機能は接続完了後に利用可能となるため、単純な実装では接続済みのクライアントのみに許可する設計となる。だが実際には、接続完了への遷移はSFUサーバからの非同期通知で進むうえ、「Amazon DynamoDB」の反映遅延も影響する。そのため、クライアント側では「接続済み」と表示されていても、サーバ側ではまだ「認証済み」として扱われる状態が発生し得る。

　このため同チームは、不正利用には該当しない点に着目し、「認証済み」の状態でもAPIの実行を許容する設計とした。厳密なエラーチェックよりも、実運用上問題のない範囲を許容する判断だ。

　2つ目は、2026年に追加された招待機能に関する事例だ。既存のチャットにフレンドを招待する機能では、データベースへの書き込みとほぼ同時に通知送信のキューが発行される。そのため、書き込み直後の読み取りタイミングによっては、SQS経由の非同期処理でデータ取得に失敗するケースがあった。

　対策としては「Consistent Read」を利用する方法が考えられる。これは結果整合性ではなく強整合の読み取りとなり、最新状態を取得できる。ただし、コスト増加の懸念があるため、今回は採用していない。その代わりに、入室済みチャットと選択済みフレンドの情報から通知内容を同期的に生成し、DBアクセス自体を回避する設計とした。整合性をデータベース側に依存させるのではなく、アプリケーション側で吸収するアプローチだ。

　吉岡氏はこれらの事例について、「いずれもDynamoDBの特性を踏まえた設計の重要性がうかがえる」と振り返った。

大規模サービス公開1年目のリアルな所感

　所感として吉岡氏はまず利点を挙げる。「DynamoDBの特性に合わせた設計にすることで、サービス開始当初から期待していたパフォーマンスとスケーラビリティを確保できました」と振り返る。一方で注意点についても率直に語った。データ構造やアクセス方式を途中で大きく変更する場合、設計見直しのコストが高くなりやすい。試行錯誤の段階ではデータモデルの変更が頻発し、運用負荷が増大しやすい点は課題として残る。

　こうした経験を踏まえ、吉岡氏は「DynamoDBは、あらかじめデータアクセスのユースケースをある程度定義でき、変化が少ないサービスに適していると考えています」と整理する。近ごろは、AWSのデータベースサービスも進化しており、柔軟なスキーマ変更が求められるケースでは、別の選択肢も検討対象になるという。同氏は「システムの特性や開発プロセスに応じて、適切なデータベースを選択することが重要です」と締めくくった。

　これらの経験はローンチまでの過程で解消され、サービス公開後は1年間にわたり安定稼働を維持しているという。相反する要件を設計によって整理し、技術特性を見極めながら選択を積み重ねていくことが、快適なゲームチャット体験を支えている。