トップ > マルチリージョン > 【AWS Summit Japan 2026】ゲームチャットを支える技術 [CDN221] セッションレポート

【AWS Summit Japan 2026】ゲームチャットを支える技術 [CDN221] セッションレポート

マルチリージョン Terraform Amazon DynamoDB
記事タイトルとURLをコピーする

はじめに

こんにちは。新人のいなみです。

先日開催された AWS Summit Japan 2026 に参加してきました。 数あるセッションの中で特に気になったのが、「ゲームチャットを支える技術」です。

タイトル

私自身、前職ではゲーム業界に携わっていたこともあり、Switch2のゲームチャットのような低レイテンシーなリアルタイム通信基盤がどう設計されているのか、興味がありました。 今回はセッションで学んだ内容を中心に、アーキテクチャのポイントをレポートします。

セッションはおおよそ以下の 4 テーマで構成されていました（と思います）

  • ゲームチャットサービスの紹介
  • システム構成
  • マルチリージョン運用
  • DynamoDB 開発手法

大きく分けて、前半パートはSREが、後半パートはDeveloperが発表するスタイルで進められました。

※資料公開されていました

Nintendo Switch 2 のゲームチャットとは

ゲームチャットは Nintendo Switch 2 で新たに追加された機能です。

ゲームプレイ中にボイスチャットができるいわゆる「ゲーム内チャット」機能ですが、 今回の登壇企業である ニンテンドーシステムズがバックエンド開発を担当しています。

ハードウェア部分であるSwitch2本体は親会社の任天堂が開発しているらしいです。 今回のセッションはバックエンドを担当するニンテンドーシステムズの発表です。

ゲームチャット（私物のSwitch2）

システム構成

WebRTC + SFU アーキテクチャ

ゲームチャットにはリアルタイム性が要件として求められます。この要件を満たすために WebRTC が採用されています。

WebRTC の構成には大きく「P2P（Peer-to-Peer）」と「SFU（Selective Forwarding Unit）」の 2 つのアプローチがあります。今回は SFU が採用されています。 なぜSFUなのかについて、セッション内でも丁寧に説明がありました。

方式 概要 特徴
P2P 参加者が相互に直接接続 参加者が増えるほど接続数が爆発的に増加。帯域・負荷が各クライアントに集中する。
SFU（Selective Forwarding Unit） 中継サーバーが各ストリームを集約・転送 クライアントは SFU に対してのみ接続。必要なストリームだけを選択的に転送するため効率的。参加者が増えてもクライアント側の負荷は一定。

ゲームチャットのように参加者が多く、かつ限られた帯域しか持たないモバイル・携帯ゲーム機環境では、SFU が合理的な選択です。

ゲームチャットのシステム構成

マルチリージョン運用

なぜマルチリージョンなのか

ゲームチャットは世界中のユーザーが使うサービスです。通信の品質、特に レイテンシー最小化のために、SFU サーバーは複数の AWS リージョンで稼働しています。

ただし、マルチリージョン構成には当然デメリットもあります。マルチリージョン化すると 開発・運用コストが高くなるという課題があります。リリース・デプロイ管理、モニタリング、障害対応、これらすべてをリージョン数だけ考慮しなければなりません。

選択的なマルチリージョン設計

この課題に対してニンテンドーシステムが取った戦略が選択的なマルチリージョン設計です。すべてのコンポーネントをマルチリージョンにするのではなく、レイテンシーに直結するコンポーネントだけをマルチリージョンにし、それ以外は単一リージョンに集約する設計です。

コンポーネント リージョン構成 理由
SFU サーバー マルチリージョン ユーザーに近いリージョンで処理することでレイテンシーを最小化
グループサーバー 単一リージョン 変更の多いアプリロジックのリリース作業をシンプルに保つ
SFU インスタンスマネージャー 単一リージョン 同上

