カオナビのCI/CDにおける自動テスト運用と速度改善

カオナビのCI/CDにおける
自動テスト運用と速度改善
© kaonavi, inc.

View Slide

山内翼
DevOpsエンジニア
登壇者紹介
© kaonavi, inc. 2
成清聡馬
DevOpsエンジニア
image

View Slide

タレントマネジメントシステム「カオナビ」
社員の個性・才能を発掘し
戦略人事を加速させるタレントマネジメントシステム
© kaonavi, inc. 3

View Slide

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

View Slide

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

View Slide

カオナビのCI/CDにおける
自動テストの変遷
2023.4.18 | 株式会社カオナビ　山内翼
© kaonavi, inc.

View Slide

山内翼 Tsubasa Yamauchi
プロダクト本部 SRE部 Productivityグループ
・DevOpsエンジニア
・青森県出身
・仙台でPHPエンジニア → CI/CDに興味を持ち始める
・現在はテスト環境構築などの運用業務をしながら
　CI/CDを始めとした自動化などの改善活動をしている
自己紹介
© kaonavi, inc. 7

View Slide

Productivityグループについて
© kaonavi, inc. 8
カオナビのProductivityグループは、
社内の生産性向上を目的とした部署です。
・エンジニアの生産性を向上するために、運用業務を肩代わりしたり自動化したり
　→ 例えばエンジニアが必要なテスト環境の作成を代行し、自動化
・もちろんエンジニア以外の生産性向上も目指します
　→最近はSalesforceへのデータ登録の自動化など

View Slide

INDEX
1 . カオナビのCI/CDの概要（2020）
2 .使われなかったE2Eテスト
3 .リリース前検知をするために
4 .運用への組み込み
© kaonavi, inc. 9
5 .GitLab CI/CD 自動テストのさらなる広がり

View Slide

カオナビのCI/CDの概要（2020）
© kaonavi, inc. 10

View Slide

GitLabを使用
・オンプレミス環境で GitLabを運用
・GitLabに付属するGitLab CI/CDという機能を
　使用して自動テストなどを実行
© kaonavi, inc. 11

View Slide

PHPUnitなど、基本的な自動テストはCI/CDで実行可能
・ユニットテストを書く文化は根付いており、
　GitLab CI/CDでコミットごとに自動実行
・カバレッジ約75％（当時）
・ユニットテストでは検知しきれない不具合も。。
© kaonavi, inc. 12

View Slide

ユニットテストでは検知しきれない不具合、例えば
・非ログインユーザーもアクセスするページで、
　ログイン前提のAPIが実行されてしまい認証エラー
・ブラウザのローカルストレージで保存していた内容が、
　別タブで参照できなくなってしまい、正しく表示されない。
© kaonavi, inc. 13

View Slide

ユニットテストとは別のテストが求められる
・「昨日の不具合、最近話題の E2Eテストがあれば検知できたんじゃ
　ないですか？」
・「よし、じゃあカオナビでも E2Eテストを実装しよう」
・「あの、実はE2Eテストはすでにあるんですけど。。」
© kaonavi, inc. 14

View Slide

使われなかったE2Eテスト
© kaonavi, inc. 15

View Slide

昔々あるところに、
E2Eテストがありました。
・QC（品質管理）チームがテスト実施コスト軽減のため
　testcafeを使用したE2Eテストを作成
・さらに運用しやすいよう、 GitLab CI/CDから
　ボタンひとつで実行できるように整備されていた
使われなかったE2Eテスト
© kaonavi, inc. 16

View Slide

このE2Eテストは使われなくなっていきました。。
© kaonavi, inc. 17

View Slide

なぜ使われなくなってしまったのか
▶ テストへの信頼低下
▶ テストの使いづらさ
使われなくなったE2Eテスト
© kaonavi, inc. 18

View Slide

・エンジニア不在で作成されたテストなので、ノーコードで作成
　→ Flaky Test（不安定なテスト）が大量に発生
　　→ カオナビのつくりとノーコードによるテストの相性が悪かった
　　→ 非エンジニアによる対応が難しい状態に
・機能追加によってテストが簡単に壊れてしまう
▶ テストへの信頼低下
© kaonavi, inc. 19

View Slide

・特定の環境・データに対してしか実行できない
　→ E2Eテストがデータに依存しており、専用の環境があった
　　→ その環境が誰にも使われていないことを確認してからテストを実行
　　→ テスト実施後にデータを実施前の状態に戻す「お掃除処理」があった
　→ E2Eテストが途中でコケるとデータが壊れる
▶ テストの使いづらさ
© kaonavi, inc. 20

