ゲーム開発のJenkins整備から横断SREチームが誕生するまで【DeNA TechCon 2023】

Slide 1

Slide 1 text

ゲーム開発のJenkins整備から横断SREチームが誕生するまで品質本部品質管理部SWET第二グループ加瀬健太（Kenta Kase）ゲーム事業本部開発事業部開発二部テクノロジー推進第一グループ白柳隆澄（Takazumi Shirayanagi）

Slide 2

Slide 2 text

Table of Contents ゲーム開発におけるCI/CDのための安定したJenkinsクラスタ構築と発展 ● Jenkins クラスタの構成と構成管理 ● macOS Agent をオフィスの Mac mini から MacStadium へ ● BigQuery を活用したビルド情報の可視化と分析 2 ゲーム事業部にプロジェクト横断SREチームが誕生 ● ゲーム事業部における CI/CD の課題 ● 横断 SRE チーム誕生までの経緯と活動 ● Jenkins から GitHub Ac?ons へ

Slide 3

Slide 3 text

自己紹介 ● 加瀬健太 ○ ＠Kesin11（Twitter) / ＠Kesin11（GitHub) ● 所属 ○ DeNA SWET 第二グループ（Software Engineer in Test) ● 業務 ○ CI/CD 関連の技術的なサポート ○ 社内共通基盤の CircleCI Server、Bitriseの運用 3 @Kesin11

Slide 4

Slide 4 text

SWETグループ MISSION ソフトウェアを起点とした ● DeNAサービス全般の品質向上 ● DeNAエンジニアの開発生産性向上により、価値あるものを素早く提供できるようにする今回は SWET の CI/CD チームの取り組みを紹介 4

Slide 5

Slide 5 text

ゲーム開発における Jenkins と SWET ● ゲーム開発におけるJenkins ○ 効率的に品質の高いゲームを開発するための自動化の基盤 ■ アプリの定期的なビルド ■ マスタデータやアセットのバリデーション ■ サーバーのデプロイ自動化 ○ 開発規模が大きくなるほど Jenkins は業務に必要不可欠 ○ だが・・・ 5

Slide 6

Slide 6 text

ゲーム開発における Jenkins と SWET ● プロジェクトごとに独自に Jenkins を構築 ○ Jenkins の運用は片手間になりがち ○ Jenkins を専門に運用するチームがいない ■ ノウハウが蓄積されない ● 新規プロジェクトにおいても Jenkins が改善されない Jenkins のノウハウを持っていたSWETが大規模なゲーム開発に耐えうる Jenkins の構築を目指すことに 6

Slide 7

Slide 7 text

可用性と拡張性に優れた Jenkinsクラスタの構成 7

Slide 8

Slide 8 text

8 Jenkins クラスタの構成 ● 主に3種類のマシンで構成 ○ Jenkins Controller ○ Linux Agent ○ macOS Agent Google Compute Engine is a trademark of Google LLC.

Slide 9

Slide 9 text

9 Jenkins クラスタの構成 ● Jenkins Controller（GCE） ○ スケールアップが容易 ○ ディスクのスナップショットをバックアップ用途に活用

Slide 10

Slide 10 text

10 Jenkins クラスタの構成 ● Linux Agent（GCE） ○ 役割 ■ macOSが必須ではないジョブ ■ docker が必要なジョブ ○ スケールアップ、スケールアウトが容易 ○ 夜間と休日は稼働台数を減らすことでコスト削減

Slide 11

Slide 11 text

11 Jenkins クラスタの構成 ● macOS Agent ○ オフィスに配置した Mac mini ○ MacStadium の Mac mini （後述） ○ 役割 ■ Xcode など macOS が必須のジョブ ■ Unity を利用するジョブ ○ Unity を macOS で使用するプロジェクトが多い

Slide 12

Slide 12 text

Jenkins Controller や Agent の構成管理 ● Google CloudのインフラはTerraform管理 ○ GCEの台数、スペック ○ ネットワーク構成 ● Jenkins自体やAgentに必要なツールのインストールや設定はAnsibleで管理 ■ マシン毎にYAMLを用意する ■ インストールするツールのバージョンを書く ■ 現在のマシン構成をコードから把握できる 12

Slide 13

Slide 13 text

