O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
『ラブライブ!スクールアイドルフェスティバルALL STARS』を支えるビルドパイプライン
〜より安定したサービス提供を目指して〜
©KLabGames©SUNRISE©bushiroad All Rights Reserved.
KLab株式...
2
モバイルゲームの開発プロジェクトと横断
組織を兼務し、DevOpsを推進
各セクションのつなぎこみや運用業務を効
率化するツールの開発、自動化など
栂井 良太
バックエンドアーキテクチャG エンジニア
2018年 KLab新卒入社
とが い...
3
ラブライブ!スクールアイドルフェスティバルALLSTARSとは
美麗な3Dで楽しめるリズムアクションRPGです!
※ 動画はリリース初期
2019/09の動画です
4
本セッションの内容
ラブライブ スクールアイドルフェスティバル ALLSTARS(スクスタ)
の新しいコンテンツやアップデートを
いち早く、安定して提供するための仕組みをご紹介
自動化 バージョン管理
CIシステム構築
ビルドパイプライン
ビルドパイプライン概要
目的と問題点、KLabでの取り組み
6
モバイルゲームビルドパイプラインとは
ユーザー

企画

プログラマー

デザイナー

リポジトリ or

ファイルストレージ

自動テスト
サーバー
展開
本番サーバー

アセット
ビルド
パッケー
ジング 追加ダウンロード用スト
レージ...
7
ビルドパイプラインの重要性
企画 開発 テスト 展開
フィード
バック
より素早い改善サイクルを提供できるゲームがユーザーに評価されやすい
・ユーザーの要望をすぐにサービスに反映できる
・バグがあればすぐに治せる
・積極的な新機能開発ができ...
8
スクスタのビルドパイプライン構成要素
アプリビルド
実機動作確認環境
アプリビルドマシン
開発サーバー
Jenkins
開発環境
プログラマー
企画
 開発サーバー
ゲームエンジン
プログラム
マスターデータ gitリポジトリ
デザイナー
...
9
ビルドパイプラインの特徴と問題点
① リリース遅延要因になりやすい
ビルドパイプライン(Jenkinsなど)は全メンバーが利用
非効率なしくみだとリリースまでに時間がかかってしまう
② 運用が属人化しやすい
日々進化するビルドパイプラインは...
10
KLabのビルドパイプラインへのとりくみ
企画

プログラマー

デザイナー

リポジトリ or

ファイルストレージ

アセット
ビルド
パッケー
ジング
追加ダウンロード
用ストレージ

自動テスト
サーバー
展開
アプリ
ビルド
ス...
11
KLabのビルドパイプラインへのとりくみ
パイプライン専属のメンバーがプロジェクトの需要に合わせ
たツールの開発を行い、知見を横断的に共有
数年後も、
よりはやくユーザーにコンテンツを届けられるシステム
を目指す
① リリース遅延要因にな...
運用を柔軟にするgod環境
サーバー環境の物量作戦
① リリース遅延要因になりやすい
対
策
13
スクスタのビルドパイプライン構成要素
開発環境
プログラマー
企画

デザイナー

AssetBundleビルド
アプリビルド
実機動作確認環境
サーバー展開
パッケージング
開発サーバー
ゲームエンジン
アプリビルドマシン
開発サーバー...
14
開発・マスターデータ作成フロー
開発者や企画者が素早く自分の修正をゲーム上で確認し、
ゲームを作りこんでいく
目的
① 開発PCで
コードやデータを
修正
②サーバ展開
開発サーバ
③Unityエディタ
動作確認
ポイント
✅ 自分の修正...
15
開発体制
参考 : CEDEC+KYUSHU 2018
「大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例」
クライアント サーバ
フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲
クライアント...
16
開発体制
この体制では、クライアント・サーバを密結合にするのが
品質・開発効率を考えると合理的
クライアント サーバ
フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲
密
結
合
参考 : CEDEC+KYUSHU 2018
...
17
クライアント・サーバ密結合の問題点
クライアントのバージョンと
サーバのバージョンが合わないとき、
アプリが正常に動作しない
→ 密結合にすることで、この問題が発生しやすくなる
古いサーバ
新しいクライアント
18
サーバ需要の増大
KLabでは従来、共用サーバを使うことが多く、
クライアント開発チームで1台の共用サーバといった体制
19
サーバ需要の増大
しかし、クライアント・サーバ密結合化を進めた結果、
1台の共用サーバで機能実装を進めるのは困難に
クライアントが
新しすぎる
クライアントが
古い
クライアントの
バージョンが
合ってる
クライアントの
バージョンが
少...
20
サーバ需要の増大
サーバを増やすことで対応
Amazon EC2でサーバをたくさん立てる体制に
21
god環境
EC2で動かしているサーバ環境はgod環境と呼ばれている
god0001 god0002 god0003 god0004
22
god環境
開発者は基本的に一人1god
23
増えるgod
マスタデータを作る企画者にも一人1god
24
増えるgod
実機動作確認のためにもgod
25
godの利点
・サーバ環境が空くまで動作確認できないという状況を回避でき、
待ち時間を節約
・各自がローカルサーバ環境を構築する時間を節約
・開発者が全サーバにssh接続できるので、
不具合調査がしやすくなる
・何か起きても、EC2インス...
26
god操作のChatOps
誰がどのgodを使っているかを管理し、
godの起動・停止・破棄ができるslack botがある
godは夜に自動停止する
(Go言語のnlopes/slackを使用)
@godpanther start
@h...
27
リポジトリ構成
baseリポジトリ
・クライアント (Unityプロジェクト)
・サーバ
・マスタデータ (tsv形式)
これらを一つのgitリポジトリで管理している
→ 同一ブランチのクライアント・サーバなら整合が取れる
→ たくさんの...
28
gitブランチ管理
9/1公開用ブランチ
9/5公開用ブランチ
次のバイナリ更新用ブランチ
本流ブランチは一つではなく、公開時期ごとにブランチが分かれている
→いつ公開予定の内容を確認したいかによって、使うブランチを変える
これによって多...
29
運用を柔軟にするgod環境
god環境と呼ばれているAmazon EC2で動作するサーバ環境によって、
簡単かつ柔軟に動作確認できる体制になっている
① 開発PCで
コードやデータを
修正
②サーバ展開
③Unityエディタ
動作確認
ポ...
アセット管理のために
作ったpbag
チーム全体の作業効率を高める
AssetBundleビルド戦略
① リリース遅延要因になりやすい
対
策
31
スクスタのビルドパイプライン構成要素
開発環境
プログラマー
企画

