Perconaは，データベースを選択して実装にアプローチする方法を議論している。

　データベース忍者であることは，多くのゲームデベロッパにとって必ずしも優先順位が高いわけではない。しかし，データベースの実装は，ゲームのローンチをスムーズに成功させるか，ボトルネックやログインの失敗，不幸なプレイヤーの出現などで揺れ動くかの分かれ目となる。

　先日，インディーズデベロッパのDonkey Crewがポストアポカリプス的なサバイバルMMO Last OasisのSteamアーリーアクセスを開始した際に実証されたように（参考URL），これはすべてのゲームデベロッパが取り組まなければならない繰り返しの問題となっている。

　では，なぜ AAA ゲームでもインディーズゲームでも，ローンチ時にボトルネックやパフォーマンスの問題が発生することが多いのだろうか？　その答えは通常，補助的なサービスや，デベロッパが社内であまり時間をかけずに行ったり，サードパーティに外注したりしているサービス（マッチメイキング，リーダーボード，ソーシャルコンポーネントなど）にある。

データベースの実装は，ゲームのローンチがスムーズに進むか，それとも揺れ動くかの分かれ目になる

　一般に，これらの機能のそれぞれは，データを収集して管理するために，独自のデータベースをインストールすることになる。ほとんどのゲーム会社は，ゲームのコア部分で大規模なテストを行っており，ゲーム自体はそれなりのスケーラビリティを持っているだろう。しかし，多くのデベロッパはゲームにアクセスするためにグローバルログインのようなサービスを使用する。その結果 その結果，サービス中なのに誰もアクセスできないゲームになってしまうのだ。

　データベースはゲームの設計と開発において重要な役割を果たしている。データベースは，プレイヤーデータ，ゲームの状態，パフォーマンスに関する情報を保存し，開発チームが力を注いできた環境を維持する。優れたデータベースがなければ，ゲームは正常に機能しない。そのため，時間をかけてデータベースの仕組みを理解する価値がある。データベースがなければ，大企業でも成功できないのだ。

• サービス：信頼はするが検証はする
• どのようなデータベースを使用するか？
• バトルテスト
• モニタリングに関する事項
• スケールを考慮する
• クラウドとコスト要因

サービス：信頼はするが検証はする

　ガタガタしたローンチを避けるために，多くのプロバイダが一般的なワークロードに最適なコードやツールを提供しているが，あなたのワークロードやゲーム内でのコンポーネントの相互作用には適していない可能性があると認識しておくことが重要だ。一般的に，多くの最適化が行われるはずだが，必ずしもそうなるとは限らない。固有のワークロードでテストを始めると，制限や，最初の時点では十分にテストされていなかったものが見つかるかもしれない。

　これが，オープンソースのソフトウェアコンポーネントを使用することが非常に有益である理由の1つだ。自分が何をしているのか分かっていれば，データベースのコードを修正して，それらのボトルネックのいくつかを克服できる。

Last Oasisはローンチ時にデータベースのデータ破損の問題を抱えていた

どんなデータベースを使えばいいのか？

　データベースの選択に関しては，どのようなゲームを作っているかによって変わってく。あなたはすでに道を切り開いたゲーム会社がどうやっているのかを見たいと思うだろう。あなたのゲームが成功すればするほど，より多くのトラフィックを受け取り，利用可能な多くのデータベース技術の限界に挑戦することになる。他のゲームで使われている技術を見ることで，学ぶことができる。

　たとえばMongoDBは，その柔軟性と拡張性の高さから，モバイルデベロッパやモバイルゲームアプリに非常に人気があることが分かった。MongoDBを使えば，デベロッパは非常に簡単に情報を追加したり削除したりすることができ，その場でスキーマを追加したり調整したりといったオーバーヘッドがないことが分かる。

　また，MongoDBは内部データをBSONと呼ばれる非常に読みやすい形式で保存しているが，これはBinary JSONの略で，JSONに似ているものだ。アプリケーション開発の観点から見ると，ほとんどのデベロッパがJSONを知っているだろうから，ほぼネイティブフォーマットに近いもので，モバイルゲームで人気があるのはそのレベルの統合性があるからだ。