詳しくは CEDEC 2020 の発表 ● モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構築と管理テクニック〜 ■ Ansibleによる構成管理 ■ ビルドパイプラインの設計 ■ ビルドマシンの監視とアラート ■ 成果物をGCSに保存してディスク容量消費を抑制 ■ Fastlane matchによるiOS開発用の証明書とプロビジョニングプロファイル管理 13

Slide 14

Slide 14 text

macOS Agent をオフィスの Mac mini から MacStadium へ 14

Slide 15

Slide 15 text

オフィスの Mac mini の不便な点 ● 注文してから納品まで時間がかかる ○ 特に近年は感染症と半導体不足の影響で数ヶ月待ちの状況であった ● マシン再起動を伴う作業は出社する必要がある ○ OS アップデートやハングアップからの復帰など ○ DeNA は近年ではリモートワーク主体 ● 台数が増えると物理的な障壁が現れる ○ 設置スペース ○ 電源容量 ○ ネットワーク容量 ● ビルの法定停電対応 ○ 停電中はビルドが行えなくなってしまう 15

Slide 16

Slide 16 text

macOS もクラウド化したい...！ 16

Slide 17

Slide 17 text

MacStadium ● データセンターの Mac mini の実機を1台ずつ月ごとに借りられるサービスを提供している ● ssh もしくは VNC でのリモート操作 ● 電源ON/OFFも web コンソールから制御可能 ● 2020年時点で既に活用実績はあったが最近はさらに積極的に活用 ○ DeNA 全体としてインフラをクラウドに寄せる方針 ○ 2020年からリモートワーク主体に変化 17

Slide 18

Slide 18 text

MacStadium のメリット ● 台数をスケールさせやすい ○ 発注してからおおよそ1日でビルドマシンとして稼働可能 ■ 注文後に MacStadium 側の初期セットアップ完了まで約半日 ■ ツールのセットアップは Ansible で自動化済みなので数時間 ○ 急激なビルド負荷の増加に対応可能 ■ リリース時期付近は1日にビルドを行う回数が増加 ■ 繁忙期だけ台数を増やし落ち着いたら減らす運用が可能に 18

Slide 19

Slide 19 text

MacStadium のデメリット ● SSDが最大でも1TB ○ ゲーム開発におけるビルドは非常にディスク容量を必要とする ■ アセットデータなどが膨大 ● アセットのリポジトリだけで20GBを超えるプロジェクトもある ■ Jenkinsでビルド時のブランチなどのパラメータに応じてワークスペースを分離したいニーズ ● ビルドキャッシュの効率化のため ● リリース候補となるバイナリ作成ジョブはまっさらな環境からビルドしておきたい 19

Slide 20

Slide 20 text

MacStadium の容量問題への対策 ● 不要データの定期的な削除の自動化 ○ Xcode の Archive、DerivedData ディレクトリ ○ 利用されていない、もしくは古い Jenkins ジョブのワークスペース ○ 過去のブランチでビルドに使用していたワークスペース ● 削除を自動化したことで台数が増えても運用工数を抑えることができた ● 詳しくはTechCon 2022のLT ○ 「ゲーム開発のCI/CDを支えるJenkins運用 ~MacStadium 活用とディスク容量との闘い~」 20

Slide 21

Slide 21 text

● ビルドに必要なデータだけを clone/fetch（shallow clone, partial clone） ● ビルドマシンのローカルにミラーリポジトリを作成して Git の共通オブジェクトの重複を削除（reference clone） ● Git LFS ローカルストレージの共有 ● 同一のアセットデータは APFS の Copy on Write 機能で重複分を削除 Git や macOS のファイルシステムレベルでの容量削減 21 詳しくはCEDEC 2022の発表やブログ ○ ブログ大きなGitリポジトリをクローンするときの工夫を図解します ○ CEDEC発表スライド「大きなGitリポジトリをJenkinsで扱うコツ〜Copy on Writeを使ったディスク節約術〜」 ○ ブログ macOSのCopy-on-Write機能を使ってディスクを節約した話

Slide 22

Slide 22 text

22 BigQuery を活用したビルド情報の可視化と分析

Slide 23

Slide 23 text

