【CEDEC 2020】KLab、『スクスタ』を支えるビルドパイプライン…より安定したサービス提供を目指す取り組みとは？

コンピュータエンターテインメント協会（CESA）は、9月2日～4日の期間、オンラインにて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2020」（CEDEC 2020）を開催した。

本稿では、9月4日に実施された、KLab<3656>のセッション「『ラブライブ！スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン～より安定したサービス提供を目指して～」の模様をお届け。

本セッションに登壇した同社エンジニアリング本部の栂井良太氏、橋本卓也氏が、『スクスタ』の新しいコンテンツやアップデートをいち早く安定して提供するための仕組みを紹介した。



「いち早く安定して提供するための仕組みを実現するためには、様々な作業の自動化、成果物のバージョン管理、CIシステムの構築などが必要」とは栂井氏。

KLabでは、これら領域をビルドパイプラインと呼んでいる。

ビルドパイプラインでモバイルゲームを作る際、企画がマスタデータ、デザイナーがアセット、プログラマーがプログラムコードとそれぞれ成果物を作り、リポジトリやファイルストレージにアップロードする必要がある。

そしてアプリをビルドし、ストアへアップロード。さらに同社はオンラインゲーム制作が多いので、サーバーコードを本番サーバーへ展開する。



また、都度自動テストなどを走らせたり、モバイルゲームでは追加ダウンロードという形でアセットを提供することが多いため、アセットをビルドしてパッケージングしたり、追加DL用ストレージにアップロードする。

こうして初めてユーザーはゲームで遊ぶことができるようになるという。

さらに本番環境と同じような環境を開発環境として開発者に提供する。同社ではこの成果物の納品からユーザーの手元に届くまでの流れをビルドパイプラインと呼んでいる。

「昨今のゲームでは、より素早い改善サイクルを提供できるゲームがユーザーに評価されやすい」と栂井氏。

バリューストリームを高速化するためには、ビルドパイプラインの安定化、高速化が必要不可欠とした。


▲企画、開発、テスト展開、そしてユーザーからフィードバックを受け、さらに企画するという一連の流れをバリューストリームと呼ぶ。

ここで『スクスタ』のビルドパイプラインの構成について。



企画やプログラマーがゲームエンジンと開発サーバーを使い、プログラムやマスタデータを入力。そしてgitにコミットする。

同時にデザイナーがアセットを作成し、サブバージョンサーバーへアップロードする。その後、Jenkinsを使いアセットをビルドすると実機動作確認ができるようになる。

そしてJenkinsを使ってアプリをビルドし、開発サーバーへサーバーコードの展開を行う事で実機でのゲーム動作確認が可能に。

最後にまたJenkinsを使い本番サーバーへサーバーコードを展開。さらに追加DL用ストレージにアセットをアップロードする、というのが構成要素となる。

しかしビルドパイプラインは、リリース遅延要因になりやすい、運用が属人化しやすい、突然壊れたら直しにくいなどの特徴と問題点が存在するという。



このような問題点は各プロジェクトに存在し、解決方法も各プロジェクト内で閉じてしまうため、KLabはビルドパイプライン専属グループを組織し、各プロジェクトと兼務しているそうだ。

■運用を柔軟にするgod環境

ここからは、先述の3つの問題点を解決した手法を橋本氏が紹介した。まずは運用を柔軟にするgod環境について。



上の開発・マスターデータ作成フローは、開発者、企画者が素早く自分の修正をゲーム上で確認し作り込む事を目的としている。

『スクスタ』はクライアントの一定範囲について、バックエンド開発者が責任を持つという開発体制となっており、クライアントとサーバーを密結合にするのが品質、開発効率を考えると合理的とのこと。

しかし、クライアント・サーバー密結合化を進めた結果、1台の共有サーバーで機能実装を進めるのが困難で、クライアントとサーバーのバージョンが合っていないと動かないため、使えなくなる人が増えてしまうという問題が発生。

その解決策がAmazon EC2でサーバーを増やすという体制。このEC2で動かすサーバー環境がgod環境だ。

god環境では、開発者は基本的に1人1godを使用。さらにマスタデータを作る企画者や実機動作確認用にもそれぞれgodを割り振っているという。


▲godの利点。他にもgod使用者を管理し、godの起動・停止・破棄ができるslack botがある。



▲便利なgodだが、多くのgodを運用するには、gitの使い方に工夫が必要という。

こうして、god環境と呼ばれるAmazon EC2で動作するサーバー環境によって、簡単かつ柔軟に動作確認できる体制を作る事が、リリース遅延要因になりやすい問題の対策の1つとした。

■アセット管理のために作ったpbag

次に紹介された、アセット管理のために作ったpbagも、リリース遅延要因になりやすい問題の対策となる。



