国内最大のゲームカンファレンス「CEDEC2021」が8月24日から26日にかけて開催され、「名作『Doom』を Fastly のサーバーレスコンピューティング Compute@Edge に移植してその機能を試してみた」のセッションが公開されました。
アメリカ合衆国のクラウドコンピューティングサービスプロバイダであるFastlyの次世代サーバーレスコンピューティング、Compute@Edge。このツールは高パフォーマンスやレイテンシの削減、可視化と安全性の向上を実現するために構築されたソリューションを押し出したものです。
本セッションはCompute@EdgeにFPSの名作『Doom』を移植することで、Compute@Edgeの機能を試してみた事例を紹介したものとなります。これまでもデジタルカメラから電卓まで、さまざまな機器に無茶な移植をされてきたことでお馴染みの『Doom』は、次世代ソリューションの中で、どのように銃弾を発射したのでしょうか？
Compute@Edgeとは何か？
本セッションのスピーカーとしてFastly株式会社の松田未央が登壇。FastlyはCDNの分野で活躍している企業ですが、その他にもセキュリティやパフォーマンスといった分野への戦略的な投資も行っているといいます。
そうした投資の一環として、コンピューティング分野にもかなりの力を入れているとのこと。今回のセッションは、その分野の投資結果であるCompute@Edgeについて解説が行われるものです。
さてCompute@Edgeとは、基本的に「サーバー管理が不要で、APIによって統一されたインターフェース」です。シングルクラウドでもマルチクラウドでもシームレスに稼働し、Rustなど複数のコーディング言語に対応していることを特徴としています。
サーバーレスの現状として、いくつかの課題が残っているとのこと。ひとつはコールドスタートによる遅延。一般的にサーバーレスは起動に時間がかかるもので、初回の起動が時間がかかるものですが、2回、3回と繰り返すなかで起動時間は早まっていくそう。しかし、不必要な遅延のため、UX上のマイナス要因には違いないと説明。
ふたつめは柔軟さに欠けた、世界の各地域にあわせたデプロイの問題です。サーバーレスのサービスは特定の地域で実行する必要があり、その前提で設計されたものといいます。それゆえに他の地域で対応しきれない点も問題とのこと。
Compute@Edgeが解決する課題には、まず優れたパフォーマンスが挙げられました。他社とは100倍以上早いスタートアップの時間を誇り、優れたスケーラビリティとセキュリティの品質を特徴としています。
松田氏によれば、Compute@Edgeは早くてセキュアなサーバーレスがその魅力だといいます。リクエストごとの実行タイムラインの性質が他社とは異なっており、ポイントは分離した実行リクエストの構造だと言います。こうした構造によって、セキュリティの脆弱性という問題も解決する狙いがあるとのことです。
Compute@Edgeのインテグレーションについても説明。コーディング言語にはRustやAssenblyScriptのほか、JavaScriptに対応しており、今後はGoの対応も考えているそうです。また、Compute@Edgeがらリクエストをオリジンクラウドに出すこともでき、AWSやGoogleクラウドなどなどと連携しているとのことです。
そんな最新型コンピューティングに『Doom』を移植したらどうなる？
そんなCompute@Edgeですが、ここから松田氏はこのサービスに『Doom』を移植してみたらどんな感じなのかについてを紹介していきます。
あらためて『Doom』を振り返りますと、本作はid softwareによって開発され、1993年にリリースされたFPSの基盤を作り上げた名作です。本作の特徴はゲームデザインだけではなく、1997年にオープンソース化することで「好きなOSにどんどん移植してください！」というスタンスを取ったことも非常に大きかったといいます。
Fastlyのシニア・ソフトウェアエンジニアであるジャスティン・ロウ氏もそんな移植に挑戦しようとしたひとり。Compute@Edgeで行われた社内ハッカソンにて、ジャスティン氏はサービスに『Doom』の移植を行った「Doom＠Edge」を発表しました。実際の内容は、こちらのリンク先にて実際にゲームプレイして確認できます。
ジャスティン氏はFastlyの公式ブログにて、いかに移植を成功させたかを記録していました。ここからのセッションは、彼のブログを元に解説を進めていきます。
まず移植（ポーティング）にはふたつの過程によって行われました。ひとつは、プラットフォームに依存しないコードをコンパイルして動作に持っていくことと、ふたつめはプラットフォームに依存するAPIコールを置き換えていったと言います。これは、音声を含む入出力関連がそれにあたるとのことです。
それからCompute@Edgeにてコードを実行するために、画面のレンダリングや音声を一時的に除外し、Wasi-sdkを利用してWASMバイナリに置き換えることで対応を目指したといいます。
実際にCompute@Edgeではどのように動いているかというと、「ゲームのループを除いて、1フレームごとの処理を行わせる」かたちとなりました。
一般的なゲームでは、初期化後にコントローラなどのローカルなデバイスからの入力を受けて映像や音声を出力する「入力→シミュレーション→出力」を、任意の頻度で繰り返し行うループで動作しています。
一方Compute@Edgeではインスタンスが起動して作業を行った後、呼び出し元へ戻ることが目的となっているため、一般ゲームのようなプロセスがプラットフォームよって最終的に削除されてしまいます。
その解決策として、ループではなく1フレームごとに処理していくという方法を取ったといいます。Compute@Edgeはリソースを長時間使うものに向かないですが、フレーム処理といった高速処理は得意なので、フレームごとの処理をインスタンス単位で実行させるかたちとなりました。
ステートはゲームのセーブの仕組みを利用したとのことで、言うなれば1フレームごとにクイックセーブして、すぐさまロードするというプロセスを繰り返すことで出力するかたちとなったそう。
次にキーボードの入力について解説。まず『DOOM』の入力システムは、入力イベントという概念で抽象化されています。たとえば「Wキーを押した」とか「マウスをX方向に動かした」といった具合です。
Compute@Edgeでは計算されたフレームバッファをブラウザへと出力し、ブラウザ側で描画の処理を行う……というのがここでの構造だそう。そこでブラウザにある標準的 JavascriptのEventListnerを使って対応したとのこと。こうして『DOOM』が対応できる入力イベントをブラウザ上で簡単に生成することができたといいます。
その後は「ちゃんとゲームできるくらいまで最適化すること」が課題になりました。最初は一回の処理でなんと200ms程度の往復スピードという、フレームレートで言えば約5fps程度しかなかったため、とてもじゃないがゲームにはならないものだったそう。そこから最適化を行い、なんとか50～75ms（フレームレートで約15fps）ほどのスピードにまでなったそうです。
松田氏は最適化については「あくまで実証実験なので、こういうふうにゲームを実装すべきという話ではない」と前置きしつつ、デバックにはLOG Tailenngの機能を使って最適化していった、とのことです。
松田氏は、Compute@Edgeでこう言ったこともできるという事例として、『Doom』移植は良いプロジェクトだったそう。「社内で観ていて、動いていることにビックリした」と振り返りました。
実際に出来たものをプレイしてみると、やはり通常の移植とは違い、かなり重い挙動ながらもたしかに『Doom』をプレイができるくらいのスピードで動いているのがわかりました。「ゲームとして使うのは難しいかもしれないですが、技術的にこういうこともできる」ということが証明されたものとなったようです。
最後に松田氏は、Compute@Edgeではその他にさまざまなデベロップメントツールを用意していると説明。今回の『Doom』移植でも利用したツールもあり、本サービスはさまざまな課題解決に役立つものである、と本セッションをまとめました。
