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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© Recruit Co., Ltd. All Rights Reserved 所属株式会社リクルートプロダクト統括本部プロダクト開発統括室データ推進室経歴 2016年にリクルートに新卒入社。データサイエンティストとしてSUUMOリコメンドシステムで使用される機械学習モデルの開発を担当。その後、データエンジニアとしてSUUMOリコメンドシステムの開発・運用に従事し、リアーキテクチャやサービスマネジメントを担当。自己紹介芳賀宣仁（はがのぶひと） 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© Recruit Co., Ltd. All Rights Reserved リクルートのビジネスモデルについて 6 ● リクルートにはユーザーとクライアントという2つのお客様が存在 ● 「企業と人（B to C）」「企業と企業（B to B）」「人と人（C to C）」のすべての間に立ち、双方にとって最適なマッチングを図る「場」を提供ユーザーとクライアントを新しい接点で結び、「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」の場を創造するリクルートマッチングプラットフォームクライアントとユーザーを結びつける対価としてクライアントからフィーを受領ユーザークライアント

Slide 7

Slide 7 text

© 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) データエンジニアリング部データサイエンス部採用・育成を含む専門性強化に責任を持つ

Slide 8

Slide 8 text

© Recruit Co., Ltd. All Rights Reserved SUUMOリコメンドシステムの安定運用に向けた取り組み 8 ● SUUMOリコメンドシステムは、SUUMO上でユーザーにお勧めの物件のリコメンデーションを行っている ● リコメンドシステム障害に伴うユーザー体験の悪化を防ぐため安定運用を実現する必要があった SUUMOリコメンドシステムリコメンドAPI基盤お勧め物件リコメンドバッチ処理基盤学習済みモデル物件情報更新、モデル更新リアルタイムログ処理基盤行動ログ収集

Slide 9

Slide 9 text

© Recruit Co., Ltd. All Rights Reserved SUUMOリコメンドシステムの安定運用に向けた取り組み 9 ● 安定運用を実現するためには、障害そのものの発生頻度を下げるだけでなく、（いつなんどき）障害が発生した際にも素早く復旧するケイパビリティを組織として備えることが必要信頼性（Reliability）回復性（Recoverability） ● 障害の発生のしにくさ ● 障害の発生する頻度（MTBF）をできるだけ少なくする ● 障害が発生した際の正常復旧の早さ ● 障害が発生した際の正常復旧までの間隔（MTTR）をできるだけ少なくする＋

Slide 10

Slide 10 text

© 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

Slide 11

Slide 11 text

© Recruit Co., Ltd. All Rights Reserved カオスエンジニアリング SUUMOリコメンドシステムの安定運用に向けた取り組み 11 ● 信頼性が高まるにつれ障害対応の実務経験の機会が減少するため、組織としての回復性が担保しづらい ● クラウドサービスの障害や担当メンバーの入れ替えなど、予期せぬ事象にも対応できるような回復性をどのように担保するかが課題に ● そこで「回復性」を担保するために、2023年よりカオスエンジニアリングの取り組みを開始 ● 障害対応訓練を定期的に実施することで、（いつなんどき）障害が発生した際にも素早く復旧するケイパビリティを組織として備えることを目指しているシステムに実験的に障害を発生させることで実際に障害が発生した際に的確な対応ができるような訓練を行うエンジニアリング手法

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© Recruit Co., Ltd. All Rights Reserved 取り組みの流れ 15 障害分析シナリオ選定訓練事前準備訓練実施振り返り ● シナリオ指針作成 ● 障害分析 ● シナリオ選定目的タスク訓練シナリオ作成の指針を立てるとともに、これまでの障害を分析しシナリオ選定を実施する ● 環境構築 ● 障害注入スクリプト&手順作成 ● 事前実験 ● 検知 ● 原因調査 ● 暫定対応 ● エスカレ&広報 ● 振り返り訓練に向けた事前準備及び既存環境に対する実験を実施する準備された障害に対して、障害対応を実際に実施する訓練内容を振り返り日々の障害対応業務や既存システムへの学びを得て、改善へと繋げる

Slide 16

Slide 16 text

© Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 障害分析&シナリオ選定 16 障害分析シナリオ選定訓練事前準備訓練実施振り返り ● シナリオ指針作成 ● 障害分析 ● シナリオ選定目的タスク訓練シナリオ作成の指針を立てるとともに、これまでの障害を分析しシナリオ選定を実施する ● スコープ設定 ● 体制構築 ● 環境構築 ● 障害注入スクリプト&手順作成 ● 事前実験 ● 検知 ● 原因調査 ● 暫定対応 ● エスカレ&広報 ● 振り返り訓練に向けた事前準備及び既存環境に対する実験を実施する障害対応を実際に実施する訓練内容を振り返り日々の障害対応業務や既存システムへの学びを得て、改善へと繋げる

