No Man’s Sky を何百万人ものプレイヤーに届けている Hello Games 社は、どのように Azure を活用しているのか
※本ブログは、米国時間 2022 年 2 月 3 日に Harvey Eagle (Azure Gaming ディレクター、マイクロソフト) により公開された How Hello Games is using Azure to bring No Man’s Sky to millions – Microsoft Industry Blogs – United Kingdom の翻訳です。
Harvey Eagle
Azure Gaming ディレクター、マイクロソフト
マイクロソフトとゲームと言えば、まず Xbox だと思われるのではないでしょうか。また、通常 Xbox ビジネスについて語る場合、お客様はゲーマーです。
しかしマイクロソフトにはゲーマーと同様に大切なお客様がいます。それはゲーム クリエーターです。その理由は、マイクロソフトの成功は、強く、常に成長していくクリエーター エコシステムとともにあるからです。
マイクロソフトは、開発者ツール、パートナーシップ、およびインフラストラクチャに重点を置くことで、Xbox で最高のゲームをプレイヤーに提供することを可能にしています。
マイクロソフトのパートナーは Azure を活用して夢を実現しており、その 1 例が Hello Games 社 (英語) です。Develop:Brighton では、Hello Games 社のサーバーおよびマルチプレイヤー担当のリーダーである Iain Brown 氏と、非常に人気がある No Man’s Sky の運用に、同社が Azure のツールとサービスをどのように活用しているかについて語り合いました。
Harvey: あなたは No Man’s Sky を開発したチームのメンバーとして大きな役割を果たされました。ご自身について、また Hello Games 社でのあなたの役割についてお話しいただけますか。
Iain: 私は 25 年ほどゲームの開発に携わっています。この 15 年は、マルチプレイヤーやオンライン サービスなど、オンライン関連の仕事に取り組んできました。Hello Games では、主にサーバー、サーバーとのやり取り、および No Man’s Sky のマルチプレイヤー バックエンドを担当しています。
Harvey: ご存じない方のために、まず No Man’s Sky のことから始めましょう。このゲームの基本的な特徴をご紹介いただけますか。
Iain: No Man’s Sky は、プロシージャル生成された宇宙を舞台とした、宇宙探査/サバイバル ゲームです。ゲーム内にはプレイヤーが探査できる惑星が約 1,800 京個あります。当然ながら存在するすべてのコンテンツを見ることができる人はいませんが、各惑星上でそれぞれ「モノ」が定義されており、すべての惑星が唯一無二となっています。
私は、惑星上のこのような「モノ」をプレイヤーに提供することに携わっています。プレイヤーは宇宙を旅しており、誰かと一緒にゲームをしていなくても、自分より先に訪れたプレイヤーが残した痕跡を見つけることができます。誰かがすでに訪れ、たとえばその人の父親にちなんだ名前が付けられた惑星に出会う場合があります。このような体験をプレイヤー間で共有することができます。
Harvey: ゲーム内のクラウド機能の一部を実装するために、どのように Azure を使用しているかについてお話しいただけますか。
Iain: 私たちのチームは少人数で、サーバーを担当しているのは基本的に私だけなので、私たちはゲームの運用には一切かかわらず、サーバーの管理はサーバーに任せたいと考えていました。この理由から、PaaS 製品、つまり、Azure App Service を採用しました。私たちは、VM についても、OS についても、フレームワークについても気にかける必要はなく、ただ C# コードを書き、クラウドにアップロードするだけで、後は Azure App Service がスケールアウトしてくれます。私たちにとってはこれが一番重要でした。私たちはコードを書くだけで、運用面については心配したくなかったのです。
私たちは Azure の多くの機能を使用していて、Azure エコシステムにどっぷりはまっていると言えます。たとえば、私たちは機密情報や証明書などの保存先として Azure Key Vault を使用しています。保護する必要があるものはすべて Azure Key Vault 内に存在し、サーバーからしか見えません。
また、データベース自体がダウンしてもプレイヤーが何も失わないようにしたかったので、Azure Event Hubs も使用しています。プレイヤーが発見したものは、データベースには直接アップロードされません。Event Hubs にいったんアップロードされてから、データベースの準備ができた時点でデータベースに取り込まれます。
こうすることでよりデータベースのメンテナンスが可能になるだけでなく、負荷も多少分散されるため、データが送信されてきても直ちに対処する必要はなくなります。
Harvey: 当然ながら大量のデータも扱っていると思いますが、それに対してはどのようなデータ ソリューションを使用されていますか。
Iain: 実際のデータベースには、Azure Cosmos DB を使用しています。これは自動的に管理およびスケーリング可能な NoSQL データベースです。データベース上でいくつかの要求を実行したいと指定するだけで、Azure が管理し、最適と思われる場所にデータを置いてくれます。
現在はそこに約 3 TB のデータが入っています。すべてテキストの JSON ドキュメントであるため、大量のデータですが、Cosmos DB は十分に処理でき、そのデータ全体に対してクエリを問題なく実行できています。
Harvey: No Man’s Sky はリリースされてから 5 年が経ちますが、その間、Azure を使用されてきたということですよね。5 年間で Azure の使い方はどのように変わりましたか。
Iain: ローンチしてから 5 年の間に、このゲームは大きく成長しました。当初サーバーに入っているものは、惑星、動物、植物、石など、基本的には発見されたものでした。その後、プレイヤーが建設して共有できる基地や、比較的最近追加した集落など、データベースに保存される機能をかなり追加してきました。また、プレイヤーが達成するミッションもゲームに追加しました。
このようにゲームは成長し、それとともに Cosmos DB データベースも成長してきました。データベースは必要に応じてスペックアップするだけです。さらに、さまざまなハードウェアから移行しています。ローンチ以来、Azure 内で 2 回ハードウェアを入れ替えました。ハードウェアは入れ替えるたびに安くなっています。最近、サーバーを新しいバージョンのハードウェアに再展開したばかりですが、問題なく機能しています。
また、ローンチ時には .NET Core 1 を使用していましたが、現在は .NET 5 を使用し、また Linux に移行しています。この移行はシームレスでした。同じコード ベースを使用したまま、Windows 用 App Service から Linux 用 App Service に移行できました。
Harvey: Slack をどのように使用しているかについても教えていただけますか。
Iain: 私たちはさまざまなものを Slack につないでいます。外部向けのものでなく、内部向けのものですが。たとえば、私はすべてのサーバーに対して Octopus Deploy を使用しています。サーバーを展開するたびに、サーバーレス コードである Azure Function にメッセージが送信されます。これは非常に単純な Web フックで、サーバーの展開が開始されたこと、またそれが成功したか失敗したかを Slack に書き込みます。Slack 通知の作成と Azure Function 内でのホスティングは、数行のコードで行えます。
Harvey: 話を戻しますが、ローンチ当初から多数のプレイヤーを獲得し、素晴らしい成功を収めていました。これは技術的な課題も伴ったと思います。当初のプレイヤーからのレベルの高い関心に対処するために、Azure がどのように役立ったのか教えてください。
Iain: ローンチ前に私たちは多くの負荷テストを実行しており、問題はないと考えていました。しかし、私たちはプレイヤー数を低く見積もりすぎていました。ローンチ当時の膨大なプレイヤー数もですが、負荷テストの内容についても同様でした。CPU と RAM の負荷テスト時に、各マシンに対して実行される接続数の負荷テストを行っていませんでした。このため、接続が足りなくなるという事態に陥りました。
私たちは Azure ポータルに急いでアクセスし、すべてのサーバーをスケールアップしなければなりませんでした。そこで、より多くの接続をサポートできる、より性能の高いマシンへ切り替えました。また、横方向にも広げ、サーバーのインスタンス数も増やしました。
これはすべてポータルで簡単に実行でき、わずかなボタンをクリックするだけで稼働させることができました。新しいハブなどを調達する必要はなく、ポータルにアクセスし、問題なく機能するまで、数字をいくつか変更するだけでした。
ローンチ当時に発生したもう一つの問題は Cosmos DB に関するものでした。以前、Cosmos DB には、パーティションなしの安価な開発用のバージョンと、より高価なパーティションありのバージョンがありました。パーティションありのバージョンは本番データベースに使用し、開発にはより安いパーティションなしのバージョンを使用できました。
ゲームのローンチ前の数か月間は本番データベース用の料金を支払いたくなかったため、PC サーバーのテスト用に開発データベースを使用していました。ですが、私たちはうっかりしていて、ローンチ前に本番用に変更するのを忘れ、十分な容量を持たず、対処しきれない開発用データベースにレコードを書き込むことになってしまいました。また当時は、現在のような 1 つの製品ではなく、2 つの別々の製品であったため、スケールアップもできませんでした。
私たちは Cosmos DB チームに電話で相談しましたが、チームは素晴らしかったです。私たちは実際に対処してくれるエンジニアやプロダクト マネージャーと連絡を取り合いましたが、チームはどう対処すべきかわかっていました。開発用データベースから、セットアップされた容量の大きい新たなデータベースにすべてをコピーするスクリプトを書き、同時にデータベースに送信されるすべてのデータにも対処してくれました。その後、開発データベースをやめて、新しいデータベースに切り替えることができました。これをすべてサーバーのダウンタイムなしに行えたのです。
Harvey: どのゲームでも、重要な目標の 1 つが、プレイヤーを満足させ、魅了することです。プレイヤーを魅了する上でクラウドがどのように役立ったか、No Man’s Sky での例についてお話しいただけますか。
Iain: 私たちは先日、ゲーム内で期間限定のシーズン モードという新しいモードをスタートさせました。このモードは数週間提供され、参加することで独自の報酬を得ることができます。このモードを早くスタートするため、また、ゲーム クライアントがハッキングされ、何が予定されているかを見られてしまわないように、すべてのデータはクラウドに置かれています。Azure 内のテーブル ストレージに保存されており、所定の日時になると、必要に応じてゲーム クライアントにダウンロードされます。
これはすべてゲーム デザイナーが設定しています。プログラマーの必要性を極力減らし、デザイナーがイベントの開始と終了日時の設定、イベントを記述するファイルの指定、報酬の内容の指定などを実行できるようにしました。重要なのはデザイナーがこれをできるようにすることです。また正直に言うと、チームにはプログラマーが少ないため、彼らへの依存を減らすことにも貢献します。
私たちは同様に、独自の報酬をもらえる週末に参加することをプレイヤーに促す、週末ミッションのイベントも開催しました。私たちは同様に、独自の報酬がもらえる週末ミッションのイベントも開催しました。このようなイベントでは、複数のプレイヤーが一緒にゲームに参加し、全員が共同で目標を達成することを目指してタスクを実行します。1 人のプレイヤーが自分だけですべての目標を達成することがないように、各プレイヤーがこの目標に対して個々にどれだけ貢献できるかも制限しています。
これをすべて Cosmos DB で行っています。プレイヤーが目標を達成したことを送信できるようにするスクリプトがあり、この結果が Cosmos DB により収集されます。このデータに対してクエリを実行することで、達成の数が、週末ミッションが開始されてから発生したものであるかを特定できます。繰り返しますが、これはすべてデザイナー主導で行われています。週末ミッションの実行にプログラマーは携わっていません。自動的に実行され、展開されるように設定されています。
Harvey: 最終的には、マッチメイキングに Azure PlayFab、ゲーム内でのコミュニケーションに Azure PlayFab Party を使用されていましたが、なぜこれらのソリューションを選択したのでしょうか。また、No Man’s Sky でこれらのソリューションがどのように使用されているかについて詳しく説明していただけますか。
Iain: 私たちにとってクロスプレイは大事なことでした。以前からクロスプレイを実行したかったのですが、先ほども申し上げたように非常に少人数のチームのため、独自のシステムを構築することは無理でした。サーバーのコードを書き、サーバーを展開し、サーバーを管理することは、私たちには不可能でした。
マイクロソフトが Azure PlayFab (英語) を検討することを提案してくれたのですが、Azure PlayFab には私たちが使いたい機能が多数備わっていました。たとえば、Xbox にサインインしているすべてのユーザーは PlayFab を無料で使用できます。私たちはランニング コストを減らしたいと常に考えているため、これは非常に助かりました。また、PlayFab Party にも素晴らしい機能があります。音声テキスト変換、テキスト読み上げ、そして外国語のリアルタイム翻訳機能が非常に優れています。
実際、会社のスタジオで初めて PlayFab を動作させたとき、この機能を見るために同僚が私の机の周りに集まってきました。どうにかして PlayFab に勝てないかと皆が PlayFab を騙そうとしましたが、人が何を言っているかを検出し、さまざまな言語に翻訳する能力はかなり優れていました。これらの機能をぜひ試すことをお勧めします。
PlayFab のマッチメイキング機能は、基本的には Xbox Smart Match システムと同じであるため、非常に簡単に統合できました。このシステムの使い方を知っていれば、PlayFab システムもすぐに稼働させることができ、クロスプラットフォームで動作させることができます。基本的に Xbox で使用していたすべてのルールを、Xbox ポータルから PlayFab ポータルへとコピーすることができ、それでマッチメイキング機能は完了でした。どのルールも問題なく機能しました。
No Man’s Sky でのプレイでは、他のプレイヤーとの 2 つのレベルの関係性をもっています。1 つは、銀河系を飛行している際に、物理的に近くにいる他のプレイヤーが一時的に現れては消えていくというものです。
私たちは、一緒に時間を過ごしたい他のプレイヤーと、1 つのセッションの間だけでなく、数時間にわたって長期の関わり合いを持てるようにもしたいと考えていました。私たちはこれをチームと呼び、2 つの PlayFab Party ネットワークを完全に別々に動作させることでこれを実現しています。31 人ものランダムなプレイヤーから話しかけられたい人はいないので、ボイス チャットはチーム内でのみ可能としています。
Harvey: 2 つのネットワークを展開することは画期的ですが、それによりネットワークのコストが上がったのではないでしょうか。コストはどうなったのか、またマイクロソフトはどのように対処できたのかが気になります。
Iain: 確かに、コストは少しですが増えました。この仕組みでは、近くにいる他のプレイヤーを見つけている場合は、そのプレイヤーとマッチメイキングする際にのみ、PlayFab Party ネットワークが作成されます。したがって銀河系を自分だけで飛行しているときは、ほとんどの場合ローカル ネットワークにはいません。
チームを機能させるためには、友達がゲーム ダッシュボードを通して参加できるように、ゲーム内のすべてのプレイヤーにずっと接続できるネットワークが必要でした。通常はこのネットワーク上ではトラフィックは発生しませんが、プレイヤーが参加できるように、ネットワークは常に使用可能でなければなりませんでした。
これにはかなりのコストがかかりましたが、私たちがこの機能を提供する前に、この設計をすでにリリースしていたマイクロソフトに相談しました。マイクロソフトは非常に寛大で、かなりの値引きしてくれました。またその直後にすべての PlayFab Party のネットワーク分に対して 90% の値下げを発表し、これによりコストはさらに安くなりました。
Harvey: クロスプレイの実装をするにあたり、3 つのデータベースを 1 つにマージするという課題が発生しました。これはどのように解決したのでしょうか。
Iain: 私たちはローンチ時には、プレイヤーが発見したものを追跡するためのデータベースを、ゲーム プラットフォームごとに分けると決めました。ユーザー名の表示やコンテンツのレポートなど、その当時は理にかなっていたさまざまな理由があったので、それぞれのプラットフォームを分ける方が簡単だったのです。
しかしクロスプレイのローンチ時には、誰もが同じモノに対して同じ名前を共有した方が賢明であると判断しました。このために、それぞれが約 2 TB の大きさの 3 つのデータベースを、1 つのデータベースに統合しなければなりませんでした。
私たちは新しいデータベースを作成し、ローンチ時に Cosmos DB チームが実行したのと基本的には同じことを行いました。つまり、スクリプトを書き、Azure Function で実行しました。Azure Functions はサーバーレスであるため、大規模なスケーリングが可能でした。これには、基本的には Cosmos DB パーティション内の全レコードのリストである、Cosmos DB の変更フィードを使用しました。
パーティション単位であるため、大規模なスケーリングも可能です。データベース内には多数のパーティションがあるため、このコードを Azure Functions に渡し、後は必要なだけ自由にスケーリングさせました。スケーリングは非常に広範に行われ、各データベースからレコードを取り出し、新しいデータベースに挿入する、この関数の多数のインスタンスが実行されました。
当然ながらいくつかの競合も発生しました。複数のプレイヤーが同じ惑星に名前を付けたケースがあったため、誰のものにするか決める必要がありました。この問題は、その惑星に最初に訪れた人に命名権を与えることで解決しましたが、作業を進めながら、競合するレコードが新しいデータベースに追加されているレコードよりも古いかどうかをチェックしなければなりませんでした。
先ほども申し上げたように、各データベースには数テラバイトのデータが格納されていたため、統合には数週間かかりましたが、大きな問題は発生しませんでした。ローンチ前に多くのテストを実施し、プレイヤーがまだ古いデータベースに書き込んでいる間も、バックグラウンドで Azure Functions を実行していました。ダウンタイムは発生しませんでした。新たにマージされたデータベースに移行し、変更する時点を設定しただけです。
実際、驚くほどスムーズに移行できました。多少の不安もありましたが、十分なテストを実施しており、その結果に満足していました。最も恐ろしかったのは、その後で古いデータベースを削除すると決めた時です。それまでは、新しいデータベースに対するバックアップとして残していましたが、これらの古いデータベースにもお金を払っていたため、使用していないものであれば削除する必要がありました。これはマージの数か月後のことでしたが、それでもそれまでで一番恐ろしい瞬間でした。
Harvey: 最後に、私たちのこの対話を通して、会場の皆さんにお伝えしたい最も重要なポイントは何でしょうか。
Iain: そうですね、最も重要なポイントは、優れたオンライン機能を備えるために、オンライン機能に巨額の投資をする必要はないということです。基本的に、コードを書いているのは私だけでした。運用エンジニアもいなければ、データベース アナリストもいませんでした。私がほぼ C# で書いていただけでした。
Azure が提供するさまざまな機能をすべて把握するには多少の調査が必要ですが、どの機能も非常に簡単に使用でき、担当する大規模なチームがなくても、これらをつないで、優れた機能を作り出すことができます。
ゲーム開発用 Azure
忙しい中、素晴らしい見識を共有してくださった Iain Brown 氏に、改めて感謝いたします。また、No Man’s Sky の大成功もおめでとうございます。私たちは皆、Hello Games 社が次に何を発表するのか楽しみでなりません。
Azure Gaming チームには、ゲーム クリエーターの夢の実現を可能にするという使命があります。この成果を測る方法の 1 つが、私たちがクリエーターのために生み出す利益です。私たちは創造性と財政面の両方でサポートすることにより、あらゆる規模および能力の開発者やパブリッシャーを支援することを目指しています。
ご存じない方のために、Microsoft Azure には、ゲーム クリエーターの夢の実現を可能にする、広範で魅力的なクラウド サービスがあります。マイクロソフトは以下のことを可能にします。
- プレイヤーを獲得し、維持し、マネタイズする。
- ゲームの寿命を伸ばし、ROI を向上させる、健全で安全でプレイヤーが積極的に参加するコミュニティを構築する。
- データと分析を活用して、プレイヤーの行動を深く理解し、喜ばれるコンテンツを提供する。
- 通知やリーダーボードなど、ゲーマーが期待する最新のゲーム機能を提供する。
- どのようなジャンルのゲームを開発していても、どのデバイスまたはプラットフォームでパブリッシュしていても、プレイヤーがどこにいるかにかかわらず確実にリーチすることを可能にする、エンタープライズ グレードのインフラストラクチャ バックボーンを利用する。
Azure はテクノロジにとらわれない最新の開発プラットフォームです。テクノロジが最適に活用されると、技術上の制約がなくなり、心配事が減ります。ゲーム クリエーターの皆さんには、素晴らしいゲームの開発に専念していただきたいのです。それがマイクロソフトの取り組みです。
