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

カオナビのCIにおける自動テスト運用と速度改善 / CI automatic test operation and speed improvement

カオナビのCIにおける自動テスト運用と速度改善 / CI automatic test operation and speed improvement

DevOpsDays Tokyo 2023で登壇した際の発表資料です。
https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18311/gitlab-cicd

本セッションでは、カオナビのCI/CD環境で運用を担当する二名のメンバーがそれぞれ直面してきた様々な事例を紹介します。

---

みなさんは、自動で実行され、エラーが発生しているにも関わらず無視され続けているテストを見たことはあるでしょうか?

前半は、そんな状態にあったカオナビの自動テストをGitLab CI/CDを活用して運用に乗せるまでの事例を紹介します。

---

セッションの後半では、CI/CDの速度改善の事例を紹介します。

・速度改善のためにデータ集計・可視化する

・他部署を巻き込んだ速度改善

株式会社カオナビ

April 20, 2023
Tweet

More Decks by 株式会社カオナビ

Other Decks in Business

Transcript

  1. SRE部 サービス開発部 プロダクト開発チームの組織体制 プロダクト本部 アプリケーションの開発をしています。 インフラ基盤の開発をしています。 Data Frontier グループ データの正規化に関わるサービス・プロダクトのシステムを開発します。

    Employee グループ 従業員レイヤーの方が使う機能を開発します。 Platform グループ システム全体の保守性を高める開発やアーキテクチャの見直しをします。 Kaizen1グループ, Kaizen2グループ 顧客側の改善業務に関わる機能を開発します。 Strategy グループ 経営や人事レイヤーの方が組織戦略で使う機能を開発します。 Productivity グループ CI/CD、E2Eテストなどの業務効率化を行います。 インフラ グループ 運用監視、障害対応、サーバ環境保守、 共通基盤の開発をします。 オペレーション グループ 不具合/インシデント対応、リリース管理、 デプロイ作業、顧客対応をします。 CTO室 企画推進本部 新規開発部 © kaonavi, inc. 4
  2. SRE部 サービス開発部 プロダクト開発チームの組織体制 プロダクト本部 アプリケーションの開発をしています。 インフラ基盤の開発をしています。 Data Frontier グループ データの正規化に関わるサービス・プロダクトのシステムを開発します。

    Employee グループ 従業員レイヤーの方が使う機能を開発します。 Platform グループ システム全体の保守性を高める開発やアーキテクチャの見直しをします。 Kaizen1グループ, Kaizen2グループ 顧客側の改善業務に関わる機能を開発します。 Strategy グループ 経営や人事レイヤーの方が組織戦略で使う機能を開発します。 Productivity グループ CI/CD、E2Eテストなどの業務効率化を行います。 インフラ グループ 運用監視、障害対応、サーバ環境保守、 共通基盤の開発をします。 オペレーション グループ 不具合/インシデント対応、リリース管理、 デプロイ作業、顧客対応をします。 CTO室 企画推進本部 新規開発部 © kaonavi, inc. 5
  3. 山内 翼 Tsubasa Yamauchi プロダクト本部 SRE部 Productivityグループ ・DevOpsエンジニア ・青森県出身 ・仙台でPHPエンジニア

    → CI/CDに興味を持ち始める ・現在はテスト環境構築などの運用業務をしながら  CI/CDを始めとした自動化などの改善活動をしている 自己紹介 © kaonavi, inc. 7
  4. 今回はそこに docker in docker を指定。 docker in dockerの中にローカル環境のコンテナ + testcafeコンテナを置いた。

    使われなくなったE2Eテスト © kaonavi, inc. 27 E2Eテスト実行環境をCIに閉じ込める とは? → 「特定の環境に対してしか実行できない」使いづらさを解消 GitLab Runner docker in docker web mysql testcafe
  5. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 毎日、masterブランチか らE2Eテスト用のブラン チを作成
  6. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
  7. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 直前テスト E2Eテストを自動実行 (直前テスト) 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
  8. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 (直前テスト) 毎日、masterブランチか らE2Eテスト用のブラン チを作成 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ
  9. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 draft/20230102 テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 (直前テスト) 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
  10. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定

    1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 draft/20230102 直前テスト テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 (直前テスト) 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
  11. master 1月1日 1月2日 1月3日 draft/20230101 毎日、masterブランチか らE2Eテスト用のブラン チを作成 feature/A feature/B

    feature/C 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 E2Eテストを自動実行 (直前テスト) 直前テスト テスト失敗時は原因特定。 必要に応じてリリース中止。 ver1.0.1 draft/20230102 ver1.0.2 ver1.0.3 直前テスト
  12. image 成清 聡馬 Soma Narikiyo プロダクト本部 SRE部 Productivityグループ • 2022年

    4月入社 • GitLab 周りの業務がメイン • 元々バックエンドエンジニア • Python と統計がマイブーム • イベント初登壇 自己紹介 © kaonavi, inc. 53
  13. カオナビにおける CI/CD 環境 © kaonavi, inc. 54 GitLab Runner GitLab

    Runner GitLab Runner • GitLab CI/CD でパイプライ ンのジョブを実行するために 必要なアプリケーション。 • 複数のインスタンスに GitLab Runner をインス トールしている。 • インスタンスはオートスケー ルせず、台数固定で運用。 GitLab Runner EC2
  14. GitLab CI/CD でジョブを実行する © kaonavi, inc. 55 worker worker worker

    GitLab Runner ジョブを実行するプロセス worker worker 数には上限値を 設定している runner GitLab とやりとりしたり、 worker を生成するエー ジェント runner 1つのインスタンスで複 数のジョブが実行される
  15. 運用していく中で起きうる問題 © kaonavi, inc. 57 運用上の問題 ジョブ実行時間の 上昇 ジョブ待ち時間の 上昇

    失敗数の増加 • OOM Killer など • worker に空きがない • リソースの奪い合いによる、CPU 実行待ち、Disk IO 待ち
  16. アラートの原因は Jest ジョブ © kaonavi, inc. 60 [deploy@prod-gitlab-runner01-a ~]$ ps

    aux --sort -%mem | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 13973 94.1 33.9 3153388 2654300 ? Dl 22:11 1:20 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13982 105 26.7 2585628 2086332 ? Rl 22:11 1:29 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13980 95.3 25.7 2513548 2014704 ? Rl 22:11 1:21 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13913 0.3 0.7 785948 59652 ? Sl 22:11 0:00 /usr/local/bin/node /usr/local/bin/yarn jest --testPathIgnorePatterns=__integration__ root 13900 0.2 0.7 785920 59616 ? Sl 22:11 0:00 node /usr/local/bin/yarn run test:ci deploy 14274 0.2 0.7 851228 58940 pts/1 Sl+ 22:12 0:00 docker volume rm runner-c8i7xc19-project-241-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8 root 13935 1.2 0.7 674036 56752 ? Sl 22:11 0:01 /usr/local/bin/node /builds/node_modules/.bin/jest --testPathIgnorePatterns=__integration__ root 9447 3.9 0.6 1949856 52296 ? Ssl 20:21 4:26 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit nofile=1024:4096 root 9879 0.3 0.2 152228 23344 ? Ssl 20:21 0:23 gitlab-runner run --user=gitlab-runner --working-directory=/home/gitlab-runner • Jest ◦ JavaScript テスティングフレームワーク。フロントエンドのコード をテストするために使用。 • Jest ジョブがメモリを使いすぎているようだ   Jest: https://jestjs.io/ja/
  17. 改善の前に・・・ © kaonavi, inc. 63 • 今まで CI/CD に関して、継続的にデータを取得してこなかった •

    この件をきっかけに、暫定対応しつつ、分析・モニタリングできる状 態をつくっていこう • データをもとに改善しよう • 断片的なデータしかなかったので、感覚・経験で運用してきた ◦ 「なんとなく」ジョブの実行時間が遅くなってきた ◦ 「なんとなく」ジョブが詰まっていそう
  18. 仮説 計画 データ 分析 結論 • 解決したい問 題を整理 • 仮説を立てる

    • 結論までの道 筋を作る • どのようなデー タが手に入れ ばいいか考え る • 計画に沿って データの収集・ 加工 • データを比較 する • 分析をまとめ 結論をだす 分析のプロセス 参考:安宅和人 .『イシューからはじめよ』 . 英治出版 . 2010
  19. 「パイプライン実行時間が延びている」、とは? © kaonavi, inc. 67 パイプライン実行時 間が延びている ジョブの実行時間 が延びている ジョブの待ち時間が

    延びている • 実行するコードが増えている • ハードウェアのリソース不足 • ジョブ数が増えている • ジョブの実行時間が延びている リソースを大量に消費するジョブがありパイプライン実行 時間に影響を与えている
  20. どうやってデータ収集する? © kaonavi, inc. 69 データ インスタンスのリソー ス状況 ジョブ実行時間 ジョブ待ち時間

    • Mackerel で確認 • GitLab の REST API を使ってデータ取得 • Python と pandas を 使ってデータ集計
  21. データ収集の段階で気をつけたこと © kaonavi, inc. 70 • データを集めすぎない ◦ 分析を始めるとあれもこれも見たくなり、データを集めすぎてしまう ◦

    仮説を裏付けるデータがとれなくても、まずは分析の PDCA を 1 周させる • 必要以上に作り込まない ◦ コードが多少汚くても目的のデータが取得できれば OK • まずは小さく始める ◦ スプレッドシートにデータをためる ◦ データの可視化は、スプレッドシートのグラフ機能
  22. Jest 対応策 ハードウェアで解 決 ソフトウェアで解 決 打ち手を考える Jest の設定を変 更する

    コードを書く 新しくインスタン スを追加する 既存のインスタン スで対応する 費用対効果が 高いのはどれ か検討する
  23. 分析結果をもとに改善策を提案 © kaonavi, inc. 77 改善提案 現状 原因 打ち手 費用対効果

    • パイプライン実行時間がxx分 • リリース作業に影響がでている • Jest ジョブがメモリを大量に使用している • Jest は専用のインスタンスで実行する • インスタンス追加でxx円/月発生 • パイプライン実行時間がxx分改善、 待ち時間がxx分改善
  24. ダッシュボードの作成 © kaonavi, inc. 81 • Looker Studio でダッシュボード作成 •

    ジョブの実行時間、待ち時間を一目で分かるようにする
  25. 身近な人を頼る © kaonavi, inc. 89 SRE部 サービス開発部 サービス開発部 なら何か知ってる かな?

    EM 改善できそう だぞ リードエンジニア会で 議題にあげとくわ UT の改善したいね ん
  26. 仲間を増やして、次の改善活動につなげる © kaonavi, inc. 91 速度改善あざっす もっと速度改善した いねん 改善案はいっぱいあ る

    短期で改善できるもの と長期的に改善してい くものがあるで • 期間限定で、Slack に速度改善チャンネルを開設。短期で改善 できるものに取り組む • (部署問わず)速度改善に興味ある人がチャンネルに参加 改善してくれた人
  27. これまでの振り返り © kaonavi, inc. 93 計測 ツール コラボレーション • 状態の把握

    • 仮説の検証 • 施策の効果測定 • 小さく始める • 作り込まない • 部署の垣根を越える • できる人の力を借りる 改善を進めた要素
  28. 今後の展望 © kaonavi, inc. 95 • GitLab Runner のオートスケール ◦

    CTO 室と連携して対応 ◦ 費用対効果の高い構成を目指す • テストコードの改善 ◦ Flaky Test の修正 ◦ 不要なテストコードの削除