LAPRASインフラチームで避難訓練を行いました

こんにちは、SRE(Site Reliability Enginner) の @showwin です。最近はAPIのレイテンシに関するSLI, SLOを定めていて、それに伴い自分自身でもアプリケーションに手を入れて高速化をしています。(リアルISUCON楽しい！)

この記事では5/25に社内で実施したインフラ避難訓練の紹介をしていきます。実施直後にレポート書くぞ！と思っていたのですが、気づいたら1ヶ月半経っていました。。

避難訓練実施の目的

今回の避難訓練実施の目的は、
・インフラチームのKubernetesへの理解を深める
・障害が起きたときの暫定的な対応方法を身につける/練習する
というものです。

現在LAPRASのインフラチームは3名いますが、うち2名は業務のほとんどをアプリケーション開発に費やしており、フルタイムでインフラを見ているのは私1人です。サブとして関わってもらっている2名には、普段の開発時のレビューや Kubernetes のバージョンアップデート、障害が発生した時のモブプロ相手として動いてもらっています。

そのような状況もあり、まずは自分たちが使っている環境への理解を深めたり、障害時のオペレーション対応をする点に重点を置きました。

避難訓練とカオスエンジニアリング

避難訓練に近い言葉として、カオスエンジニアリングがありますが、今回は意図的にカオスエンジニアリングではなく避難訓練という言葉を使っています。カオスエンジニアリングでは、意図的に障害を注入した結果どのような範囲でユーザに影響が出るのか仮説を立ててそれを検証し、その実験を経ることでチームが耐障害に対する確信を得ていくことが目的とされています。

一方で今回の避難訓練では、障害を意図的に注入するという点ではカオスエンジニアリングと同様ですが、発生する障害の内容は過去にオペレーションミスなどにより実際に発生したことがある、あるいは将来起きると想定されるものとしています。そして、発生した問題に対して原因を追求しバグを修正する、あるいは即時の修正が難しければ暫定的な対応をしてサービスの復旧を第一とすることを訓練の内容としています。Chaos Monkey などのカオスエンジニアリング向けのツールでは、(特定の原因があるわけではなく)ランダムにインスタンスを落としてくれたりしますが、今回の避難訓練では人為的なミスで起きうる障害に対して練習をするということになります。

実施方法

攻撃者: @h3poteto
防衛側: 上述のLAPRASインフラチーム3名

で行いました。h3poteto さんは元LAPRAS社員で今のKubernetesのインフラ基盤を整えてくれた方です。転職先でも深くKubernetesに関われているということで、今回攻撃役を依頼しました。快く受けてくださりありがとうございました！

障害の注入先はステージング環境です。攻撃側が障害を注入するとWebサービスが閲覧不可能あるいはそれに近い状態になりますが、そこから正常にレスポンスを返すように復元することが防衛側の役割です。

タイムテーブル

10:00 ~ 12:00 準備時間
13:00 ~ 16:00 避難訓練実施
(16:00 ~ 17:00) 別MTGのため休憩
17:00 ~ 18:00 振り返り

訓練時間中の3時間は、障害を起こしてもらう -> 対応する -> 別の障害を起こしてもらう -> 対応するを繰り返し行います。根本原因が究明できなかった場合には、暫定的な対応をして終わりにすることもあります。なぜなら、実際に障害が起きたときにも第一にサービスが復旧することを目的として対応するからです。原因の答え合わせは17時からの振り返りの時間で行うため、実施中にはわかりません。

訓練中にやること

障害が発生したら、本番で実際に障害が発生した場合と同じ対応をします。LAPRASでは障害通知用のSlackチャンネルに障害対応ワークフローがあるため、まずはそれを起動します。

起動すると、Google MeetのURLと障害対応シートのテンプレートが出てきます。

リモートワークをしていると、障害が発生しても無意識に個々人で調査を始めてしまいがちです。役割分担を明確にして効率よく対処するためにもまずは皆であつまります。

招待対応シートのテンプレがこちらです。
Google Docs のテンプレート機能を使っています。項目は Site Reliability Engineering (通称SRE本) に載っていたインシデント状況ドキュメントを参考にしました。

訓練中は、問題ごとに指揮官、作業者、計画者の役割をローテーションしていました。
作業者や計画者は目の前の課題に没頭して周りが見えにくくなってしまうことがありますが、指揮官がタイムラインをまとめたり全体を見渡して「あれ、そもそも今なんでそこの調査しているんだっけ？」「今の状況を整理すると…」と一歩引いたところから意見を言うことで、効率よく原因の探索ができることができます。

今回は訓練のため行いませんでしたが、実際の障害の場合にはこのシートのタイムラインを元に https://status.lapras.com/ にて状況の更新を行います。

振り返り

今回の避難訓練では計4つの課題に対応することができました。(うち1問はk8sのレジリエンスが強すぎて時間経過で自然と治ってしまいました)
注入された障害としては、意図していないPodSecurityPolicyが作成されていてPodが立ち上がってこない問題や、OIDCプロバイダのURLが誤っておりIngressが期待通りに動いていない問題などがありました。

OIDCプロバイダのURLは単に過去にコピペミスで発生した問題です。PodSecurityPolicyに関しては、EKS で v1.13 にアップデートする際に(クラスタ作り直しのBlueGreenでのアップデートではなく)ローリングアップデートをする場合には自分たちでこれに相当するPodSecurityPolicyを作成する必要があったのですが、それを忘れてPodが立ち上がらなくなった事件があり、今回採用されました。

実は今回の避難訓練が2回目で、1回目は2020年の夏頃に行ったのですが、前回と比べるとスムーズに対応できたような気がします。また当時はSlackのワークフローも障害対応シートもなかったため、1年前と比較して障害対応の体制もアップデートできていると感じました。

カオスエンジニアリングとは違い、人為的なミスで起こる障害の訓練であったため、対インシデントの練習だけではなく、普段の開発で注意すべきポイントの学習にもなりました。攻撃する側はコンテンツを考えるのが大変ですが、過去に発生したインシデントのポストモーテムを振り返り、それを攻撃のネタとしてみると良いかもしれません。ぜひ皆さんの組織でも実施してみてください！