カオスエンジニアリングで、障害時の回復性を担保に挑戦
障害が発生しないことは良いことだが、その一方で、新しい問題も起こったという。「障害対応の実務経験の機会が減少し、いざ障害が発生した際の障害調査に手間取ったり、障害対応に時間がかかったりするなど、障害時の回復性が担保しにくい状態になったのです」（鶴谷氏）
パブリッククラウドサービスの障害や担当メンバーの急な入れ替えなど、予期せぬ事象にも対応できる回復性をどのように担保するかが課題になったという。鶴谷氏たちが回復性を担保するために2023年より開始したのが、カオスエンジニアリング的な取り組み「障害対応訓練」である。カオスエンジニアリングとは、意図的に障害を発生させることで、実際に障害が発生した際に的確な対応ができるような訓練を行うエンジニアリング手法だ。
具体的な取り組み内容について、芳賀氏が紹介した。芳賀氏はリクルートに新卒で入社し、以降、データサイエンティストとしてSUUMOレコメンドシステムのモデル開発を担当。現在はデータエンジニアとしてリコメンドシステムのリアーキテクチャやサービスマネジメント能力向上のための施策を担当している。
「今回の取り組みでは、障害対応時に対応する人のプロセスの理解や手動でのシステム復旧能力の向上、平時においてはそもそも障害を起こさないための自動復旧可能なシステム設計能力を付けられることを目的としました」（芳賀氏）
訓練の事前準備で最初に行ったのは、障害分析およびシナリオ選定。障害シナリオ作成の指針を立てると共に、これまでの障害を分析し、実際に訓練ができるようシナリオ選定を実施するというもの。芳賀氏は、2つの重点ポイントを定めシナリオを作成したそうだ。
ポイントの1つ目は実際の障害を参考にすること。「一度経験した障害は、Confluence（コンフルエンス）などの社内wikiツールにまとめていると思われるが、実際に対応できるかどうかは別問題であるため」と芳賀氏は指摘する。また経験したことのある障害をチーム全員で対応できるようにすることで、属人化の排除にもつなげることができる。もちろん、実際の障害を参考にする際には、ビジネスインパクトの大きさや頻度、自動復旧の難しさなども考慮に入れたという。
もう1つのポイントは、手順書の有無を考慮することだ。「障害対応で利用する手順書の内、使われていない手順書があったため、それらの手順を確認できるようなシナリオを作成することにしました」（芳賀氏）
SUUMOレコメンドシステムはリコメンドAPI基盤、リアルタイムログ処理基盤、バッチ処理基盤という3つのコンポーネントで構成されているが、いずれも依存関係にあるため、今回の訓練では3つの基盤すべてをスコープとして実施することになったという。
障害分析については、過去3年の障害をシステム（対象システム、障害分類、障害概要、対象AWSサービス）、頻度・検知・影響（影響・発生頻度、ビジネス影響、システム影響、検知方法、検知スピード）、対応方法（一次対応方法、対応手順有無、対応スピード）の観点で整理。「特に件数が多かったインフラ障害やデータ障害に対応できるようにするため、最終的に7個のシナリオに絞りました」（芳賀氏）
さらに7つのシナリオ候補を、「手順書では復旧が難しいタイプの障害」と「手順書で復旧ができるタイプの障害」の2つのタイプに分類。前者はカオスエンジニアリングでカバーされる範囲であるため、事前準備の中で、実際に障害を注入し、システムが想定通りの挙動をするのか確かめ、復旧方法の検討を行う。後者はまさに障害対応訓練でカバーされる範囲の障害。実際の障害対応訓練の中で、対応手順を確認することになる。
訓練準備のポイントとして芳賀氏が挙げたのは、①訓練の仕立てを考える、②環境を構築する、③事前実験および最終的なシナリオを確定すること。「訓練当日はチームを2つに分けて、競い合う形式で訓練を行うことにしました」と芳賀氏は言う。また訓練の参加者はインフラメンバーを中心とし、アプリ開発メンバーにはQA対応など、サポート要員として参加してもらったという。
カオスエンジニアリングのセオリーでは、本番環境でやるべきと言われているが、2チームが独立して障害対応にあたれるよう、本番同等の環境を2つ、開発環境に用意。「APIリクエストは本番相当のリクエストを再現、バッチ処理も本番同等の時間、データで実行されるよう設定しました」（芳賀氏）
事前実験では、AWS Fault Injection Simulator（FIS）を利用して障害を注入したところ、APIが一部想定外の挙動を示したという。「回復性の検証をするカオス実験を前に挟むことで、人の対応能力だけではなく、システムの改善ポイントも一緒に発見することができました」（芳賀氏）