● いつの間にかビルド時間が長くなっている ● ランダムにたまに失敗するビルド ● ビルドキューが詰まりがちビルド・テストが失敗した際の根本原因の修正が放置されがちな原因となる ● 問題の調査が困難 ○ Jenkins に過去のビルド情報を分析する機能が乏しい ■ 過去のビルドログを1つ1つ調べるしかない ○ ビルドログが長大かつ数が膨大 23 Jenkins を長く運用していると見えてくる問題

Slide 24

Slide 24 text

● CIAnalyzer ○ https://github.com/Kesin11/CIAnalyzer ● Jenkins, GitHub Actions, CircleCI, Bitriseの API からビルド情報を整形して BigQuery に送信 ● BigQuery のデータの可視化は Looker Studio （旧データポータル）を利用 ● 詳しくは CI/CD Conference 2021 の発表 ○ 「CI/CDのボトルネックを把握できていますか？BigQueryでビルド情報ダッシュボードを構築した話」 24 ビルドに関する情報の可視化と分析

Slide 25

Slide 25 text

1年間のビルド時間の推移 BigQuery によって膨大なデータ量でも数秒で表示が可能 25 長期トレンドでビルド時間が右肩下がりなので健全

Slide 26

Slide 26 text

ジョブとステップ毎にかかる時間の分析どのステップに時間がかかっているのかが分かりやすい 26 青色のステップがビルド時間の約80%を占めている

Slide 27

Slide 27 text

キュー待ち時間の分析 12月->1月にかけて対策を講じたことで劇的に改善した様子 27 12月キュー待ち時間が長い 1月キュー待ち時間がほぼゼロ

Slide 28

Slide 28 text

過去のビルド履歴の表（開始日時、Succees/Fail）ビルド番号に Jenkins のジョブ詳細画面へのリンクを埋め込んでいる 28

Slide 29

Slide 29 text

● ジョブ内で時間がかかっているコマンドが統計的に分かる ○ ビルド時間の改善幅が大きい部分から着手しやすい ● キュー待ち時間の推移が定量的に分かる ○ 肌感ではなく数字に基づいたビルドマシン台数の調整 ● いつのビルドから失敗するようになったのか正確に分かる ○ リトライすれば直るケースは調査が後日になりやすい ○ 問題の正確な発生日は重要な情報 ■ 日付から修正コミットやインフラの変更などを追跡できる 29 可視化するとビルドの分析調査が効率的に

Slide 30

Slide 30 text

30 SWET グループによる Jenkins 運用のまとめ

Slide 31

Slide 31 text

● Jenkins Controller と Agent をクラウド化 ○ GCE ○ MacStadium ● Terraform と Ansible で構成管理 ● macOS Agent の MacStadium 活用 ○ 台数をスケールさせやすい ○ ディスク容量問題への対策 ● BigQuery を活用したビルドに関する情報の可視化と分析 ○ ビルドの調査分析が効率的に 31 SWET グループによる Jenkins 運用のまとめ

Slide 32

Slide 32 text

32 今後の展望

Slide 33

Slide 33 text

● SRE チームと協力して Jenkins の運用をサポート ○ SWETのCI/CDチームはゲーム開発や Unity のノウハウが足りていない ○ お互いの得意分野で協力 ● DeNA 全体の CI/CD のサポートにも力を入れたい ○ GitHub Ac\onsの発展に注目 ■ ゲーム開発以外のプロジェクトでは知名度が急上昇 ■ ゲーム開発でも Jenkins の代替として利用できるかも ○ SRE チームと協力して GitHub Ac\ons の利用を開始 33 今後の展望

Slide 34

Slide 34 text

ゲーム開発のJenkins整備から横断SREチームが誕生するまで (後半) ゲーム事業部にプロジェクト横断SREチームが誕生

Slide 35

Slide 35 text

自己紹介 ● 白柳隆澄（しらやなぎたかずみ） ○ Facebook (takazumi.shirayanagi) ○ Twitter/GitHub やってるけど秘密 ● 所属 ○ ゲーム事業本部開発事業部 ■ 開発二部テクノロジー推進第一グループ ● 業務 ○ SRE ○ ゲームエンジニアだったり、ビルドエンジニアだったり、インフラエンジニアだったり ○ 直近は CI/CD 関連がメイン 35

Slide 36

Slide 36 text