View Slide

このE2Eテストを「使われるテスト」にしよう
© kaonavi, inc. 21

View Slide

▶テストへの信頼低下の解消
・エンジニアが専任し、ひたすら不安定テスト潰しをしていく
・画面操作をライブラリ化することにより、機能変更に強いコードへ
　→ これについては昨年の DevOpsDaysでも発表しました
© kaonavi, inc. 22

View Slide

▶テストの使いづらさの解消
© kaonavi, inc. 23

View Slide

▶テストの使いづらさの解消
　→ 実行環境をCIの中に閉じ込めよう！
© kaonavi, inc. 24

View Slide

© kaonavi, inc. 25
E2Eテスト実行環境をCIに閉じ込める　とは？
CI実行のたびにCI環境の中にローカル環境を立ち上げ、
そこに対してE2Eテストを実施するようにした。
GitLab Runner
E2Eテストを実行

View Slide

GitLab CI/CDでは、設定したDockerイメージをジョブの中で使用できる機能がある。
© kaonavi, inc. 26
GitLab Runner

View Slide

今回はそこに docker in docker を指定。
docker in dockerの中にローカル環境のコンテナ + testcafeコンテナを置いた。
© kaonavi, inc. 27
→ 「特定の環境に対してしか実行できない」使いづらさを解消
GitLab Runner
docker in docker
web mysql testcafe

View Slide

E2Eテスト実行用のdumpデータを用意しておき、
環境構築時に流し込む。
© kaonavi, inc. 28
→ 「テスト実行後にデータを元に戻さなければならない」使いづらさを解消
GitLab Runner
docker in docker
web mysql testcafe
dump
E2E
環境

View Slide

結果
・やっぱりそんなに使われない
・一度信頼を失ったテストはなかなか根付かない。。
© kaonavi, inc. 29
→ 使われないならこっちから運用に乗せていこう

View Slide

運用への組み込み
© kaonavi, inc. 30

View Slide

どのように運用に乗せる？
◆ 開発者が意識しなくてもテストが実行されている
◆ テストが落ちていたら開発者に通知し、修正を求める
© kaonavi, inc. 31

View Slide

◆ 開発者が意識しなくてもテストが実行されている
・そもそも開発者が意識しないと実行されないから運用に乗らない
・ただし、E2Eテストは実行時間がかかるので無闇に実行はできない
© kaonavi, inc. 32
→ 毎日１回、リリースを控えた機能に対して自動実行するようにしよう。

View Slide

E2Eテストの実行タイミング
・日次でリリース予定のチケットをまとめてマージしたブランチを作成し、
　そのブランチに対してE2Eテストを実行するようにした
© kaonavi, inc. 33

View Slide

master
1月1日 1月2日 1月3日
feature/A
feature/B
feature/C
1/1 リリース予定

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
毎日、masterブランチか
らE2Eテスト用のブラン
チを作成

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
明日リリース予定のブラ
ンチをE2Eテスト用ブラン
チにマージ
チを作成

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
直前テスト
E2Eテストを自動実行
（直前テスト）
チにマージ
チを作成

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
直前テスト
ver1.0.1
テスト失敗時は原因特定。
必要に応じてリリース中止。
チを作成
チにマージ

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
直前テスト
ver1.0.1
draft/20230102
チにマージ
チを作成

View Slide

master
draft/20230101
feature/A
feature/B
feature/C
直前テスト
ver1.0.1
draft/20230102
直前テスト
チにマージ
チを作成

View Slide

master
draft/20230101
チを作成
feature/A
feature/B
feature/C
チにマージ
直前テスト
ver1.0.1
draft/20230102
ver1.0.2 ver1.0.3
直前テスト

View Slide

◆ テストが落ちていたら開発者に通知し、修正を求める
・いくらテストを実行しても、開発者に知らせて修正を促せなければ意味がない
© kaonavi, inc. 42

View Slide

通知
・成功／失敗をみんなが見る Slackに通知
・失敗時は目を引くような通知にする
・失敗時にちゃんと騒ぐことで、
　テストの結果にメンバーを巻き込む
© kaonavi, inc. 43

View Slide

通知
・失敗時だけでなく成功時も通知すること
　で、詳しく知らない人にも「毎日何かのテ
　ストをやってるんだな」と思ってもらうの
　が重要
© kaonavi, inc. 44

View Slide

結果
・運用に乗せることに成功
・「テストを使ってもらう」のではなく、「テストが使われている」状態にする
　ことができた
© kaonavi, inc. 45