Slide 17

Slide 17 text

© Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定：シナリオ作成指針 17 訓練当日に発生させる障害を下記の指針で選定シナリオ作成指針 ● 実際の障害を参考にする ○ ビジネスインパクトの大きなもの ○ 起きる頻度の高いもの ○ Gracefulに対応できない、手動復旧が必要などの理由により起きたら困るもの ○ 十分に対応ができているはずというもの ● 手順書の有無も考慮する ○ 作成したは良いが、一度も利用した経験がない手順書

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 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 インフラ小大大手動 … … … … … … … … …

Slide 20

Slide 20 text

© Recruit Co., Ltd. All Rights Reserved 障害分析&シナリオ選定：障害分析 20 過去3年の障害一覧を整理し、前頁の指針にそった形で障害の候補を選定障害分類具体例インフラ障害コネクション不足、Spot/キャパ不足、HW障害、リソース不足、RateExceed, などアプリ障害コード改修不備、設定ファイル記述ミス、要件漏れ、などデータ障害データ欠損、異常値混入、などヒューマンエラーオペレーションミス、手順書間違い、など

Slide 21

Slide 21 text

© 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) インフラ設定記述ミス手順書では復旧が困難なタイプ実験(既知障害)を注入し、挙動の観察・復旧方法の検討や復旧時間を計測する通常のカオスエンジニアリングでカバーされる範囲手順書で対応が可能だが、手順書がないもの（作りましょう）手順書で手動復旧ができるタイプ障害対応訓練でカバーされる範囲

Slide 22

Slide 22 text

© Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 訓練事前準備 22 障害分析シナリオ選定訓練事前準備訓練実施振り返り ● シナリオ指針作成 ● 障害分析 ● シナリオ選定目的タスク訓練シナリオ作成の指針を立てるとともに、これまでの障害を分析しシナリオ選定を実施する ● 環境構築 ● 障害注入スクリプト&手順作成 ● 事前実験 ● 検知 ● 原因調査 ● 暫定対応 ● エスカレ&広報 ● 振り返り訓練に向けた事前準備及び既存環境に対する実験を実施する障害対応を実際に実施する訓練内容を振り返り日々の障害対応業務や既存システムへの学びを得て、改善へと繋げる

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 訓練の仕立て 24 ● 訓練当日はチームを2つに分けて競い合える形式で訓練を実施 ● 初回のためミニマムで実施するため、インフラメンバー(運用メンバー)を主な参加者としてチームを形成 ● 環境は開発環境を整備して本番相当の状況を作り出せるように調整 ● アプリチームには事前に訓練中の質疑への協力と開発環境が一時的に利用できなくなる可能性がある旨を連絡

Slide 25

Slide 25 text

© Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 環境構築 25 ２チームが独立して障害対応にあたれるよう、 ● 障害対応用環境を二重で用意（今回は開発環境を2つ用意した。IaC必須) ● APIのリクエストは本番相当のリクエストを再現 ● バッチ処理を本番同等の時間/データで実行されるよう設定ログから本番APIリクエストを再現し、流し続けることで、 APIのアクセスも本番シチュエーションに合わせる環境は二重で用意 (AWSアカウントも別) 開発環境のバッチ処理は本番同等に設定

Slide 26

Slide 26 text

© Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 事前実験 26 ● 障害対応訓練のシナリオとして利用する障害は、手順書をもとに手動で復旧ができるタイプの障害であり、下記の3件のように手順書で復旧が困難なタイプの障害は利用できない（カオスエンジニアリングの実験でカバーされる範囲） → そのためそのような障害については事前にシステムが想定通りの挙動をするかを実験で確かめる。 No 障害対象障害の概要 1 当日ログ処理 (ログ処理) リクエスト過多によるCPU高騰 2 データ更新処理 (API) AWSサービスのAPIコールのタイムアウト 3 データ作成処理 (バッチ) Spot Instance枯渇手順書では復旧が困難なタイプ実験(既知障害)を注入し、挙動の観察・復旧方法の検討や復旧時間を計測する通常のカオスエンジニアリングでカバーされる範囲

Slide 27

Slide 27 text

