ユーザーログ管理やリーダーボード(ランキング)、マッチメイキング、あるいはオフラインのタイトルにおいてもアイテムや武器種のリスト保持など、現代のゲーム開発においては必ずと言って良いほどデータベースの仕組みが必要になります。
今回はゲーム業界でも急速に普及が進むNoSQLにフォーカス。Microsoftが提供する「Cosmos DB」を題材にして、高い拡張性やデータの冗長化など、NoSQLならではの強みを紐解きます。
ユーザーログ管理やリーダーボード(ランキング)、マッチメイキング、あるいはオフラインのタイトルにおいてもアイテムや武器種のリスト保持など、現代のゲーム開発においては必ずと言って良いほどデータベースの仕組みが必要になります。
今回はゲーム業界でも急速に普及が進むNoSQLにフォーカス。Microsoftが提供する「Cosmos DB」を題材にして、高い拡張性やデータの冗長化など、NoSQLならではの強みを紐解きます。
TEXT / 神山 大輝
EDIT / 田端 秀輝
最初に、現在の主流であるRDB(リレーショナル・データベース)について説明します。RDBは最もポピュラーなデータベースの管理方式で、データを複数の表として管理する仕組みです。
データテーブルの中には「番号・苗字・名前・生年月日・年齢・性別・点数」など、あらかじめ定義された項目が格納されています。ゲームにおいてはアイテムや武器の性能・金額などを並べて置いていたり、ネットワークゲームにおいてはユーザーログの保持、課金履歴の管理などに利用されています。RDBにおいて、データベースに対してデータを書き込む、検索条件に合致するデータを読み込むなどの命令を行う言語が「SQL」です。RDBのメリットとして、SQLを用いた複雑な条件での検索への対応、システムの堅牢性に直結するデータの一貫性が挙げられます。
NoSQLは、RDB以外のデータベース技術を指します。NoSQLのデータベースは、RDBでは提供できない多くの非構造化データモデルをサポートします。NoSQLの特徴は、主に「スケーラビリティ」と「柔軟性」です。
RDBは一般的にデータを一つのデータベースで集中して管理するという前提があるため、スケールアウトが難しいという特性があります。データベースのスペックそのものがボトルネックになるケースもあります。
また、ネットワークゲームにおいては突発的に大勢がアクセスしたり、あるいは(悲しいことですが)ゲームがヒットせずアクセスが非常に少なかったり、さまざまな状況が考えられますが、いずれのケースも「データの書き込み量を問わず、重くならない(遅延=レイテンシーが少ない)」という状況を作りやすいのがNoSQLの強みです。
また、RDBで利用できるデータは表構造に限られていましたが、NoSQLはデータモデルに制限がありません。事前に明確な定義が必要なRDBと比較して、システムの拡張性が確保しやすい特徴があります。
Azure Cosmos DBは、最新のアプリ開発に対応するフル マネージドの分散型データベースです。
NoSQLを利用するサービスは複数ありますが、Cosmos DBの特徴はSLAに基づく10msec未満の読み取りと書き込み速度を担保していること、99.999%までの可用性(システム継続性)を確保する手段が用意されていること。速度、信頼性に優れています。
NoSQLの概要をお伝えしたところで、ここからはゲーム業界での使われ方や「NoSQLの得手不得手」など、具体的なエピソードをご紹介します。今回はNoSQL、そしてCosmos DBのユースケースや技術的特徴について、Microsoft MVPの3名にインタビューを行いました。
※Microsoft Most Valuable Professionalの略称。優れたコミュニティリーダーを表彰する制度
――今日はよろしくお願いいたします。自己紹介をお願いします。
三宅:株式会社ゼンアーキテクツ代表の三宅です。Azureの技術支援を行うMicrosoftのパートナーとして仕事をしていますが、個人としてもMicrosoft MVP(※)として活動をしています。自分の推しであるCosmos DBを世の中に広めたい、使っていただきたいということをひとつの使命として、個人としても会社としても啓蒙活動を続けています。
横浜:横浜と申します。私自身もMicrosoft MVPで、AzureのPaaSやGitHubのトレーナーなどを業務で行いつつ、自身でもコードを書いています。推しの話でいうと、Microsoftは箱推しでして、Cosmos DBだけでなくAzure Functions、GitHub Actionsなど幅広く好んでおります。
芝村:エンジニアの芝村です。ここにいる3人は全員Microsoft MVPですが、私も例年受賞させていただいております。普段はApp ServiceやAzureのサーバーレスを利用した設計など、Cosmos DBをたくさん使って仕事をしております。
――スケーラビリティや拡張性の高さなどのメリットから、近年はNoSQL自体が注目されています。改めて、ゲーム業界におけるNoSQLの利点を教えてください。
三宅:ゲームは、突発的なバースト(トラフィックが急増する)があることと、同時書き込みが非常に多いのが特徴です。不定期かつ一気に増えたり減ったりする場合、RDBのコネクションでは受け止めきれない場合があります。どれだけCPUやメモリを積んでも、入り口がダメだともう動かない。こうした点において、充分なスループットを確保できるNoSQLは利点があります。
芝村:ゲームが急に遅くなったり、レイテンシ(遅延)が不安定だと、プレイヤーとしてはものすごくストレスになりますよね。Cosmos DBはレイテンシーが10msec以下と定められています。これを数値として保証してくれるサービスは少ないため、この点で大きな安心感があります。
もうひとつはメンテナンス性です。RDBの場合は常に増え続けるデータをどう処理するのか、初期の設計から変更しにくいですし、特定のクエリ(データベースへの問い合わせ)が遅かったりインデックスのチューニングが上手くいっていない気がしても原因の絞り込みが難しい側面があります。NoSQLの持つ特性であるスキーマレスがもたらす柔軟性は大きな利点だと思います。
横浜:直接的なところだと、ゲームでよくあるリーダーボードは汎用的なアーキテクチャがありません。タイトルにもよりますが、良くあるのは全世界のランキング、ギルドごとのランキング、あるいは個人戦績など、複数の集計処理が必要になる設計ですね。これをRDBで実装する場合は「クエリで頑張る」となりがちですが、処理が遅かったり、あるいは大量のログが一斉に流れてきた際に対応できなかったりと特定環境では問題が起きてしまいます。
NoSQLであれば書き込みと読み込みをセパレートして設計することでデータを冗長化できますし、高速化を図ることもできます。タイトルで言えば、例えば『No Man’s Sky』や『Fall Guys』、『Minecraft Earth』ではNoSQLが使われています。
――お話に挙がったRDBとの比較も踏まえて、Cosmos DBの特徴を教えてください。
三宅:RDBとの比較の前に、まずCosmos DB自体がデータストアの中でもトップクラスに高い信頼性であることは外せません。SLAとしても99.99%から最大99.999%まで保証されています。実際の運用でも、この数字は達成されています。99.99%でも高い信頼性ですが、ファイブナイン(99.999%)は特に高い数値です。
芝村:ここ数年では限りなく100%に近いと思いますね。Cosmos DBは比較的新しいサービスですが、大前提として「信頼性がかなり高い」という部分は重要だと思います。
ユースケースでいくと、例えば工場などで各機器にセンサーを取り付け、リアルタイムにデータをクラウドに取り込んで異常検知をしている事例があります。秒間何千、何万というログが常時送られてくるため、どこかで処理が止まるとリカバリーが難しくなります。こうした現場でもCosmos DBが扱われています。
三宅:本来、データベースにおける書き込みと読み出しは必要なデータ構造や処理特性が異なります。設計次第ですが、RDBでは中心に位置するDB自体がボトルネックになってしまう傾向にあります。
このため、データを書き込む「コマンド(Command)」とデータを読み出す「クエリ(Query)」を分離して、それぞれの負荷を分散することが重要になります(CQRS:Command Query Responsibility Segregation と呼ばれる設計手法)。Cosmos DBの場合、Change Feedという機能を用いることで容易に実現可能です。
横浜:Change feed自体はデータの変更を検知してイベントを発火できるという機能ですが、この機能が本当に便利です。間違いなく、ゲームのドメインと非常に相性が良い要素のひとつですね。
芝村:Cosmos DBはChange feed機能が非常に優秀で、データがCosmos DBに書き込まれると同時に、そのデータを更に特化したデータ構造のDBに貯めていく仕組みを取り入れることで、低いレイテンシと高いパフォーマンスを維持したまま更に別の処理向けにイベントドリブンでデータを活用できるようになります。
横浜:一方において、NoSQLはRDB自体を否定するものではありません。トランザクションを保証する処理はRDBの強みですので、課金周りや予約などの領域では使い分けが必要です。一部のデータをNoSQLに逃がしてあげることで更にRDBが使いやすくなりますし、余計な負荷を軽減することもできます。すべてのユースケースに対応するテーブル構成を考えるのは難しいですし、どこかで無理が生じます。得手不得手を把握した上で、それぞれを使い分けるのが重要です。
三宅:その通りです。特定のプロダクトを全てのケースに適用するのではなく、適材適所で使い分けることが大切です。選択肢がたくさんある時代になってきて、柔軟な設計ができるようになってきた。オンプレ時代のNoSQLは最低5台、マネジメントノードにクラスタに3台など、ものすごく大変だったのですが、Cosmos DBは裏側の大変なところをすべてMicrosoftが作ってくれています。
――メリットも多いNoSQLですが、ゲーム開発においてはまだまだRDBが主流の印象があります。
芝村:NoSQL自体の普及についてはこれからという印象ですね。キャッシュ管理など、「正直これはRDBでも良いよね?」というサンプルも多いため、せっかくのメリットが見えづらい側面もあります。企業レベルで見ても、稼働しているRDBをベースにしたテンプレートをもとに構築を進める場合が多いため、NoSQLへの移行のモチベーションが高まらないのが現状だと思います。
横浜:RDBはインデックス設計やメンテナンス設計が必要ですが、NoSQLはまた別の設計が必要になります。どちらもデータモデリングを誤れば、想定したパフォーマンスを出すことができません。RDBにせよNoSQLにせよアプローチが違うだけで、「設計」は絶対に必要なんです。
三宅:うまくモデリングできれば、コスト面でも非常に大きなメリットがあります。リターンが大きいので、納得の行くまで何ヶ月でも試行錯誤を繰り返して、ベストな設計を得られるようにするのが大切ですね。
――その「ベストな設計」というのは、どのように学べば良いのでしょうか。RDBに慣れ親しんだ企業ほど、発想の転換が必要な感覚があります。
三宅:どのプロダクトを選ぶにせよ、アーキテクチャ全体で考えるべきです。これはAzureだけに限定した話ではなく、そもそも設計におけるアーキテクチャパターンは既にいくつも存在しています。大量のデータ書き込みと複雑な集計を両立するアーキテクチャパターンは昔からいくつもあります。「この設計パターンを実現するなら、Azure であれば、Azure FunctionとCosmos DBを組み合わせるのが最適だな」というふうに考えていく。つまり設計が先で、使いたいプロダクトありきでは考えないんです。今日は本当に、これだけは言っておきたいですね。
芝村:日本国内においては、実証された歴史あるデザパタ(デザインパターン)より、有名人がポロっと言った設計の方がもてはやされる気がしています。ただ、そのままだと他の事例に転用できないので、議論をするなら抽象度をひとつ上げるべきです。私がCosmos DBのサポートをするときも、必ず設計を議論した上で実装へ落とし込むという順番を守っています。ただ手を動かすだけでなく、自らがしっかり設計を考えることで、自分の体験、自分の事例としてインプットに繋がります。
横浜:やりたいことが決まっていて、それをどのアーキテクチャパターンで実現するか、その判断が難しいからこそ私達のようなMicrosoft MVPがお手伝いする意義があります。アーキテクチャパターンは一過性のブームではなく、ずっと考え続ける必要があるものですからね。
――開発者の目線で、Cosmos DBに興味を持ったエンジニアの方にメッセージを頂ければと思います。
芝村:開発者としてはSDKの使いやすさ、開発のしやすさが大切です。Cosmos DBはデザインが共通化・洗練されたSDKがC#やJava、Pythonなどに向けて提供されているため、言語が変わっても同じ仕組みで設計ができるのがメリットです。
GitHubでもオープンにコミュニケーションができて、ドキュメントも整備されているため、エンジニアとしてはストレスフリーです。サービスが素晴らしいのはもちろん、SDKも優れていることをお伝えしておきます。SDKも含めてCosmos DBなんですよ。あとは、実は毎週YouTubeもやっているし、カンファレンスもやっているんです。そこも含めて、エンジニアに対する手厚い姿勢が好きですね。
横浜:SDKが良いというのはその通りで、あとはやはりChange feed機能が最高ということは重ねて言っておきたいです。イベントを契機にデータを整形したり、別のイベントを発火させたり、とにかく開発の柔軟性が素晴らしいです。デベロッパーエクスペリエンス、開発体験の素晴らしさをぜひ体験していただきたいです。
三宅:Cosmos DB の SDKはOSSとしてずっとGitHubで開発されていて、開発チームの空気感、取り組みの姿勢も本当に素晴らしいです。開発のスピードも速いし、ロードマップもちゃんとしています。データベースと言いますが、開発環境の一部として非常に優れた設計になっています。いつかこれもRDBのように当たり前になる、時代を変える技術の1つだと思っています。
Cosmos DBなど最新の技術の学習および業務への活用を目的として、Microsoftは「Azure Light-up」と題した短期間の開発ハッカソンを主催しています。ゲーム業界向けとなる「Azure Light-up for Gaming」は、Microsoft MVPが技術課題の解決、あるいは開発の壁打ち役として一緒に並走しながら開発するハッカソンとして定期的に開催されています。
ここからは、実際にCosmos DBを活用した「総選挙システム」をわずか1日で実装した株式会社KMSのインタビューをお届けします。
Azure Light-up――最初に、会社のご紹介をお願いします。
株式会社KMSは、「世界中に新しい体験を。」というビジョンのもとゲーム開発やクラウド管理サービス、デジタルコミックなどを取り扱っています。ゲーム事業としては『天啓パラドクス』や『オトギフロンティア』など、4本を運用しています。
従業員数は約200名で、そのうちエンジニアが3割ほど。私のようなサーバーエンジニアは、更にその3割ほどの割合になります。
株式会社KMS 公式サイト――Azure Light-up for Gamingに参加したきっかけを教えてください。
「Cosmos DBというプロダクトに興味があった」というのが一番の理由です。KMSではRDBを中心に利用していますが、NoSQLもデータキャッシュ用途で一部活用しています。
ただ、この使い方ではNoSQLの強みを活かしきれているとは言えないと感じていました。
また、スキームを定義する際、どうしてもRDB的な考え方になってしまっていたため、今回のハッカソンを通じてNoSQLではどのような考え方が最適なのか、その概念にも技術的な興味がありました。NoSQLについては書籍などを読むだけでは良く分からない部分も多いため、実際に手を動かして、ツールの使い方も含めて覚えたいと考えました。
――「実際に手を動かす」というお話ですが、今回はどのような題材に取り組んだのでしょうか。
最初はリーダーボード(ランキング)という題材に取り組む予定でした。その後、「KMSのタイトルでリーダーボードが必要なシーンとは?」というディスカッションから総選挙というキーワードが出てきたため、これを掘り下げて実装することにしました。
総選挙はゲーム内のキャラクターに対して行われるユーザー投票の仕組みです。データベースリクエストは、書き込みも読み込みも非常に多いのが特徴です。運営側は1票ずつ確実に処理したい一方、ユーザー側は最新の票の集計結果をいつでも確認したいというニーズがあり、RDBとは少し相性の悪い内容でした。「書き込みを大量かつ高速に処理したい」「集計も高速化したい(キャッシュのない初回の集計処理は重くなり易いため)」という要件においては、書き込みと読み込みを分離することで最適化を図るというアプローチを考えました。
――純粋なリーダーボードよりも、総選挙のほうがNoSQLの利点を活かせそうですね。
チームメンバーでディスカッションしたときも、総選挙は広く一般に知られる概念であるため、題材として適切だろうと判断しました。今はゲームでも総選挙は実装されるケースが多く、Cosmos DBとの相性が良いとともに弊社タイトルとの相性も良いかも知れないと思っています。
総選挙は初動のタイミングのリクエストが非常に大きいのが特徴です。恒常的にデータがある仕組みと異なり、初動などスパイクの発生するドメインの場合、Cosmos DBの利点が充分に活かせました。また、柔軟なスケーラビリティによって、既存のDBと違ってコストの最適化も可能な点が非常に良かったと感じています。
――今回のハッカソンを経て、どういった部分が特に大きな学びになりましたか。
KMSとして、設計の幅が大きく広がりました。今まで使っていたRDBでは最初にテーブルを用意し、テーブルに合わせて、アプリの設計を考えるというアプローチをしてきました。Cosmos DBでは、NoSQLの特徴を生かし、アプリの都合に合わせてデータベース設計を後から考えたり変更する、という逆方向のアプローチができました。この概念を学べたことは非常に価値がありました。
――最後に、ハッカソンを終えた感想を教えてください。
実はこうしたイベント参加は初めてで、最初は「ひたすら作るのかな?」と緊張していましたが、実際はMicrosoft MVPの方との議論や詳しい解説も含めて知識の充足ができました。知的好奇心を満たすという意味では、学生時代を思い出すような、普段の仕事と違う楽しさがありました。
今後のプロジェクトでも、今日の経験を活かしてCosmos DB導入を進めたいと考えています。
Cosmos DB公式サイトAzure Light-up 公式サイトゲームメーカーズ編集長およびNINE GATES STUDIO代表。ライター/編集者として数多くのWEBメディアに携わり、インタビューや作品メイキング解説、その他技術的な記事を手掛けてきた。ゲーム業界ではコンポーザー/サウンドデザイナーとしても活動中。
ドラクエFFテイルズはもちろん、黄金の太陽やヴァルキリープロファイルなど往年のJ-RPG文化と、その文脈を受け継ぐ作品が好き。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁(のざわ くにひと)氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
東京ゲームショウ2024で展示された作品のプレイレポートやインタビューをまとめました。
CEDEC2024で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブル2024で行われた講演のアーカイブ動画・スライドをまとめました。
CEDEC2023で行われた講演レポートをまとめました。
東京ゲームショウ2023で展示された作品のプレイレポートやインタビューをまとめました。
UNREAL FEST 2023で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドをまとめました。
UNREAL FEST 2022で行われた講演レポートやインタビューをまとめました。
CEDEC2022で行われた講演レポートをまとめました。