View Slide

GitLab CI/CD 自動テストのさらなる広がり
© kaonavi, inc. 46

View Slide

E2Eテスト実装後の展開
・「前日ではなく、もっと早めに不具合を検知したい」との声
　→ 直前テストに加え、リリース予定に組み込まれた時点で実施するテストを追加
・「明日リリース予定のブランチ」を手動でラベル付けしていたのが面倒、との声
　→ラベル付けを自動化
運用して初めて分かる不便や、新たに出てくる要望に合わせて改善をしていくフェーズへ
© kaonavi, inc. 47
→ 運用が根付いていっている！

View Slide

まとめ
・使われないテストに対して、下記二点の改善に取り組んだ
　　・使いづらさ解消
　　・信頼性回復
・それでも使われないテストは、積極的に運用に乗せてメンバーを巻き込むことで、
　「テストが使われている状態」に持っていくことが出来た
© kaonavi, inc. 48

View Slide

学び
◇ 便利な自動テストの仕組みを作っただけでは、なかなか使ってもらえない
・これは自動化全般にもいえる
© kaonavi, inc. 49

View Slide

学び
◇こちらから新しい仕組みを運用に乗せてしまう「攻めの運用」もときには重要
・このとき、なるべく使う側の手間になることは避ける
・使う側が面倒なイメージを持ってしまったら仕組みは廃れていく
© kaonavi, inc. 50

View Slide

学び
◇運用してみて初めてわかる不便さ・欠陥もある
・裏を返せば、それらを解消していけばさらに運用が根付いていく
© kaonavi, inc. 51

View Slide

カオナビの CI/CD 速度改善事例

View Slide

image
成清聡馬 Soma Narikiyo
プロダクト本部 SRE部 Productivityグループ
● 2022年 4月入社
● GitLab 周りの業務がメイン
● 元々バックエンドエンジニア
● Python と統計がマイブーム
● イベント初登壇
自己紹介
© kaonavi, inc. 53

View Slide

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

View Slide

GitLab CI/CD でジョブを実行する
© kaonavi, inc. 55
worker
worker
worker
GitLab Runner
ジョブを実行するプロセス
worker
worker 数には上限値を
設定している
runner
GitLab とやりとりしたり、
worker を生成するエー
ジェント
runner
1つのインスタンスで複
数のジョブが実行される

View Slide

パイプラインの説明
● ステージごとにジョブが存在する
● 基本的には、ステージ内のジョブがすべ
て終わらないと次のステージのジョブが
実行されない。

View Slide

運用していく中で起きうる問題
© kaonavi, inc. 57
運用上の問題
ジョブ実行時間の
上昇
ジョブ待ち時間の
上昇
失敗数の増加
● OOM Killer など
● worker に空きがない
● リソースの奪い合いによる、CPU
実行待ち、Disk IO 待ち

View Slide

問題は望んでなくてもやってくる

View Slide

ことのはじまり
© kaonavi, inc. 59
● アラートが頻繁に Slack に通知されるようになった

View Slide

アラートの原因は Jest ジョブ
© kaonavi, inc. 60
[[email protected] ~]$ 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/

View Slide

パイプライン実行時間が上昇してくる
© kaonavi, inc. 61

View Slide

マネージャーに急かされる
© kaonavi, inc. 62
パイプライン改善が急務になる！

View Slide

改善の前に・・・
© kaonavi, inc. 63
● 今まで CI/CD に関して、継続的にデータを取得してこなかった
● この件をきっかけに、暫定対応しつつ、分析・モニタリングできる状
態をつくっていこう
● データをもとに改善しよう
● 断片的なデータしかなかったので、感覚・経験で運用してきた
○ 「なんとなく」ジョブの実行時間が遅くなってきた
○ 「なんとなく」ジョブが詰まっていそう

View Slide

分析って？
© kaonavi, inc. 64
仮説
計画
データ
分析
結論

View Slide

仮説計画データ分析結論
● 解決したい問
題を整理
● 仮説を立てる
● 結論までの道
筋を作る
● どのようなデー
タが手に入れ
ばいいか考え
る
● 計画に沿って
データの収集・
加工
● データを比較
する
● 分析をまとめ
結論をだす
分析のプロセス
参考：安宅和人 .『イシューからはじめよ』
. 英治出版 . 2010

View Slide

今回のケースにあてはめる

View Slide

