「AWS Summit Japan 2026」レポート 第3回

リージョンを使い分ける運用から「DynamoDB」設計のポイントまで

Nintendo Switch 2の新体験「ゲームチャット」の実装　低遅延とコスト効率の両立に挑むバックエンドの工夫とは

DynamoDB設計時に意識した「3つのポイント」

　続いて、バックエンドアプリケーション開発を担当する吉岡氏より、アプリケーション開発観点でのDynamoDBの取り組みについて深掘りされた。

　DynamoDBは、AWSが提供するキーバリュー型のフルマネージドなNoSQLデータベースであり、スケーラビリティの高さと低遅延を安定して維持できる点が特徴だ。今回のゲームチャットでは、特にスケーラビリティが決め手となり選定された。

　まずは、こうした強みを十分に生かすために、設計時に意識したポイントが3つ挙げられた。

　まず1点目は「コスト効率」だ。

　キーバリュー型DBはキー指定で取得できるアイテム単位でデータを取り扱う。DynamoDBではこの読み書きのたびにキャパシティユニットを消費し、コストに直結する。そしてその消費は、データのサイズとアクセス数に依存し、同じサイズのデータでは書き込みの方が大きくなる。

　こうした点から、シンプルなクエリで、最低限のデータを少ない読み書きでやり取りできる設計を心掛けたという。

アクセス種別やサイズでコストが変わるキーバリュー型

　2点目は「ユースケース主導」だ。

　アプリケーションからのデータアクセスは可能な限りキー指定で取得できる形で実装する必要があり、さらには、複数のクエリを組み合わせるとキャパシティユニットを大量消費してしまう。だからこそ、どのようなデータアクセスが発生するのかを、テーブル設計段階で把握する必要がある。

　今回はDynamoDBの開発経験者が少なかったため、まず暫定のRDB向けのデータ構造を整理して、必要なAPIを仮設計した。そこからユースケースとアクセスパターンを洗い出し、最後にそれに合わせたキーとパラメーターを特定する手法をとった。

　3点目は「非正規化」だ。

　DynamoDBは、RDBのようにJOIN（結合）をサポートしない。そのため、1回のクエリで必要な情報を取得できるよう、正規化をせずにリスト情報などをアイテム内でそのまま冗長に保持する（非正規化）ことがある。結果、アプリケーション側で整合性を考慮する必要が生じるため、要件に応じてデータの更新や参照を設計する必要がある。

非正規化

　「これらは基本的なポイントだが、実際の開発時にこれらの前提を十分に踏まえていないと、想定外の挙動や制約に直面してしまう」（吉岡氏）

結果整合に対応した2つの事例と実装の工夫

　最後に、結果整合（一時的なデータのズレは許容して、最終的には整合を担保する）で発生した問題に対応した2つの事例が紹介された。まずは、「状態遷移処理」における結果整合への対応だ。

　ゲームチャット開始時に、グループサーバーでは、「予約済み」「認証済み」「接続済み」という段階的な状態でユーザーを管理している。そして、チャット内でのゲーム画面の共有やカメラ利用といった機能は、“接続済み”のステータスになることでAPIを介してクライアントに提供される。

　ただ、クライアントがチャットに接続した状態でAPIを呼び出しても、グループサーバーのステータスがひとつ前の“認証済み”の状態に見え、実行できないことがある。これは、接続済みへの状態の変更がクライアントとは非同期で進行するのに加えて、DynamoDBの反映タイミングの差が重なることで起こりえる。

　本来ならエラーにするのが厳密な設計だが、認証済み状態を経て本人確認も終わっているため、不正利用でないことは明らかだった。そこで、APIの呼び出し時に、ユーザーの状態が認証済みでもAPI実行できるよう調整した。「結果整合や非同期処理によって一時的に状態の見え方がずれることを前提に、許容できる範囲を見極め、必要以上にエラーを多用しない設計にしている」（吉岡氏）

エラーとせず状態がひとつ前でも許容する設計に

　2つ目の開発事例は、分散ストレージによる結果整合への対応だ。

　DynamoDBは内部的に複数のアベイラビリティゾーン（AZ）内で自動複製されるが、レプリケーション間の同期遅延が存在するため、読み取りの結果整合を考慮する場面がある。

DynamoDBの読み取り不整合

　実際に対応に迫られたのが、2026年に公開した「追加招待機能」の実装時だった。通常は、通信上の問題などで存在しないチャットに誤って招待しないよう、認証などを経てチャットへの接続が完了することで、ようやくフレンドへの招待通知が送信される。しかし、追加招待の場合はこの前提が成り立たない。

　既に接続済みの状態であるため、招待通知の構築に必要な情報も含まれる招待操作に伴うDBへの書き込みとほぼ同時に、招待通知が発行されてしまう。その結果、データの同期が間に合わず、招待情報のデータを取得できないケースが発生する。

　この問題の代表的な対応策として、常に最新のデータを取得させる「Consistent Read（強い整合性）」を設定する方法があるが、キャパシティユニットが増加するため採用せず、今回はアプリケーション側のロジックで補完した。

　具体的には、招待操作時の情報と入室中のチャットに含まれる情報から直接、招待通知を構築する仕組みに変更。DBの読み込み自体をなくす工夫を凝らした。

読み込み不整合への対応