Amazon DynamoDB: ゲームのユースケースと設計パターン

ゲーム会社は、ゲームステート、プレイヤーデータ、セッション履歴、およびリーダーボードなどのゲームプラットフォームのあらゆる部分で Amazon DynamoDB を使用しています。これらの会社が DynamoDB から得る主なメリットは、1 桁ミリ秒で測定される一貫した低レイテンシーを確保しながら、何百万もの同時ユーザーとリクエストに確実にスケールする DynamoDB の能力です。それに加えて、完全マネージド型サービスである DynamoDB には運用上のオーバーヘッドがありません。ゲーム開発者は、データベースの管理ではなく、ゲームの開発に集中することができます。また、単一の AWS リージョンから複数のリージョンへの拡大に関心を持つゲームメーカーは、マルチリージョンでのアクティブ/アクティブ型のデータレプリケーションのために DynamoDB のグローバルテーブルに頼ることができます。

このブログ記事では、DynamoDB を使用するゲーム会社の最も一般的なユースケースと設計パターンについて詳しく説明します。

この記事で使用される用語

この記事では、以下のデータモデリング用語を使用します。

• 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。
• 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。
• N:M モデリング: テーブルとグローバルセカンダリインデックスがあり、パーティションキーとソートキーをプライマリキーとして使用する 多対多関係のモデリング。

ゲームのユースケースと設計パターン

ユースケース: ゲームステートとプレイヤーのデータストア

プレイヤーのゲームステートとその他のプレイヤーデータを保存するための DynamoDB の使用は、ゲーム会社がミリ秒単位のアクセスレイテンシーを維持しながら、多数の同時プレイヤーに対応することを可能にします。その例として、世界中に 3 億人以上の登録プレイヤーを抱えるビデオゲームの大手企業、Electronic Arts (EA) 社について検討してみましょう。EA 社にとって、高い同時実行性は 1 秒あたり 100,000 件以上のリクエストと、1 日あたり数百万人のアクティブユーザーを意味する場合があります。DynamoDB への移行により、EA 社は古いデータベースの MySQL クラスターから 90 パーセントのコスト削減を実現しました。EA 社は DynamoDB を使って、ゲームステート、ユーザーデータ、およびゲームのインベントリデータを複数のテーブルに保存します。EA 社はユーザー ID をパーティションキーおよびプライマリキーとして使用します (1:1 モデリングパターン)。

大規模多人数参加型のオンラインロールプレイングゲーム、Battle Camp を作成した PennyPop は、1 分あたり数件しかリクエストがない Battle Camp のローンチに DynamoDB を使用し、それを 1 秒あたり 80,000 件を超えるリクエストまで拡大しました。DynamoDB は完全マネージド型サービスであるため、PennyPop の小さな開発チームが、ゲームの運営ではなく、その開発に集中することを可能にしました。また、DynamoDB を使用することによって、PennyPop は MySQL データベースをホストしてシャードすることと比較して、コストを少なくとも年間 50 パーセント節約しました。PennyPop が同じ環境をオンプレミスで実行するには、運営スタッフを 3 人から 6 人のサーバーエンジニアに倍増しなくてはならなかったでしょう。

設計パターン: DynamoDB にデータを保存するため、ゲーム会社はプレイヤー ID を使ってゲームステートとその他のプレイヤーデータを分割し、キー/値アクセスパターン (1:1 モデリング) を使用します。より細かなアクセスが求められる場合、ゲーム会社はソートキーを使用します (1:M モデリング)。これは、プレイヤーのデータセットの異なるプロパティまたはサブセットに個別にアクセスして更新することを可能にします。こうすることで、データセット全体を取り出す必要がなくなります。このアプローチでは、DynamoDB のトランザクション API を使用することによって、異なるプロパティを保存する複数の項目をトランザクション的に更新できます。ゲーム会社の中には、ユーザーデータを圧縮してコストを削減する会社もあります。例えば、PennyPop は gzip を使ってプレイヤーデータを圧縮し、それを base64 文字列として保存することで、プレイヤーデータを元のサイズの 10 パーセントに縮小します。