　他のゲームで使用されている技術を見ることで，以下のことを学ぶことができる。

　大規模な多人数参加型ゲームを開発する際には，あらゆる種類の技術やツールを使って評価することになる。多くの決定は，高速にデータにアクセスする必要性，つまりインメモリデータベースを使用する必要性に基づいて行われる。

　例として，世界最大のマルチプレイヤーオンラインゲームの1つは，元々MySQL NDB Clusterで構築されており，数千とは言わないまでも数百台のマシンがクラスタ化されていた。ゲームがリアルタイムの更新を要求するため，すべてのデータはメモリに保存されていたのだ。今日では，多くのインメモリデータベースが存在しており，どのデータベースを選択するかはニーズに応じて異なる。

　何百万人ものプレイヤーがいるような大規模なゲームでは，膨大な量のデータを保存するには，作業量に応じてApache CassandraやRedisが必要になるかもしれない。両方を同時に使用することもあるだろう。

　たとえば，Redisはキャッシング，リーダーボード，スコアリングなどの用途に適しているが，Cassandraは事前に定義されたインデックスを持つ大規模なデータセットの高速読み込みに適しているため，インベントリに適している（広大なクラフトシステムを持つオープンワールドゲームや，すべてをため込むのが好きなゲーマーにとっては，静かな友人となる）。

　ほかにも数百万人規模のプレイヤーベースのデータベースが利用されている。― MySQLについてはすでに触れたが，PostgreSQLやMongoDB，その他いくつかのデータベースについても同様だ。バックエンドのデータやアナリティクスに関しては，Elasticsearchのようなものにデータが入ることもあり，データのレポートやクエリ分析のためのSQLコンポーネントを持っていることもあるだろう。

MongoDBはその柔軟性と拡張性の高さからモバイルデベロッパに人気がある

バトルテスト

　どのテクノロジーを選択するにしても，すべてのコンポーネント，とくに付属サービスを網羅した実戦テストを実施する必要がある。部門内でのテストは，予想されるローンチ条件を再現できる場合にのみ機能することを覚えておくことが重要だ。同時接続ユーザー数が500，1000，1万人の場合にのみテストを行っていても，ローンチ時に100万人のユーザーを受け入れた場合，データベースは失敗する。したがって，適切なレベルでの負荷テストは絶対に必要だ。

　ここでは，次のゲームのローンチに向けて，ローンチ前，ローンチ中，ローンチ後に検討する必要のある領域を網羅した便利なチェックリストを紹介する。

●ローンチ前

1. モニタリングを設定する ― 何が起こっているかを確認できなければ，どのようにして成功を測ることができるか？
2. ローンチ前にボトルネックを見つける ― アプリケーションの負荷テストを行い，通常の負荷とピーク時の負荷でどのようにスケーリングするかをテストする。
3. フェイルオーバーのテスト ― ローンチ日ではなく，今すぐにどれだけ迅速に復旧できるかを理解する。
4. コードフリーズ ― ゲームアプリケーションが成長し，コードや設定が変化している場合，パフォーマンスを確保するのは本当に難しい。
5. セカンドオピニオンを得る ―信頼するが検証する準備をする。やる価値はある。
6. バックアップをチェックする ― データベースの信頼性の高い一貫性のあるバックアップがあることを確認してほしい。

　部門内でのテストは，予想されるローンチ条件を再現できる場合にのみ機能する。

●ローンチ時