上図はアセット製作・管理のフロー。デザイナーがゲーム素材を制作し、アセットバンドルビルドしたものを管理することを目的としている。

1つ問題として、Unityプロジェクトを開く時間の短縮が挙げられるが、「ここを高速化したらチーム全体の作業効率が高まる」と橋本氏。

そこで、ベースリポジトリ構成を工夫し、ベースリポジトリ内のUnityプロジェクトには3Dモデル等のアセットは入れず、別のUnityプロジェクトに分離した。

これでベースリポジトリ内のUnityプロジェクトを開く時間が短縮、ベースリポジトリの容量が減りサーバー展開も早くなった。



前述の別Unityプロジェクト分離について、リソース入りgitリポジトリがその分離先となり、ここに3Dモデル等の素材データが入っている。




リソース入りgitリポジトリは、アセット等の素材が基本的に全部入っているためUnityエディタの動作が遅く、作業者のストレージも圧迫する問題点もあり、直接使うのは作業効率があまりよくない。

そこでリソース入りgitリポジトリを細分化し、サブバージョンで管理。通常の制作ではサブバージョンを使っているという。


▲アセットバンドルビルドについて。

また、アセットバンドルビルドの成果物を集積し、ベースリポジトリ側UnityプロジェクトをUnityエディタで開く作業者が、アセットバンドルズチルダのフォルダにアセットバンドルビルドの成果物を持ってくる、ということを可能にするためのストレージが必要になる。

そこで自作したのがpbagとなる。



その概要について、pbagサーバーは概念的にはファイルのダイジェストからファイル実体へのkey-value storeとなっている。

そしてクライアントはサーバーに接続し、ファイルのダイジェストを送信するとファイル実体が返ってくる、という仕組みだ。




これにより、新しい名前を登録したり名前に紐づけられるダイジェストを変更したりという操作が可能に。pbagにアセットバンドルビルドの成果物を集積し、Unityエディタ作業者がアセットバンドルを使いやすくするストレージを提供できるようになった。

次にアセットダウンロードについて。pbagで管理されるのは、エディタ実行用のファイルで、実機ではAmazon S3からダウンロードしたファイルを使っている。

S3上のファイルはDLを早くするため、複数のアセットバンドルを結合する処理をして、結合時に暗号化している。

ここでチーム全体の作業効率を高めるには、という要件を改めて考えると、「サーバーを増やしやすくしたいという課題があるので、それに合わせたアセット管理の実現が必要」と橋本氏。

そこでアセットマスタデータというものを考えた。これはS3上に配置されたファイル情報で、それをベースリポジトリに入れてサーバーに展開。

展開されたアセットマスタデータをクライアントがDLし、クライアントはアセットマスタデータに基づいてS3からアセットが入ったファイルのDL処理をするという。

そのアセットマスタデータ作りを担うのがパッケージングだ。これはマスタデータに基づいてpbag上のファイルを結合・暗号化してS3にアップロードし、アセットマスタデータをベースリポジトリにコミットするという処理。



パッケージングはJenkinsジェンになっていて、ベースリポジトリのブランチを指定して実行する形となる。

パッケージングはマスタデータから必要なアセットを列挙する処理を行う。

パッケージング側のデータベースがあるので、S3にアップロードされているファイル情報を入れておき、パッケージング処理ではデータベースから情報を取得。

さらにどのようなファイルを作成してS3にアップロードするかを計算するという処理を行う。

そしてpbagから必要なファイルをDL。事前に使用するファイルを決定しているので、必要なファイルだけを取得できる。

また、どのようにファイルを結合・暗号化してS3にアップロードするか決められており、処理して作られたファイル情報をデータベースに保存できる。

最後にアセットマスタデータを生成し、ベースリポジトリにコミットすればパッケージングは完了となる。



パッケージングは、マスタデータから参照されているアセットだけをアセットマスタデータに書き出す仕組みになっていた。

この時、マスタデータから参照されていないアセットがあると、パッケージングがアップロードするべきファイルをアップロードしないことがあるため、アセットローダはマスタデータから取得したアセットパスしか受け付けない仕組みにしているという。

そのためアセットパスはstringにせず、アセットのカテゴリごとに専用のクラスを用意するという対応をしているそうだ。



また、未公開データの流出を防ぐ事は『スクスタ』において重要。

とはいえマスタデータ調整や動作確認の作業をする上では、公開したら不味い将来のアセットバンドルも必要となり、それを満たすアセット公開制御の仕組みも求められた。


▲将来のアセットバンドルをpbagに格納できる事で、チーム全体の作業効率を高めるという目的を達成。

アセット管理はチーム全体の作業効率を左右するので重要。

そのためにアセットバンドルを管理するためのストレージとしてpbagが作成され、リリース遅延要因になりやすい問題の対策となった。

