Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

youtube:https://youtu.be/nkJOEP2Hczs

概要:
近年のソフトウェア開発ではCI/CDサービスを活用することでビルドやテストを自動化して効率的に開発を行うことが一般的となっています。これはゲーム開発でも同様であり、このようなCI/CDを実現するために様々なツールを動かす基盤は重要な役割を担っています。

DeNAのゲーム開発では以前からJenkinsを利用しており、大規模なデータを扱い大人数が関わるゲーム開発現場に耐えうるJenkinsの運用を年々アップデートしてきました。

また、開発を効率化するための様々なタスクの自動化や基盤整備のニーズが年々高まり、個々の開発プロジェクト内だけでは人手が不足しがちなことが課題となりつつありました。

この問題を解決するためにプロジェクト横断したSREチームを立ち上げました。自動化などを主軸に、ゲーム開発におけるCI/CD運用や開発効率化を行っています。

今回はチームの最新ノウハウや、今後の展望をご紹介します。
・JenkinsビルドマシンとしてMacStadiumの利用
・BigQueryによるビルド情報の分析基盤の構築
・Jenkinsの代わりにGithub Actionsを活用する取り組み

登壇内でのリンク集:
p13, https://speakerdeck.com/dena_tech/mohairukemukai-fa-niokerujenkinskurautoshi-dai-falsejenkinsgou-zhu-toguan-li-tekunituku
p20, https://techcon2022.dena.dev/spring/session/lightning-talks/
p21-1, https://swet.dena.com/entry/2021/07/12/120000
p21-2, https://speakerdeck.com/dena_tech/kaorumaeda_cedec2022
p21-3, https://swet.dena.com/entry/2022/09/21/100000
p24-1, https://github.com/Kesin11/CIAnalyzer
p24-2, https://event.cloudnativedays.jp/cicd2021/talks/1152
p63, https://github.com/DeNA/setup-job-workspace-action

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

DeNA_Tech