1. フェイルオーバーは最後の手段 ― フェイルオーバーはトラフィックを新しいサーバーに移動させる。キャッシュのウォームアップに時間がかかるため，トラフィックが追加されるとほとんどのシステムは遅くなる。
2. オールハンズイベント ― 問題が手に負えなくなる前に監視，調整，修正するために適切なスタッフが待機している。
3. 目標に目を向ける ― 一時的な修正により，人々がゲームをプレイできるようにする。インパクトを与える時間は有限だが，同様に重要なことは，プレッシャーを感じている人はミスをしやすいということだ。ただ，最終的には恒久的な解決策にすることを忘れないでほしい。
4. 地獄への道 ― 問題を悪化させず，変更する前にその影響を知ること。地獄への道は善意で舗装されている。
5. 収集して保存― 状況が悪化しているときに必要なデータを取得して，次のアップデートやローンチに向けて分析したり改善したりできるようにする。

●ローンチ後

1. データを分析する ― 将来のローンチに向けて戦略を計画し，強化し，微調整するためにあなたのデータを使用してほしい。
2. 迅速な修正を排除する ― 停滞期に恒久的な修正を行うために，時間と費用をかけてほしい。
3. 失敗から学ぶ - 将来の問題やリスクを軽減するための計画を構築する。
4. システムを更新する ― 遅い時間帯を利用して，最新のビルドとセキュリティ修正を入手する。
5. 自己満足してはいけない ― それぞれのアプリケーションとユーザーベースは生きている，呼吸している存在であり，前回のローンチ時にはうまくいったことが次回はうまくいかないかもしれない。定期的に分析し，計画し，レビューしよう。

モニタリングの重要性

　ゲームローンチのチェックリストでモニタリングを第一に考えるのには理由がある。データベースのパフォーマンスの限界がどこにあるかを理解することは重要だが，限界を超えそうになったときにそれを知ることも重要だ。

　モニタリングは，とくにコアゲームの一部ではない補助的なサービスには不可欠なコンポーネントだ。パフォーマンスの問題をピンポイントで特定するためには，モニタリングツールを用意することが非常に重要だ。

PerconaのMatt Yonkovit氏

　MySQL，MariaDB，PostgreSQL，MongoDBなどのデータベース用のオープンソースの監視・管理ツールがあるが，どのようなツールが必要かは，ネットワークトラフィックやゲームアプリケーションの使用状況など，監視対象によって異なる。複数のデータベースを使用している場合は，当社独自のPercona Monitoring and Managementのようなものを使用して管理ツールを統合すると，本当に役立つ。

　オープンソースのほかにも，多くのプロプライエタリなツールがある。たとえば，我々はアプリケーションスタックにNew Relicを使用している多くの企業と協力している。しかし，ツールセットだけではない。適切なレベルのロギングやデバッグの設定を行っていることを確認することで，問題を迅速に発見して理解できる。

スケールを考慮する

　スケーラビリティへのアプローチを計画するには，ゲームのライフサイクルがどのようなものであるかを知る必要がある。ゲームの種類によってパターンは異なる。AAAのショーケースゲームは，一般的に大規模なローンチ期間があり，トラフィックが急増し，その後，徐々に興味が落ち着くようになる。マルチプレイヤーマッチメイキングサービスのスケーラビリティを構築していないと，ローンチ時にとくに苦しい思いをすることになる。そのため，最初の1〜2か月は過剰なプロビジョニングを考慮する必要がある。

　モバイルゲーム，とくに小規模なインディーズタイトルは，ライフサイクルが長期化する傾向があり，その分，伸びが鈍くなる可能性がある。モバイルゲームで見られる主な違いは，トラフィックが非常にギザギザしていることだ。たとえば，数か月間利用率が低く，注目度の高いレビューやアップデートによってゲームが一時的に流行ることもあるだろう。

　スケーラビリティへのアプローチを計画するには，ゲームのライフサイクルがどのようになるかを知る必要がある。

　トラフィックが増加したり，新機能や拡張機能がリリースされたりすると，システムや基盤となるインフラストラクチャの負荷が変化する。作業負荷の変化により，ボトルネックとなっている場所が大幅に変化する可能性があり，すべてが適切にスケーリングされているかどうかを確認するために，ほぼ確実に反復テストが必要になる。

　データベースが次のゲームのアップデートに対応できるかどうか分からない場合は，このチェックリストに沿って，よくある落とし穴を回避してほしい。

