株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例

はじめに

株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。

本記事では、同社が開発・運用する『ソニックランブル パーティ』のバックエンドに Amazon DynamoDB と Amazon ElastiCache Serverless for Valkey を採用した経緯・技術的な工夫・得られた効果を、開発チームの声を交えて紹介します。

※本画像は株式会社セガの許諾を得て掲載しています

『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンと PC のクロスプレイに対応し、2024 年初頭に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。

解決したかった課題

グローバルに展開する Games as a Service（GaaS）のバックエンドを、少人数のチームで開発・運用できるようにすること。これが本タイトルの大前提であり、データベース選定でも最優先の要件でした。マネージドサービスを最大限活用し、インフラ運用の負荷を極力排除する方針のもと、データベースには次のような要件がありました。

• グローバル規模でスムーズにスケールできること：需要が読みにくいグローバル展開では、トラフィックの伸びに安定して追従できることが必要でした。Amazon Aurora では、API サーバーを増やすほど、各サーバーが保持するコネクションプールの分だけ DB への接続数が積み上がり、DB の接続数の上限が API サーバーのスケールの制約になりやすい構造がありました。
• リソースのサイジング・管理からの解放：ストレージ容量・CPU 性能のサイジングや、ユーザー分割（シャーディング）に伴う複数クラスターの運用といった、リソースを自分たちで管理し続ける作業そのものをなくし、キャパシティを気にせず開発に集中したいという要望がありました。
• データ量が増えても安定したレイテンシー：数千万人規模のデータを持っても、応答性能（レイテンシー）が変わらないことが求められました。
• 稼働の波・スパイクへの対応：ローンチ時のトラフィックが読みにくく、また「最初は大きく構え、後から縮小できるようにしておきたい」というゲーム業界特有の事情に、無駄なく追従できることが重要でした。

なぜ DynamoDB / ElastiCache Serverless for Valkey を選んだのか

DynamoDB 採用の決め手

複数のデータベース／クラウドサービスを比較検討したうえで、DynamoDB を採用しました。前述の課題を踏まえ、次の点が決め手となりました。

• サーバーレスで、実質無制限のスケーラビリティを持つこと
• メンテナンスウィンドウやバージョン管理を意識せず、運用し続けられること
• 接続数・ストレージ・CPU といったリソース管理から解放されること

ElastiCache Serverless for Valkey 採用の決め手

メインデータベースである DynamoDB への読み取り負荷を抑え、レイテンシーとコストを最適化するために、インメモリのキャッシュ／データストアとして ElastiCache を採用しました。ElastiCache は当初 Redis OSS エンジンのノードベース構成で構築を開始し、その後 Redis OSS 互換の Valkey エンジンによる Serverless 構成へ移行しました。Serverless を選んだ決め手は次の点です。

• ノードベースのクラスターモードで必要だったシャードやクラスターの構成・管理から解放され、少人数チームでも運用できること
• 「立ち上げ時は大きく構え、ローンチ後は規模に合わせて縮小・最適化していく」というゲーム特有の需要変動にキャパシティが自動で追従し、過剰なリソースを抱えずに済むこと
• 冗長化構成を自分たちで設計・管理しなくても、高可用性が標準で備わること

アーキテクチャ概要

主要なコンポーネントと役割は次の通りです。

• Amazon DynamoDB（メインデータベース）：主要なゲームデータを格納する永続データストア。ユーザーデータ（プロフィール・所持アイテム・進行状況等）とログデータ（行動ログ）を、基本的にシングルテーブル設計で管理しています。
• Amazon ElastiCache Serverless for Valkey（キャッシュ／リーダーボード）：ユーザーデータのキャッシュ、マッチメイキング処理の作業データ、リーダーボード（Sorted Set）などに利用。用途別に汎用の Common とリーダーボード専用の Ranking の 2 つに分けています。
• Amazon ECS on EC2（API サーバー）：API・マッチメイク・行動ログ集計加工の各アプリを配置しています。
• Amazon EKS Auto Mode + Agones：専用ゲームサーバーを管理しています。なおこちらの詳細は別記事「株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon EKS Auto Mode × Agones 活用事例」にてご紹介しています。

技術的に工夫した点

1. シングルテーブル設計とキー設計

チームはこれまでリレーショナルデータベース（RDB）の Aurora が中心で、DynamoDB の知見はほぼゼロからのスタートでした。DynamoDB は RDB のように join や任意条件での柔軟なクエリができません。RDB でもインデックス設計は行いますが、DynamoDB では、想定するアクセスパターンに合わせてキーや GSI（グローバルセカンダリインデックス）、データを非正規化してどう持つかまで含めて先に設計する必要があり、アクセスパターンがデータモデルそのものを規定します。本タイトルはユーザーデータ・アカウント・フレンド・ギルド（クルー）・ランキングなどエンティティが多く、かつ各エンティティに複数の検索軸（ユーザー ID・アカウント ID・フレンドコードなど）が必要でした。

