カオナビのDevOps実践

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の１つ
13. © kaonavi Inc. 13 社内Webアプリの構築 13 Redmineでチケット起票 エンジニアがチケットを確認して作業 本番環境 作業したらチケット更新して返却 営業担当
14. © kaonavi Inc. 14 社内Webアプリの構築 対応 - エンジニアが本番環境にログインして環境構築や破棄を しないで済むように社内Webアプリを構築 - アプリの利用者は営業担当 - 契約内容をSalesforce側から引っ張ってくることで 入力作業をなくす - 営業のメンバーが契約内容を確認して ボタン１つで環境構築ができるように
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. ご清聴ありがとうございました