（後半）ゲーム事業部にプロジェクト横断SREチームが誕生ゲーム事業部における CI/CD の課題 ● 横断的なベストプラクティス議論 ● プロジェクト格差とシフトレフト・共通化の必要性 SREチームの誕生と活動 ● 誕生経緯 ● 「ゲーム開発者のための SRE」の実践 ● 主な活動と今後 ● Jenkins から GitHub Actions へ 36

Slide 37

Slide 37 text

横断的なベストプラクティス議論 ● Jenkins 運用してると問題めっちゃ発生する ● 各プロジェクトごとに独自運用 ○ 一部 SWET 運用 ● 車輪の再発明 ○ 前のプロジェクトでも同じことやったな？ ○ プロジェクトごとに Jenkinsﬁle の書き直し ● 横断的に課題と最善策を議論する会が発足（ベスプラ会） ○ CI/CD 編としてゲーム事業部・SWET で議論の場ができた ○ ここが起点となり双方が互いに歩みより 37

Slide 38

Slide 38 text

プロジェクト単体での課題 ● リリース前の開発フェーズとリリース後の運営フェーズで変化 ● 開発フェーズではメインライン1本 ○ 並列実行などは少なめシンプルな構成で事足りる ○ イテレーションが優先される傾向 ○ リリースが近づくにつれて・・ 38 Jenkins Artwork - Jenkins / CC BY-SA 3.0 Jenkins Artwork - Fire / CC BY-SA 3.0

Slide 39

Slide 39 text

プロジェクト単体での課題 ● 運営フェーズでは複数ラインが同時並行で走る ○ パイプライン完了までの時間が長くなる ○ ビルドマシン不足（ディスク容量・速度・並列数） ○ 複雑度が増す ○ 安定性が大事になってくるゲームの成長とともに CI/CD も大きく成長していく 39

Slide 40

Slide 40 text

複数プロジェクトでの課題 ● SWET 管理 Jenkins のノウハウが一部のプロジェクトのみに ○ SWET 管理の Jenkins は開発者目線ではすごく楽でとても助かる ○ ただし SWET が対応できるプロジェクト数は限られる ○ ゲーム事業部側に Jenkins 運用のエキスパートが少ない ■ SWET からの移譲が滞留しがち ○ 恩恵を受けられないプロジェクトがガラパゴス、カオス化 40 Jenkins Artwork - JCasC by Nicolas De loof & Kseniia Nenasheva / CC BY-SA 3.0 Jenkins Artwork - Duchess France by TatoBerres Duchess France / CC BY-SA 3.0 Jenkins Artwork - Googly by Lakhan Kumawat / CC BY-SA 3.0 Jenkins Artwork - Ninja by Masanobu Imai / CC BY-SA 3.0

Slide 41

Slide 41 text

複数プロジェクトでの課題 ● プロジェクト初期の構成からの負債 ○ プロジェクト初期にコピーされた Jenkins が開発終盤まで現役 ○ コピー元の負債ごと持ってきてしまう ■ 動いてるものだけコピー ■ 改善案などは受け継がれず 41

Slide 42

Slide 42 text

議論から実践へプラクティスを議論していざ実践へあとは実践する人さえいれば 42

Slide 43

Slide 43 text

ゲーム事業部横断SREチームの誕生 43

Slide 44

Slide 44 text

SRE チーム＝「ゲーム開発者のための SRE」を実践するチーム単に SRE だと何をする組織か分かりづらい状況となっているため「ゲーム開発者のための SRE」と命名 ● SRE（Site Reliability Engineering/Engineer） ○ 一般的には Google が実践しているやり方を指すことが多い ○ Site の数だけ SRE がある ≒「サービスの運用/運営にあたって、価値目標に向け、自動化（自働化）を主軸にエンジニアリングを用いて、継続的に改善していく」人/こと、と理解 44

Slide 45

Slide 45 text

「ゲーム開発者のための SRE」とは ● ゲームの SRE ○ ユーザー（ゲームプレイヤー）のために活動するイメージ ● ゲーム開発者のための SRE ○ ゲーム開発者のためにも活動ゲーム開発中に必要なツールやサービス、ゲーム中のデバッグ機能、環境構築、ワークフロー、etc... それらを「ゲーム開発者」向けのサービスと捉えて運用と改善をするのが「ゲーム開発者のための SRE」です 45