そこで、全エンティティを 1 つのテーブルに集約するシングルテーブル設計を採用しました。各アイテムのキーに「エンティティ名」の接頭辞を付けて名前空間を分離し、検索軸は汎用的な GSI をエンティティ横断で使い回す設計としています。

たとえばアカウントデータのキー設計は次のようになっています。

※「具体例」は実際の値のイメージです。

参照時は、同じ GSI に対してエンティティ名付きのキーを指定するだけです。たとえば GSI1 は、アカウント検索にもギルド（クルー）検索にも同じ 1 本を使い回します。

例 1：アカウント ID 5555 のアカウントを引く

Query(index = Gsi1, P1 = "AccountDataEntity#A5555")

例 2：同じ GSI1 で、今度はギルド（クルー）”Dragons” を引く

Query(index = Gsi1, P1 = "CrewEntity#Dragons")

このように、少数の汎用 GSI をエンティティ横断で使い回すことで、インデックスの本数を抑えつつ、多様な検索軸に対応できます。RDB 中心だったチームにとっても、移行そのものは想定より円滑に進みました。一方で、GSI を使いこなせるようになるまでには数か月を要し、負荷試験時に GSI のキャパシティ不足に気づきにくいといった学習コストもありました。

2. トランザクションを使わず楽観ロック中心の設計

コストと性能を考慮し、トランザクションは採用せず、楽観ロック中心の設計としました。実装には、AWS SDK のオブジェクト永続化モデルが備えるバージョン属性による楽観ロックを利用し、必要な場面では SkipVersionCheck（バージョンチェックの無効化）を使い分けられるよう、データアクセス層を設計しています。

一方、ギルド（クルー）機能のように複数ユーザーが同一データを同時に更新する機能では整合性の担保が重要になるため、そうした箇所では Valkey によるロックを用いて競合を防いでいます。

3. リーダーボードのホットキー対策

ランキングは、ElastiCache（Sorted Set）でライブに集計・配信する一方、スコアはユーザーデータとして DynamoDB にも永続化しています。この DynamoDB 側のランキング用 GSI では、同一のランキング（単一のパーティションキー）に多数のプレイヤーの書き込みが集中し、特定のパーティションがホットになりやすいという課題がありました。

そこで、ランキング用 GSI のパーティションキーにユーザー ID の下 4 桁によるシャード分割（P1 = …#Shard{ユーザーID下4桁}）を導入し、書き込みを複数のパーティションに分散しています。ランキング全体の参照時は、集計タスクで各シャードを集約する構成です。

一方、キャッシュ側の ElastiCache Serverless にも同種の考慮が必要でした。ElastiCache Serverless は常にクラスターモードで動作するため、同一スロット制約を踏まえ、マルチキー操作は関連するキーを同一ハッシュスロットに寄せる（ハッシュタグを使う）キー設計が求められます。その分キーが偏る（ホットスロット化）リスクもあるため、トレードオフを意識する必要があります。本タイトルでも、設計当初にこの点を意識しておくとよいという気づきがありました。

4. グローバルローンチの急なトラフィックへの対策

2025 年 11 月のグローバルローンチは、トラフィックが読みにくい最大の山場でした。事前の暖機（ウォームアップ）として、次の対応を行いました。

• DynamoDB：Warm Throughput を利用し、マネジメントコンソールから必要なスループットを引き上げるだけで暖機が完了しました。手動でのプロビジョンドスループット調整（引き上げ後にオンデマンドへ戻す運用）と比べ、手間を大きく削減できました。
• ElastiCache Serverless：ローンチ前に最低 ECPU を設定するだけで事前に暖機できました。ローンチ後は通常運用に戻すのみで、キャパシティ調整の手間は最小限で済みました。

結果として、読みにくい急なスパイクにも問題なく追従できました。

AWS の技術支援

本タイトルの設計・実装にあたっては、AWS の技術支援プログラムである DynamoDB Immersion Day と、DynamoDB DCAD（Database Clinic in A Day）を通じて、数日間にわたる DynamoDB の勉強会・ハンズオンを実施しました。あわせて、Solutions Architect による設計相談・アーキテクチャレビュー・キー設計レビューも行っています。

特に効果が大きかったのは、次の点でした。