この設計の狙いは明確で、変更の多いアプリロジックへのリリース作業はシンプルに保つ、という運用上の要件です。マルチリージョンにするとリリース手順が複雑になるため、変更頻度の高いサービスは単一リージョンに留め、安定している低レイテンシー要件のものだけをマルチリージョンとしています。 ちなみに、グループサーバーは Golang + ADOT SDK で実装しているとのことです。

「全部マルチリージョンにする」ではなく「どのコンポーネントがマルチリージョンの恩恵を本当に受けるか」を選択する設計思想が印象的でした。

IaC（Terraform）による効率的なインフラ管理

マルチリージョン構成の運用コストを下げるために、インフラ管理は Terraform モジュールによって整備されています。

アプローチは「リージョンごとに必要なリソース一式をモジュールにまとめる」というものです。

# 多分こんな感じ？リージョンごとに必要なリソースをモジュール化した例（イメージ）

module "sfu_region_ap_northeast" {
  source  = "../modules/sfu_region"
  config  = local.region_config["ap-northeast-1"]
}

module "sfu_region_us_east" {
  source  = "../modules/sfu_region"
  config  = local.region_config["us-east-1"]
}

このアプローチにより、Config 定義のみで一括リソース変更が可能になります。新しいリージョンを追加する際も、設定ファイルにリージョン定義を追加するだけで対応できるため、リージョン追加時の工数を大幅に削減できる設計となっているようです

  • リージョンを「単位」としてモジュール化することで、追加・変更が設定ファイルだけで完結
  • モジュールの再利用性によりリージョン間の設定差異を防止（設定ドリフトの抑制）
  • 新規リージョン展開の際に既存モジュールをそのまま適用できる

DynamoDB での開発手法

後半のパートでは、DynamoDB を使ったゲームチャット基盤のデータ設計について紹介がありました。

コスト効率を意識したテーブル設計

DynamoDB は RDB と異なり、テーブル設計の段階でアクセスパターンを綿密に洗い出しておくことが非常に重要です。セッションでは以下のフローで設計を進めていると紹介されていました。

ユースケースの洗い出し → アクセスパターンの確認 → クエリパターンの特定 → テーブル設計

RDB のように、まずテーブルを正規化、ではなく、まずユースケース、から検討を始めるベストプラクティスに沿った設計です。

DynamoDB はスキャンが高コストなため、設計段階でどのようなクエリが走るかを明確にしておかないと、後から不必要なコストが発生してしまいます。コスト効率を意識した設計をきっちりやっているという印象的でした。

感想

全体を通じて、大規模なコンシューマー向けリアルタイム通信基盤をどう AWS 上に構築・運用するかという実践的な内容で、学びのあるセッションでした。

特に印象的だったのが、選択的なマルチリージョン設計、という考え方です。マルチリージョンにすれば安心というわけではなく、コンポーネントごとにマルチリージョンにすべきかを明確に判断している点が、実際の運用目線で考えられた設計だと感じました。

また、Terraform モジュールによるリージョン管理の方法も参考になりました。Infrastructure as Code の恩恵を最大化するためのモジュール設計は、マルチリージョン・マルチアカウント構成を扱う際に意識したいポイントです。

なお、セッション終盤に発表者のマイクが突然入らなくなるというアクシデントがありましたが、それでも頑張って最後まで話しきっており、その姿勢をみて心の中で応援しておりました（ファイティン!）

まとめ

本セッションから得られた主なポイントです。

  • リアルタイム通信に WebRTC を採用。P2P ではなく SFU（Selective Forwarding Unit）方式で効率的なストリーム転送を実現
  • SFU サーバーはマルチリージョン展開しつつ、変更頻度の高いコンポーネントは単一リージョンに留める、選択的なマルチリージョン設計を採用
  • Terraform モジュールをリージョン単位で整備し、Config 定義のみで一括変更・リージョン追加に対応
  • DynamoDB はアクセスパターン駆動の設計が鉄則。コスト最適化のためにユースケース起点で設計を進める

以上、「ゲームチャットを支える技術」のセッションレポートでした。

いなみ(執筆記事)

元SRE。お酒は少しだけ嗜んでいます