Slide 46

Slide 46 text

SRE チーム MISSION ゲーム開発におけるプロダクト・プロジェクト上のサービスの信頼性を担保する ● ゲーム開発における開発フロー・対ユーザーサービスを運用し、信頼性の高いサービスを提供する ● 50%ルールを守り、エンジニアリングによる継続的な改善を行う 46

Slide 47

Slide 47 text

なぜ CI/CD を担当しているのか ● ゲーム事業部として解決した課題は山程ある ○ ゲーム開発における CI/CD の部分をカバーできてなかった ● 「ゲーム開発者のための SRE」として ○ CI/CD はゲーム開発者向けのもっとも利用者が多く、重要なサービスであるから ○ 小さな改善でも大きな効果が見込める 47

Slide 48

Slide 48 text

to SRE 技術的負債時間を借りてできた課題ゲーム開発では締切優先で短期的な解決方法を取ることがしばしばある「課題」として認識しているが、将来的にやりたい、手が空いたらやりたい、積んでいるだけ、など課題は先送りされてしまいがちであるゲームの運営、改善チーム ● 運営チーム機能開発、リリース業務を行いつつ、障害対応と再発防止、業務フローの改善など、SRE と言っても過言ではない ● 改善チーム技術的負債の返済を目的とした人・チームがしばしば誕生する私も改善チームとして活動していたスタッフロールの肩書はどうしたらいい？ → SRE 48

Slide 49

Slide 49 text

Embedded/Enabling SRE ● Embedded SRE ○ SRE がプロジェクトに参加しプロジェクトメンバーとして活動これまで運営チームや改善チームがやってきたことただし、ゲームの運営・開発がメイン改善は継続的に回っていなかった ● Enableing SRE ○ プロジェクトに SRE のプラクティスや文化を浸透させるプロジェクトメンバーに SRE になってもらう 49

Slide 50

Slide 50 text

なぜ横断組織なのか白柳はもともと Embedded SRE として活動してきたゲーム事業部の各プロジェクトの CI/CD 課題を解決するにはプロジェクト初期から関わる必要がありプロジェクトに所属するのではなく横断組織が都合がよかった Embedded から Enabling に注力 SRE でなくても誰もが SRE の思想を実行できるゲーム事業部にしていきたい 50

Slide 51

Slide 51 text