■ChatOpsによるビルド作業の効率化

再び栂井氏が登壇し、ChatOpsによるビルド作業の効率化について解説。ChatOpsは運用が属人化しやすいという問題の対策となる。

アプリをビルドしたい時、まずJenkinsでビルドを開始。するとMac上でアプリがビルドされ、アプリのビルドが完了すると実機にアプリをインストールする。

それと同時にサーバーコードを開発サーバーへ展開し、アセットをアップロード。こうして実機でサーバーに接続し、動作テストを行うことができるようになる。

ここでの要件は、Jenkinsを使ってMacで素早く安定してアプリのビルドと展開が出来る事と、非開発者でもアプリビルドやサーバー展開ができる事。


▲アプリビルドやサーバー展開、アセットビルド等、あらゆる運用作業でJenkinsが起点に。

しかし、「JenkinsのUIや複雑なパラメーターをいきなり非開発者が使うのは難しく、一定のレクチャーが必要」と栂井氏。

従来は、非開発者がアプリを欲しい場合、特定の運用作業者にビルドを依頼し、運用作業者が代理でビルドを行っており、多くの非開発者から特定運用作業者にビルド依頼が集中し、パンクしていたという。

そこで非開発者でも利用しやすいインターフェースで、誰でもJenkinsで運用作業が行えるよう、ChatOpsの導入が検討された。

ChatOpsとは、チャット経由であらゆる運用作業が完結するシステムで、KLabではチャットシステムとしてSlackを用いているという。


▲非開発者でもSlackに発言するだけでJenkinsで運用作業ができ、ビルドの仕方がわからない場合はSlackのログ検索でやり方がわかる。

しかし、問題はこれだけでは解決しなかったという。当初、ビルドコマンドを入力するだけで簡単に運用作業ができると想定していた。

が、実際ゲームを作るためには非常に多くの、そして複雑なビルドコマンドが必要で、調整のハードルが高いという問題点が存在。

この問題を解決するために、「実現したいビルド要素を入れると、ビルドコマンドが返ってくるコマンド生成シートを作る事を考えた」（栂井）


▲実現したいビルド要素をコマンド生成シートに入れると返ってくるビルドコマンドをSlackにコピペするだけで簡単にビルドができるシステム。

ChatOpsとコマンド生成シートを導入した結果、特定運用作業者にビルド依頼が集中した形から、運用属人化問題は解消。さらにコマンド生成シートで非開発者でもビルドができるようになった事で、より運用がスムーズになったそうだ。

■壊れても復活するビルドシステム

続いて、壊れても復活するビルドシステムについて、ビルドマシンを紹介。こちらは突然壊れたら直しにくい、という問題点の対策となる。

従来、アプリのビルドやアセットバンドルビルドは1プロジェクトに1台だけある社内Macを使用していた。

しかし、運用の長期化で社内Macにつぎはぎで設定を入れていくことになり、誰もJenkinsやビルドマシンを1から構築する方法がわからなくなる。

そして、いざMacが故障するとMacやJenkinsの復元に時間がかかり、アプリのリリースができなくなるという問題が存在していた。

そこで『スクスタ』では、Jenkins master slave運用を導入する事に。



これは、Jenkins自体はMacに置かずクラウド上のLinuxに載せ、Mac上ではjnlp slaveを立ち上げてJenkins masterに接続し、master-slave構成をとることができるという。

またMacは複数台用意し、冗長化。東京オフィスだけでなく福岡オフィスにもslave Macを置くことで地理的冗長化もとることができ、例え1台が壊れてもリリースは止まらない、ということを実現できる。

さらにChatOpsと合わせると、ビルドのロードバランシングを行うことも可能に。



作業者はSlackにアプリのビルドコマンドを投げると、Slack botはJenkinsのAPIから最も実行中ビルドが少ないslaveを取得し、ビルドを行う。

これにより、特定のMacにビルドが集中することなく全体的にビルドスピードが向上するという。


▲Jenkinsのあらゆる手動設定をgit管理し、Jenkinsが壊れても再現性を確保することができるようになった。


▲Ansible、Dockerによる構成管理も行った。

これらの仕組みを導入し、アプリビルドやアセットバンドビルドを従来1プロジェクトに1台だけある社内Macでビルドしていた形から、社内Macを冗長化し、Macの障害に対するリスクヘッジを達成した。

さらに、あらゆるJenkinsやMacの手動設定をコード化し、git管理、コードレビューを可能にする事で、Jenkinsの故障に対するリスクヘッジも達成。こうしてビルドマシンに潜むあらゆるリリース遅延要因を排除できたそうだ。

最後に栂井氏は、「今回紹介した工夫により、『スクスタ』はバリューストリームの高速化を達成できました」と語った。