リクルートのデータ組織における カオスエンジニアリングによる 安定運用の取り組み

2023/07/27に、DevelopersSummitで発表した、鶴谷と芳賀の資料です。

Transcript

1. © Recruit Co., Ltd. All Rights Reserved リクルートのデータ組織における カオスエンジニアリングによる 安定運用の取り組み 1 株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室 鶴谷誠文 芳賀宣仁 2023/7/27
2. © Recruit Co., Ltd. All Rights Reserved 所属 株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室 経歴 2015年にリクルートに中途入社。 リクルートIDのデータ基盤の開発やクラウド移行を担当。 その後SUUMOリコメンドシステムの基盤移行や 社内の複数の分析基盤の運営など幅広く担当。 自己紹介 鶴谷 誠文 （つるたに まさふみ） 2
3. © Recruit Co., Ltd. All Rights Reserved 所属 株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室 経歴 2016年にリクルートに新卒入社。データサイエンティス トとしてSUUMOリコメンドシステムで使用される機械 学習モデルの開発を担当。その後、データエンジニアとし てSUUMOリコメンドシステムの開発・運用に従事し、リ アーキテクチャやサービスマネジメントを担当。 自己紹介 芳賀 宣仁 （はが のぶひと） 3
4. © Recruit Co., Ltd. All Rights Reserved アジェンダ 1. リクルートおよびデータ推進室の紹介 2. SUUMOリコメンドシステムの安定運用に向け た取り組み 3. 回復力を高めるための障害対応訓練の取り組み 事例 4
5. © Recruit Co., Ltd. All Rights Reserved 株式会社リクルートについて 5 マッチング＆ソリューションSBU HRテクノロジーSBU 人材派遣SBU 販促領域 人材領域 国内派遣 海外派遣 etc... 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」を実現する
6. © Recruit Co., Ltd. All Rights Reserved リクルートのビジネスモデルについて 6 • リクルートにはユーザーとクライアントという2つのお客様が存在 • 「企業と人（B to C）」 「企業と企業（B to B）」 「人と人（C to C）」のすべての間に立ち、双方にとって最適なマッチン グを図る「場」を提供 ユーザーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」の場を創造する リクルート マッチングプラットフ ォーム クライアントとユーザーを結びつける 対価としてクライアントからフィーを受領 ユーザー クライアント
7. © Recruit Co., Ltd. All Rights Reserved データ推進室について 7 各事業領域のデータ戦略立案・推進を行う領域特化ユニットと 領域横断で支援を行う専門職種のユニットが交差するマトリクス型組織 データテクノロジーユニット DPU 販促1 DSU 販促2 DSU 販促3 DSU 販促4 DSU SaaS DSU アジリティテクノロジー部 より高度な専門性を基に領域・横断の重要案件の支援を行う DPM1部 DPM2部 DTL部 Megagon ATL部 HR DSU 主務組織（領域戦略の実現のための活動に責任を持つ） D3M部(Data Driven Making) データエンジニアリング部 データサイエンス部 採用・育成を含む専門性強化に 責任を持つ
8. © Recruit Co., Ltd. All Rights Reserved SUUMOリコメンドシステムの安定運用に向けた取り組み 8 • SUUMOリコメンドシステムは、SUUMO上でユーザーにお勧めの物件のリコメンデーションを行っている • リコメンドシステム障害に伴うユーザー体験の悪化を防ぐため安定運用を実現する必要があった SUUMOリコメンドシステム リコメンドAPI基盤 お勧め物件 リコメンド バッチ処理基盤 学習済みモデル 物件情報更新、 モデル更新 リアルタイムログ処理基盤 行動ログ収集
9. © Recruit Co., Ltd. All Rights Reserved SUUMOリコメンドシステムの安定運用に向けた取り組み 9 • 安定運用を実現するためには、障害そのものの発生頻度を下げるだけでなく、（いつなんどき）障害が発生した 際にも素早く復旧するケイパビリティを組織として備えることが必要 信頼性 （Reliability） 回復性 （Recoverability） • 障害の発生のしにくさ • 障害の発生する頻度（MTBF）をできる だけ少なくする • 障害が発生した際の正常復旧の早さ • 障害が発生した際の正常復旧までの間 隔（MTTR）をできるだけ少なくする ＋
10. © Recruit Co., Ltd. All Rights Reserved SUUMOリコメンドシステムの安定運用に向けた取り組み 10 • 「信頼性」については、2020年より現在まで着実に取り組みを進めた結果、障害発生件数を着実に低減出来た No 取り組み内容 取り組みの目的 実施年度 1 監視項目の整備・強化 障害の適切な検知 2020 2 障害対応フロー整備 障害対応の型化 2020 3 障害発生時の振り返りと暫定対応・恒久対応・ 横展開の徹底 障害再発の予防 2020〜 4 バッチ処理基盤の社内横断プロダクトへの移行 既存ワークフロー基盤の技術負債解消 2021 5 リアルタイムログ処理基盤のサーバレス化・オ ートスケーリング適用 運用・保守が容易な基盤への変更 2022 6 リコメンドAPI基盤のサーバレス化・CI/CD整備 運用・保守が容易な基盤への変更 2022
11. © Recruit Co., Ltd. All Rights Reserved カオスエンジニアリング SUUMOリコメンドシステムの安定運用に向けた取り組み 11 • 信頼性が高まるにつれ障害対応の実務経験の機会が減少するため、組織としての回復性が担保しづらい • クラウドサービスの障害や担当メンバーの入れ替えなど、予期せぬ事象にも対応できるような回復性をどのよ うに担保するかが課題に • そこで「回復性」を担保するために、2023年よりカオスエンジニアリングの取り組みを開始 • 障害対応訓練を定期的に実施することで、（いつなんどき）障害が発生した際にも素早く復旧するケイパビリテ ィを組織として備えることを目指している システムに実験的に障害を発生させることで 実際に障害が発生した際に的確な対応ができる ような訓練を行うエンジニアリング手法
12. © Recruit Co., Ltd. All Rights Reserved 12 回復力を高めるための 障害対応訓練の取り組み事例
13. © Recruit Co., Ltd. All Rights Reserved 背景・課題 13 • 障害発生件数の減少に伴いメンバーの障害対応能力を上げる機 会が減っている • 障害対応に慣れているメンバーへの属人化の傾向 • 障害に強いシステム設計能力をつけたい カオスエンジニアリング的な取り組みとして『障害対応訓練』を開始
14. © Recruit Co., Ltd. All Rights Reserved 目的 14 障害対応時の、 • プロセス（フローや役割）の理解 • システム復旧能力の向上 平時の、 • システム設計能力の向上（障害に強いシステムの構築）
15. © Recruit Co., Ltd. All Rights Reserved 取り組みの流れ 15 障害分析 シナリオ選定 訓練事前準備 訓練実施 振り返り • シナリオ指針作成 • 障害分析 • シナリオ選定 目的 タスク 訓練シナリオ作成の 指針を立てるととも に、これまでの障害 を分析しシナリオ選 定を実施する • 環境構築 • 障害注入スクリプ ト&手順作成 • 事前実験 • 検知 • 原因調査 • 暫定対応 • エスカレ&広報 • 振り返り 訓練に向けた事前準 備及び既存環境に対 する実験を実施する 準備された障害に対 して、障害対応を実 際に実施する 訓練内容を振り返り 日々の障害対応業 務や既存システムへ の学びを得て、改善 へと繋げる
16. © Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 障害分析&シナリオ選定 16 障害分析 シナリオ選定 訓練事前準備 訓練実施 振り返り • シナリオ指針作成 • 障害分析 • シナリオ選定 目的 タスク 訓練シナリオ作成の 指針を立てるととも に、これまでの障害 を分析しシナリオ選 定を実施する • スコープ設定 • 体制構築 • 環境構築 • 障害注入スクリプ ト&手順作成 • 事前実験 • 検知 • 原因調査 • 暫定対応 • エスカレ&広報 • 振り返り 訓練に向けた事前準 備及び既存環境に対 する実験を実施する 障害対応を実際に実 施する 訓練内容を振り返り 日々の障害対応業 務や既存システムへ の学びを得て、改善 へと繋げる
17. © Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定 ： シナリオ作成指針 17 訓練当日に発生させる障害を下記の指針で選定 シナリオ作成指針 • 実際の障害を参考にする ◦ ビジネスインパクトの大きなもの ◦ 起きる頻度の高いもの ◦ Gracefulに対応できない、手動復旧が必要などの理由により起きたら困るもの ◦ 十分に対応ができているはずというもの • 手順書の有無も考慮する ◦ 作成したは良いが、一度も利用した経験がない手順書
18. © Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定 ： 障害分析 18 SUUMOリコメンドシステム全体を訓練スコープとして設定 AWS上に構築されており、「リコメンドAPI」「リアルタイムログ処理」「バッチ処理」の3つのコン ポーネントに分かれている
19. © Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定 ： 障害分析 19 過去3年の障害一覧を下記の観点で整理し、前頁の指針にそった形で障害の候補を選定 • システム：対象システム、障害分類、障害概要、対象AWSサービス • 頻度/検知/影響：発生頻度、ビジネス影響、システム影響、検知方法、検知スピード • 対応方法：一時対応方法(自動)、一時対応方法(手動)、対応手順有無、対応スピード No 障害名 発生年月 対象システム 障害分類 発生頻度 ビジネス影響 システム影響 対応方法 1 A障害 2019/1 API インフラ 小 中 小 自動復旧 2 B障害 2019/5 バッチ ヒューマン エラー 小 小 小 切り戻し 3 C障害 2020/4 バッチ インフラ 中 小 小 手動リラン 4 D障害 2020/8 ログ処理 アプリ 小 小 小 切り戻し 5 E障害 2020/11 API インフラ 小 大 大 手動 … … … … … … … … …
20. © Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定 ： 障害分析 20 過去3年の障害一覧を整理し、前頁の指針にそった形で障害の候補を選定 障害分類 具体例 インフラ障害 コネクション不足、Spot/キャパ不足、HW障 害、リソース不足、RateExceed, など アプリ障害 コード改修不備、設定ファイル記述ミス、要 件漏れ、など データ障害 データ欠損、異常値混入、など ヒューマンエラー オペレーションミス、手順書間違い、など
21. © Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定 ： 障害分析 21 過去3年の障害一覧を整理し、前頁の指針にそった形で障害の候補を選定 → 障害分類なども踏まえて、最終的に以下の候補に絞った No 障害対象 障害の概要 1 当日ログ処理 (ログ処理) リクエスト過多によるCPU高騰 2 データ更新処理 (API) AWSサービスのAPIコールのタイムアウト 3 データ作成処理 (バッチ) Spot Instance枯渇 4 データ更新処理 (API) 証明書の有効期限切れ 5 データ作成処理 (バッチ) 異常値データの混入 6 データ更新処理 (API) アプリ設定記述ミス 7 API処理 (API) インフラ設定記述ミス 手順書では復旧が困難なタイプ 実験(既知障害)を注入し、挙動の観察・復旧方 法の検討や復旧時間を計測する通常のカオスエ ンジニアリングでカバーされる範囲 手順書で対応が可能だが、手順書 がないもの（作りましょう） 手順書で手動復旧ができるタイプ 障害対応訓練でカバーされる範囲
22. © Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 訓練事前準備 22 障害分析 シナリオ選定 訓練事前準備 訓練実施 振り返り • シナリオ指針作成 • 障害分析 • シナリオ選定 目的 タスク 訓練シナリオ作成の 指針を立てるととも に、これまでの障害 を分析しシナリオ選 定を実施する • 環境構築 • 障害注入スクリプ ト&手順作成 • 事前実験 • 検知 • 原因調査 • 暫定対応 • エスカレ&広報 • 振り返り 訓練に向けた事前準 備及び既存環境に対 する実験を実施する 障害対応を実際に実 施する 訓練内容を振り返り 日々の障害対応業 務や既存システムへ の学びを得て、改善 へと繋げる
23. © Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 環境構築 23 訓練準備にあたってのポイントは下記の3つ • 訓練の仕立て（参加者/環境/事前調整) • 環境構築 • 事前実験/最終的なシナリオ確定
24. © Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 訓練の仕立て 24 • 訓練当日はチームを2つに分けて競い合える形式で訓練を実施 • 初回のためミニマムで実施するため、インフラメンバー(運用メンバー)を主な参加者とし てチームを形成 • 環境は開発環境を整備して本番相当の状況を作り出せるように調整 • アプリチームには事前に訓練中の質疑への協力と開発環境が一時的に利用できなくなる 可能性がある旨を連絡
25. © Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 環境構築 25 ２チームが独立して障害対応にあたれるよう、 • 障害対応用環境を二重で用意（今回は開発環境を2つ用意した。IaC必須) • APIのリクエストは本番相当のリクエストを再現 • バッチ処理を本番同等の時間/データで実行されるよう設定 ログから本番APIリクエストを 再現し、流し続けることで、 APIのアクセスも本番シチュエ ーションに合わせる 環境は二重で用意 (AWSアカウントも別) 開発環境のバッチ処理は 本番同等に設定
26. © Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 事前実験 26 • 障害対応訓練のシナリオとして利用する障害は、手順書をもとに手動で復旧ができるタイ プの障害であり、下記の3件のように手順書で復旧が困難なタイプの障害は利用できな い（カオスエンジニアリングの実験でカバーされる範囲） → そのためそのような障害については事前にシステムが想定通りの挙動をするかを実験 で確かめる。 No 障害対象 障害の概要 1 当日ログ処理 (ログ処理) リクエスト過多によるCPU高騰 2 データ更新処理 (API) AWSサービスのAPIコールのタイムアウト 3 データ作成処理 (バッチ) Spot Instance枯渇 手順書では復旧が困難なタイプ 実験(既知障害)を注入し、挙動の観察・復旧方 法の検討や復旧時間を計測する通常のカオスエ ンジニアリングでカバーされる範囲
27. © Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 事前実験 27 • AWS FISを利用して障害を注入 ◦ CPU負荷高騰させたところ、想定通りの挙動(APIのtimeout2秒に引っかかりエラ ーとなる)とはならず、APIの応答速度は2秒以上かかるがレスポンスを返しエラーと はならない → アプリケーションの課題を発見。本来なら改修すべきだが、今回は台数増強を手動 で対応すれば対応できそうであったので、訓練シナリオへ組み込んだ
28. © Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 訓練実施 28 障害分析 シナリオ選定 訓練事前準備 訓練実施 振り返り • シナリオ指針作成 • 障害分析 • シナリオ選定 目的 タスク 訓練シナリオ作成の 指針を立てるととも に、これまでの障害 を分析しシナリオ選 定を実施する • スコープ設定 • 体制構築 • 環境構築 • 障害注入スクリプ ト&手順作成 • 事前実験 • 検知 • 原因調査 • 暫定対応 • エスカレ&広報 • 振り返り 訓練に向けた事前準 備及び既存環境に対 する実験を実施する 準備された障害に対 して、障害対応を実 際に実施する 訓練内容を振り返り 日々の障害対応業 務や既存システムへ の学びを得て、改善 へと繋げる
29. © Recruit Co., Ltd. All Rights Reserved 訓練実施 : 訓練当日の様子 29 （注）上記は、あくまで訓練における想定シナリオであり事実ではありません 訓練当日は、以下のような想定シナリオをおいて訓練を開始。
30. © Recruit Co., Ltd. All Rights Reserved 訓練実施 : 訓練当日の様子 30 訓練当日は、午後を丸々利用し、オフラインで集まり、２チームに分かれ訓練を実施。 オフラインで集まることで、 • 障害対応未経験メンバーへの教育/説明がやり易かった • グループの一体感が増した というメリットがあった
31. © Recruit Co., Ltd. All Rights Reserved 訓練実施 : 訓練当日の様子 31 一方で訓練に際しては、 • 準備していた障害発生用のスクリプトが動かず、急遽タイムラインを組み替えた • 開発環境で想定外のエラーが発生し、参加者以外の開発者に影響があった • 障害対応するためにアプリチームへのQAがかなり発生し、対応負荷が想定以上だった などの課題も発生した。
32. © Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 振り返り 32 障害分析 シナリオ選定 訓練事前準備 訓練実施 振り返り • シナリオ指針作成 • 障害分析 • シナリオ選定 目的 タスク 訓練シナリオ作成の 指針を立てるととも に、これまでの障害 を分析しシナリオ選 定を実施する • スコープ設定 • 体制構築 • 環境構築 • 障害注入スクリプ ト&手順作成 • 事前実験 • 検知 • 原因調査 • 暫定対応 • エスカレ&広報 • 振り返り 訓練に向けた事前準 備及び既存環境に対 する実験を実施する 障害対応を実際に実 施する 訓練内容を振り返り 日々の障害対応業 務や既存システムへ の学びを得て、改善 へと繋げる
33. © Recruit Co., Ltd. All Rights Reserved 振り返り : 訓練当日の様子 33 訓練の最後には、チーム毎に振り返りの実施と共有をすると共に、各チームのMVPを決めた。
34. © Recruit Co., Ltd. All Rights Reserved 振り返り : 障害対応及び現行システムに関して 34 障害対応訓練を通して、既存システムに対する技術的な課題だけでなく、障害対応 プロセス自体に対する非技術的な課題も得ることができた • 技術的な課題 ◦ 必要なアラート/ダッシュボードがなく障害に気付けない(気づくのが遅れる) ◦ 調査実施のための前提条件が満たせない ▪ 普段あまり触れていないシステムのログイン手順や、ダッシュボードの見方などがわからな い ◦ アプリケーションのログやエラーの見方/対応の仕方がわからない ◦ 影響範囲調査のための情報(データの依存関係など)がまとまってないため、影響範囲調査に時 間がかかる • 非技術的な課題 ◦ 他チームへの広報や連携タイミングがわからない ◦ サービス復旧の優先度判断ができない
35. © Recruit Co., Ltd. All Rights Reserved 振り返り : 障害対応訓練に関して 35 障害対応訓練自体の振り返りも合わせて実施 • Keep ◦ 普段担当しない役割の経験値が増えた ◦ 普段の運用も見据えた課題の発見ができた ◦ 普段自分が担当しないサービスの詳細を真剣に見る機会になった ◦ 各サービスの知見が増えた • Try ◦ アプリケーションチームのメンバーも巻き込んだ訓練を実施したい ◦ 環境構築周りをもうちょっと自動化したい（特にAPIの正常リクエスト周り) ◦ 訓練する側ではなく、訓練を考える企画側(今回だと私)が1番知見が貯まったのではと思われるの で、企画メンバーをローテーションにしたい
36. © Recruit Co., Ltd. All Rights Reserved 今後の展望及び目標 36 • 障害対応訓練を定期的に実施することで、組織として回復力の維持・向上を図る • 社内の別組織のメンバーも障害対応訓練に参加することで知見の共有を行い、 室全体の回復力の向上に寄与する • カオス実験（障害訓練パターン）の種類を増やすとともに、そもそもそれらが発生 しても障害にならないシステムを構築する
37. © Recruit Co., Ltd. All Rights Reserved 37 信頼性が高まるにつれ障害対応の実務経験の機会が減少するため、 組織としての回復性が担保しづらい まとめ 我々は、カオスエンジニアリングベースの障害対応訓練により 擬似体験の機会を作ることで、組織としての回復性を担保している システムの安定運用のためには、信頼性とともに障害時の回復性が重要 障害対応訓練を行うことで以下のメリットが獲得できる • 個人の障害対応ナレッジを組織としてのナレッジに変換 • 今後の更なる障害対応改善ポイントの発見 • 安定運用に対する担当者意識の醸成
38. © Recruit Co., Ltd. All Rights Reserved We are hiring！ 38 カジュアル面談はこちらより お申し込みください データサイエンティスト 機械学習エンジニア データエンジニア アナリティクスエンジニア BIエンジニア R&Dエンジニア データアプリケーションエンジニア パブリッククラウドエンジニア