Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 『ラブライブ！スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜
Similaire à 『ラブライブ！スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜 (20)
Plus de KLab Inc. / Tech
Plus de KLab Inc. / Tech (20)
Dernier
Dernier (9)
『ラブライブ！スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜
- 1. 『ラブライブ！スクールアイドルフェスティバルALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜 ©KLabGames©SUNRISE©bushiroad All Rights Reserved. KLab株式会社 栂井 良太 / 橋本 卓也
- 2. 2 モバイルゲームの開発プロジェクトと横断 組織を兼務し、DevOpsを推進 各セクションのつなぎこみや運用業務を効 率化するツールの開発、自動化など 栂井 良太 バックエンドアーキテクチャG エンジニア 2018年 KLab新卒入社 とが い りょうた APIサーバ開発・通信アーキテクチャー 設計を経て、パイプライン担当になる。 パイプラインのためのクライアント・ サーバの各種設計・実装に関わる。 橋本 卓也 バックエンドアーキテクチャG エンジニア 2012年 KLab新卒入社 はしもと たくや
- 4. 4 本セッションの内容 ラブライブ スクールアイドルフェスティバル ALLSTARS(スクスタ) の新しいコンテンツやアップデートを いち早く、安定して提供するための仕組みをご紹介 自動化 バージョン管理 CIシステム構築 ビルドパイプライン
- 7. 7 ビルドパイプラインの重要性 企画 開発 テスト 展開 フィード バック より素早い改善サイクルを提供できるゲームがユーザーに評価されやすい ・ユーザーの要望をすぐにサービスに反映できる ・バグがあればすぐに治せる ・積極的な新機能開発ができる バリューストリーム ✅ バリューストリーム高速化のためには ビルドパイプラインの安定化、高速化が必要不可欠
- 9. 9 ビルドパイプラインの特徴と問題点 ① リリース遅延要因になりやすい ビルドパイプライン(Jenkinsなど)は全メンバーが利用 非効率なしくみだとリリースまでに時間がかかってしまう ② 運用が属人化しやすい 日々進化するビルドパイプラインは使い方も変わっていく 特定の運用作業者しかテストビルドを作ることができなくなる ③ 突然壊れたら直しにくい アップデート必須の状況はやってくる その日、数年間触ってないマシンを触らないといけなくなる
- 11. 11 KLabのビルドパイプラインへのとりくみ パイプライン専属のメンバーがプロジェクトの需要に合わせ たツールの開発を行い、知見を横断的に共有 数年後も、 よりはやくユーザーにコンテンツを届けられるシステム を目指す ① リリース遅延要因になりやすい ② 運用が属人化しやすい ③ 突然壊れたら直しにくい 本日は得られた知見の中で、 3つの問題点を解決した手法をご紹介
- 14. 14 開発・マスターデータ作成フロー 開発者や企画者が素早く自分の修正をゲーム上で確認し、 ゲームを作りこんでいく 目的 ① 開発PCで コードやデータを 修正 ②サーバ展開 開発サーバ ③Unityエディタ 動作確認 ポイント ✅ 自分の修正をUnityエディタで 簡単に動作確認できること ✅ クライアントだけでなく、 サーバの動作確認も一緒にできること ④PRを出してマージ サーバとAPI通信 サーバとAPI通信 ⑤実機で 動作確認 ✅ 多様な需要を満たせるように 運用に柔軟性があること
- 15. 15 開発体制 参考 : CEDEC+KYUSHU 2018 「大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例」 クライアント サーバ フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲 クライアントの一定範囲について バックエンド開発者が責任を持つ開発体制
- 16. 16 開発体制 この体制では、クライアント・サーバを密結合にするのが 品質・開発効率を考えると合理的 クライアント サーバ フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲 密 結 合 参考 : CEDEC+KYUSHU 2018 「大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例」
- 26. 26 god操作のChatOps 誰がどのgodを使っているかを管理し、 godの起動・停止・破棄ができるslack botがある godは夜に自動停止する （Go言語のnlopes/slackを使用） @godpanther start @hashimoto-t god0003 started
- 27. 27 リポジトリ構成 baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) これらを一つのgitリポジトリで管理している → 同一ブランチのクライアント・サーバなら整合が取れる → たくさんのgodを運用する上でも都合が良い
- 29. 29 運用を柔軟にするgod環境 god環境と呼ばれているAmazon EC2で動作するサーバ環境によって、 簡単かつ柔軟に動作確認できる体制になっている ① 開発PCで コードやデータを 修正 ②サーバ展開 ③Unityエディタ 動作確認 ポイント ✅ 自分の修正をUnityエディタで 簡単に動作確認できること ✅ クライアントだけでなく、 サーバの動作確認も一緒にできること ④PRを出してマージ サーバとAPI通信 サーバとAPI通信 ⑤実機で 動作確認 ✅ 多様な需要を満たせるように 運用に柔軟性があること god環境 まとめ
- 32. 32 アセット制作・管理のフロー デザイナーがゲーム素材(アセット)を制作し、 AssetBundleビルドしたものを管理する 目的 ポイント ✅ アセット制作後、AssetBundleを 素早くビルドできること ✅ 必要なリリースタイミングで 適切にアセットを公開できること ✅ ビルドしたAssetBundleを バージョンをつけて管理できること ② AssetBundle ビルド Subversion ① アセットの制 作 ダウンロード ⑤実機で 動作確認 ③ ビルド後の 成果物を集積 ④ パッケージング 追加ダウンロード用 ストレージサーバ ④ リリースタイミングを制 御 pbag
- 34. 34 Unityプロジェクトの構成 3Dモデル等のアセットを別のUnityプロジェクトに分離 → Unityプロジェクトを開く時間の短縮 → サーバ展開の高速化 baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式)
- 35. 35 Unityプロジェクトの構成 baseリポジトリのUnityプロジェクトでは、 AssetBundleビルド後のアセットを使用 AssetBundleはgit管理外とし、 Hidden AssetsにすることでUnityエディタからも管理外に AssetBundles~ git上では空 この下に大量の AssetBundleファイル AssetBundles~は無い UnityEditorからは見えない 参考 : https://docs.unity3d.com/Manual/SpecialFolders.html
- 43. 43 pbag概要 pbagサーバ pbagクライアント a9993e3... 84983e4... 34aa973... dea356a... 認証サーバ 兼 ファイルリスト管理サーバ (カテゴリ, 名前) から ファイルリストのダイジェスト への マッピングを管理する。 gitでいうところのブランチ マッピング 76aa478... 8c7b756... ver1.8.0 ver1.8.1
- 49. 49 パッケージング処理 (1/5) パッケージングはJenkinsジョブになっていて、 baseリポジトリのブランチを指定して実行する まず、マスタデータから必要なアセットを列挙する baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) アセット一覧を 作成
- 51. 51 パッケージング処理 (3/5) pbagから必要なファイルをダウンロードする 事前に使用するファイルを決定しているので、 必要なファイルだけをダウンロードすれば良い pbag ダウンロード
- 53. 53 パッケージング処理 (5/5) アセットマスタデータを生成して、 baseリポジトリにcommitする baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) ・アセットマスタデータ
- 56. 56 アセットローダ アセットパスをアセットローダに渡すとロードされる構造 pbag管理ファイル (AssetBundles~) からロードするか S3からダウンロードしたファイルからロードするかは アセットローダによって隠蔽される → フロントエンド実装は、どちらからロードしているかを意識しない アセットローダ アセットパス アセット pbag AssetBundles~ S3
- 58. 58 アセットの公開制御 パッケージングは、マスタデータから参照されているアセットだけを アセットマスタデータに書き出すことで、未公開データの流出を防ぐ → 適切なマスタデータが設定されていたら流出は防がれるので、 pbagには将来のAssetBundleを格納できる → 将来のAssetBundleがpbagに入っていることで、 マスタデータ調整や動作確認がしやすくなる → チーム全体の作業効率を高める
- 59. 59 アセット管理のために作ったpbag ・アセット管理はチーム全体の作業効率を左右する ・AssetBundleを管理するためpbagを作成した まとめ ポイント ✅ アセット制作後、AssetBundleを 素早くビルドできること ✅ 必要なリリースタイミングで 適切にアセットを公開できること ✅ ビルドしたAssetBundleを バージョンをつけて管理できること ② AssetBundle ビルド Subversion ① アセットの制 作 ダウンロード ⑤実機で 動作確認 ③ ビルド後の 成果物を集積 ④ パッケージング 追加ダウンロード用 ストレージサーバ ④ リリースタイミングを制 御 pbag
- 62. 62 スクスタのアプリビルドフロー ポイント ✅ Jenkinsを使って、Macで素早く安定し てアプリのビルドと展開ができること ✅ 非開発者でもアプリビルドやサーバー展 開ができること ① Jenkinsでビ ルド開始 ② Macで アプリビルド ③ 実機に アプリを インストール ④ サーバー 展開 開発サーバー 追加DL ストレージ サーバー アセット管理 サーバー ⑤ パッケー ジング ⑥ 実機でサーバーに 接続し、動作テスト ⑦ 追加ダウンロード
- 64. 64 ChatOpsの導入 ビルド結果 コマンド投稿 ChatOps 非開発者でも利用しやすいインターフェースで、 誰でもJenkinsで運用作業できるようにしたい HTTP Request Slack bot ビルド実施 ビルド 非開発者 ビルド依頼 ✅ 非開発者でも、slackに発言するだけで Jenkinsで運用作業ができるようになった ✅ ビルドの仕方がわからなくても、slackのロ グを検索することでやり方がわかる 運用作業者 Slack bot
- 66. 66 ビルドパラメータの複雑性 長いビルドコマンド サーバー接続先 ブランチ 認証キー アプリタイトル アセットのブランチ ビルドマシン名 💣 ビルドパラメータが肥大化しがち 実現したいビルドを作るために必要なパラメータが多 い 結局限られた運用作業者でないとビルドが困難 ビルド Slack bot 生成されたコマンドをコピペ 🧐 解決案の着想 実現したい ビルドの要素 コマンド 生成器 ビルドコマンド
- 68. 68 ChatOpsとコマンド生成シートの導入結果 非開発者 ビルド依頼 運用作業者 ビルド 非開発者 コピー＆ ペースト ビルド Slack bot ✅ ChatOpsの導入により、運用属人化問題が解消 ✅ ビルドパラメータがわからなくても、コマンド生成シートからコピー &ペーストするだけで非開発者でもビルドができる ✅ プロジェクトのメンバー全員が、自分の欲しいビルドを自分でつくれ るようになった
- 72. 72 Jenkins master slave運用 AWS 東京オフィス jnlp slave jnlp slave jnlp slave 福岡オフィス jenkins master ✅ Jenkins自体はMacに置かず、 クラウド上のLinux(EC2)に載せる ✅ Mac上ではjnlp slaveを立ち上げ、 jenkins masterに接続する (master-slave構成) ✅ Macは複数台用意し、地理的冗長化す る ✅ Macが1台壊れたとしても、リリース が止まらない
- 73. 73 ChatOpsと合わせた、ビルドのロードバランシング jnlp slave 3 (3ビルド実行中) jenkins master Slack bot ビルド jnlp slave 2 (1ビルド実行中) jnlp slave 1 (4ビルド実行中) 最も実行中ビルドが 少ないslaveを指定して ビルド ✅ ChatOpsと合わせると、Macをロードバ ランスし、ビルドを効率化可能 ✅ ビルド時にslack botからJenkinsの最も ビルド数の少ないMacを取得し、ビルド ✅ 特定のMacにビルドが集中することな く、全体的にビルドスピードが向上 JenkinsのAPIから 最も実行中ビルドが 少ないslaveを取得 slave2が最も ビルドが少ない
- 74. 74 Jenkinsの手動設定をgit管理 Jenkins Configuration as code (Jenkins本体の設定) ✅ Jenkins本体の設定をyamlで記述可能 ✅ Jenkinsの設定をgitで管理可能。コード レビューが可能 Jenkins Pipeline Script (各ジョブの設定) ✅ Jenkinsの各ジョブの設定をgroovyライク なスクリプトとして記述可能。シェル実行可能 ✅ ビルドスクリプトをgithubから取得可能。 git管理、コードレビューできる Jenkinsにスクリプトや設定を手書きして、 誰がいつ更新したかも管理できていない Jenkinsのあらゆる手動設定を gitで管理し、 Jenkinsが壊れても再現性を確保
- 75. 75 Ansible、Dockerによる構成管理 jnlp slave jnlp slave jnlp slave jenkins master jenkins docker image ✅ Jenkins masterはDocker上で 構築し、構成管理する ✅ Mac slaveはAnsibleで 構成管理をする ✅ 冗長化Macが増えた場合でも、 Ansibleで即セットアップ可能 ✅ どこかのサーバーが故障しても 即座に復旧可能
- 76. 76 アプリビルドがどう変わったか 1プロジェクトに1台だ けある社内Mac アプリビルド ABビルド jnlp slave jnlp slave jnlp slave jenkins master アプリビルド ABビルド ✅ 単一障害点となっていた社内Macを冗長化し、Macの故障に対するリ スクヘッジを達成 ✅ あらゆる手動設定をコード化し、git管理、コードレビュー可能にし てJenkinsの故障に対するリスクヘッジを達成 ✅ ビルドマシンに潜む、あらゆるリリース遅延要因を排除
- 77. まとめ
- 78. 78 ビルドパイプラインの特徴と問題点と解決策 ① リリース遅延要因になりやすい ② 運用が属人化しやすい ③ 突然壊れたら直しにくい 1人1サーバー環境(god)の整備 アセット管理方法の工夫 対 策 Slackを利用したChatOpsの導入 コマンド生成シートの作成 対 策 ビルドマシンの冗長化 CIのあらゆる設定をコード化 対 策 バリューストリームの高速化を達成できた