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

カオナビのDevOps実践

 カオナビのDevOps実践

435eba9fb75cb03779eedd169974fd97?s=128

Yoshiyuki Ishikawa

April 20, 2022
Tweet

Other Decks in Technology

Transcript

  1. © kaonavi Inc. カオナビのDevOps実践 〜運用自動化・テスト自動化の秘訣〜

  2. © kaonavi Inc. 2 登壇者紹介 石川 善幸
 グループマネージャー
 櫛田 陽介


    ProductivityLeadエンジニア 
 棚橋 敬
 グループマネージャー

  3. • 石川 善幸(いしかわ よしゆき) • 所属 プロダクト本部 SRE部 ProductivityG マネージャー

    • 担当業務 開発チームにおける生産性の向上支援 • 好きなもの 猫、日本酒 自己紹介
  4. © kaonavi Inc. 4 会社概要

  5. © kaonavi Inc. 5 組織体制

  6. © kaonavi Inc. 6 組織体制

  7. © kaonavi Inc. 7 このセッションでお話すること • 定常業務の自動化
 • E2Eテスト開発


  8. 定常業務の自動化

  9. • 棚橋 敬(たなはし けい) • 所属 プロダクト本部 オペレーションG マネージャー • 担当業務

    本番環境に関する運用業務全般やディレクション • 好きなもの 銭湯、パン、クラフトコーラ 自己紹介
  10. 10 社内Webアプリの構築 © kaonavi Inc.

  11. © kaonavi Inc. 11 社内Webアプリの構築 背景・課題 - カオナビではお客様毎の環境をセットアップするために 本番環境にログインしてから都度シェルを実行 -

    お客様の環境を破棄する場合も本番環境に ログインしてから都度シェルを実行 - プラン変更やオプション変更をするときも都度シェルを実行
  12. © kaonavi Inc. 12 社内Webアプリの構築 背景・課題 - スケールしなくなってくる - 作業・手続きが増えてくる

    - 発生する繰り返し作業... - 利用企業数は重要なKPIの1つ
  13. © kaonavi Inc. 13 社内Webアプリの構築 13 Redmineでチケット起票 エンジニアがチケットを確認して作業 本番環境 作業したらチケット更新して返却

    営業担当
  14. © kaonavi Inc. 14 社内Webアプリの構築 対応 - エンジニアが本番環境にログインして環境構築や破棄を しないで済むように社内Webアプリを構築 -

    アプリの利用者は営業担当 - 契約内容をSalesforce側から引っ張ってくることで 入力作業をなくす - 営業のメンバーが契約内容を確認して ボタン1つで環境構築ができるように
  15. © kaonavi Inc. 15 社内Webアプリの構築 15 Redmineの起票とエンジニアの手動作業がなくなった

  16. © kaonavi Inc. 16 社内Webアプリの構築 作業コストが改善できた  - もともとSalesforce側には契約情報があるため、 営業担当がRedmineの起票への転記作業がなくなった -

    起票してからエンジニアがチケットを 確認するまでのタイムラグもなくなった - エンジニアが本番環境にログインして シェルを実行する必要がなくなった - マルチテナントに対する考慮をサービス側に もたせることができた
  17. © kaonavi Inc. 17 社内Webアプリの構築 今後の展望  - 運用業務を社内サービス化していく余地はまだまだたくさんある - 現行でも他にも機能がある

    - 調査時のログ取得機能(開発者向け) - 調査時のdumpファイル取得機能(開発者向け) - まずは既存の定常業務のサービス化 - 作業者がミスをしないようなシステムを心がける - 目的は効率化・業務改善であることを忘れない
  18. 18 リリース作業の効率化 © kaonavi Inc.

  19. © kaonavi Inc. 19 リリース作業の効率化 背景・課題 - 日々のリリース作業を本番環境にアクセスしてシェルで実行 - GitLab側でリリースするブランチをマスターにマージしてタグ付け

    - ビルド用のシェルを実行 - リリース用のシェルを実行
  20. © kaonavi Inc. 20 リリース作業の効率化 背景・課題 - リリース作業そのものの手作業が多い - ステージング環境用にビルド・リリースのシェルを実行

    - 本番環境用にビルド・リリースのシェルを実行 - リリース作業担当者が作業の進み具合をSlackに共有 - 属人化...
  21. © kaonavi Inc. 21 リリース作業の効率化

  22. © kaonavi Inc. 22 リリース作業の効率化 対応 - シェルをCode Build /

    Code Deployに移植して、CodePipelineを使ってリリース をできるように - GitLab側のジョブでs3にソースをアップロードすることがトリガー - パイプラインの進捗状況をSlackへ通知
  23. © kaonavi Inc. 23 リリース作業の効率化 主に作業工程が削減された  - GitLab側でのタグ付けのみでステージングと本番へのデプロイが可能に - 通知による可視化・作業待ち時間の短縮

    - 全体の作業時間が計測しやすくなったことで リリースの計画を立てやすくなった
  24. © kaonavi Inc. 24 リリース作業の効率化 今後の展望 - いつでもリリース作業ができる状況であることを目指す - リリース作業全体の効率化を目指す

    - Slackのワークフローとの連携 - 待ち時間をなくす
  25. E2Eテスト開発

  26. • 櫛田 陽介(くしだ ようすけ) • 所属 プロダクト本部 ProductivityG Tech Lead

    • 担当業務 E2Eテスト開発全般 テスト設計、コーディング、レビュー、ツール導入、 メンバのサポート&育成 • 甘党、ウクレレ弾き 自己紹介
  27. © kaonavi Inc. 27 E2Eテスト導入の背景 品質維持の一環として(今回はこちら)  ・リバートが増えてきた  ・広範囲のテストをしたい、それには自動化が必要だった アジャイル開発の一環として  ・アジャイル開発をするチームも増えてきた

     ・アジャイルテストもやってみたい
  28. © kaonavi Inc. 28 技術スタック gitlab-ci

  29. © kaonavi Inc. 29 戦略 メインとする大きな2軸 1. 既存テスト(後ほど紹介)の安定化、メンテナンス 2. 広く浅いテストの新規作成

    その他、メインではないものは都度検討 ・インシデント再発防止のテスト ・手動ではつらいテスト
  30. © kaonavi Inc. 30 1. 引き継いだコードの安定化、メンテナンス 巻き取り、運用体制を作る ・59/159 が不安定で動作しない ・環境依存の排除、リファクタリング

    ・CI環境整備  ・インスタントなdocker環境 ・リリース物に対して日次でテストを流せるように  ・リリースフロー、パイプライン整備 ・QA組織の非プログラマが作っていた E2Eテストコードがあった ・メンテできる人間が少なく、手が回らない状態になっていた
  31. © kaonavi Inc. 31 2. 広く浅いテストを新規作成 ・機能の深掘りはせず、画面上の主要な要素がちゃんと表示されているか  ・全画面をまずはカバー ・シナリオを作りつつ画面の挙動を調査して、画面の操作をライブラリ化  ・別のシナリオでも流用できるように

     ・引き継いだコードにも徐々にライブラリを適用 ・テストデータ設計をしながら進めていった
  32. © kaonavi Inc. 32 発生した課題と対応 どんな課題が出て、どういう対応をしたのか

  33. © kaonavi Inc. 33 課題: 環境依存 課題: ・特定の共用環境でしか動かない ・複数人が同時に実行できない・開発できない ・そこにあるデータが正、壊れたら戻せない

    対応: ・ハードコードから環境変数化 ・ローカル開発環境整備 ・テストデータを抽出、初期化可能に ・誰でもいつでも開発・実行ができる状態になった
  34. © kaonavi Inc. 34 課題: リリース前にテストが実行されていない 課題: ・リリース後、特定環境で日次実行されていた  ・masterブランチを定期的にデプロイ ・リリース前にデグレを検知できていない

    対応: ・リリースフロー、パイプラインを整備 ・リリース物に対して、リリース前に日次実行(夜間)するようにした ・リリース前にバグが検出できる状態になり、安全度が上がった
  35. © kaonavi Inc. 35 課題: 不安定 課題: ・実行するたびに、成功したり失敗したり  ・全体の3割以上 ・乗せてみたはいいものの、毎日赤い

    CI ・ノイズであり、調査コストがかさむ 対応: ・長い目で見ながら地道にテストコードを修正 ・プロダクトの仕様変更や、 CI環境のスペック変動なども成功率に影響する ・現在は月に0~数回程度の発生に収まり、無駄な調査コストを削減できた ・発生ベースで対応
  36. © kaonavi Inc. 36 不安定による失敗数の推移

  37. © kaonavi Inc. 37 課題: 大量にメモリを消費 課題: ・4シナリオの実行に2GB以上消費して、1プロセスに乗らなかった ・解決できずテストスイートが細かく分割されていた  ・テスト結果のマージをする必要があったり煩雑

    対応: ・インスタンスキャッシュ、リファクタリング ・159シナリオが400MB前後で流れ切るように ・速度も改善した ・シンプルな状態、あるべき状態になった
  38. © kaonavi Inc. 38 課題: 大量にメモリを消費 試しに一部を対応すると、全シナリオ通して 2G超になった 最終的には、全シナリオ通して 400MB前後になった

  39. © kaonavi Inc. 39 課題: 同様の修正があちこちで発生 課題: ・不安定の修正も、仕様変更に対する修正も ・画面操作のための(長い)実装がばらけている 対応:

    ・PageObjectモデルを採用、画面操作をライブラリ化  ・修正範囲が狭くなり、より沢山のテストを運用可能になった
  40. © kaonavi Inc. 40 課題: CI環境固有のトラブル 課題: ・ローカル開発環境の仕組みを CI環境上に立てたら、CI環境でだけ発生 ・ファイル書き込み時、一定確率でエラー

    ・dockerの共有ボリュームで、 ファイルシステムのオーナ周りの挙動が違った  ・ホストが windows/mac のローカル開発環境では発生しない  ・ホストが linux のCI環境でだけ発生した 対応: ・オーナを合わせる対応 ・細々とログを仕込みながらトライ&エラーを繰り返して潰した
  41. © kaonavi Inc. 41 課題: データ量が増えて遅くなる 課題: ・テストデータが増えてゆき、初期化処理に時間がかかるようになった  ・RDB、検索エンジン ・全件見るようなシナリオ

    対応: ・思い切ってデータ量を削減、 作成済みのシナリオもデータに追従 ・広く浅いテストについては、 2ページ分程度あればいい ・全件見るようなシナリオは厳選
  42. © kaonavi Inc. 42 課題: 必ず学習コストが発生する 課題: ・みんな初めてのE2Eなので慣れるまで時間がかかる ・メンバー入れ替わりのたびに毎回発生 ・希望者も少ない

    対応: ・オンボードコストを下げる努力  ・ナレッジをひたすらドキュメント化 ・ライブコーディングやペアプロでスキルの均一化 ・テストSaaSでローコードも視野に ...?
  43. © kaonavi Inc. 43 課題(対応中): テスト起動が不安定 課題: ・テストコードが安定してきたらこちらが目立ってきた 対応: ・ひとまず自動リトライ

    ・ログを整備して調査中
  44. © kaonavi Inc. 44 課題(検討中): パイプラインの並列数が不足することがある 課題: ・複数のテスト実行とテスト開発が重なると、並列数が足りず待ちが発生することがある ・このままテスト数を増やしていけばより顕著になっていく 対応:

    ・テスト実行環境のオートスケール?
  45. © kaonavi Inc. 45 効果まとめ 実施前 実施後 テスト実行条件 特定条件を揃える必要あり 誰でもいつでも実行可能

    バグ検出タイミング リリース後 リリース前 不安定起因の失敗数 40前後/月 0~数回/月 メンテナンス 追い付かず 仕様変更に追従しながら拡充できてい る テスト工数 (人間の時間) 6~7時間 0~1時間 その他 潜在バグの検出
  46. © kaonavi Inc. 46 新規作成した「広く浅いテスト」数の推移

  47. © kaonavi Inc. 47 約280シナリオのテストをいつでも実行できる状態になった ・日次のCIジョブ  ・明日のリリース対象  ・直近のリリース対象 ・ほかにも、影響範囲の広い改修をする場合など  ・影響範囲の広い、開発中の

    featureブランチ  ・言語やフレームワークのアップデート  ・M1用のdockerの開発環境での動作確認 人の手はかからない ・裏で、夜中に、流しておくが可能
  48. © kaonavi Inc. 48 プロダクトバグ検出数

  49. © kaonavi Inc. 49 検出されたバグの傾向 ・副産物的なもの  ・ドラッグ操作の始点が変わった  ・jsエラーが発生していた(ユーザに直接影響がない範囲の) ・プロダクト細かい知識がないと、テストケースから漏れやすい機能  ・〇〇の場合だけ表示項目が違う、使う

    APIが違う、フローが違う、など  ・公開〇〇、非公開〇〇、匿名〇〇  ・通常ログイン、特殊ログイン ・他の画面にも影響を与えてしまっていた  ・影響範囲の認識ずれ
  50. © kaonavi Inc. 50 所感と今後 まだまだテストを増やしても運用できそう ・画面操作をライブラリ化したことで、仕様・デザイン変更への対応が楽になった ・不安定発生数を大幅に削減できたので、無駄な調査コストがなくなった ・プロダクトに詳しくないと漏れやすい、見落としやすい機能 ・バグりやすい、複雑な機能

    ・そうでなくても、事業影響が大きい機能 ・手動だと工数がかかる、面倒くさいテスト
  51. まとめ

  52. © kaonavi Inc. 52 まとめ 定常業務の自動化・セルフサービス化で大幅な工数削減 ・ネタはそこら中に転がってる。効率厨の腕の見せ所 ・理想はセルフサービス化 E2Eテストは難産だったが、徐々に成果が出始めた ・課題はあるものの、軌道に乗ってきた

    ・今は価値を高めるフェーズ
  53. ご清聴ありがとうございました