• 勉強会に社内の複数部署が参加したことで、「シングルテーブル設計」について複数の視点から比較・議論でき、設計の方向性を確かめられたこと
• 「TTL は設定時刻に必ず消えるわけではない」といった実運用上の注意点を事前に把握でき、誤った設計・運用のままサービスインすることを回避できたこと
• 実運用でのスケールの仕組みを聞けたことで、運用イメージを持てたこと

開発・運用面で得られた効果

開発・運用負荷を軽減し少人数運用を実現

現在、データベースを含むバックエンドを実質 1 名で開発・運用・保守できています。キャパシティ設計が不要なため、少人数でもアプリケーション開発に集中できています。

さらに、パーティショニングやシャーディングが透過的に扱えることで、開発環境と本番環境で構成を変えずに運用できる（dev/prod parity）点も大きなメリットでした。過去のプロジェクトで Aurora を利用していた際は、書き込み負荷を 1 クラスターで捌ききれず、ユーザー単位で複数クラスターにシャーディングしていました。どのクラスターにアクセスするかはアプリケーション側の振り分け（ディスパッチ）処理で制御していましたが、開発環境ではコスト都合で本番と同じクラスター構成を再現できないため、この振り分けを開発と本番で作り分ける必要がありました。一方、DynamoDB のパーティショニングや ElastiCache のシャーディングは透過的に行われ、キャパシティやシャード数の管理も不要です。そのため、アプリケーションはクラスターへの振り分けや分割を一切意識する必要がなく、同じコード・同じテーブル設計・キャッシュ構成が開発から本番までそのまま動作します。サーバーレスのため開発環境をコストのために縮小する必要もなく、本番との構成差が生じないことから、「開発で確認したものが本番でもそのまま通用する」状態になりました。

DynamoDB 移行後は、アラートが来たときを除いてほとんど監視画面を見る必要がなくなり、DB 周りの日常的な運用がほぼなくなりました。Aurora 利用時に気を配っていた、大規模テーブルのパーティション運用や肥大化に伴うパフォーマンス劣化への対処、API サーバーのスケール時のコネクション数（コネクションプール）といった懸念からも解放されています。

性能面の効果

DynamoDB のレイテンシーは、全 DynamoDB API の平均で 10 ミリ秒以下（CloudWatch の DynamoDB レイテンシー値）で安定しています。データ量が増えても応答性能が変わらないため、一貫して低いレイテンシーを維持できています。複雑なクエリを組まない（組む必要のない）設計になっていることも、クエリが重くなりにくい要因の 1 つです。

ElastiCache for Valkey については、従来利用してきた Redis と遜色ない性能を維持できています。頻繁に参照されるユーザーデータやランキングを ElastiCache でキャッシュすることで、低レイテンシーで応答しつつ、DynamoDB への読み取りアクセスも抑えられています。アクティブ・上位ユーザーほど参照頻度が高いため、限られたキャッシュ量でも高いヒット率が得られ、効率よく読み取り負荷を軽減できています。

コスト面の効果

最も実感しているのは、運用・管理まで含めたトータルでのコストメリットです。DynamoDB では、クラスター分割した Aurora での試算と比べて、開発・ステージング・QA 環境あわせて 95%、本番環境で 40〜50% のコストを削減できています。また、インフラの利用料金そのものに加え、これまで DB の運用・管理にかけていたコストまで含めて、負担が大きく下がりました。

ElastiCache Serverless については、開発環境ではノード構成と比べて大幅に低コストで運用できています。本番環境でも、スパイクに備えた過剰なプロビジョニングやリザーブドノードの事前購入が不要になり、負荷が読みにくいなかで容量を先に見込んで確保する必要がなくなりました。

可用性・耐障害性

最初のローンチ以降、無停止で安定稼働しており、サービスに影響するような障害は発生していません。

さいごに

『ソニックランブル パーティ』で得られたこうした成果を踏まえ、DynamoDB と Valkey は今後、部門の標準アーキテクチャとして後続タイトルでも採用していく予定です。なお、ElastiCache for Valkey を Serverless とノードベースのどちらで構成するかは、リザーブドノードの活用可否を踏まえて各プロジェクトで選択できるようにしています。

株式会社セガ 第4オンライン研究開発プログラム部 副部長の上園 政雄氏は、次のように話しています。

「DynamoDB と ElastiCache Serverless for Valkey は、少人数でグローバル展開を支えるうえで欠かせない基盤になりました。今後のタイトルでも標準的なアーキテクチャとして活用していきたいと考えています。」

株式会社セガ 第4オンライン研究開発プログラム部 副部長
上園 政雄 氏