デザイナー

AssetBundleビルド
アプリビルド
実機動作確認環境
サーバー展開
パッケージング
開発サーバー
ゲームエンジン
アプリビルドマシン
開発サーバー...
32
アセット制作・管理のフロー
デザイナーがゲーム素材(アセット)を制作し、
AssetBundleビルドしたものを管理する
目的
ポイント
✅ アセット制作後、AssetBundleを
素早くビルドできること
✅ 必要なリリースタイミングで...
33
チーム全体の作業効率を高めるには
Unityプロジェクトを開くのに時間がかかる
→ これを高速化したらチーム全体の作業効率が高まる
34
Unityプロジェクトの構成
3Dモデル等のアセットを別のUnityプロジェクトに分離
→ Unityプロジェクトを開く時間の短縮
→ サーバ展開の高速化
baseリポジトリ
・クライアント (Unityプロジェクト)
・サーバ
・マスタ...
35
Unityプロジェクトの構成
baseリポジトリのUnityプロジェクトでは、
AssetBundleビルド後のアセットを使用
AssetBundleはgit管理外とし、
Hidden AssetsにすることでUnityエディタからも管理...
36
リソース入りgitリポジトリ
リソース入りgitリポジトリが別に存在する
→ baseリポジトリから分離した3Dモデル等のアセットが入っている
リソース入りgitリポジトリからAssetBundleビルドして
baseリポジトリで使う
リ...
37
リソース入りgitリポジトリ
リソース入りgitリポジトリは、baseリポジトリを包含する構造
baseリポジトリからリソース入りリポジトリへ随時同期する
リソース入り
gitリポジトリ
baseリポジトリ
同期
38
Subversion
リソース入りgitリポジトリは重い
・アセットの素材が基本的に全部入っている
・Unityエディタの動作が遅くなる
・作業者のストレージを圧迫する
→ 細分化し、Subversionで管理する
例:
リソース入り
g...
39
AssetBundleビルド
AssetBundleビルドはJenkinsで実行している
リソース入りgitリポジトリの任意のブランチを指定して
AssetBundleビルドできる
→ プログラム修正などが柔軟にできるように
3Dモデルの...
40
pbag
AssetBundleビルドの成果物を集積し、
Unityエディタで作業する人がAssetBundleを利用可能にする
ストレージが必要
紆余曲折あって、
ストレージソフトウェアを自作することにした
pbag
AssetBund...
41
pbagの要件
・pbagからのダウンロードが高速
・pbagへのアップロードはビルドマシンのみに限定して良い
・管理するファイルは多かったり大きかったりする
・gitブランチのような機能が欲しい
・あるバージョンの中で一部のファイルだけ...
42
pbag概要
pbagサーバ
pbagクライアント
a9993e3...
84983e4...
34aa973...
dea356a...
ファイルのダイジェストから
ファイル実体へのkey-value store
ファイルリスト
a99...
43
pbag概要
pbagサーバ
pbagクライアント
a9993e3...
84983e4...
34aa973...
dea356a...
認証サーバ 兼
ファイルリスト管理サーバ
(カテゴリ, 名前) から
ファイルリストのダイジェスト...
44
アセットダウンロード
pbagで管理されるのはエディタ実行用のファイル
実機ではAmazon S3からダウンロードしたファイルを使う
(ipaに埋め込むなど例外あり)
S3上のファイルはダウンロード時間短縮のため
複数のAssetBund...
45
チーム全体の作業効率を高めるには
サーバを増やしやすくしたい
→ サーバを増やしやすいアセット管理にする必要がある
46
アセットマスタデータ
S3上に配置されたファイルの情報は、
アセットマスタデータとしてサーバに展開する
サーバを増やしやすくするため、baseリポジトリに入れる
アセットマスタデータ
展開
baseリポジトリ
47
アセットダウンロード
クライアントはアセットマスタデータをサーバからダウンロードし、
それに基づいてS3からファイルをダウンロードする
アセットマスタデータ
アセットマスタデータ
ダウンロード
ダウンロード対象
ダウンロード対象
ダウンロ...
48
パッケージング
マスタデータに基づきpbag上のファイルを
結合・暗号化してS3にアップロードし、
アセットマスタデータをbaseリポジトリにcommitする
baseリポジトリ
・クライアント (Unityプロジェクト)
・サーバ
・マ...
49
パッケージング処理 (1/5)
パッケージングはJenkinsジョブになっていて、
baseリポジトリのブランチを指定して実行する
まず、マスタデータから必要なアセットを列挙する
baseリポジトリ
・クライアント (Unityプロジェク...
50
パッケージング処理 (2/5)
パッケージング用のデータベースが存在する
既にS3にアップロードされているファイルの情報を取得し、
どのようなファイルを作成してS3にアップロードするかを決定する
パッケージ済ファイルの
情報を取得
データ...
51
パッケージング処理 (3/5)
pbagから必要なファイルをダウンロードする
事前に使用するファイルを決定しているので、
必要なファイルだけをダウンロードすれば良い
pbag
ダウンロード
52
パッケージング処理 (4/5)
ファイルを結合・暗号化してS3にアップロードする
作成したファイルの情報はデータベースに保存する
アップロード
情報を
保存
データベース
53
パッケージング処理 (5/5)
アセットマスタデータを生成して、
baseリポジトリにcommitする
baseリポジトリ
・クライアント (Unityプロジェクト)
・サーバ
・マスタデータ (tsv形式)
・アセットマスタデータ
54
パッケージング(再掲)
マスタデータに基づきpbag上のファイルを
結合・暗号化してS3にアップロードし、
アセットマスタデータをbaseリポジトリにcommitする
baseリポジトリ
・クライアント (Unityプロジェクト)
・サー...
55
データの流れ
デザイナー

リソース入り
gitリポジトリ
同期
pbag
AssetBundleビルド
AssetBundles~
エディタ実行
ダウンロード
パッケージング
実機実行
56
アセットローダ
アセットパスをアセットローダに渡すとロードされる構造
pbag管理ファイル (AssetBundles~) からロードするか
S3からダウンロードしたファイルからロードするかは
アセットローダによって隠蔽される
→ フロン...
57
アセットの公開制御
パッケージングは、マスタデータから参照されているアセットだけを
アセットマスタデータに書き出すことで、未公開データの流出を防ぐ
マスタデータから参照されていないアセットがあると困るので、
アセットローダはマスタデータか...
58
アセットの公開制御
パッケージングは、マスタデータから参照されているアセットだけを
アセットマスタデータに書き出すことで、未公開データの流出を防ぐ
→ 適切なマスタデータが設定されていたら流出は防がれるので、
  pbagには将来のAss...
59
アセット管理のために作ったpbag
・アセット管理はチーム全体の作業効率を左右する
・AssetBundleを管理するためpbagを作成した
まとめ
ポイント
✅ アセット制作後、AssetBundleを
素早くビルドできること
✅ 必要...
ChatOpsによる
ビルド作業の効率化
誰でもほしいビルドが
自分で作れるしくみ
② 運用が属人化しやすい
対
策
61
スクスタのビルドパイプライン構成要素
開発環境
開発
企画

デザイナー

AssetBundleビルド
アプリビルド
実機動作確認環境
サーバー展開
パッケージング
62
スクスタのアプリビルドフロー
ポイント
✅ Jenkinsを使って、Macで素早く安定し
てアプリのビルドと展開ができること
✅ 非開発者でもアプリビルドやサーバー展
開ができること
① Jenkinsでビ
ルド開始
② Macで
アプリ...
63
Jenkins運用と問題点
アプリビルド
サーバー展開
アセットビルド
パッケージング
あらゆる運用作業をJenkinsを起点
として行う
非開発者
ビルド依頼
運用作業者
ビルド
✅ Jenkinsを非開発者に使ってもらうには一定のレク...
64
ChatOpsの導入
ビルド結果

コマンド投稿
ChatOps
非開発者でも利用しやすいインターフェースで、
誰でもJenkinsで運用作業できるようにしたい
HTTP Request
Slack bot
ビルド実施
ビルド
非開発者
...
65
理想のビルドコマンド
ビルドパラメータ複雑問題
実際にプロジェクトで使っているビルドコマン
ド
ビルドパラメータが複雑で
調整のハードルが高い
66
ビルドパラメータの複雑性
実際にプロジェクトで使っているビルドコマンド
サーバー接続先
ブランチ
認証キー
アプリタイトル
アセットのブランチ
ビルドマシン名
💣 ビルドパラメータが肥大化しがち

実現したいビルドを作るために必要なパラメ...
67
ビルドコマンド生成シートの導入
コピーアンドペースト
ビルドしたい条件を入力していく
スプレッドシートの数式処理により
ビルドコマンドが自動生成される
✅ビルドパラメータ
複雑問題が解決
ビルド ビルド実施
ビルドコマンドが
生成される
68
ChatOpsとコマンド生成シートの導入結果
非開発者
ビルド依頼
運用作業者
ビルド
非開発者
コピー&
ペースト
ビルド
Slack bot
✅ ChatOpsの導入により、運用属人化問題が解消
✅ ビルドパラメータがわからなくても、...
壊れても復活する
ビルドシステム
マシンが故障しても
リリース遅延を起こさないしくみ
③ 突然壊れたら直しにくい
対
策
70
スクスタのビルドパイプライン構成要素
開発環境
開発
企画

デザイナー

AssetBundleビルド
アプリビルド
実機動作確認環境
サーバー展開
パッケージング
71
アプリビルドマシンと問題点
1プロジェクトに1台だ
けある社内Mac
アプリビルド
ABビルド
社内Mac上のJenkinsでアプリビルド

iOSのビルドのため、アプリビルドは社内Mac

Mac上にJenkinsを構築し、アプリビルド...
72
Jenkins master slave運用
AWS
東京オフィス
jnlp slave jnlp slave jnlp slave
福岡オフィス
jenkins master
✅ Jenkins自体はMacに置かず、
クラウド上のLin...
73
ChatOpsと合わせた、ビルドのロードバランシング
jnlp slave 3
(3ビルド実行中)
jenkins master Slack bot
ビルド
jnlp slave 2
(1ビルド実行中)
jnlp slave 1
(4ビル...
74
Jenkinsの手動設定をgit管理
Jenkins Configuration as code
(Jenkins本体の設定)
✅ Jenkins本体の設定をyamlで記述可能
✅ Jenkinsの設定をgitで管理可能。コード
レビューが...
75
Ansible、Dockerによる構成管理
jnlp slavejnlp slave jnlp slave
jenkins master
jenkins docker image
✅ Jenkins masterはDocker上で
構築し...
76
アプリビルドがどう変わったか
1プロジェクトに1台だ
けある社内Mac
アプリビルド
ABビルド
jnlp slavejnlp slave jnlp slave
jenkins master
アプリビルド
ABビルド
✅ 単一障害点となっ...
まとめ
78
ビルドパイプラインの特徴と問題点と解決策
① リリース遅延要因になりやすい
② 運用が属人化しやすい
③ 突然壊れたら直しにくい
1人1サーバー環境(god)の整備
アセット管理方法の工夫
対
策
Slackを利用したChatOpsの導入...
79
おわりに
より良いゲーム運営をするためには、
バリューストリームの高速化、安定化が必要
バリューストリームの速度は、
ビルドパイプラインシステムの影響が大きい
KLabではビルドパイプラインに熱い情熱を注ぎ、
日々より良い運営ができるシス...
Próximos SlideShares
Carregando em…5
×
Próximos SlideShares
What to Upload to SlideShare
Avançar
Transfira para ler offline e ver em ecrã inteiro.

0

Compartilhar

Baixar para ler offline

『ラブライブ!スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜

Baixar para ler offline

CEDEC2020にて、『ラブライブ!スクールアイドルフェスティバル ALL STARS』の開発におけるアセットやソースコードの納品からアセットビルド、バイナリビルド、サーバー展開までの流れを支えるチーム、ワークフロー、アーキテクチャを紹介したセッションの資料です。

  • Seja a primeira pessoa a gostar disto

『ラブライブ!スクールアイドルフェスティバル ALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜

  1. 1. 『ラブライブ!スクールアイドルフェスティバルALL STARS』を支えるビルドパイプライン 〜より安定したサービス提供を目指して〜 ©KLabGames©SUNRISE©bushiroad All Rights Reserved. KLab株式会社 栂井 良太 / 橋本 卓也
  2. 2. 2 モバイルゲームの開発プロジェクトと横断 組織を兼務し、DevOpsを推進 各セクションのつなぎこみや運用業務を効 率化するツールの開発、自動化など 栂井 良太 バックエンドアーキテクチャG エンジニア 2018年 KLab新卒入社 とが い
 りょうた APIサーバ開発・通信アーキテクチャー 設計を経て、パイプライン担当になる。 パイプラインのためのクライアント・ サーバの各種設計・実装に関わる。 橋本 卓也 バックエンドアーキテクチャG エンジニア 2012年 KLab新卒入社 はしもと
 たくや
  3. 3. 3 ラブライブ!スクールアイドルフェスティバルALLSTARSとは 美麗な3Dで楽しめるリズムアクションRPGです! ※ 動画はリリース初期 2019/09の動画です
  4. 4. 4 本セッションの内容 ラブライブ スクールアイドルフェスティバル ALLSTARS(スクスタ) の新しいコンテンツやアップデートを いち早く、安定して提供するための仕組みをご紹介 自動化 バージョン管理 CIシステム構築 ビルドパイプライン
  5. 5. ビルドパイプライン概要 目的と問題点、KLabでの取り組み
  6. 6. 6 モバイルゲームビルドパイプラインとは ユーザー
 企画
 プログラマー
 デザイナー
 リポジトリ or
 ファイルストレージ
 自動テスト サーバー 展開 本番サーバー
 アセット ビルド パッケー ジング 追加ダウンロード用スト レージ
 開発環境構築 ビルドパイプライン アプリ ビルド ストア アップロード
  7. 7. 7 ビルドパイプラインの重要性 企画 開発 テスト 展開 フィード バック より素早い改善サイクルを提供できるゲームがユーザーに評価されやすい ・ユーザーの要望をすぐにサービスに反映できる ・バグがあればすぐに治せる ・積極的な新機能開発ができる バリューストリーム ✅ バリューストリーム高速化のためには ビルドパイプラインの安定化、高速化が必要不可欠
  8. 8. 8 スクスタのビルドパイプライン構成要素 アプリビルド 実機動作確認環境 アプリビルドマシン 開発サーバー Jenkins 開発環境 プログラマー 企画
 開発サーバー ゲームエンジン プログラム マスターデータ gitリポジトリ デザイナー
 AssetBundleビルド Jenkins アセットビルドマシン Subversion サーバー サーバー展開 パッケージング Jenkins 本番サーバー 追加ダウンロード ストレージ サーバー
  9. 9. 9 ビルドパイプラインの特徴と問題点 ① リリース遅延要因になりやすい ビルドパイプライン(Jenkinsなど)は全メンバーが利用 非効率なしくみだとリリースまでに時間がかかってしまう ② 運用が属人化しやすい 日々進化するビルドパイプラインは使い方も変わっていく 特定の運用作業者しかテストビルドを作ることができなくなる ③ 突然壊れたら直しにくい アップデート必須の状況はやってくる その日、数年間触ってないマシンを触らないといけなくなる
  10. 10. 10 KLabのビルドパイプラインへのとりくみ 企画
 プログラマー
 デザイナー
 リポジトリ or
 ファイルストレージ
 アセット ビルド パッケー ジング 追加ダウンロード 用ストレージ
 自動テスト サーバー 展開 アプリ ビルド ストア アップロード 開発環境構築 本番サーバー
 プロジェクトA 企画
 プログラマー
 デザイナー
 リポジトリ or
 ファイルストレージ
 アセット ビルド パッケー ジング 追加ダウンロード 用ストレージ
 自動テスト サーバー 展開 アプリ ビルド ストア アップロード 開発環境構築 本番サーバー
 プロジェクトB ビルドパイプライン専属グループ 兼務 兼務 知見、ツールの横 断的共有
  11. 11. 11 KLabのビルドパイプラインへのとりくみ パイプライン専属のメンバーがプロジェクトの需要に合わせ たツールの開発を行い、知見を横断的に共有 数年後も、 よりはやくユーザーにコンテンツを届けられるシステム を目指す ① リリース遅延要因になりやすい ② 運用が属人化しやすい ③ 突然壊れたら直しにくい 本日は得られた知見の中で、 3つの問題点を解決した手法をご紹介
  12. 12. 運用を柔軟にするgod環境 サーバー環境の物量作戦 ① リリース遅延要因になりやすい 対 策
  13. 13. 13 スクスタのビルドパイプライン構成要素 開発環境 プログラマー 企画
 デザイナー
 AssetBundleビルド アプリビルド 実機動作確認環境 サーバー展開 パッケージング 開発サーバー ゲームエンジン アプリビルドマシン 開発サーバー Jenkins Jenkins アセットビルドマシン プログラム マスターデータ gitリポジトリ Subversion サーバー Jenkins 本番サーバー 追加ダウンロード ストレージ サーバー
  14. 14. 14 開発・マスターデータ作成フロー 開発者や企画者が素早く自分の修正をゲーム上で確認し、 ゲームを作りこんでいく 目的 ① 開発PCで コードやデータを 修正 ②サーバ展開 開発サーバ ③Unityエディタ 動作確認 ポイント ✅ 自分の修正をUnityエディタで 簡単に動作確認できること ✅ クライアントだけでなく、 サーバの動作確認も一緒にできること ④PRを出してマージ サーバとAPI通信 サーバとAPI通信 ⑤実機で 動作確認 ✅ 多様な需要を満たせるように 運用に柔軟性があること
  15. 15. 15 開発体制 参考 : CEDEC+KYUSHU 2018 「大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例」 クライアント サーバ フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲 クライアントの一定範囲について バックエンド開発者が責任を持つ開発体制
  16. 16. 16 開発体制 この体制では、クライアント・サーバを密結合にするのが 品質・開発効率を考えると合理的 クライアント サーバ フロントエンド開発者の責任範囲 バックエンド開発者の責任範囲 密 結 合 参考 : CEDEC+KYUSHU 2018 「大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例」
  17. 17. 17 クライアント・サーバ密結合の問題点 クライアントのバージョンと サーバのバージョンが合わないとき、 アプリが正常に動作しない → 密結合にすることで、この問題が発生しやすくなる 古いサーバ 新しいクライアント
  18. 18. 18 サーバ需要の増大 KLabでは従来、共用サーバを使うことが多く、 クライアント開発チームで1台の共用サーバといった体制
  19. 19. 19 サーバ需要の増大 しかし、クライアント・サーバ密結合化を進めた結果、 1台の共用サーバで機能実装を進めるのは困難に クライアントが 新しすぎる クライアントが 古い クライアントの バージョンが 合ってる クライアントの バージョンが 少しずれてるけど 動いている
  20. 20. 20 サーバ需要の増大 サーバを増やすことで対応 Amazon EC2でサーバをたくさん立てる体制に
  21. 21. 21 god環境 EC2で動かしているサーバ環境はgod環境と呼ばれている god0001 god0002 god0003 god0004
  22. 22. 22 god環境 開発者は基本的に一人1god
  23. 23. 23 増えるgod マスタデータを作る企画者にも一人1god
  24. 24. 24 増えるgod 実機動作確認のためにもgod
  25. 25. 25 godの利点 ・サーバ環境が空くまで動作確認できないという状況を回避でき、 待ち時間を節約 ・各自がローカルサーバ環境を構築する時間を節約 ・開発者が全サーバにssh接続できるので、 不具合調査がしやすくなる ・何か起きても、EC2インスタンスを破棄して サーバ環境を作り直す手段がとれる
  26. 26. 26 god操作のChatOps 誰がどのgodを使っているかを管理し、 godの起動・停止・破棄ができるslack botがある godは夜に自動停止する (Go言語のnlopes/slackを使用) @godpanther start @hashimoto-t god0003 started
  27. 27. 27 リポジトリ構成 baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) これらを一つのgitリポジトリで管理している → 同一ブランチのクライアント・サーバなら整合が取れる → たくさんのgodを運用する上でも都合が良い
  28. 28. 28 gitブランチ管理 9/1公開用ブランチ 9/5公開用ブランチ 次のバイナリ更新用ブランチ 本流ブランチは一つではなく、公開時期ごとにブランチが分かれている →いつ公開予定の内容を確認したいかによって、使うブランチを変える これによって多様な需要を満たせるようにしている
  29. 29. 29 運用を柔軟にするgod環境 god環境と呼ばれているAmazon EC2で動作するサーバ環境によって、 簡単かつ柔軟に動作確認できる体制になっている ① 開発PCで コードやデータを 修正 ②サーバ展開 ③Unityエディタ 動作確認 ポイント ✅ 自分の修正をUnityエディタで 簡単に動作確認できること ✅ クライアントだけでなく、 サーバの動作確認も一緒にできること ④PRを出してマージ サーバとAPI通信 サーバとAPI通信 ⑤実機で 動作確認 ✅ 多様な需要を満たせるように 運用に柔軟性があること god環境 まとめ
  30. 30. アセット管理のために 作ったpbag チーム全体の作業効率を高める AssetBundleビルド戦略 ① リリース遅延要因になりやすい 対 策
  31. 31. 31 スクスタのビルドパイプライン構成要素 開発環境 プログラマー 企画
 デザイナー
 AssetBundleビルド アプリビルド 実機動作確認環境 サーバー展開 パッケージング 開発サーバー ゲームエンジン アプリビルドマシン 開発サーバー Jenkins Jenkins アセットビルドマシン プログラム マスターデータ gitリポジトリ Subversion サーバー Jenkins 本番サーバー 追加ダウンロード ストレージ サーバー
  32. 32. 32 アセット制作・管理のフロー デザイナーがゲーム素材(アセット)を制作し、 AssetBundleビルドしたものを管理する 目的 ポイント ✅ アセット制作後、AssetBundleを 素早くビルドできること ✅ 必要なリリースタイミングで 適切にアセットを公開できること ✅ ビルドしたAssetBundleを バージョンをつけて管理できること ② AssetBundle ビルド Subversion ① アセットの制 作 ダウンロード ⑤実機で 動作確認 ③ ビルド後の 成果物を集積 ④ パッケージング 追加ダウンロード用 ストレージサーバ ④ リリースタイミングを制 御 pbag
  33. 33. 33 チーム全体の作業効率を高めるには Unityプロジェクトを開くのに時間がかかる → これを高速化したらチーム全体の作業効率が高まる
  34. 34. 34 Unityプロジェクトの構成 3Dモデル等のアセットを別のUnityプロジェクトに分離 → Unityプロジェクトを開く時間の短縮 → サーバ展開の高速化 baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式)
  35. 35. 35 Unityプロジェクトの構成 baseリポジトリのUnityプロジェクトでは、 AssetBundleビルド後のアセットを使用 AssetBundleはgit管理外とし、 Hidden AssetsにすることでUnityエディタからも管理外に AssetBundles~ git上では空 この下に大量の AssetBundleファイル AssetBundles~は無い UnityEditorからは見えない 参考 : https://docs.unity3d.com/Manual/SpecialFolders.html
  36. 36. 36 リソース入りgitリポジトリ リソース入りgitリポジトリが別に存在する → baseリポジトリから分離した3Dモデル等のアセットが入っている リソース入りgitリポジトリからAssetBundleビルドして baseリポジトリで使う リソース入り gitリポジトリ AssetBundles~ baseリポジトリ AssetBundle ビルド
  37. 37. 37 リソース入りgitリポジトリ リソース入りgitリポジトリは、baseリポジトリを包含する構造 baseリポジトリからリソース入りリポジトリへ随時同期する リソース入り gitリポジトリ baseリポジトリ 同期
  38. 38. 38 Subversion リソース入りgitリポジトリは重い ・アセットの素材が基本的に全部入っている ・Unityエディタの動作が遅くなる ・作業者のストレージを圧迫する → 細分化し、Subversionで管理する 例: リソース入り gitリポジトリ 3Dモデル制作用 Subversion 3Dモーション制作用 Subversion 同期 同期
  39. 39. 39 AssetBundleビルド AssetBundleビルドはJenkinsで実行している リソース入りgitリポジトリの任意のブランチを指定して AssetBundleビルドできる → プログラム修正などが柔軟にできるように 3DモデルのAssetBundleビルド、 3DモーションのAssetBundleビルド、 のようにカテゴリごとにビルドできる → ビルド時間の短縮 パラメータ: ・ブランチ ・カテゴリ
  40. 40. 40 pbag AssetBundleビルドの成果物を集積し、 Unityエディタで作業する人がAssetBundleを利用可能にする ストレージが必要 紆余曲折あって、 ストレージソフトウェアを自作することにした pbag AssetBundles~ AssetBundle ビルド 成果物を 集積 ファイル を取得
  41. 41. 41 pbagの要件 ・pbagからのダウンロードが高速 ・pbagへのアップロードはビルドマシンのみに限定して良い ・管理するファイルは多かったり大きかったりする ・gitブランチのような機能が欲しい ・あるバージョンの中で一部のファイルだけをダウンロードできる
  42. 42. 42 pbag概要 pbagサーバ pbagクライアント a9993e3... 84983e4... 34aa973... dea356a... ファイルのダイジェストから ファイル実体へのkey-value store ファイルリスト a9993e3... 84983e4... 34aa973... dea356a... Models/Models Models/Models.manifest Models/shader.unity3d Models/prefab.unity3d ファイルリストも pbagサーバで管理されるファイルであり、 そのダイジェストは gitでいうところのcommit id
  43. 43. 43 pbag概要 pbagサーバ pbagクライアント a9993e3... 84983e4... 34aa973... dea356a... 認証サーバ 兼 ファイルリスト管理サーバ (カテゴリ, 名前) から ファイルリストのダイジェスト への マッピングを管理する。 gitでいうところのブランチ マッピング 76aa478... 8c7b756... ver1.8.0 ver1.8.1
  44. 44. 44 アセットダウンロード pbagで管理されるのはエディタ実行用のファイル 実機ではAmazon S3からダウンロードしたファイルを使う (ipaに埋め込むなど例外あり) S3上のファイルはダウンロード時間短縮のため 複数のAssetBundleを結合した状態になっており、 暗号化もされた状態になっている pbag 結合・ 暗号化
  45. 45. 45 チーム全体の作業効率を高めるには サーバを増やしやすくしたい → サーバを増やしやすいアセット管理にする必要がある
  46. 46. 46 アセットマスタデータ S3上に配置されたファイルの情報は、 アセットマスタデータとしてサーバに展開する サーバを増やしやすくするため、baseリポジトリに入れる アセットマスタデータ 展開 baseリポジトリ
  47. 47. 47 アセットダウンロード クライアントはアセットマスタデータをサーバからダウンロードし、 それに基づいてS3からファイルをダウンロードする アセットマスタデータ アセットマスタデータ ダウンロード ダウンロード対象 ダウンロード対象 ダウンロード
  48. 48. 48 パッケージング マスタデータに基づきpbag上のファイルを 結合・暗号化してS3にアップロードし、 アセットマスタデータをbaseリポジトリにcommitする baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) ・アセットマスタデータ pbag データベース
  49. 49. 49 パッケージング処理 (1/5) パッケージングはJenkinsジョブになっていて、 baseリポジトリのブランチを指定して実行する まず、マスタデータから必要なアセットを列挙する baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) アセット一覧を 作成
  50. 50. 50 パッケージング処理 (2/5) パッケージング用のデータベースが存在する 既にS3にアップロードされているファイルの情報を取得し、 どのようなファイルを作成してS3にアップロードするかを決定する パッケージ済ファイルの 情報を取得 データベース
  51. 51. 51 パッケージング処理 (3/5) pbagから必要なファイルをダウンロードする 事前に使用するファイルを決定しているので、 必要なファイルだけをダウンロードすれば良い pbag ダウンロード
  52. 52. 52 パッケージング処理 (4/5) ファイルを結合・暗号化してS3にアップロードする 作成したファイルの情報はデータベースに保存する アップロード 情報を 保存 データベース
  53. 53. 53 パッケージング処理 (5/5) アセットマスタデータを生成して、 baseリポジトリにcommitする baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) ・アセットマスタデータ
  54. 54. 54 パッケージング(再掲) マスタデータに基づきpbag上のファイルを 結合・暗号化してS3にアップロードし、 アセットマスタデータをbaseリポジトリにcommitする baseリポジトリ ・クライアント (Unityプロジェクト) ・サーバ ・マスタデータ (tsv形式) ・アセットマスタデータ pbag データベース
  55. 55. 55 データの流れ デザイナー
 リソース入り gitリポジトリ 同期 pbag AssetBundleビルド AssetBundles~ エディタ実行 ダウンロード パッケージング 実機実行
  56. 56. 56 アセットローダ アセットパスをアセットローダに渡すとロードされる構造 pbag管理ファイル (AssetBundles~) からロードするか S3からダウンロードしたファイルからロードするかは アセットローダによって隠蔽される → フロントエンド実装は、どちらからロードしているかを意識しない アセットローダ アセットパス アセット pbag AssetBundles~ S3
  57. 57. 57 アセットの公開制御 パッケージングは、マスタデータから参照されているアセットだけを アセットマスタデータに書き出すことで、未公開データの流出を防ぐ マスタデータから参照されていないアセットがあると困るので、 アセットローダはマスタデータから取得したアセットパスしか受け付けない アセットローダ アセットパス アセット pbag AssetBundles~ S3 マスタデータ ↑ stringではない
  58. 58. 58 アセットの公開制御 パッケージングは、マスタデータから参照されているアセットだけを アセットマスタデータに書き出すことで、未公開データの流出を防ぐ → 適切なマスタデータが設定されていたら流出は防がれるので、   pbagには将来のAssetBundleを格納できる → 将来のAssetBundleがpbagに入っていることで、   マスタデータ調整や動作確認がしやすくなる → チーム全体の作業効率を高める
  59. 59. 59 アセット管理のために作ったpbag ・アセット管理はチーム全体の作業効率を左右する ・AssetBundleを管理するためpbagを作成した まとめ ポイント ✅ アセット制作後、AssetBundleを 素早くビルドできること ✅ 必要なリリースタイミングで 適切にアセットを公開できること ✅ ビルドしたAssetBundleを バージョンをつけて管理できること ② AssetBundle ビルド Subversion ① アセットの制 作 ダウンロード ⑤実機で 動作確認 ③ ビルド後の 成果物を集積 ④ パッケージング 追加ダウンロード用 ストレージサーバ ④ リリースタイミングを制 御 pbag
  60. 60. ChatOpsによる ビルド作業の効率化 誰でもほしいビルドが 自分で作れるしくみ ② 運用が属人化しやすい 対 策
  61. 61. 61 スクスタのビルドパイプライン構成要素 開発環境 開発 企画
 デザイナー
 AssetBundleビルド アプリビルド 実機動作確認環境 サーバー展開 パッケージング
  62. 62. 62 スクスタのアプリビルドフロー ポイント ✅ Jenkinsを使って、Macで素早く安定し てアプリのビルドと展開ができること ✅ 非開発者でもアプリビルドやサーバー展 開ができること ① Jenkinsでビ ルド開始 ② Macで アプリビルド ③ 実機に アプリを インストール ④ サーバー 展開 開発サーバー 追加DL ストレージ サーバー アセット管理 サーバー ⑤ パッケー ジング ⑥ 実機でサーバーに 接続し、動作テスト ⑦ 追加ダウンロード
  63. 63. 63 Jenkins運用と問題点 アプリビルド サーバー展開 アセットビルド パッケージング あらゆる運用作業をJenkinsを起点 として行う 非開発者 ビルド依頼 運用作業者 ビルド ✅ Jenkinsを非開発者に使ってもらうには一定のレクチャーが必要 ✅ 運用作業者が代理でビルドをする場合、ビルド待ち、コミュニケーショ ンコストが発生する 非開発者には 難しい
  64. 64. 64 ChatOpsの導入 ビルド結果
 コマンド投稿 ChatOps 非開発者でも利用しやすいインターフェースで、 誰でもJenkinsで運用作業できるようにしたい HTTP Request Slack bot ビルド実施 ビルド 非開発者 ビルド依頼 ✅ 非開発者でも、slackに発言するだけで Jenkinsで運用作業ができるようになった ✅ ビルドの仕方がわからなくても、slackのロ グを検索することでやり方がわかる 運用作業者 Slack bot
  65. 65. 65 理想のビルドコマンド ビルドパラメータ複雑問題 実際にプロジェクトで使っているビルドコマン ド ビルドパラメータが複雑で 調整のハードルが高い
  66. 66. 66 ビルドパラメータの複雑性 実際にプロジェクトで使っているビルドコマンド サーバー接続先 ブランチ 認証キー アプリタイトル アセットのブランチ ビルドマシン名 💣 ビルドパラメータが肥大化しがち
 実現したいビルドを作るために必要なパラメータが多 い
 結局限られた運用作業者でないとビルドが困難
 ビルド Slack bot 生成されたコマンドをコピペ 🧐 解決案の着想
 
 実現したい ビルドの要素 コマンド 生成器 ビルドコマンド
  67. 67. 67 ビルドコマンド生成シートの導入 コピーアンドペースト ビルドしたい条件を入力していく スプレッドシートの数式処理により ビルドコマンドが自動生成される ✅ビルドパラメータ 複雑問題が解決 ビルド ビルド実施 ビルドコマンドが 生成される
  68. 68. 68 ChatOpsとコマンド生成シートの導入結果 非開発者 ビルド依頼 運用作業者 ビルド 非開発者 コピー& ペースト ビルド Slack bot ✅ ChatOpsの導入により、運用属人化問題が解消 ✅ ビルドパラメータがわからなくても、コマンド生成シートからコピー &ペーストするだけで非開発者でもビルドができる ✅ プロジェクトのメンバー全員が、自分の欲しいビルドを自分でつくれ るようになった
  69. 69. 壊れても復活する ビルドシステム マシンが故障しても リリース遅延を起こさないしくみ ③ 突然壊れたら直しにくい 対 策
  70. 70. 70 スクスタのビルドパイプライン構成要素 開発環境 開発 企画
 デザイナー
 AssetBundleビルド アプリビルド 実機動作確認環境 サーバー展開 パッケージング
  71. 71. 71 アプリビルドマシンと問題点 1プロジェクトに1台だ けある社内Mac アプリビルド ABビルド 社内Mac上のJenkinsでアプリビルド
 iOSのビルドのため、アプリビルドは社内Mac
 Mac上にJenkinsを構築し、アプリビルドを行う
 手動設定されたJenkins設定や ビルドスクリプト 💣単一障害点となる社内Mac
 運用が長期化してくると、社内Macにつぎはぎで設定を入れ ていくことになる
 もはや誰もビルドマシンを構築することができなくなる
 Macが故障すると、アプリのリリースができなくなる

  72. 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. 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. 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. 75 Ansible、Dockerによる構成管理 jnlp slavejnlp slave jnlp slave jenkins master jenkins docker image ✅ Jenkins masterはDocker上で 構築し、構成管理する ✅ Mac slaveはAnsibleで 構成管理をする ✅ 冗長化Macが増えた場合でも、 Ansibleで即セットアップ可能 ✅ どこかのサーバーが故障しても 即座に復旧可能
  76. 76. 76 アプリビルドがどう変わったか 1プロジェクトに1台だ けある社内Mac アプリビルド ABビルド jnlp slavejnlp slave jnlp slave jenkins master アプリビルド ABビルド ✅ 単一障害点となっていた社内Macを冗長化し、Macの故障に対するリ スクヘッジを達成 ✅ あらゆる手動設定をコード化し、git管理、コードレビュー可能にし てJenkinsの故障に対するリスクヘッジを達成 ✅ ビルドマシンに潜む、あらゆるリリース遅延要因を排除
  77. 77. まとめ
  78. 78. 78 ビルドパイプラインの特徴と問題点と解決策 ① リリース遅延要因になりやすい ② 運用が属人化しやすい ③ 突然壊れたら直しにくい 1人1サーバー環境(god)の整備 アセット管理方法の工夫 対 策 Slackを利用したChatOpsの導入 コマンド生成シートの作成 対 策 ビルドマシンの冗長化 CIのあらゆる設定をコード化 対 策 バリューストリームの高速化を達成できた
  79. 79. 79 おわりに より良いゲーム運営をするためには、 バリューストリームの高速化、安定化が必要 バリューストリームの速度は、 ビルドパイプラインシステムの影響が大きい KLabではビルドパイプラインに熱い情熱を注ぎ、 日々より良い運営ができるシステムを目指しています!

CEDEC2020にて、『ラブライブ!スクールアイドルフェスティバル ALL STARS』の開発におけるアセットやソースコードの納品からアセットビルド、バイナリビルド、サーバー展開までの流れを支えるチーム、ワークフロー、アーキテクチャを紹介したセッションの資料です。

Vistos

Vistos totais

361

No Slideshare

0

De incorporações

0

Número de incorporações

0

Ações

Baixados

3

Compartilhados

0

Comentários

0

Curtir

0

×