© Recruit Co., Ltd. All Rights Reserved 訓練事前準備 : 事前実験 27 ● AWS FISを利用して障害を注入 ○ CPU負荷高騰させたところ、想定通りの挙動(APIのtimeout2秒に引っかかりエラーとなる)とはならず、APIの応答速度は2秒以上かかるがレスポンスを返しエラーとはならない → アプリケーションの課題を発見。本来なら改修すべきだが、今回は台数増強を手動で対応すれば対応できそうであったので、訓練シナリオへ組み込んだ

Slide 28

Slide 28 text

© Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 訓練実施 28 障害分析シナリオ選定訓練事前準備訓練実施振り返り ● シナリオ指針作成 ● 障害分析 ● シナリオ選定目的タスク訓練シナリオ作成の指針を立てるとともに、これまでの障害を分析しシナリオ選定を実施する ● スコープ設定 ● 体制構築 ● 環境構築 ● 障害注入スクリプト&手順作成 ● 事前実験 ● 検知 ● 原因調査 ● 暫定対応 ● エスカレ&広報 ● 振り返り訓練に向けた事前準備及び既存環境に対する実験を実施する準備された障害に対して、障害対応を実際に実施する訓練内容を振り返り日々の障害対応業務や既存システムへの学びを得て、改善へと繋げる

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© Recruit Co., Ltd. All Rights Reserved 取り組みの流れ : 振り返り 32 障害分析シナリオ選定訓練事前準備訓練実施振り返り ● シナリオ指針作成 ● 障害分析 ● シナリオ選定目的タスク訓練シナリオ作成の指針を立てるとともに、これまでの障害を分析しシナリオ選定を実施する ● スコープ設定 ● 体制構築 ● 環境構築 ● 障害注入スクリプト&手順作成 ● 事前実験 ● 検知 ● 原因調査 ● 暫定対応 ● エスカレ&広報 ● 振り返り訓練に向けた事前準備及び既存環境に対する実験を実施する障害対応を実際に実施する訓練内容を振り返り日々の障害対応業務や既存システムへの学びを得て、改善へと繋げる

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© Recruit Co., Ltd. All Rights Reserved 振り返り : 障害対応及び現行システムに関して 34 障害対応訓練を通して、既存システムに対する技術的な課題だけでなく、障害対応プロセス自体に対する非技術的な課題も得ることができた ● 技術的な課題 ○ 必要なアラート/ダッシュボードがなく障害に気付けない(気づくのが遅れる) ○ 調査実施のための前提条件が満たせない ■ 普段あまり触れていないシステムのログイン手順や、ダッシュボードの見方などがわからない ○ アプリケーションのログやエラーの見方/対応の仕方がわからない ○ 影響範囲調査のための情報(データの依存関係など)がまとまってないため、影響範囲調査に時間がかかる ● 非技術的な課題 ○ 他チームへの広報や連携タイミングがわからない ○ サービス復旧の優先度判断ができない

Slide 35

Slide 35 text

© Recruit Co., Ltd. All Rights Reserved 振り返り : 障害対応訓練に関して 35 障害対応訓練自体の振り返りも合わせて実施 ● Keep ○ 普段担当しない役割の経験値が増えた ○ 普段の運用も見据えた課題の発見ができた ○ 普段自分が担当しないサービスの詳細を真剣に見る機会になった ○ 各サービスの知見が増えた ● Try ○ アプリケーションチームのメンバーも巻き込んだ訓練を実施したい ○ 環境構築周りをもうちょっと自動化したい（特にAPIの正常リクエスト周り) ○ 訓練する側ではなく、訓練を考える企画側(今回だと私)が1番知見が貯まったのではと思われるので、企画メンバーをローテーションにしたい

Slide 36

Slide 36 text

© Recruit Co., Ltd. All Rights Reserved 今後の展望及び目標 36 ● 障害対応訓練を定期的に実施することで、組織として回復力の維持・向上を図る ● 社内の別組織のメンバーも障害対応訓練に参加することで知見の共有を行い、室全体の回復力の向上に寄与する ● カオス実験（障害訓練パターン）の種類を増やすとともに、そもそもそれらが発生しても障害にならないシステムを構築する

Slide 37

Slide 37 text

© Recruit Co., Ltd. All Rights Reserved 37 信頼性が高まるにつれ障害対応の実務経験の機会が減少するため、組織としての回復性が担保しづらいまとめ我々は、カオスエンジニアリングベースの障害対応訓練により擬似体験の機会を作ることで、組織としての回復性を担保しているシステムの安定運用のためには、信頼性とともに障害時の回復性が重要障害対応訓練を行うことで以下のメリットが獲得できる ● 個人の障害対応ナレッジを組織としてのナレッジに変換 ● 今後の更なる障害対応改善ポイントの発見 ● 安定運用に対する担当者意識の醸成