Zenn
🚒

障害対応訓練を通じて運用改善したはなし

2022/06/20に公開
#
ふりかえり
#
障害
#
SRE
#
運用
idea

障害対応訓練を通じて運用改善したはなし

こんにちは、atama plusでSREをやっている石井です。

atama plusのSREチームは会社のミッションに加え、「生徒が学習に集中できるプロダクト基盤を実現する」というチームミッションを持ってます。
ミッションの実現のために高い信頼性(壊れづらい・壊れてもすぐに復旧できる)を持ち、atama plusのサービスの成長に耐える基盤作りを行っています。

今回はこの中の「壊れてもすぐに復旧できる」を実現する為の障害対応訓練についてご紹介します。
少しでもatama plusやSREに興味を持っていただけたらとてもうれしいです。

atama plusのSREがどのようなことをしているチームなのかについては、こちらのnoteをご覧ください。

【学びを止めるな】10万人以上の生徒の学習から大規模オンライン模試まで支えるチームの紹介 https://note.com/jtsukamoto/n/n427f6337fe5f

背景

atama plusは、塾を通じて全国の中高生に、一人ひとりに学習を最適化するAI先生「atama＋」を提供しています。

そのため、atama＋を利用する生徒たちは必然的に塾の中でatama＋を使うことになります。そういった背景から、障害でサービスが使えない状態が長引くと、塾での学習体験が著しく低下してしまいます。

復旧時間は早いに越したことはないのですが、費用対効果を踏まえて現実的に対応可能な限界をチームで話し合って決め、「生徒の学習部分において、想定する外的要因のインシデントに対する平均復旧時間を30分以下にする」を目標として置きました。

“想定する外的要因のインシデント”とは、atama＋が利用している各種クラウドサービスでの障害発生を想定しています。AZ障害だけでなくリージョン障害など、想定する外的要因に応じて、それぞれ訓練シナリオを作成しています。

障害発生時の対応方法は、マニュアル化してあり、誰でも対応可能な状態です。しかし、マニュアルがあったとしても、障害発生時に実際に対応する場合は、思わぬつまずきがつきものです。
SREチームでは、そういったつまずきを極力へらすため、実際にマニュアルに基づいて一度対応してみる訓練を行うようにしています。

訓練を通じて、SREメンバーの誰が実施してもつまずくことなく、同じくらいの速さでサービス復旧ができるようになることを目指しています。

システム構成と訓練の種類

訓練を行うプロダクトのシステムについて簡単に説明します。
「atama＋」は主に 3つのアプリケーションが連携しており、生徒が学習を行う「atama＋」、塾の講師が生徒の学習状況を把握する「atama＋ COACH」、そして主に塾の運営を行う教室長が使う「atama＋ PORTAL」です。

詳細について、この記事では省略しますが、AWSとFirebaseを組み合わせた構成になっています。
Multi-AZ構成が採れる部分についてはMulti-AZ構成を標準としており、生徒が学習を行う部分についてはその上で(対障害性の観点で)マルチリージョン構成も採っています。

演習では、以下のようなパターンを想定しています。

  • メインのリージョンでDBのサービス障害が起こったことを想定
  • XaaSを利用している箇所で、対象サービスに障害が発生したことを想定
  • 生徒の学習状況をリアルタイムで講師に連携する部分で利用しているFirebase（Real time Database）で障害が起こったことを想定
  • DBに限らず、メインのリージョン大半のサービスが利用不可となるリージョン障害が起こったことを想定

シナリオは、これらのパターンそれぞれで作成しています。

また、これまで行ってきた演習は、目的別で大きく分けて二通りあります。

  1. あらかじめ仕掛ける障害を決めて執り行う
    • 定めている復旧手順の正当性・復旧時間の測定が目的
    • どこからどこまでが復旧時間の計測対象かどうかは事前に決めておく
  2. 障害対応をするメンバーにはどの障害を起こすか伝えずに障害を仕掛ける
    • 正しく検知できているか、検知した情報から原因特定は可能か
    • 原因調査のアプローチの正当性と原因判明までの時間測定が目的

今回は「生徒の学習状況をリアルタイムで講師に連携する部分」に障害が発生したシナリオ × あらかじめ仕掛ける障害を決めて執り行う演習の進め方を紹介します。

実施方法

障害対応訓練フロー

訓練は、下記のような流れを1セットとして行います。

  1. 障害を仕掛けるサービスと実施する時間を決めたら参加メンバーの時間を確保
  2. 障害を仕掛ける準備：演習用環境の状態と仕掛けるための手順を確認
  3. 演習実施
  4. レトロスペクティブ（振り返り）

障害を仕掛けるメンバーと障害対応するメンバー、起こった事柄や時間を記録するメンバーで行います。他のオブザーバーは気になったことを記録していって、最後にチームに共有します。

実際の訓練の様子

