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

モバイルゲーム開発におけるJenkinsクラウド時代のJenkins構築と管理テクニック...

DeNA_Tech
September 07, 2020

 モバイルゲーム開発におけるJenkinsクラウド時代のJenkins構築と管理テクニック.pdf

CEDEC2020 DAY3 09/04
https://cedec.cesa.or.jp/2020/session/detail/s5e831cb604422
昨今のソフトウェア開発ではCI/CD専門のクラウドサービスを利用することが
一般的になってきています。しかし、一般的なソフトウェア開発と比較して特殊な要件
が多いゲーム開発の現場においては、様々な理由からCI/CD環境として
Jenkinsを自前で構築することが多いと思います。
本発表では、Jenkins運用で起こりがちな問題、私達が提案するJenkins
構成のメリット、Terraform・AnsibleによるJenkinsと
ビルドマシンの構築など中心に紹介します。さらに、クラウドのmacOSや一般的な
クラウドCI/CDサービスとの併用など、さらにクラウドを活用していく未来の展望
についてもご紹介いたします。

DeNA_Tech

September 07, 2020
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構築と管理テクニック〜 加瀬 健太 (Kenta Kase) 株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部

    SWETグループ 井口 恒志 (Hisashi Iguchi) 株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループ @ CEDEC2020 2020/09/4
  2. 自己紹介 2 • 氏名 • 加瀬 健太(Kenta Kase)@Kesin11 • 所属

    • 株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • 趣味 • CI/CDサービスを触ること、自動化
  3. 自己紹介 • 氏名 • 井口 恒志(Hisashi Iguchi)@hisa9chi • 所属 •

    株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • その他活動 • CircleCI Japan User Group Community Leaders 3
  4. Make Testing Fun, Smart, and Delighting End-Users • Fun •

    テスティングを楽しくクリエイティブなものにしたい • Smart • 定型的なテストを人の手を煩わせず実現したい • テストによるフィードバックを上手に活用 • Delighting End-Users • エンドユーザをデライトさせるための様々な品質特性をテスティングで向上 させます 8 4 3 2 1
  5. SWET のプロジェクトへの関わり • ソフトウェアテスト技術分野ごとのチーム • アーキテクチャ • 自動テスト • プロセス(CI/CD)

    • それぞれのチームが様々な技術領域の案件へサポート • QAによるテスト工程よりも前の工程で品質・生産性の向上 • デバッグの効率化・工数削減などテスト技術の蓄積 • テスト全般の実行環境・プロセスサポート・サービス化 10 4 3 2 1 開発チームに技術として蓄積してさらには運用していけるようにもサポート 我々が所属するチーム 開発プロセスにてCI/CDを効果的に活用できるように ゲーム開発案件への取り組みを開始
  6. CI/CD に Jenkins を利用している理由 • アプリの定期的なビルド • 特定な環境に依存していないかの早期発見 • 最新版を容易にインストール可能

    • チームメンバーが容易にビルド可能 • アプリのビルドに速度が求められる • 高スペックなマシンが必要 • クラウドCI/CDサービスが提供しているマシンではスペック不足な場合あり • ネットワークの転送コスト • 膨大な量のアセットデータ • ビルド時などのデータ転送がビルド時間に影響 12 1 4 3 2 Jenkins master / agent を社内ネットワーク上に構築して利用するケースが多い
  7. Jenkins 環境構築する上での前提 • 全社共通の Jenkins をサービスとして提供している部門なし • 運用コストがとてつもなく高い • master

    / plugin の更新 • ユーザ、権限、ジョブの管理 • 案件とは無関係な人が情報に触れられないようにする • 協力会社との取り決めにより分ける必要性 • 秘匿情報が漏れることの防止 • 権限管理よりも効果的 13 1 4 3 2 プロジェクト毎に Jenkins を構築
  8. Jenkins 環境構築 • 構築タイミング • 開発開発初期 • 構成 • 初期は

    master のみの1台構成が多い • 物理マシン(macOS) • ジョブも master で実施 14 1 4 3 2 Jenkins master ・開発メンバーが少数 ・ビルドの頻度が低い
  9. Jenkins 環境構築 • 構築方法 • 手動で構築 • 物理マシンの手配 • 必要なツールをインストール

    • Jenkins / Xcode / Unity / Android SDK,NDK など • ビルドジョブを作成して動作確認 • 担当者 • エンジニア(Jenkins 構築経験者 or 未経験者) 15 1 4 3 2 システム構成などを経験者にヒアリング or 世の中の事例を調査しつつ実施
  10. Jenkins の運用 - master に関して • ホストマシンのメンテナンス • OSのアップデート •

    システムエラーなど発生時の調査・問題解決 • 社内用ツールのアップデートなど • 不要データの削除 • Jenkins master のメンテナンス • version update • システム設定の管理 • plugin の メンテナンス • インストールとアップデート • アップデートによるシステム設定やジョブの修正 16 1 4 3 2
  11. Jenkins の運用 - agent に関して • 追加タイミング • 開発の進行状況 •

    並行開発やメンバー増加 • ジョブ実行待ち時間増加 • ホストマシンの故障 • メンテナンス • 新規ツールの手動インストール • 不要データの削除 • 不要ジョブのワークスペース • Xcode の Archive ファイル 17 1 4 3 2 Jenkins master macOS agent Jenkins master 初期 macOS agent Jenkins master macOS agent macOS agent 運用
  12. 起こりがちな問題 • マシンの運用コスト大 • オンプレの master / agent 管理 •

    OSのアップデート • 監視や可用性の仕組み構築して運用 • ディスクの不要データ削除 • Jenkins の成果物の保存など物理マシンではストレージに限界あり • ビルドに必要なツールのセットアップ • インストールするバージョンなども管理 19 1 4 3 2
  13. macOS agent 起こりがちな問題 • agent の環境差異 • ジョブの改造やエラー解決により agent へ新規ツールのインストール

    • ジョブの新規追加時に特定の agent で動作させようとする 20 1 4 3 2 Jenkins master macOS agent macOS agent インストール インストール漏れ 統一性が失われる 特定の agent でしか動作しないジョブが複数存在して実行に偏り
  14. 起こりがちな問題 22 1 4 3 2 • Jenkins master /

    agent の停止時間の発生 • 社内にマシンを持つことで法定点検などによる停電 • 社内用のツールなどのアップデート時 • 新規追加マシン調達のリードタイム • 急遽必要となった場合に対応困難 • 先を見越しての申請が必要 • マシン設置場所の問題 • 弊社で開発チームの近くに設置する場合が多いため以下の問題 • スペース問題 • 電源容量問題
  15. SWETの取り組み 1. パイプライン構成例 • 基本的な構成を定義 2. Jenkins の構成 • 1

    を運用可能な master / agent 構成の定義 3. セットアップの自動化 • master / agent (Linux / macOS) • 監視とアラート 4. 運用のコスト削減施策 • 成果物のGCS保存 / fastlane match 25 1 2 4 3 複数のタイトルで 活用可能
  16. ビルドパイプライン - iOS / Android クライアントビルド 27 1 2 4

    3 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
  17. ビルドパイプライン - iOS / Android クライアントビルド 28 1 2 4

    3 ・簡易的なチェック ・ビルド時の失敗を極力減らすため チェック完了までの時間は極力短く 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
  18. ビルドパイプライン - iOS / Android クライアントビルド 29 1 2 4

    3 ビルドタスクは用途に応じて分類 ・ナイトリータスク ・QAリリース用のアプリ作成などに利用 ・マニュアルタスク ・開発者がビルド確認など利用 ・日中定期タスク ・ビルドエラーなど早期発見に利用 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
  19. ビルドパイプライン - iOS / Android クライアントビルド 30 1 2 4

    3 ストレージ枯渇問題に対してGCSを活用 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
  20. ビルドパイプライン - iOS / Android クライアントビルド 31 1 2 4

    3 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos 1つの問題 これらジョブは Unity を利用するジョブが多い Unityがインストールされている macOS にジョブが集中
  21. ビルドパイプライン - iOS / Android クライアントビルド 32 1 2 4

    3 macOSを利用したジョブが詰まりやすい なるべくLinux での実行に寄せていく • Unityを利用したクライアントビルドプロセスを完全分割 • iOS / Android プロジェクトのエクスポート : macOS • クライアントビルド • iOS : macOS / Android : Linux • マージ前の簡易チェックも可能な限り Linux • クライアントビルド完了までに数時間がかかる • キュー待ち後にビルドが始まり失敗などの可能性もある • 確認サイクル鈍化 • ビルドジョブの改善が困難 • 開発者が利用していないタイミング実施する必要あり • macOS agent はスケールが容易でない 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
  22. Jenkins 構成の定義 • 構成 • master - agent 構成(agentは複数台) 35

    1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物
  23. macOS agent macOS agent 社内 Jenkins 構成の定義 • 構成 •

    master - agent 構成(agentは複数台) 36 1 2 4 3 ・社内事情によるダウンタイム削減 ・GCS利用によるストレージ枯渇問題の解決 ・Linux agent のスケーラビリティ確保 Linux agent Jenkins master GCS GCP JNLP 成果物
  24. Jenkins 構成の定義 • 構成 • master - agent 構成(agentは複数台) 37

    1 2 4 3 Linux agent Jenkins master GCS GCP 成果物 JNLP ・冗長性を確保 ・OSやツールの update 検証が可能 macOS agent macOS agent 社内
  25. Jenkins 構成の定義 • 構成 • master - agent 構成(agentは複数台) 38

    1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物
  26. macOS agent Linux agent Jenkins master macOS agent GCS GCP

    社内 JNLP 成果物 Jenkins 構成の定義 • 構成 • master - slave 構成(slaveは複数台) 39 1 2 4 3 手順書が整備されていたとしても手動ではかなり面倒
  27. 自動構築する理由 1. ビルドマシンの台数が増えると手動管理に限界がある 2. 極力コードで管理することで属人化を排除したい • スクリプトのレビューが可能 • 誰が実行しても同じ構成になる •

    他チームへの展開が容易になる 3. ビルドマシン構築のノウハウを会社で横展開させたい • 新規タイトルを立ち上げるときに「強くてニューゲーム」で始められるように • 構築手順書の作成だけではスケールさせることが難しい • スクリプトを共有するだけで同じ構成から始められる 43 1 2 4 3
  28. TerraformによるJenkinsのインフラ構築 • Jenkins周りで使用するGCPの各リソースの管理 • Jenkins master • GCE n1-standard-1 ubuntu

    • Linuxビルドマシン • GCE n1-standard-2 ubuntu • Jenkinsの成果物用ストレージ • GCSのバケット2種類 • 詳細は後述 45 Compute Engine Cloud Storage Cloud Storage Compute Engine 画像引用: https://cloud.google.com/icons https://www.jenkins.io/artwork/ 1 2 4 3
  29. Terraformの運用 • Terraformを実行するだけで初期の構築は完了 • 構築後の運用もTerraformで行う • スクリプトを修正して再度 terraform apply するだけ

    • 実際の運用事例 • GCEのディスク容量の追加 • ディスク使用量が圧迫されてきたタイミングで柔軟に増やす • GCEのインスタンスタイプの変更 • CPUやメモリのスペックが物足りなくなったらスケールアップ 46 1 2 4 3
  30. Macビルドマシン • 役割 • UnityやmacOSが必要なジョブ • UnityからXcode、Gradleのエクスポート • iOSアプリのビルド •

    インストールするツール • Unity • Xcode • Android SDK, NDK • 監視用agent(Telegraf) • Jenkinsに接続するためのagent.jar 50 Linuxビルドマシン • 役割 • UnityやmacOSを使う必要がないジョブ • AndroidアプリのGradleビルド • Dockerを使うジョブ • その他雑用 • インストールするツール • Docker • .NET • Android SDK, NDK • 監視用agent(Telegraf) • Jenkinsに接続するためのagent.jar 1 2 4 3
  31. プロビジョニング詳細 • 各種ツールのインストール • 基本的にパッケージマネージャでインストール • Ubuntu • aptを使用。難しいことはほぼない •

    macOS • Homebrew, Homebrew Caskを使用 • XcodeはOSSのxcode-installを使用 • 各種ツールをインストールするroleは自作 • 将来はAnsible Galaxyを活用するかも • インストール中にインタラクティブが操作が求められる場合も自動化 • Ansibleのexpect機能や、yesコマンド, expectコマンドを直接使用する • 特定のファイルを配置することで回避できるツールは事前に配布しておく 51 1 2 4 3
  32. どうしても手動対応が必要なもの • 開発チームから急ぎでツールのインストールを求められた場合 • 実際はこのパターンが多い • 極力aptやHomebrewでインストールしてもらい、後日Ansibleに追加する • インストール時のコマンドや手順のメモを残してもらうことが重要 •

    UnityはUnity Hubから手動でインストール • Unity Hubと同様のフローで自動化する方法を調査できていないため • Unityのバージョンアップはそれほど頻繁ではないので現状は問題ではない 53 1 2 4 3
  33. Ansible PlaybookのCI(pull-request) • 正しくプロビジョニングできるかをPlaybook修正のpull-requestで必ずテストする • Test Kitchen + Vagrant •

    実機を”汚さずに”毎回クリーンなVMを使用するため開発しやすく、再現性がある • ”自分の環境では動いた”問題の解消 • UbuntuはVagrant Cloudに用意されているイメージを使用して検証 • macOSは自前でイメージを作成して検証 55 create converge verify destroy VM作成 Ansible実行 検証スクリプト VM破棄 $ kitchen test macos-1015 1 2 4 3
  34. Ansible PlaybookのCI(定期実行) • Ansibleは外部環境に強く依存するため”何もしていないのに壊れた”が普通に起こる • Pull-requestに加えて週1回の頻度でmasterブランチをテスト • 特にHomebrewとxcode-installで問題が起こりやすい • 何かエラーが起きたらまずはGitHubのIssueを見に行く

    • 最近起きた事例 • HomebrewでJava8のパッケージが廃止 • →AdoptOpenJDKに移行 • HomebrewでPython2系が廃止 • →Python3に完全移行 • Xcode11登場時にXcode10系がxcode-installでインストール不可能に • 自前で修正してxcode-installにパッチを送った 56 その都度Playbookを修正して対応していくしかない 1 2 4 3
  35. 実際に役に立った事例 • ビルドマシンのMac miniがまれに突然反応しなくなる • 年に何回かまれに発生。原因不明 • 死活監視アラートで早期に気がつける • sshできないことを確認したら手動で実機を再起動させる

    • ディスクフルの事前回避 • ディスク使用率85%でwarning、90%超えでアラート • Jenkins master、LinuxビルドマシンはGCEのディスク拡張 • Terraformの修正、適用を余裕を持って行える • Mac miniは不要ファイルの削除 • 古いXcodeのアーカイブ • 古いJenkinsジョブのディレクトリなど 60 1 2 4 3
  36. 成果物をGCSに保存する • Google Cloud Storageを活用 • 従量課金制 • 容量の上限がないため成果物を保存する用途に適している •

    JenkinsのGCSプラグインを活用 • https://plugins.jenkins.io/google-storage-plugin/ • Jenkinsfileで扱いやすいように薄くラップした関数を自作している 64 1 2 4 3
  37. GCSのライフサイクルとストレージクラスについて • ライフサイクル • 一定の日数で自動削除、ストレージクラスを変更することが可能 • ストレージクラス • Standard, Nearline,

    Coldline, Archive • 頻繁にアクセスする場合はStandardがお得 詳細は https://cloud.google.com/storage/pricing 65 Standard Nearline Coldline Archive 保存容量当たりの課金額 大 小 アクセス時の課金額 小 大 1 2 4 3
  38. 2種類のバケットを使い分けてコスト管理 • 2つのバケットを用意して異なるポリシーで運用 • 一時保存用バケット • 手動実行のビルド、ナイトリービルドの成果物を保存 • Standard Storage

    • 30日経過したオブジェクトは自動削除 • 永続保存用バケット • QAやリリース提出用のビルドの成果物を保存 • Standard Storage & Coldline Storage • 最初はStandard、90日経過したオブジェクトを自動でColdlineに変更 • ライフサイクル機能を使うとGCSが自動で管理してくれる 66 1 2 4 3
  39. GCSの費用について • Jenkins masterに成果物として保存し、PD-SSDの容量を増やしていく 運用と比較 • 簡略化のために単に1TBを保存する場合で計算 • 全てをStandard Storageで保存したとしても約1/10

    • 永続保存用バケットはColdline Storageに自動で切り替わるのでさらに若干安くなる 67 1TBあたりの費用 GCE PD-SSD USD 221.0 GCS Regional Standard Storage USD 23.00 GCS Regional Coldline Storage USD 6.0 リージョンは東京(asia-northeast1) GCEはネットワーク、GCSはオペレーション毎に別途費用がかかりますが計算には含めていません 1 2 4 3
  40. その他の運用コスト削減策 • fastlane matchによる証明書とプロビジョニングプロファイルの管理 • 各ビルドマシンへの配布が1コマンドで完了する • 更新作業もデベロッパーサイトで作業せずにCLIから行うことが可能 • メリットが非常に多いためかなりオススメ

    • GCEのスナップショット機能でJenkins masterの検証環境を手軽に立ち上げる • Jenkins本体やプラグインバージョンを更新する際に検証環境で実験したい • スナップショット機能で稼働しているJenkinsと全く同じ環境を複製可能 • 数時間で検証環境の立ち上げと検証作業が完了 • ジョブ完了時にSlack通知の自動メンション • ジョブを実行したメンバーへのメンション機能をJenkinsfileとgroovyで実現 • ビルドジョブの分析基盤をBigQueryに構築 • 全体ビルド時間やステップ毎の時間などのデータを保存して可視化 69 1 2 4 3
  41. クラウドサービスの活用 • クラウドのCI/CDサービス • 特徴 • 実機、インスタンスの管理が不要 • プロビジョニングが不要 •

    ジョブの設定がJenkinsよりも簡単 • VMやDocker上で動作するため一般的にスペックは実機より劣る • DeNAで利用しているサービス • CircleCI • Bitrise • 実機を借りるサービス • MacStadium 73 1 2 3 4
  42. • https://circleci.com/ • SaaS型のCI/CDサービス • DeNAではCircleCI Server(オンプレ)を使用 • DeNAではmacOSマシンの契約をしていない •

    サーバーサイド開発のCIでは既に活用 • 以下のジョブはCircleCIでの実行に変えていきたい • Unityに依存していない • macOSに依存していない • 手動で複雑なパラメータの選択が必要ではない 74 画像引用: https://brandfolder.com/circleci 1 2 3 4
  43. • https://www.macstadium.com/ • Mac miniなどの実機をクラウド上で借りられるサービス • 電源のON/OFFをコンソール上から可能 • 実機を置き換える、あるいは繁忙期に臨時で追加する運用などを想定 •

    DeNA内で既に活用実績あり • Unityを使用するビルドマシンとして使用できるか現在検証中 76 画像引用: https://www.macstadium.com/company/media 1 2 3 4
  44. 将来のパイプラインの構成イメージ 79 • マシンパワーが必要なビルドジョブは 実機Mac & MacStadium • MacStadiumはネットワークの 転送コストがどうしても発生する

    • 若干軽い or 優先度が低いタスクを 任せるかもしれない 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/, https://github.com/logos https://brandfolder.com/circleci, https://www.bitrise.io/presskit, https://www.macstadium.com/company/media 1 2 3 4
  45. まとめ • Jenkinsの構築・運用において起こりがちな問題の紹介 • これまでの取り組み • パイプラインタスクの一部をmacOS以外のマシンに逃がす • Jenkinsのmaster –

    agent構成 • セットアップ自動化 • Terraform、Ansible • 監視とアラート • 成果物をGCSに保存 • 今後の展望 • クラウドサービスをさらに活用してスケーラブルな構成を目指す 81