VISION 開発チームが「楽」してゲーム開発・運営ができる場を作るいわゆる DX (Developer eXperience）開発者体験の向上 SRE や DX というと聴こえがいいかもしれませんが今までやってきた改善を継続的に行っていくただそれだけです「ゲーム開発者のための SRE」が目指すところ 51

Slide 52

Slide 52 text

SRE チームの取り組み 52

Slide 53

Slide 53 text

これまでの活動 ● CI/CD ○ 運用 ■ ビルドマシンメンテナンス ■ パイプライン上の失敗のハンドリング ■ ジョブ作成、改修サポート ○ SWET 構成の Jenkins へのリプレイス ○ プロジェクト初期からのサポート ■ GitHub Actions (self hosted runner) の導入 ● SWET と協力 ○ SWET とプロジェクト間の橋渡し 53

Slide 54

Slide 54 text

これまでの活動 ● プロジェクト内での活動 ○ 作業環境構築サポート ○ クラッシュレポーター導入 ○ 不具合調査 ○ その他お助けマン ■ Slack 上のヘルプに駆けつけ ■ リアクション大事 54

Slide 55

Slide 55 text

今後 ● SRE のプラクティスをより実践していく ● CI/CD 関連業務をもっと簡単に ● CI/CD に限らず SRE の活動の場を増やす ○ ゲーム事業部に SRE を増やす ○ 「ゲーム開発者のための SRE」としてゲーム開発もこなす Embedded SRE ○ 組織運営など開発現場以外にも自動化を推進 55

Slide 56

Slide 56 text

Jenkins から GitHub Actions へ SRE と SWET が協力して進めている脱 Jenkins の取り組みを紹介 ● SWET ○ GitHub Actions の機能や使い方の調査 ○ runner 構築方法 ○ インフラ、IaC（Infrastructure as Code） ○ 汎用ワークフロー/アクション開発 ● SRE ○ プロジェクトへの導入支援 ○ ゲーム開発向けのワークフロー/アクション開発 ○ runner 運用相互にフィードバックをし合う 56

Slide 57

Slide 57 text

なぜ GitHub Actions ？ ● 脱 Jenkins ○ ゲーム業界ではまだまだ現役だが他業界ではだいぶ下火 ○ 本体・プラグインのバージョンアップが大変 ○ 設定が煩雑 ● GitHub Ac\ons ○ GitHub Enterprise Server を使っているため相性バツグン ○ 開発が活発 ○ エンジニア以外でも使えるかの懸念があったがクリア ■ 手動トリガー ■ ジョブサマリー 57

Slide 58

Slide 58 text

現状の Jenkins と GitHub Actions ● Jenkins のみを使用 ○ リリース済みプロジェクト ● Jenkins + GitHub Actions を使用 ○ リリース済みプロジェクト GitHub Actions が使える以前に開発始まったプロジェクト ○ Jenkins メインで一部 GitHub Actions なハイブリッド構成 ○ ゲームのビルドなどの高負荷なジョブは Jenkins GitHub のイベント（プルリクエストなど）に紐づく軽量なジョブは GitHub Actions ● GitHub Actions のみを使用 ○ 新規プロジェクト 58

Slide 59

Slide 59 text

Jenkins vs GitHub Actions Jenkins GitHub Actions (self hosted runner) Controller タイトル管理 GitHub Enterprise Server Controller 設定 GUI or JCasC - Agent プロジェクト管理プロジェクト管理ツール類プリインストールが基本 ansible で管理プリインストール（ansible）と setup-XXX 系 action ジョブ設定 GUI で作成 or JobDSL YAML ジョブ処理 GUI or Jenkinsfile に記述 YAML に記述ワークスペースジョブごとのディレクトリにファイルが残るリポジトリごとのディレクトリにファイルが残る 59

Slide 60

Slide 60 text

Jenkins から GitHub Actions になって ● Controller の管理分の負担がなくなった ● Agent に関しては self hosted runner なのであまり変わらない ○ ゲーム開発の場合、差分ビルドしたり、Unity セットアップ、 OS依存など、自分たちで管理のほうがむしろ好都合 ○ マシン構築は Jenkins 時代に SWET が作ったもののを流用 ● ツール類のセットアップ ○ Jenkins ではプリインストールが基本 GitHub Actions ではジョブからでもセットアップしやすい 60

Slide 61

Slide 61 text

Jenkins から GitHub Actions になって ● ジョブ ○ ジョブの設定/処理内容どちらも GitHub Actions は as Code 共有（action/reusable workflow）の仕組みもありプロジェクト間共有しやすい ○ Jenkins でも JCasC や JobDSL を使ってみたが記述量が少なく済むので GitHub Actions のほうが楽（個人的な感想） 61

Slide 62

Slide 62 text

Jenkins から GitHub Actions になって ● ワークスペース ○ Jenkins と同様に常にクリーンな状態ではなく利用者側でコントロール可能 ○ ただし GitHub Ac\ons ではリポジトリごとにワークスペースが共有なので注意が必要 ○ 意図的に clean しないようにしていたジョブのキャッシュが他のジョブの checkout で消えていた（e.g. Unity プロジェクトの Library ディレクトリ） 62

Slide 63

Slide 63 text

GitHub Actions でジョブ単位ワークスペースにする DeNA/setup-job-workspace-action ジョブ/ワークフロー単位でワークスペースを切り替える action アクション呼ぶだけでワークスペースが切り替わる ● キャッシュが誤って消されることがなくなった Unity の Library などキャッシュ管理がとても簡単になった 63

Slide 64

Slide 64 text

まとめ ● GitHub Actions だけでできるのか不安もあったが思っていたよりも問題にならなかった ○ Jenkins 時代の知見が活かせた ○ まだ始めたばかりなのでこれが答えではない ■ ゲームリリースや運営まで経験してない ■ これからも継続的に改善 ● ゲーム事業部と SWET の間に SRE が入ることで CI/CD のトレンドを取り込みつつ安定的な運用と改善のサイクルが回るようになった 64

Slide 65

Slide 65 text

おわり 65