ここからは実際に行った訓練の様子について、具体例を元に紹介します。

記録係が開始から終了までの作業や状態をチャットツールに記録していきます。あとで対応にかかった時間などを拾うためです。

障害の仕掛け方

障害を発生させるメンバーは、障害を発生させたいサービスに対して疑似障害を仕掛けます。

今回は​​firebase-admin sdkのサービスアカウントを一時的に無効にしました。これによってFirebaseへのリクエストがエラーを返すようになります。

尚、AWSのコンポーネントで障害を起こしたい場合は、 Fault Injection Simulator が利用可能なサービスに関しては、それを利用して障害を仕掛けられたらより本番に近い演習になるかもしれません。

復旧方法

復旧方法は大きく分けて2通りあります。

  1. 障害が発生した機能を利用しないようにフラグをスイッチして切り離す
  2. Multi-AZ構成であれば障害が起きたAZを変更 or 障害が起きたリージョンを回避するためのリージョンフェイルオーバー

今回は1.に該当する機能なので、そちらの手順を進めます。

1.に関する補足ですが、障害点となる機能に対して、有効・無効を切り替えられるフラグを事前にプログラムコードに埋め込んでいます。

何でもかんでもフラグ化しているわけではなく、下記を判断基準としています。

  • その機能が一時的に利用できなくても 生徒が学習を継続できるか
  • 機能固有のインフラ障害の可能性があるか

レトロスペクティブ

障害の復旧対応が完了したら、振り返り（レトロスペクティブ）を行います。

  1. より本番に近い訓練にするための改善点
  2. より簡単に訓練を開始するための改善点
  3. 復旧作業を高速化・簡素化できるところはあるか
  4. より安全に復旧できるか

などの項目についてメンバーでディスカッションをして、有効なアイデアはネクストアクションとして作業チケット化します。ディスカッションや障害対応訓練自体を通じて得た学びは、運用・システム改善に生かされています。

いくつか紹介したいと思います。

良かった点

1. 障害対応手順の認識・正当性をSREチームで合わせることができた

手順化する流れを通じて、全員のシステムへの理解度が進み、SREチームとしての可用性をも向上させることができました。

「このときはどのメトリクスをみて、どう対応するべきか」というノウハウは、そのシステムに精通しているメンバーに属人化しがちなのですが、そういった部分を手順化することで、明確にすることができました。

2. 対応手順の自動化・システムの改善につながった

この手順だとミスが起きそう・復旧に時間がかかるという部分が、手順書の作成中 または 訓練の中で露見しました。結果、より正確に、よりスピーディーに障害から復旧させるために、手順を自動化したり、システムをシンプルにする動きが生まれたことも良かったです。

そういった改善を重ねた結果、訓練では目標としていた「障害発生から復旧完了までを30分以下にする」を達成できました。

3. ログ監視・外形監視の充実

起こっている事象を正確に把握しやすくするために、ログに出す情報に修正を加えたり、クライアント側のエラー発生状態の可視性を上げるためにリアルユーザモニタリング（RUM）ツールを導入しました。

ブラッシュアップしたい点

1. 開催コストと頻度

今回の訓練は、一回あたり訓練の準備に加えて4人×1時間ほどのコストがかかりました。

SREとして推進したい他の作業とのバランスを考えると、規模の大きい障害対応訓練をメンバー全員で行うのはコストが高すぎると考え、以下の方針を決めました。

  • 四半期〜半年に一回はドキュメントレビューという形で、ピックアップした障害シナリオに対する復旧手順の見直しをおこなう
  • 復旧手順が単純にできない障害については、冗長性確保のために二人くらいが実際に、障害対応訓練の障害対応実施者を行ったことがある状態にする
  • 半年から1年に一回程度、机上ではないフル実施の対応訓練を実施

2. 障害対応手順書のアップデートフローの構築

障害対応手順書が日々の機能追加や改修内容に追従できていないと、いざ障害が発生したときにうまく活用することができません。そのため、日々の手順書のアップデートのフローの検討する部分に伸びしろがあると考えています。

現時点では、「日々の作業チケットの中に手順書を更新すべきか」という項目を加え、手順書への内容の反映が必要かどうかを確認できるようにしています。

おわりに

今回紹介した障害演習以外にも、生徒が学びに集中できるように、多くの課題と向き合っています。
プロダクトが拡大していく中でそれを支える基盤インフラを一緒に整え、進化させていきませんか？

【Engineer】クラウドインフラエンジニア / SRE

また、この記事を読んで「もう少しSREについて詳しく知りたいかも？」と思っていただいた方は、ぜひこちらのマガジン) から他の記事もご覧いただけたらと思います！

もしくは、「中の人にもう少し詳しく話を聞きたい！」と思っていただけた方は、お気軽に カジュアル面談フォームやmeetyのカジュアル面談からお申し込みください。ぜひ、カジュアルにお話しましょう！

Discussion