March 02, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. Table of Contents ゲーム開発におけるCI/CDのための安定したJenkinsクラスタ構築と発展 • Jenkins クラスタの構成と構成管理 • macOS Agent

    をオフィスの Mac mini から MacStadium へ • BigQuery を活用したビルド情報の可視化と分析 2 ゲーム事業部にプロジェクト横断SREチームが誕生 • ゲーム事業部における CI/CD の課題 • 横断 SRE チーム誕生までの経緯と活動 • Jenkins から GitHub Ac?ons へ
  2. 自己紹介 • 加瀬健太 ◦ @Kesin11(Twitter) / @Kesin11(GitHub) • 所属 ◦

    DeNA SWET 第二グループ(Software Engineer in Test) • 業務 ◦ CI/CD 関連の技術的なサポート ◦ 社内共通基盤の CircleCI Server、Bitriseの運用 3 @Kesin11
  3. ゲーム開発における Jenkins と SWET • ゲーム開発におけるJenkins ◦ 効率的に品質の高いゲームを開発するための自動化の基盤 ▪ アプリの定期的なビルド

    ▪ マスタデータやアセットのバリデーション ▪ サーバーのデプロイ自動化 ◦ 開発規模が大きくなるほど Jenkins は業務に必要不可欠 ◦ だが・・・ 5
  4. ゲーム開発における Jenkins と SWET • プロジェクトごとに独自に Jenkins を構築 ◦ Jenkins

    の運用は片手間になりがち ◦ Jenkins を専門に運用するチームがいない ▪ ノウハウが蓄積されない • 新規プロジェクトにおいても Jenkins が改善されない Jenkins のノウハウを持っていたSWETが大規模なゲーム開発に耐 えうる Jenkins の構築を目指すことに 6
  5. 8 Jenkins クラスタの構成 • 主に3種類のマシンで構成 ◦ Jenkins Controller ◦ Linux

    Agent ◦ macOS Agent Google Compute Engine is a trademark of Google LLC.
  6. 10 Jenkins クラスタの構成 • Linux Agent(GCE) ◦ 役割 ▪ macOSが必須ではないジョブ

    ▪ docker が必要なジョブ ◦ スケールアップ、 スケールアウトが容易 ◦ 夜間と休日は稼働台数を減らす ことでコスト削減
  7. 11 Jenkins クラスタの構成 • macOS Agent ◦ オフィスに配置した Mac mini

    ◦ MacStadium の Mac mini (後述) ◦ 役割 ▪ Xcode など macOS が必須のジ ョブ ▪ Unity を利用するジョブ ◦ Unity を macOS で使用する プロジェクトが多い
  8. Jenkins Controller や Agent の構成管理 • Google CloudのインフラはTerraform管理 ◦ GCEの台数、スペック

    ◦ ネットワーク構成 • Jenkins自体やAgentに必要なツールのインストールや設 定はAnsibleで管理 ▪ マシン毎にYAMLを用意する ▪ インストールするツールのバージョンを書く ▪ 現在のマシン構成をコードから把握できる 12
  9. 詳しくは CEDEC 2020 の発表 • モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構 築と管理テクニック〜 ▪ Ansibleによる構成管理

    ▪ ビルドパイプラインの設計 ▪ ビルドマシンの監視とアラート ▪ 成果物をGCSに保存してディスク容量消費を抑制 ▪ Fastlane matchによるiOS開発用の証明書と プロビジョニングプロファイル管理 13
  10. オフィスの Mac mini の不便な点 • 注文してから納品まで時間がかかる ◦ 特に近年は感染症と半導体不足の影響で数ヶ月待ちの状況で あった •

    マシン再起動を伴う作業は出社する必要がある ◦ OS アップデートやハングアップからの復帰など ◦ DeNA は近年ではリモートワーク主体 • 台数が増えると物理的な障壁が現れる ◦ 設置スペース ◦ 電源容量 ◦ ネットワーク容量 • ビルの法定停電対応 ◦ 停電中はビルドが行えなくなってしまう 15
  11. MacStadium • データセンターの Mac mini の実機を1台ずつ月ごとに借りられ るサービスを提供している • ssh もしくは

    VNC でのリモート操作 • 電源ON/OFFも web コンソールから制御可能 • 2020年時点で既に活用実績はあったが最近はさらに積極的に活 用 ◦ DeNA 全体としてインフラをクラウドに寄せる方針 ◦ 2020年からリモートワーク主体に変化 17
  12. MacStadium のメリット • 台数をスケールさせやすい ◦ 発注してからおおよそ1日でビルドマシンとして稼働可能 ▪ 注文後に MacStadium 側の初期セットアップ完了まで約半日

    ▪ ツールのセットアップは Ansible で自動化済みなので数時間 ◦ 急激なビルド負荷の増加に対応可能 ▪ リリース時期付近は1日にビルドを行う回数が増加 ▪ 繁忙期だけ台数を増やし落ち着いたら減らす運用が可能に 18
  13. MacStadium のデメリット • SSDが最大でも1TB ◦ ゲーム開発におけるビルドは非常にディスク容量を必要とす る ▪ アセットデータなどが膨大 •

    アセットのリポジトリだけで20GBを超える プロジェクトもある ▪ Jenkinsでビルド時のブランチなどのパラメータに応じてワ ークスペースを分離したいニーズ • ビルドキャッシュの効率化のため • リリース候補となるバイナリ作成ジョブは まっさらな環境からビルドしておきたい 19
  14. MacStadium の容量問題への対策 • 不要データの定期的な削除の自動化 ◦ Xcode の Archive、DerivedData ディレクトリ ◦

    利用されていない、もしくは古い Jenkins ジョブの ワークスペース ◦ 過去のブランチでビルドに使用していたワークスペース • 削除を自動化したことで台数が増えても運用工数を抑えること ができた • 詳しくはTechCon 2022のLT ◦ 「ゲーム開発のCI/CDを支えるJenkins運用 ~MacStadium 活用 とディスク容量との闘い~」 20
  15. • ビルドに必要なデータだけを 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機能を使ってディスクを節約した話
  16. • いつの間にかビルド時間が長くなっている • ランダムにたまに失敗するビルド • ビルドキューが詰まりがち ビルド・テストが失敗した際の根本原因の修正が放置されがちな 原因となる • 問題の調査が困難

    ◦ Jenkins に過去のビルド情報を分析する機能が乏しい ▪ 過去のビルドログを1つ1つ調べるしかない ◦ ビルドログが長大かつ数が膨大 23 Jenkins を長く運用していると見えてくる問題
  17. • CIAnalyzer ◦ https://github.com/Kesin11/CIAnalyzer • Jenkins, GitHub Actions, CircleCI, Bitriseの

    API からビルド情報を 整形して BigQuery に送信 • BigQuery のデータの可視化は Looker Studio (旧データポータル)を利用 • 詳しくは CI/CD Conference 2021 の発表 ◦ 「CI/CDのボトルネックを把握できていますか?BigQueryで ビルド情報ダッシュボードを構築した話」 24 ビルドに関する情報の可視化と分析
  18. • ジョブ内で時間がかかっているコマンドが統計的に分かる ◦ ビルド時間の改善幅が大きい部分から着手しやすい • キュー待ち時間の推移が定量的に分かる ◦ 肌感ではなく数字に基づいたビルドマシン台数の調整 • いつのビルドから失敗するようになったのか正確に分かる

    ◦ リトライすれば直るケースは調査が後日になりやすい ◦ 問題の正確な発生日は重要な情報 ▪ 日付から修正コミットやインフラの変更などを追跡できる 29 可視化するとビルドの分析調査が効率的に
  19. • Jenkins Controller と Agent をクラウド化 ◦ GCE ◦ MacStadium

    • Terraform と Ansible で構成管理 • macOS Agent の MacStadium 活用 ◦ 台数をスケールさせやすい ◦ ディスク容量問題への対策 • BigQuery を活用したビルドに関する情報の可視化と分析 ◦ ビルドの調査分析が効率的に 31 SWET グループによる Jenkins 運用のまとめ
  20. • SRE チームと協力して Jenkins の運用をサポート ◦ SWETのCI/CDチームはゲーム開発や Unity のノウハウが足り ていない

    ◦ お互いの得意分野で協力 • DeNA 全体の CI/CD のサポートにも力を入れたい ◦ GitHub Ac\onsの発展に注目 ▪ ゲーム開発以外のプロジェクトでは知名度が急上昇 ▪ ゲーム開発でも Jenkins の代替として利用できるかも ◦ SRE チームと協力して GitHub Ac\ons の利用を開始 33 今後の展望
  21. 自己紹介 • 白柳隆澄(しらやなぎ たかずみ) ◦ Facebook (takazumi.shirayanagi) ◦ Twitter/GitHub やってるけど秘密

    • 所属 ◦ ゲーム事業本部開発事業部 ▪ 開発二部テクノロジー推進第一グループ • 業務 ◦ SRE ◦ ゲームエンジニアだったり、ビルドエンジニアだったり、 インフラエンジニアだったり ◦ 直近は CI/CD 関連がメイン 35
  22. 横断的なベストプラクティス議論 • Jenkins 運用してると問題めっちゃ発生する • 各プロジェクトごとに独自運用 ◦ 一部 SWET 運用

    • 車輪の再発明 ◦ 前のプロジェクトでも同じことやったな? ◦ プロジェクトごとに Jenkinsfile の書き直し • 横断的に課題と最善策を議論する会が発足(ベスプラ会) ◦ CI/CD 編としてゲーム事業部・SWET で議論の場ができた ◦ ここが起点となり双方が互いに歩みより 37
  23. 複数プロジェクトでの課題 • 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
  24. SRE チーム=「ゲーム開発者のための SRE」を実践するチーム 単に SRE だと何をする組織か分かりづらい状況となっているため 「ゲーム開発者のための SRE」と命名 • SRE(Site

    Reliability Engineering/Engineer) ◦ 一般的には Google が実践しているやり方を指すことが多い ◦ Site の数だけ SRE がある ≒「サービスの運用/運営にあたって、価値目標に向け、 自動化(自働化)を主軸にエンジニアリングを用いて、 継続的に改善していく」人/こと、と理解 44
  25. 「ゲーム開発者のための SRE」とは • ゲームの SRE ◦ ユーザー(ゲームプレイヤー)のために活動するイメージ • ゲーム開発者のための SRE

    ◦ ゲーム開発者のためにも活動 ゲーム開発中に必要なツールやサービス、ゲーム中のデバッグ機能、 環境構築、ワークフロー、etc... それらを「ゲーム開発者」向けのサービスと捉えて 運用と改善をするのが「ゲーム開発者のための SRE」です 45
  26. なぜ CI/CD を担当しているのか • ゲーム事業部として解決した課題は山程ある ◦ ゲーム開発における CI/CD の部分をカバー できてなかった

    • 「ゲーム開発者のための SRE」として ◦ CI/CD はゲーム開発者向けのもっとも 利用者が多く、重要なサービスであるから ◦ 小さな改善でも大きな効果が見込める 47
  27. to SRE 技術的負債 時間を借りてできた課題 ゲーム開発では締切優先で短期的な解決方法を取ることがしばしばある 「課題」として認識しているが、将来的にやりたい、手が空いたらやりたい、積んで いるだけ、など課題は先送りされてしまいがちである ゲームの運営、改善チーム • 運営チーム

    機能開発、リリース業務を行いつつ、障害対応と再発防止、 業務フローの改善など、SRE と言っても過言ではない • 改善チーム 技術的負債の返済を目的とした人・チームがしばしば誕生する 私も改善チームとして活動していた スタッフロールの肩書はどうしたらいい? → SRE 48
  28. Embedded/Enabling SRE • Embedded SRE ◦ SRE がプロジェクトに参加しプロジェクトメンバーとして活動 これまで運営チームや改善チームがやってきたこと ただし、ゲームの運営・開発がメイン

    改善は継続的に回っていなかった • Enableing SRE ◦ プロジェクトに SRE のプラクティスや文化を浸透させる プロジェクトメンバーに SRE になってもらう 49
  29. VISION 開発チームが「楽」してゲーム開発・運営ができる場を作る いわゆる DX (Developer eXperience)開発者体験の向上 SRE や DX というと聴こえがいいかもしれませんが

    今までやってきた改善を継続的に行っていく ただそれだけです 「ゲーム開発者のための SRE」が目指すところ 51
  30. これまでの活動 • CI/CD ◦ 運用 ▪ ビルドマシンメンテナンス ▪ パイプライン上の失敗のハンドリング ▪

    ジョブ作成、改修サポート ◦ SWET 構成の Jenkins へのリプレイス ◦ プロジェクト初期からのサポート ▪ GitHub Actions (self hosted runner) の導入 • SWET と協力 ◦ SWET とプロジェクト間の橋渡し 53
  31. 今後 • SRE のプラクティスをより実践していく • CI/CD 関連業務をもっと簡単に • CI/CD に限らず

    SRE の活動の場を増やす ◦ ゲーム事業部に SRE を増やす ◦ 「ゲーム開発者のための SRE」としてゲーム開発もこなす Embedded SRE ◦ 組織運営など開発現場以外にも自動化を推進 55
  32. Jenkins から GitHub Actions へ SRE と SWET が協力して進めている脱 Jenkins

    の取り組みを紹介 • SWET ◦ GitHub Actions の機能や使い方の調査 ◦ runner 構築方法 ◦ インフラ、IaC(Infrastructure as Code) ◦ 汎用ワークフロー/アクション開発 • SRE ◦ プロジェクトへの導入支援 ◦ ゲーム開発向けのワークフロー/アクション開発 ◦ runner 運用 相互にフィードバックをし合う 56
  33. なぜ GitHub Actions ? • 脱 Jenkins ◦ ゲーム業界ではまだまだ現役だが他業界ではだいぶ下火 ◦

    本体・プラグインのバージョンアップが大変 ◦ 設定が煩雑 • GitHub Ac\ons ◦ GitHub Enterprise Server を使っているため相性バツグン ◦ 開発が活発 ◦ エンジニア以外でも使えるかの懸念があったがクリア ▪ 手動トリガー ▪ ジョブサマリー 57
  34. 現状の Jenkins と GitHub Actions • Jenkins のみを使用 ◦ リリース済みプロジェクト

    • Jenkins + GitHub Actions を使用 ◦ リリース済みプロジェクト GitHub Actions が使える以前に開発始まったプロジェクト ◦ Jenkins メインで一部 GitHub Actions なハイブリッド構成 ◦ ゲームのビルドなどの高負荷なジョブは Jenkins GitHub のイベント(プルリクエストなど)に紐づく 軽量なジョブは GitHub Actions • GitHub Actions のみを使用 ◦ 新規プロジェクト 58
  35. 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
  36. Jenkins から GitHub Actions になって • Controller の管理分の負担がなくなった • Agent

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

    Actions は as Code 共有(action/reusable workflow)の仕組みもあり プロジェクト間共有しやすい ◦ Jenkins でも JCasC や JobDSL を使ってみたが 記述量が少なく済むので GitHub Actions のほうが楽 (個人的な感想) 61
  38. Jenkins から GitHub Actions になって • ワークスペース ◦ Jenkins と同様に常にクリーンな状態ではなく

    利用者側でコントロール可能 ◦ ただし GitHub Ac\ons では リポジトリごとにワークスペースが共有なので注意が必要 ◦ 意図的に clean しないようにしていたジョブのキャッシュが 他のジョブの checkout で消えていた (e.g. Unity プロジェクトの Library ディレクトリ) 62
  39. まとめ • GitHub Actions だけでできるのか不安もあったが 思っていたよりも問題にならなかった ◦ Jenkins 時代の知見が活かせた ◦

    まだ始めたばかりなのでこれが答えではない ▪ ゲームリリースや運営まで経験してない ▪ これからも継続的に改善 • ゲーム事業部と SWET の間に SRE が入ることで CI/CD のトレンドを取り込みつつ 安定的な運用と改善のサイクルが回るようになった 64