システムの安定運用を実現するための取り組み
大学新聞の広告代理店として、人材を求める企業と仕事を求める学生のニーズをマッチングさせる情報誌ビジネスから始まったリクルート。「求職活動や採用活動を支援する人材領域」に加え、今ではSUUMOやじゃらん、ゼクシィ、ホットペッパーなど「住宅・旅行・飲食といった販促領域」においても、個人ユーザーと企業クライアントが出会う場を創り出し、より最適なマッチングを生み出すべくさまざまなビジネス・サービスを展開している。
鶴谷氏や芳賀氏が所属するデータ推進室は、販促領域や人材領域という事業領域ごとのデータ施策を推進する縦の組織と、データサイエンスやデータエンジニアリングという専門分野ごとに専門性を強化する横の組織とを併せ持つマトリックス型の組織構造を採用している。この縦の組織の内、SUUMO領域で担当しているシステムの一つが、SUUMOレコメンドシステムである。
「SUUMOレコメンドシステム」は、SUUMOの公式サイト上でユーザーのお勧めの物件をリコメンドするサービス。「このシステムは、最新の物件の情報や機械学習モデルの更新が行われないなど障害が発生するとユーザーの体験が悪化してしまうため、安定運用を実現する必要があった」と鶴谷氏は振り返る。鶴谷氏は証券系SIerで10年、インフラエンジニアやシステムコンサルタントを経験した後、2015年にリクルートに入社。リクルートIDの基盤の開発やクラウド移行を担当。その後、SUUMOレコメンドシステムの基盤移行や複数の分析基盤の運営などに携わってきた。
SUUMOレコメンドシステムの安定運用を実現するために、鶴谷氏たちが重視したのが「信頼性」と「回復性」である。信頼性とは、障害の発生しにくさや障害の発生する頻度をできるだけ少なくすること。一方の回復性とは、障害が発生した際にできるだけ素早く正常復旧させることである。「組織としてこのようなケイパビリティを備えることは必要だと考えていました」（鶴谷氏）
そこでデータ推進室では、3年前から安定運用のための各種取り組みを強化してきたが、「当初は信頼性の向上を中心に取り組みを進めていた」と鶴谷氏は語る。具体的には監視項目の整備や強化、不足している監視項目の追加、障害が発生した際の対応フローの整備など、トラブルが発生した際に適切に対応するためのルール整備に努めていたという。
その上で発生する障害に対して毎回、暫定対応や恒久対応することに加え、「同様の障害が発生しないよう横展開での調査や対抗を行うことを徹底してきました」と鶴谷氏は語る。それらの取り組みと共に、一定期間経過して古くなった基盤を社内の横断プロダクトに移行したり、サーバーレス化やCI/CD整備を進めることで技術負債を解消したり、保守運用が容易な基盤に作り替えることも行ってきたという。
「このような取り組みをした結果、リコメンドが表示されないなどの重度な障害が発生することがなくなり、障害が起きないことが当たり前の状態になりました」と鶴谷氏は話す。
カオスエンジニアリングで、障害時の回復性を担保に挑戦
障害が発生しないことは良いことだが、その一方で、新しい問題も起こったという。「障害対応の実務経験の機会が減少し、いざ障害が発生した際の障害調査に手間取ったり、障害対応に時間がかかったりするなど、障害時の回復性が担保しにくい状態になったのです」（鶴谷氏）
パブリッククラウドサービスの障害や担当メンバーの急な入れ替えなど、予期せぬ事象にも対応できる回復性をどのように担保するかが課題になったという。鶴谷氏たちが回復性を担保するために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が一部想定外の挙動を示したという。「回復性の検証をするカオス実験を前に挟むことで、人の対応能力だけではなく、システムの改善ポイントも一緒に発見することができました」（芳賀氏）
障害対応訓練で得られた知見と今後の課題
芳賀氏はセッションの中で、実際の訓練の様子も紹介した。訓練の想定シナリオは次の通り。
「ある日、システム担当のHさん＆Tさんが世界を旅するために長期でお休みを取ることになりました。Hさん＆Tさんはリコメンドシステム全般の運用を担当していました。障害対応のノウハウやハンドリングはHさん＆Tさんの秘伝のタレとなっている部分も多く、2人が長期休暇に入ることで、システムの安定稼働に起用信号が灯ったのです。しかも最悪なことにHさん＆Tさんは、お休みの前にいくつかのバグをシステムに入れ込んでしまっていました」
訓練はオフラインで実施。「障害対応未経験のメンバーへの教育や説明がやりやすく、グループの一体感が増したというメリットが得られた」と芳賀氏。その一方で、訓練内容については「準備していた障害発生用のスクリプトが動かず、急遽タイムラインを組み替えたり、開発環境で想定外のエラーが発生したため、参加者以外の開発者に影響を及ぼしたり、障害対応するためにアプリチームへのQAがかなり発生したり、想定以上の対応負荷も発生したという。「次回開催する際には、このあたりの課題を改善したいと思う」と芳賀氏は語る。
訓練後の終わりにはチームごとに振り返りを実施した。障害対応訓練を経験したことで、「現行システムに対する技術的な課題だけではなく、障害対応プロセス自体に対する非技術面での課題の把握もできた」と芳賀氏は話す。明らかになった非技術的な課題とは、他チームへの広報タイミングや連携方法などが明文化できていなかったことだ。
さらに障害対応訓練の取り組み自体に対しても振り返りを実施。良かった点として、普段担当しない役割の経験や、サービス詳細を真剣に見る機会が得られたことが挙げられた。メンバーからも「総じて好評を得ている」と芳賀氏は語る。
今後も障害対応訓練の活動を継続しつつ、個々人の障害対応能力を磨き上げ障害訓練パターンの種類を増やすことで、障害が発生しない回復力の高いシステム設計ができるようにしていきたいという。また実際の障害対応はインフラメンバーだけではなく、アプリ開発メンバーも巻き込んで行うことも検討。「自グループのみならず、他グループも障害対応訓練に参加してもらうなど、データ推進室全体での回復力の向上に寄与したい」と芳賀氏は意気込みを語り、セッションを締めくくった。