1. トップに10％を追加する ― 昨年のトラフィックレベルでデータベース環境のパフォーマンスを測定し，10％増加させる。このアプローチはベンチマークを提供するだけでなく，以前に遭遇した問題が解決されているかどうかを発見できる。この最初のシナリオを実行した後は，たとえば25％や50％のシナリオを繰り返すことができる。
2. 災害に備えた計画を立てる - データベースがダウンした場合，適切なデータバックアップとリカバリープランがあることを確認する必要がある。プロセスを文書化し，共有することで，障害発生時にキーパーソンが利用できないことが判明した場合の単一障害点を回避できる。
3. しっかりとした監視 ― ゲーム開始前，開始中，終了後にデータベース環境を監視できるように設定しておく必要がある。クエリの数，クエリの応答時間の増加，ディスクやCPUの使用量や飽和度にとくに注意を払う必要がある。
4. ゲームローンチ＝人材 ― すべてのタイムゾーンをカバーするために，24時間体制で，問題を迅速に診断し，解決策を実行するための専門的な知識を持った適切なスタッフが配置されているか，またはオンコールで待機していることを確認してほしい。
5. 障害を把握する ― データベースのブレークポイントを見つけるために負荷を増加させる。複数の障害シナリオを実行し，復旧までの時間を測定する。

クラウドとコスト要因

　ほとんどのデベロッパは，ゲームをスケールアップする方法を考えているが，必ずしもスケールダウンを考えているわけではない。とくに現在，多くのゲームバックエンドがホストされているクラウド空間では，コストに注意する必要がある。ゲームのスケールダウンを運用するのにどれくらいのコストがかかるか知っているだろうか？　これは我々が「ホテル・カリフォルニア」効果と呼んでいるもので，チェックインすれば簡単にスケールアップできるが，退出してダウングレードするのは大変だ。

　また，クラウドが魅力的なのは，ゲーム会社やゲームデベロッパの中には，必ずしもインフラの専門家ではなく，サーバーの設定やメンテナンスの専門家ではなく，新しいゲームの開発の専門家である人が多いからだ。クラウドサービスは可能な限り回復力があるように設計されているが，クラウドプロバイダに障害が発生することがある。企業は，クラウドプロバイダのインフラストラクチャの上に社内のクラウドインフラストラクチャをロールオーバーすることもある。これには，複数のクラウドプロバイダにまたがってKubernetes（コンテナオーケストレーションプラットフォーム）を使用することが含まれる。

　多くのゲームデベロッパは，自社のデータベースインスタンスを実行するのではなく，マネージドサービスを利用する方法を検討する。これは良い選択肢だが，自分の責任を理解することも重要だ。多くのサービスは「完全に管理されています」と表示されていても，それが必ずしもあなたが想定しているものとは限らない。インスタンスがクラウドで完全に管理されていても，ゲームデベロッパであるあなたは，データ保護に関する基本的な予防措置を講じる責任があるという，セキュリティに関する共有責任の原則が残っている。

　新しいクラウドサービスを導入する際には，あらゆるものにベストプラクティスが存在することを知らなかったり，自分たちのために実施されていると思い込んでいたりすることがある。たとえば，多くのデータベースでは，認証やパスワードを自動的に必要としないデフォルトの設定が行われている。これは，インターネット上で多くの人がつまずきがちな罠である。愚かなことだが，そういったことは簡単に起こりうる。そのため，サードパーティのプロバイダが言っていたとおりにすべてが設定されているかどうかを確認することが重要だ。

---

Matt Yonkovit氏 は，Percona の最高経験責任者であり，会社の戦略とマーケティング機能を監督している。2009年にPerconaに入社する前は，MySQL ABとSun Microsystemsでソリューションアーキテクトとして，Fortune 500をはじめとする無数のWebプロパティのためのハイパフォーマンスインフラストラクチャの構築と最適化に従事していた。

GamesINdustry.biz ACADEMY関連翻訳記事一覧