「パイプライン実行時間が延びている」、とは？
© kaonavi, inc. 67
パイプライン実行時
間が延びている
ジョブの実行時間
が延びている
ジョブの待ち時間が
延びている
● 実行するコードが増えている
● ハードウェアのリソース不足
● ジョブ数が増えている
● ジョブの実行時間が延びている
リソースを大量に消費するジョブがありパイプライン実行
時間に影響を与えている

View Slide

どういう流れで結論にもっていくか？
リソースを大量に消
費するジョブがある
リソース不足によっ
て、ジョブの実行時間
が全体的に延びてい
る
ジョブの実行時間が長
くなっているので、ジョ
ブの待ち時間も延びて
いる
パイプライン実行時間
が延びている

View Slide

どうやってデータ収集する？
© kaonavi, inc. 69
データ
インスタンスのリソー
ス状況
ジョブ実行時間
ジョブ待ち時間
● Mackerel で確認
● GitLab の REST API
を使ってデータ取得
● Python と pandas を
使ってデータ集計

View Slide

データ収集の段階で気をつけたこと
© kaonavi, inc. 70
● データを集めすぎない
○ 分析を始めるとあれもこれも見たくなり、データを集めすぎてしまう
○ 仮説を裏付けるデータがとれなくても、まずは分析の PDCA を 1 周させる
● 必要以上に作り込まない
○ コードが多少汚くても目的のデータが取得できれば OK
● まずは小さく始める
○ スプレッドシートにデータをためる
○ データの可視化は、スプレッドシートのグラフ機能

View Slide

実際のデータ

View Slide

メモリ使用状況

View Slide

Jest 対応策
ハードウェアで解
決
ソフトウェアで解
決
打ち手を考える
Jest の設定を変
更する
コードを書く
新しくインスタン
スを追加する
既存のインスタン
スで対応する
費用対効果が
高いのはどれ
か検討する

View Slide

分析結果をもとに改善策を提案
© kaonavi, inc. 77
改善提案
現状
原因
打ち手
費用対効果
● パイプライン実行時間がxx分
● リリース作業に影響がでている
● Jest ジョブがメモリを大量に使用している
● Jest は専用のインスタンスで実行する
● インスタンス追加でxx円/月発生
● パイプライン実行時間がxx分改善、
待ち時間がxx分改善

View Slide

パイプラインの実行時間は減少しました、めでたし

View Slide

問題にいち早く気づく方法はないか？

View Slide

パイプラインの問題は解決、最低限の分析もできるようになった

View Slide

突然、協力者があらわれる

View Slide

なぜ別部署のエンジニアが改善してくれたのか？

View Slide

せっかく速度改善してくれたので、さらなる改善を目指す

View Slide

仲間を増やして、次の改善活動につなげる
© kaonavi, inc. 91
速度改善あざっす
もっと速度改善した
いねん
改善案はいっぱいあ
る
短期で改善できるもの
と長期的に改善してい
くものがあるで
● 期間限定で、Slack に速度改善チャンネルを開設。短期で改善
できるものに取り組む
● （部署問わず）速度改善に興味ある人がチャンネルに参加
改善してくれた人

View Slide

パイプライン実行時間
84% 短縮

View Slide

これまでの振り返り
© kaonavi, inc. 93
計測
ツール
コラボレーション
● 状態の把握
● 仮説の検証
● 施策の効果測定
● 小さく始める
● 作り込まない
● 部署の垣根を越える
● できる人の力を借りる
改善を進めた要素

View Slide

今後の展望
© kaonavi, inc. 95
● GitLab Runner のオートスケール
○ CTO 室と連携して対応
○ 費用対効果の高い構成を目指す
● テストコードの改善
○ Flaky Test の修正
○ 不要なテストコードの削除

View Slide

DevOpsエンジニアを積極採用中！
▼DevOpsエンジニア選考エントリー
https://hrmos.co/pages/kaonavi/jobs/0000246
▼その他求人エントリー
https://corp.kaonavi.jp/recruit/list/?j=engineer
▼カジュアル面談エントリー
https://hrmos.co/pages/kaonavi/jobs/casual21
▼DevOpsエンジニアとして働くメンバーの紹介記事
https://vivivi.kaonavi.jp/articles/iwahara-masaki-220316/
https://vivivi.kaonavi.jp/articles/kushida-yosuke-220920/
https://vivivi.kaonavi.jp/articles/miyashita-hiroyuki-221013/

View Slide

カオナビのCI/CDにおける自動テスト運用と速度改善

カオナビのCI/CDにおける自動テスト運用と速度改善

yamauchi_kaonavi

Other Decks in Programming

Featured

Transcript