こちらは AWS for Games Advent Calendar 2023 11 日目の記事となります。
皆さん、ゲームは好きですか？
エンジニアの方はゲームが好きな方は多くいらっしゃると思います。かくいう私も大好きです。特にゲームの中でもオンライン要素のあるもの、みんなで 1 つの目標に向かって進むマルチプレイでの共闘であったり、PvP での手に汗を握る知力と反射神経を尽くした戦い、そういったゲームが 2023 年も数多く流行っており、大変楽しく遊ばせて頂きました。
本日はそうしたオンラインゲームのサーバー・インフラ周りの開発体制の歴史や流行り廃りについて思いを巡らしつつ、2024 年以降の開発体制の流行り廃りがどう変わっていくのか、近年流行りの Platform Engineering の紹介と共に個人的な将来の予想を述べてみたいと思います。
オンラインゲーム開発の流れについて
まず初めに、一般的なオンラインゲーム開発の流れについてご紹介いたします。
当たり前なのですが、「ゲームサーバー」の開発は、一般的にはゲーム開発工程において後半に位置します。まずはゲーム体験のコアを考えるための企画書の作成やプロトタイプの開発をプリプロダクションのフェイズで行います。その後、開発工程が前に進んだとき、特定の機能を作り込むバーティカルスライスの開発や一連のゲームループを仮実装する α 版の制作時期には、基本的にサーバー処理が必要な部分は Local 通信などで代替されるケースが殆どで、あっても検証環境用のサーバーをせいぜい1-2台用意する程度となります。そして、ゲームが面白いかどうかはこの開発期間に決まるといっても過言ではないため、多くの時間はゲーム開発体験向上のために費やされるため手戻りも数多く発生し、元々の企画自体も星の数ほど生まれては消えていきます。
オンラインゲームを作る場合、もちろん会社や組織によっても異なる部分は多いのですが、インフラ・サーバーエンジニアはゲームの仕様が決まって、それを実現するための「手段」を実現する段階からプロジェクトに対してエンゲージが始まることが多いです。オンライン要素の仕様にあうための「技術」を選定して確実にゲームをエンドユーザーに届けることが期待されます。逆に言えば仕様を実現できるのであれば、コスト面などのビジネス制約はあれども、基本的には技術選定は自ら権限を持って行うことができ、特に大型のタイトルでは大規模なトラフィックを捌くためのシステムやアーキテクチャを自身で選定し実装できる貴重な経験を得ることができます。新しい技術なども本番規模で試しやすいので、オンラインゲーム開発はサーバー・インフラエンジニアにとって、とても良い環境だと思います。
しかしながら、オンラインゲーム開発が大規模・長期化するに従って、サーバーエンジニアにとって腕に見せ所である技術選定のチャンスが減ってしまっています。例えば大規模タイトルであれば開発に3-4年かかることもざらで、3 年間の開発期間のうちプロジェクト内にサーバーエンジニアが必要な期間は実質的には半年ないしは 1 年しかない、ということもありえます。しかし、スキルのあるエンジニアがいるのに残りの 2 年間で何もさせないで放っておくわけには行かないので、ゲーム会社としては複数プロジェクトの掛け持ちをお願いしてサーバーエンジニア全体の人数を減らしたりもするのですが、今度はプロジェクトの繁忙期が重なったりしてしまうと、サーバー・インフラの人が足りなくなり、ゲーム開発のボトルネックになりかねないという構造が顕出してしまいます。
この問題の本質としては、「サーバーはスケールするが、人間はそう簡単にスケールしない」というのがポイントなのですが、幸いにも我々エンジニアは「共通化」という武器を普段から磨いているため、多くのゲーム開発会社において、テクノロジーを応用して人材需要の不均一性に対する課題に取り組まれてきました。
ゲームサーバー共通基盤の誕生
ゲームのオンライン要素が増えるにつれ、前述したサーバー・インフラ人材不足という背景も相まって開発効率化は謳われ続けてきました。「ゲーム 共通基盤」と Google 検索をすると、特にモバイルゲームの開発会社を中心として多数の求人がヒットする状況となっています。また、コンソールゲーム開発でもゲームサーバーを用いたマルチプレイ体験だけでなく、ゲーム内課金やクロスプラットフォーム連携、ユーザー認証と数多くのオンライン要素が必要になってきており、サーバー開発の重要性はますます向上しています。ひょっとしたらモバイルゲームよりもクライアント開発に時間がかかるコンソールゲーム開発会社の方が共通基盤が生まれる力学は強く働くかもしれません。
ゲーム共通基盤には幾つかの種類がありますが、基本的にはどのドメイン境界で抽象化のレイヤリングを行いたいかという前提のもの会社の組織状況を考慮した上で決定することが多いでます。例えば以下がよくある共通基盤の例です。
↑ビジネス寄り
- 課金決済共通基盤
- ID 共通基盤
- データ分析共通基盤
- API サーバー共通基盤
- リアルタイムサーバー共通基盤
↓in-game 寄り
世の中の流れとしては基本的には in-game の仕様に引っ張られることの少ない、課金とかID基盤などの out-game の中でもビジネス寄りな部分は車輪の再発明を避けるために共通化されることが最も多いです。さらなる効率化を目指して API サーバーやリアルタイムサーバーといった in-game に近い領域を抽象化した場合は、より効率的なゲーム開発ができる一方で、ゲーム性自体に共通基盤の仕様が多少影響を与えることになるため、会社によって採用するかはまちまちです。このように共通基盤により抽象化されるドメイン対象はゲーム会社に応じて異なりますが、クライアントの開発期間が伸びれば伸びるほど、必然手が開いているサーバーエンジニアの数が増えてしまうので、やはり会社全体として効率化のために共通基盤を作成する流れになってしまいます。
ゲームサーバー共通基盤の課題と宿命
多くのユーザーにとって共通基盤を作る目的としては効率化・省力化のためですが、サーバー・インフラエンジニアにとっても目的は同じです。一方で、ゲームサーバー共通基盤において特に重要視される要件として挙げられるのがサーバーのスケール速度になります。特にモバイルゲームでは各種「イベント」を開催されることが多いのですが、そうしたイベントのたびにサーバーのスケールを調整する作業から開放されるためには、イベントの開始直後に 5-10 倍ものトラフィックを捌けるような性能がゲームサーバー共通基盤には期待されます。こうしたスケール性能を達成するための作り込みであったり、中長期的な運用を見据えたコスト削減のための施策を多数施された、自分たちだけの「プラットフォーム」が開発される傾向自体は、あらゆる共通基盤が抱える宿命とも言えます。
こうした作り込み自体は楽しい作業で付加価値も高い営みになのですが、いざその共通基盤を運用する際には様々な課題が徐々に表層化していきます。大抵の場合初めて課題を感じる瞬間としては、作り込んだ部分の運用を続ける時となります。「共通」化されるほど複数のシステムから利用される価値の高いシステム基盤になっていくのですが、多くのシステムで使われるほどに、些細な変更が波及する影響が増えてしまい更新作業が煩雑になってしまいます。そして「共通基盤」に対する更新や新規開発が少なくなってくるにつれてノウハウが失われていきます。特に作り込まれた基盤ほど完成度が高い分、メンテナンスが不要だと判断されて使い回されるようになります。こうして「技術的負債」と呼ばれる Pain が溜まっていってしまいます。
一方で、進化を止めてしまったプラットフォームを置き去りにする形で技術革新は日々進んでいくため、数年後には現在プラットフォームで採用されている技術より魅力的な機能やサービス、プログラミング言語が世に溢れ出ています。そういった将来においては、前述の通り、時間にゆとりのあるスキルの高いエンジニアが独自の技術でサーバー開発を選定するため、せっかく作ったはずの共通基盤は再利用されずに、式年遷宮のようにまた次の新しいプラットフォームが作られてしまいます。
面白いオンラインゲームを作りたかっただけのはずなのに、こうした共通基盤が抱える宿命から我々はどうやって逃れると良いのでしょうか・・・？それを解決する鍵となるのが Platform Engineering となります。
Platform Engineering について
Platform Engineering は、2023年のガートナーの戦略的テクノロジのトップトレンド 1にも取り上げられており、世界的に見て Generative AI の次に注目度が高いトレンドだと言えるでしょう。どういったアプローチなのかを一言で表すといえば、Platform Engineering は、サーバーやインフラの管理運用を自動化する営みの一種と言えます。しかし、プラットフォームを利用する「アプリ開発者」に徹底的にフォーカスを当てている点が、従来の共通基盤化との違いを生み出しています。次の図を参考にしながら各アプローチの比較をすることで理解を深めていきましょう。
ゲーム開発共通基盤 ： Centralized Provisioning
図の左端、「中央集権型プロビジョニング」アプローチでは、Central PlatformDevOps Team（いわゆるインフラエンジニア）がある種の共通基盤を用意して、アプリケーション開発者はその上で動くコードを開発していきます。このアプローチでは、開発当初は順調に進むのですが、運用フェイズに入ると、基本的に共通基盤チームは忙しく、プラットフォームの改善要望は Backlog に山積みとなってしまいます。新技術を導入するための余裕はなく、技術的負債が溜まり、先程の式年遷宮パターンに陥る可能性を秘めています。結果的に効率的だと思っていたゲーム開発共通基盤の導入が、そうでない可能性に気付かされてしまいます。
ゲームタイトル毎の個別開発環境 ： Embedded/Decentralized DevOps
共通基盤アプローチとは真逆に、図の右端 2 つの体制は、各ゲームタイトル毎に特注のインフラを毎回作成するアプローチとなります。メリットとしては、ボトルネックとなる共通要素はないため、各タイトルでは常に自分の好きな最新技術を導入できるため、一見すると理想的な開発環境であるとも言えます。しかし、常に流行や新技術を追いかけながら機能要件だけでなく、セキュリティやロギング、CI/CD といった非機能要件まで全てをカバーする開発を都度行う必要があるため、エンジニアにとっての「認知負荷」が非常に高いです。そのようなわけで、1 チームで全てをカバーする Deventralized DevOps アプローチが理想だとは思いつつ、実際にはエンジニア不足から Embedded DevOps アプローチのようにインフラ/アプリが分裂したチーム構成になりがちで、そうなると効率を追い求めて共通基盤を作ったほうがよいのでは？と振り出しに戻る議論をすることになります。
これらのアプローチにはそれぞれ Pros/Cons が存在しているのですが、長い運用期間を経ると Cons ばかりが目立ってしまい、これまでと真逆のアプローチに飛びついてしまうような経験は大なり小なり誰しもが身に覚えがあると思います。ではここで紹介した 2 つのアプローチ以外のパターンはないか？それが Platform Engineering となります。
セルフサービスの開発者ポータル ： Platform-enabled Golden Path
Platform Engineering では、開発チームに「セルフサービス」でインフラ環境を構築できる、再利用可能なツールを提供していきます。プラットフォームチームは、開発者プラットフォーム (Internal Developer Platform) と呼ばれるプロダクトを構築し、製品開発に必要な要件を抽象化して隠蔽し、開発チームの需要に答えて、継続的に改善していきます。具体例をあげるとすると、EC2+RDS を使った API サーバーを構築する場合、開発者は自分たちだけが利用できる Web サイト (IDP) を参照し、サイトの中でそれらを構築するための Terraform のコードを選択して、自分でデプロイすることが可能になるといったイメージです。そこでは、CI/CD や Security といった非機能要件も意識することなく自分たちに合った形で提供されていきます。ゆえに、開発者は下回りの仕組みを意識することがなく、あくまで開発者がセルフサービスで必要なリソースを IDP 経由で「認知負荷」を下げながら使うことができるというのがポイントです。
こうした IDP があるおかげで、開発者はゼロからインフラを構築する必要性はなくなります。また、あくまでインフラを管理するのは開発者となるため、共通基盤チームが面倒を見る必要はなくなるため、プラットフォーム開発チームは、IDP をボトルネックなく改善し続けることが可能になり、「技術的負債」がなく最新の技術を取り込むことが可能になります。イメージとしては、「自分たち専用のマネージドサービスを抽象化して作り上げる」ような体験になります。IDP の維持のためには継続した開発が必要であるので、多くの場合は IDP 専用の開発チームが独立して設けられています。
改めて先程の 2 つのアプローチと比較してみると、「認知負荷」ならびに「技術的負債」の問題に対して、Platforn Engineering が解となりうる可能性があることがわかります。つまり、共通基盤にあふれがちなゲーム開発環境の抜本的解決ができる可能性を秘めているため、世の中で注目されているテクノロジーアプローチとなっています。
ゲーム業界のこれからについて
ここで紹介した Platform Engineering ですが、実はまだ明確な定義が決まっていません。White Paper 2 も存在自体はしているのですが、具体的な事例などは現在 Platform Engineering Meetup 3 などで業界全体が見識を深めている最中です。
冒頭に述べたように、ゲーム業界には素晴らしいサーバー・インフラエンジニアの方が沢山いらっしゃると思います。新しいゲームサーバー共通基盤を構築する機会がありましたら、是非 Platform Engineering の考え方を参考にして頂き業界を導いて頂けると、今より面白いオンラインゲームが沢山増える未来に近づいていくことでしょう。
最後に、Platform Engineering についての Nintendo Systems 様の re:Invent 2023 での素晴らしい登壇を共有いたします。英語登壇にはなるのですが、本記事に興味がある方は是非ご参照頂けると幸いです！
※本記事の内容はあくまでも個人の意見であり、所属する企業や団体は関係ございません。