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

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

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

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

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

---

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

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

---

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

・速度改善のためにデータ集計・可視化する
・他部署を巻き込んだ速度改善

yamauchi_kaonavi

April 18, 2023
Tweet

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. ▶テストの使いづらさ の解消
    ・特定の環境・データに対してしか実行できない
    使われなくなったE2Eテスト
    © kaonavi, inc. 23

    View full-size slide

  24. ▶テストの使いづらさ の解消
    ・特定の環境・データに対してしか実行できない
     → 実行環境をCIの中に閉じ込めよう!
    使われなくなったE2Eテスト
    © kaonavi, inc. 24

    View full-size slide

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

    View full-size slide

  26. GitLab CI/CDでは、設定したDockerイメージをジョブの中で使用できる機能がある。
    使われなくなったE2Eテスト
    © kaonavi, inc. 26
    E2Eテスト実行環境をCIに閉じ込める とは?
    GitLab Runner

    View full-size slide

  27. 今回はそこに docker in docker を指定。
    docker in dockerの中にローカル環境のコンテナ + testcafeコンテナを置いた。
    使われなくなったE2Eテスト
    © kaonavi, inc. 27
    E2Eテスト実行環境をCIに閉じ込める とは?
    → 「特定の環境に対してしか実行できない」使いづらさを解消
    GitLab Runner
    docker in docker
    web mysql testcafe

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. 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テスト用のブラン
    チを作成

    View full-size slide

  38. 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テスト用ブラン
    チにマージ

    View full-size slide

  39. 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テスト用のブラン
    チを作成

    View full-size slide

  40. 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テスト用のブラン
    チを作成

    View full-size slide

  41. 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
    直前テスト

    View full-size slide

  42. どのように運用に乗せる?
    ◆ テストが落ちていたら開発者に通知し、修正を求める
    ・いくらテストを実行しても、開発者に知らせて修正を促せなければ意味がない
    運用への組み込み
    © kaonavi, inc. 42

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  51. 学び
    ◇運用してみて初めてわかる不便さ・欠陥もある
    ・裏を返せば、それらを解消していけばさらに運用が根付いていく
    GitLab CI/CD 自動テストのさらなる広がり
    © kaonavi, inc. 51

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  60. アラートの原因は 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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  65. 仮説 計画 データ 分析 結論
    ● 解決したい問
    題を整理
    ● 仮説を立てる
    ● 結論までの道
    筋を作る
    ● どのようなデー
    タが手に入れ
    ばいいか考え

    ● 計画に沿って
    データの収集・
    加工
    ● データを比較
    する
    ● 分析をまとめ
    結論をだす
    分析のプロセス
    参考:安宅和人 .『イシューからはじめよ』
    . 英治出版 . 2010

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  68. どういう流れで結論にもっていくか?
    リソースを大量に消
    費するジョブがある
    リソース不足によっ
    て、ジョブの実行時間
    が全体的に延びてい

    ジョブの実行時間が長
    くなっているので、ジョ
    ブの待ち時間も延びて
    いる
    パイプライン実行時間
    が延びている

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  71. 実際のデータ

    View full-size slide

  72. メモリ使用状況
    © kaonavi, inc. 72

    View full-size slide

  73. メモリ使用状況

    View full-size slide

  74. Jest 以外のジョブにも影響がでてる
    © kaonavi, inc. 74

    View full-size slide

  75. ジョブの待ち時間も上昇している
    © kaonavi, inc. 75

    View full-size slide

  76. Jest 対応策
    ハードウェアで解

    ソフトウェアで解

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

    View full-size slide

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

    View full-size slide

  78. 効果測定
    © kaonavi, inc. 78

    View full-size slide

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

    View full-size slide

  80. 問題にいち早く気づく方法はないか?

    View full-size slide

  81. ダッシュボードの作成
    © kaonavi, inc. 81
    ● Looker Studio でダッシュボード作成
    ● ジョブの実行時間、待ち時間を一目で分かるようにする

    View full-size slide

  82. 分析のプロセス
    © kaonavi, inc. 82
    仮説
    計画
    データ
    分析
    結論
    ● ダッシュボード
    問題

    View full-size slide

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

    View full-size slide

  84. まだまだ改善できることはある
    © kaonavi, inc. 84
    ● ダッシュボードの作成によって、ジョブの状態が把握しやすくなった

    View full-size slide

  85. まだまだ改善できることはある
    © kaonavi, inc. 85
    ● unit_test_4 の実行時間が改善できると、インパクトが大きそうだ
    ● どうやって改善しよう・・・

    View full-size slide

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

    View full-size slide

  87. 50%短縮!!!
    © kaonavi, inc. 87
    ● unit_test_4 の実行時間が、50%短縮
    ● 速度改善してくれたのは、別部署のエンジニア

    View full-size slide

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

    View full-size slide

  89. 身近な人を頼る
    © kaonavi, inc. 89
    SRE部
    サービス開発部
    サービス開発部
    なら何か知ってる
    かな?
    EM
    改善できそう
    だぞ
    リードエンジニア会で
    議題にあげとくわ UT の改善したいね

    View full-size slide

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

    View full-size slide

  91. 仲間を増やして、次の改善活動につなげる
    © kaonavi, inc. 91
    速度改善あざっす
    もっと速度改善した
    いねん
    改善案はいっぱいあ

    短期で改善できるもの
    と長期的に改善してい
    くものがあるで
    ● 期間限定で、Slack に速度改善チャンネルを開設。短期で改善
    できるものに取り組む
    ● (部署問わず)速度改善に興味ある人がチャンネルに参加
    改善してくれた人

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  94. 今後の展望
    © kaonavi, inc. 94

    View full-size slide

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

    View full-size slide

  96. 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 full-size slide