ユースケース: プレイヤーのセッション履歴のデータストア

ゲームメーカーは、プレイヤー、日付、および時間別のすばやい検索のために、セッション履歴とその他の時系列データを DynamoDB に保存します。例えば、毎日テラバイト規模のデータを作成する国際的なプレイヤーにサービスを提供する Riot Games 社は、プレイヤーのセッション履歴を DynamoDB に保存します。これにより、Riot Games 社のプレイヤーサポートチームは、全プレイヤーのゲーム内購入、および最後のログイン時間など、所定のプレイヤーについてすべての情報をすばやく検索することができるようになります。このデータは以前 Vertica に保存されていました。Vertica は分析に適していますが、単一キー検索には適していません。検索に数分かかることもよくありました。検索パフォーマンスを向上させるため、Riot Games 社は DynamoDB の使用を決定し、すべてのデータを Vertica から DynamoDB にコピーして、すばやい検索のために DynamoDB で全ユーザーのデータと履歴のマテリアライズドビューを作成しました。DynamoDB の使用は、検索時間を数分から 1 秒未満に短縮するために役立ちました。

設計パターン: DynamoDB にプレイヤーのセッション履歴とその他時系列データを保存するため、ゲーム会社は通常プレイヤー ID をパーティションキーとして使用し、最後のログインなどの日付と時間をソートキーとして使用します (1:M モデリング)。このスキーマは、これらのゲーム会社が、プレイヤー ID、および日付と時間を使用することによって各プレイヤーのデータに効率的にアクセスすることを可能にします。クエリは、特定の日付と時間のために単一のレコードを選択、または所定の日付と時間範囲のためにレコード一式を選択するように、簡単にカスタマイズできます。

ユースケース: リーダーボード

ゲームメーカーは、DynamoDB を使用することによって、シンプルなリーダーボードを簡単にサポートすることができます。このようなユースケースのひとつは、ゲームのトップスコアを表示する機能です。ゲーム会社がプレイヤーのトップスコアなどのプレイヤーのゲームステートをすでに DynamoDB に保存している場合、トップスコアを取得する機能はグローバルセカンダリインデックスを使用することで実装できます。

設計パターン: 属性としてのトップスコアなどのプレイヤーのゲームステートを保存する、プレイヤー ID でパーティション化されたテーブルでは、グローバルセカンダリインデックスでリーダーボードを実装することができます。インデックスはゲーム ID または名前をパーティションキーとして使用し、トップスコア属性をソートキーとして使用します (N:M モデリング)。これは、DynamoDB 開発者ガイドの「グローバルセカンダリインデックス」セクションで説明されています。

まとめ

この記事では、ゲーム会社の最も一般的な DynamoDB ユースケースと設計パターンについて説明しました。厳密な整合性と結果整合性のオプション、複数項目の ACID トランザクションのサポート、アトミックカウンター、および DynamoDB Accelerator (DAX) を使ったインメモリキャッシングにより、DynamoDB はゲームアプリケーションで一般的に見られる多数の要件を満たすことができます。

AWS におけるゲームの設計パターンに関するより詳しい情報については、Introduction to Scalable Gaming Patterns on AWS をお読みください。また、AWS でのゲーム開発に関する追加のリソースについては、Amazon Game Tech を参照してください。コメントは以下から送信でき、DynamoDB forum で新しいスレッドを開始することも可能です。

著者について

Edin Zulich は AWS のシニア NoSQL スペシャリストソリューションアーキテクトで、困難なデータ管理問題に対するスケーラブルでコスト効率性に優れたソリューションを設計できるように、あらゆる業界のお客様を助けています。2016 年に AWS に入社した Edin は、2005 年以来ずっと分散型データテクノロジーに携わっています。