つづいて鈴木さんは、マスターデータの管理と配信について話題を移しました。
Googleワークスペースを全社的に利用しており、スプレッドシートも使われています。スプレッドシートは大量のデータ管理に向いており、計算などもできるため、ゲーム開発とも相性が良いと鈴木さんはつづけます。
『学園アイドルマスター』では、なんとマスターデータをスプレッドシートで管理し、これをMy SQLへ取り込む形でゲームに反映しているといいます。
同期元となる環境のマスターデータを取得し、それを作業中の環境に取り込んで差分を抽出、表示された差分を確認して、問題がなければ同期を実行するという形になっています。管理ツール上ではマスターデータのバリデーションも実行でき、リリース前にはこれらチェックをすべて通す必要があります。
データベースにインポートされたマスターデータをリリースする際には、マスタータグという仕組みを使用しており、MySQLに保存されたデータをパッキングして、タグという形で個別に保存。バージョニングとして利用でき、管理ツールからタグを切り替えることでマスターデータを配信することができます。
鈴木さんは、トランザクションワークロードにおけるキャッシュ戦略について話題を変え、講演を進めていきました。
トランザクションワークロードとは、サーバーなどにかかる処理の負荷や作業量の大きさやデータベースなどのシステムにおける一連の処理という意味ですが、モバイルゲームの特徴として「テーブル数が多い」「書き込み比率が高い」といった特徴があり、データーベース負荷がとても高くなりやすいといいます。
データベース通信を減らすために必要なのがクエリキャッシュで、いくつかのパターンがあるなか、QualiArtsではサーバー上のインメモリのクエリキャッシュを実装していると説明しました。
今回実装したクエリキャッシュでは、テーブルごとに3つの内部APIで構成されたデータアクセス層（リポジトリ）が自動生成され。アプリケーションレイヤーはこのリポジトリを利用してデータアクセスすることが可能となっています。
ここで使われるのは、クエリを構築するクエリビルダー、検索結果をキャッシュしておくサーチリザルトキャッシュ、更新データをバッファリングしておくミューテーション、ウェイト、バッファーの3つの内部APIです。
最後に鈴木さんは、ツールや基盤整備などでうまれた安定運用のための機能を紹介しました。
『学園アイドルマスター』は、Slackbotで作成したタスクがCloud Taskに送信され、Cloud RANでリリース処理が実行されています。つまり、Slack上からデータリリースされているのです。
スナップショットは、ユーザーデータを保存して別の環境に反映するための機能になっており、不具合の発生しているユーザーデータを開発環境に反映して検証したり、デバッグや難易度調整でユーザーデータを作成するためにも利用しています。
ほかにもお知らせエディタやプロデュースコントローラーなどの独自ツールが開発・運用がされているとのことです。
組織編成の都合で少人数編成でアプリ導入やサーバー運用をしなくてはいけない状況で、コードを自動生成するツールを開発し、マスターデータの配信機能やキャッシュ機構に工夫をこらし、アクセスが集中してもプレイヤーが快適なプレイを提供できるようにと環境を構築していることが伝わってきました。
今後ゲーム上でさまざまな運用・アップデートが重なっていくと、サーバー運用もまた変化していくと思われます。その際にどのようなアイディアをもちいてサーバー運用で同作を支えていくのか、また同社ゲーム作品にどのように反映されていくのかには注目です。
￥24,322
(価格・在庫状況は記事公開時点のものです)
