2023年6月23日、ベルサール渋谷ガーデンでアマゾン ウェブ サービス ジャパン合同会社による国内最大級のIT開発者向けテクニカルカンファレンス「AWS Dev Day 2023 Tokyo」が開催されました。
信頼性と拡張性に優れたクラウドサービスを低コストで提供するAWS（アマゾン ウェブ サービス）は、ゲーム業界でも大手メーカーから小規模なチームに至るまで身近な存在となっており、数多くの大手ゲームメーカーが導入しています。
そうした潮流を鑑み、2023年の「Dev Day」はスペシャルトラックの一つとして「Game開発トラック」を展開し、ゲーム業界に特化した5つのセッションが行われました。本稿は、注目のセッション「イラストで学ぶAmazon DynamoDB ～テーブル設計からパフォーマンスチューニングまで～」を中心に、同トラックで行われたセッションの模様をお届けします。
さまざまな視点からの知見を得られたGame開発トラック
「AIがゲーム開発に参戦！アセット生成やチート対策などの活用方法！」では、ゲームの開発工程を試作・本開発・運営に大別し、それぞれの工程に適したAWSのサービスを紹介。
事前に用意したアセットなどをデプロイし、直接の利益を生まない試作を速やかに終わらせるためのAmazon SageMaker Jump Start、本開発時の画像検知やキーワード検索を助けるAmazon RekognitionやAmazon Kendra、運営におけるチート検知に役立つAmazon SageMaker AutoPilotなどにスポットが当たりました。
「今年は進化の年にしよう！ ステップバイステップで目指す2023年最新ゲームアーキテクチャ」は”架空のゲームの開発現場をAWSのソリューションアーキテクト視点でレビューする”という内容のセッション。
コンテナによる環境構築、サーバーレスデータ分析論、セキュリティ対策についてなど、さまざまな視点を提示し、聴講者にゲームアーキテクチャを進化させる方法を共有しました。
「ソリューションアーキテクトが考える！マネージド型サービスを利用してゲームを作る方法」は「オンライン対戦に対応した神経衰弱のゲームを開発する」という趣旨のセッション。
インフラ構築には、サーバーホスティングのためのAmazon GameLiftを含む AWS ソリューションライブラリを利用しました。また、画像とBGMの作成には、Amanzon SageMaker JumpStartやAWS DeepComposerを用いています。このようにAWSの各種マネージド型サービスを組み合わせることで少人数・短期間でゲーム開発を終えられることが示されました。
Game開発トラックの締めくくりとなったのは、「ゲーム業界のエンジニア達に訊く！エンジニアのキャリア論！」というセッション。
株式会社カプコン、ガンホー・オンライン・エンターテイメント株式会社、株式会社スクウェア・エニックス、株式会社MIXIから最前線で活躍を続けるエンジニアや人材開発の担当が登壇。キャリアのターニングポイントはどこにあるか、AIはエンジニアの仕事を奪いうるのか、リモートワークの普及にともなう働き方の変遷など、さまざまなテーマをパネルディスカッション形式で語りました。
ゲームでの導入事例も増えているAmazon DynamoDB
Game開発トラックの中で、ひと際注目を集めていたのが、カプコンの中島淳平氏とアマゾン ウェブ サービス ジャパンの中村一樹氏とによるセッション「イラストで学ぶAmazon DynamoDB ～テーブル設計からパフォーマンスチューニングまで～」です。
まずは中村氏から、Amazon DynamoDBの特徴や魅力が紹介されました。Amazon DynamoDBは完全マネージド型のNoSQLサービスです。
KeyとValueの組み合わせのみで表現されるシンプルな構造ならではの高いスケーラビリティは、時間帯によってプレイヤー数が大きく変化するゲームと相性がよく、サーバーレスであることからサーバーの維持・管理に必要なコストを削減しつつゲームの核となる「遊びの部分」の制作に注力できます。
ビデオゲームでの導入事例は少しずつ増えており、Amazon GamesによるMMORPG『New World』にも採用されています。
今日のゲーム開発においてはRDB（リレーショナル・データべース）を採用するのが主流ですが、Amazon DynamoDBはそれに対してどのような違いや強みを持つのか？それを解説すべく、スマホアプリ『モンスタハンター ライダーズ』でリードサーバーエンジニアを務めたカプコンの中島氏が登壇しました。
カプコンのエンジニアが語るAmazon DynamoDB活用術
Amazon DynamoDBはスキーマの定義を必要としないスキーマレスデータベースであるとともに、テーブル設計がシンプルにまとまっているので「データをどこに置きたいか」だけを考えればよい、と中島氏は切り出します。
RDBにおける「レコード」をAmazon DynamoDBでは「アイテム」と呼称しますが、アイテムの配置はパーティションキーとソートキーで決まります。中島氏は続けて、この二つのキーをいかにうまく設定するかがAmazon DynamoDBにおけるテーブル設計のすべてとすらいえると語りました。
その次に、具体的なユースケースを交えた解説へ。ゲームにおいてユーザーとアイテムを管理する際は、それぞれにIDを設定し、そのユーザーが誰であるか、そのアイテムがどんな種類で、誰が所有しているかなどを分類します。
RDBを用いてのゲーム制作では、ここからユーザーを管理するユーザーテーブルとアイテムを管理するユーザーアイテムテーブルを作るのが一般的ですが、Amazon DynamoDBの場合は「データが持つ意味より開発者の意図が優先されてよい」とのこと。
中島氏は「ユーザー情報とユーザーアイテム情報は併せて使用することが多い。それならば、同一のパーティションで管理すればアクセス効率がよりよくなるのではないか」という発想から、二つの情報を一つのテーブルにまとめることにしました。
しかし、パーティションキーとソートキーの組み合わせはユニークなものにしなければユーザーがアイテムを1個しか所持できない状態になってしまうので、それを避けるためにソートキーには固有のアイテムIDも連結されます。
ただ連結させただけではテーブル名と固有IDの境目が視認しづらくなってしまうので、中島氏はそれらを区切るマークとして「＠」を使用していると説明。視認性を確保しつつ、ソートキーに複数のスキーマを詰め込んで一つのテーブルにまとめることができました。
テーブルの行を少なくするほどリターンがある
「それでは、テーブルをひとつにまとめられたら何がうれしいでしょうか？」と語る中島氏は、運用の最適化の話題へ。テーブルを少なくすると「パフォーマンス」と「コスト」両面でメリットがあるとしました。それぞれ、具体的に見ていきます。
パフォーマンス―行を少なくしてページングを回避
データベースの動作速度が落ちる要因のひとつには、クエリが適切なものになっていないことが挙げられますが、「Amazon DynamoDBはクエリの機能がシンプルなので、書き方が原因で速度が出ないことはほぼありません」と中島氏。
しかし、1クエリのやりとりでデータを1MBまでしか扱えないため、それ以上のデータを扱うとページングが発生して処理が遅くなります。
それを回避する方法の一つが、前述した「行ではなく列でデータを持つ」ことです。「RDBで1つのレポートを横へ横へと伸ばしていくのはスマートではありませんが、Amazon DynamoDBでは間違った設計ではないのです」。
また、Amazon DynamoDBはクライアントとの通信をHTTPプロトコルで行うので、他のデータベースと比べるとここのパフォーマンスが動作速度全体におよぼす影響が大きい傾向にあります。
それを補うのが、複数コマンドで複数アイテムを一気に書きかえるBatchWrite / BatchGet APIです。中島氏は「Amazon DynamoDBの高速化は、どれだけのコマンドをバッチにまとめられるかが重要です」とまとめました。
CUの使い方が明暗を分ける
バッチは一部のコマンドを失敗してしまうことがあり、そうした場合に考えられる理由は「キャパシティユニット（CU）の不足」が挙げられます。
CUは1秒間に読み込み / 書き込み処理を行える容量を示す単位で、Amazon DynamoDBの運用コストを抑えるうえで大切なのがCUの管理であると中島氏は続けます。
CUには、事前購入の「プロビジョンモード」と従量制の「オンデマンドモード」が用意されています。単価はプロビジョンの方が安価なので、コスト最適化における理想は「プロビジョンで最適な量を設定すること」となります。
しかし、BtoCであるゲーム運営でユーザーの行動（ログイン回数や頻度）を正確に予測するのはほぼ不可能です。そこで中島氏は2つの選択肢を提示しました。
1.特に読みづらいリリース直後はオンデマンドに設定し、トラフィック傾向が分かってきたらプロビジョンに切り替える
2.リリース直後は過剰といえるくらいにプロビジョンを設定しておき、トラフィック傾向が分かってきたら数を適宜調整する
中島氏は上記「2」の選択肢を強く推奨し、そのためにも普段からCUの値を計測するなどして、正確な予測はできないにしても、勘所を養っておくのが大切であるとしました。
プロビジョンモードは無料でオートスケール機能を利用できるほか、1年か3年のどちらかでリザーブしておけば費用対効果が高いので、少量でもリザーブしておくことでさらにコストを抑えられます。
また、CUはテーブルごとに設定するので、テーブルの数が少なければ少ないほど余剰分の発生が抑えられ、コスト削減につながります。
テーブルの数は、一般的なボリュームのゲームであれば1ケタから多くても20程度、気軽に遊べるカジュアルゲームであれば1テーブルにおさまっているゲームも実際にあるそうです。中島氏は、そうした数に収まらない場合はどこかでテーブル設計を間違えているか、ゲームの仕様がAmazon DynamoDBに合っていないかのどちらかであると考えられる、と補足しました。
中島氏は最後に「Amazon DynamoDBを採用する際は、テーブルの数を少なく抑えるほど管理・運用コストが低くなります。設計段階からそれを意識しましょう。ユニークなデータベースではありますが、まずは一部分だけでも導入してみてはいかがでしょうか」とセッションをまとめました。
本カンファレンスはどのセッションにも大勢の聴講者が訪れましたが、スペシャルトラックとして行われた全4業種・20セッションの中でも1、2を争うくらい早く聴講の予約が満席となったのが「イラストで学ぶAmazon DynamoDB」でした。
AWSがゲーム業界専用のサービスを集めた「AWS for Games」を2022年3月23日に立ち上げてから約1年。「AWS Dev Day 2023 Tokyo」におけるGame開発トラックの盛り上がりは、ゲーム業界の側からも、いかにAWSへ熱い視線が向けられているかがうかがえました。AWSとゲーム業界の結びつきが今後より一層強固なものになっていくことは、想像に難くありません。
AWS公式サイト
