国内最大のゲームカンファレンス「CEDEC2021」が8月24日から26日にかけて開催され、「1年半運用してわかった！BLUE PROTOCOLにおけるビルドパイプラインのクラウド化の壁」のセッションが公開されました。
本セッションは、バンダイナムコスタジオが開発したオンラインRPG『BLUE PROTOCOL』の開発において、ビルドのプロセスをクラウド化したことによる効率化についてまとめられています。
セッションにはバンダイナムコスタジオのエグゼクティブテクニカルディレクターの大井隆義氏と、総務ITサービス部の吉田卓哉氏が登壇。現在、ゲーム品質の高度化に伴う開発期間の長期化やゲームエンジンでのビルド時間増加の問題があり、ビルドパイプラインのクラウド化がそうした問題の解決にどう貢献できたかが語られました。
膨大なデータを処理することになるビルドのプロセス
まずゲーム開発におけるビルドパイプラインのプロセスを解説。Perforceからソースコードをコンパイルし、クックでアセットを形成、その後パッケージングにてファイルを形成する……というのが、基本的なピルドの流れとなります。
しかし、現代のゲームは膨大なデータを処理しなくてはならない問題があり、スムーズにはいかない状況となっていました。
ビルドプロセスの最初の作業となる、ソースコードのコンパイルにも大量のソースが存在しているため、円滑に進めるにはビルド作業などを分散するコンピューティングツール、Incredibuildを導入してようやく進むほどだったといいます。
アセットをクックするプロセスも同様に、現代のオンラインRPGともなれば膨大なアセットが必要に。キャラからアニメーション、シェーダーなどの他、個々のサイズも大きいため、処理にかなりの工夫が必要だったそうです。
このようにビルドのプロセスは、大量のデータを処理しなくてはならない事情があり、開発の時間がかかってしまう要因の1つとなっています。
なぜビルドパイプラインをクラウド化したか
そんなビルドパイプラインをクラウド化したのはなぜでしょうか。続いて、1年前に本格的に実行した背景について解説されました。
まず、ゲームのサーバーがすでにクラウド運用となった流れを受けて、開発チームからは「開発環境もクラウド化できないか？」という声が挙がりました。
しかし実際にはさまざまな契約や社内のセキュリティの問題から難しいといいます。社外のクラウドから社内のファイルへのアクセスは許可されておらず、使用しているシステムもライセンス契約の関係で禁止されているほか、ファーストパーティ製のソフトウェア開発キット（SDK）も社外のクラウドに置くのも禁止されているため、環境をそのままクラウドに移行することはできません。
クラウドへ移行しようにも壁として、ユーザー認証基盤の問題からそもそもの業務にあたってのネットワークのスピードの他、ツールの契約などが立ちふさがり、解決すべき課題が大量にあるため簡単にはいかないのです。
なので、開発プロセスすべてをクラウド化するのは難易度やコスト面から難しいため、まずは「クラウド化しやすい部分からやってみる」考えのもと、ビルドパイプラインをクラウド化するに至ったそうです。いわば、将来的な開発環境のクラウド移行に向け、先行した環境づくりのひとつなのだと言えるでしょう。
いかにビルドパイプラインをクラウド化したか
さて従来のビルドパイプライン構成は、基本的に社内でビルド用PCにJenkinsを使ってビルドを行い、データセンタに成果物を納めるかたちでした。社外の開発協力会社は、ビルドPCのほか、成果物へのアクセスはファイアーフォールによってNGとなっています。
現在のピルドパイプラインの悩みとして、ビルド用PCの調達に時間がかかってしまうことや、PCのセットアップのほか、社内にPCを設置する場所の問題など主だったといいます。運用にも、停電や故障してしまうとそれまでのビルドに問題が起こるため、対応が必要なのですが、PCは運用期間が長くなるほど故障する可能性も増えてしまうため、常にリスクがあったといいます。
では、このビルドパイプラインをクラウド化する構成ではどうでしょうか。主にAmazonの運営しているクラウドサービスAmazon Web Services（以下、AWS）のクラウドを利用し、クラウド内にビルド用のインスタンスを設計することで、これまでの構成の代替としていったとのことです。
ここではJenkins自体がビルドするのではなく、ビルドインスタンスを別に作っていることが特徴。Jenkinsからビルドインスタンスへビルド実行する指示を送り、成果物をAWS内や、社内のストレージに格納するかたちです。
このプロセスの構築には、Jenkins単体ではなくAWS内のシステムを利用しているとのこと。主にAWS CLIという、AWS内のサービスを操作・実行できるツールを使います。
これはJenkinsにビルド依存しないかたちの環境を構築するためにそうしたサービスを使ったとのことです。というのも、Jenkinsが壊れると復旧が大変なため、主な役割はビルドインスタンスの起動やリモートでの実行・停止の管理に絞ったといいます。
続いてこうした構成によってどのようにビルドが流れていくかを解説。まずJenkinsインスタンスからPerforceへ最新のリビジョン番号を問い合わせます。
それからJenkinsがビルドインスタンスを立ち上げ、リビジョン番号してビルドのリクエストを指示。
そしてビルドインスタンスが、指定されたリビジョン番号にてPerforceから取得します。
ビルドインスタンスがタスクを並列実行し、成果物をアップロードするかたちで一連のビルドを完了させています。成果物はAWS内のストレージから、社外の開発協力会社に渡しやすくするなどの体制を整えている模様です。
ビルドパイプラインをクラウド化したことのメリット
クラウド化の結果、以前のようなローカルでのビルドPCによるビルドと比較しても遜色ない速度が出たそうです。
コンパイルからクック、パッケージングのプロセスにおいて、これまで2.5時間かかっていたものがクラウド化によって2.1時間でビルドが完了。この結果から、「クラウドでもビルドは問題ない」と判断したとのこと。ランニングコストも月に約18万円ほどだそうです。
クラウド化の中核となるAWSの良かったことは、これまでビルドマシン調達が2週間ほどかかっていたところを、環境構築が数分で出来たことがまず大きいそうです。また、成果物のデータを社外開発会社などに受け渡しも柔軟な点もありがたかったといいます。
さらにネット上でのナレッジも、公式だけではなくユーザーのものも多く、AWSの使用や対応をやりやすい環境だったと振り返りました。
一方、悪かった点として、AWSは従量課金制のため、「稼働時間が長いと金額が膨れ上がってしまうのが怖い」問題もあったそう。加えてマイクロソフトのVisual Studio がライセンスの問題から使えなかったり、ここまでに解説されたように複数のサービスを使うことでコストの試算が大変だったりする点があったそうです。
こうしたクラウド化したビルドパイプラインを1年運用した現状として、完全に開発は円滑になったかというと別の問題も発生していました。
ビルドまでの時間は環境構築した初期よりも1時間ほど増大してしまったといいます。その理由は、開発が進むにつれ、ソースコードやアセットが増えていったせいでした。またローカルのビルドPCのスペックに比べ、クラウドパイプラインのスペックが劣ってしまうこともあって、クックのプロセスで時間がかなりかかってしまった模様です。
必要に応じてクラウドパイプラインの他にビルドPCも使っていましたが、成果物を格納するAmazonのストレージであるElastic Block Store (以下、EBS) もコストがかかってしまうにのも困らされるポイントでした。
このようにクラウド化に立ちふさがった壁として、「ビルドインスタンスの進捗が把握しづらい」とか「クラウドと社内Jenkinsとの連携」のほか、在宅リモートワークによるダウンロード時間などなどの問題がありました。
こうした壁をどのように解決していったかというと、いくつかの問題はある程度対応でき、いくつかはまだ対応しきれない、もしくは対応の途中という結果となりました。
たとえばビルドインスタンスの進捗の問題は、Jenkinsの機能である、スレーブエージェント機能を使うことによって対応したといいます。その対応によって「ビルドの結果の確認がしやすくなった」ということで問題は解決できたそうです。
クラウドと社内のJenkinsをいかに連携させるか？という課題には、Slackを利用したやり取りを構築することで対応。クラウドJenkinsが終わると社内Jenkinsが働くようにするために、Slackへのビルド完了通知を利用したシステムを構築。
クラウドJenkinsがビルドを完了するとSlackへ完了の通知を発信、その通知を検知し、社内Jenkinsが動くようにトリガーを入れることで、連携させたとのことです。
また現在、コロナ禍ゆえの在宅リモートワークが活発です。しかし業務に当たり、ダウンロード時間の問題がボトルネックの一つになっているといいます。社内のファイルサーバーからVPN経由のダウンロードはとても遅く、業務の進捗を阻害してしまうものでした。
そこで「クラウドなのだから、そこから直接ダウンロードしたのほうが早いのでは？」と考えます。そこで成果物が保管されているAWSから直接ダウンロードするかたちに変更。セキュリティの対応としてアクセスキーの認証や、成果物の格納されているディレクトリのみへアクセスできるようにする形で対応します。この結果、ダウンロード高速化に成功します。
こうしたインスタンスを作成後、すぐにリモートデスクトップで作業したいといった課題もうまく解決できたのですが、いくつかの課題は未解決となりました。
停止中のインスタンスEBSの問題は、ストレージのタイプを変更しても20％金額が安くなる程度で、根本的な解決には至らなかったそうです。また複数環境でのJenkinsアカウント管理についても、Amazon Cognitoを利用したユーザー管理を考案しているものの調査中とのこと。
ハイスペックインスタンスの動作していないCPUにて、CPUを100％使いきりたいと考えた時、Incredibuildのクラウドを導入することも考えたそうです。これはスポットインスタンスで動作が可能なのはわかりましたが、インスタンスのタイプと導入するツールのライセンス料のバランスを考えた結果、見送ったといいます。
まとめとして、「社内で閉じた開発を一部、クラウドに移行できた」のは確かだといいます。クラウドのメリットはインスタンス追加の手軽さなど、環境構築を行う効果はとても大きいことが分かりました。しかし改善すべき問題はかなり残っているとのこと。今後も改善に務めていくと語り、セッションを終えました。
