こんにちは。SREチームの清水です。 普段はGKEベースのアプリケーション基盤 Vessel の開発や、メトリクス収集基盤の整備、GCPの社内セキュリティ対策などに関わっています。

SREチームでは、全社横断のアプリケーション基盤として Vessel を開発・運用しています。 詳細は 日経の次世代アプリケーション基盤「Vessel」の紹介 も併せて御覧ください。

Vesselでは様々な障害に備え、月次で障害訓練を実施しています。 これにより、障害に対するVesselの開発チームメンバの知識の向上、対応力の強化を目指しています。

本記事では、Vesselにおける障害訓練のフレームワークのほか、GKEクラスタにおける障害注入の事例も紹介します。 みなさまのGKEクラスタ運用や障害訓練の参考になれば幸いです。

Vesselにおける障害訓練のフレームワーク

はじめにVesselチームにおける一連の障害訓練の流れについて紹介します。

Vesselチームでは、月に1回 4時間程度の時間を設けて訓練を実施しています。 ただし、状況等に応じて臨時での訓練や、全社横断的な訓練に参加することもあります。

訓練は 出題の企画 → 実施 → ふりかえり → Next Actionの決定の順で実施しています。 4時間のうち、3時間程度を訓練の実施に、概ね1時間程度はふりかえりとNext Actionの決定に充てています。

出題の企画

まずは出題の企画を実施します。チームメンバのうち1名を輪番でアサインし、訓練内容や注入する障害をデザインします。 ここではアサインされた人を出題者、訓練を受ける人を被訓練者としておきます。

具体的には、出題者は以下のような事項を検討・企画しておきます。私たちはこの企画書を「シナリオ」と呼んでいます。

• 訓練の出題時系列
• 擬似的な社員や開発者からの連絡メッセージ
• 擬似的なユーザトラフィックの発生方法
• 障害注入の内容

訓練の出題時系列

どのようなタイミングで障害を注入するかや、作業を実施するかを列挙しておきます。

これらの具体的な障害注入や作業については、タイムラインとは別に明記すると良いと思います。障害注入の詳細については、後ほど説明します。

また、サービスダウンについては、Vesselの開発チームがいち早く気付くことが良いとはいえ、実際にはユーザや社員、他チームの開発者からの指摘等で明らかになることもあります。

この状況を想定して、被訓練者に対するサービスダウンを知らせる擬似的なメッセージの送信タイミングも明記しておきます。

擬似的な社員や開発者からの連絡

被訓練者に擬似的に送信するメッセージとして、以下のようなものを策定しておきます。

• 障害訓練であることを明言するSlackコメント
• サービスダウンが発生したことの連絡
• 状況確認の連絡

まず、障害訓練であることの明言は行うことが好ましいです。これは訓練中であることを知らない人に対して、本当の障害でないことを明確にする目的です。

訓練中は、実際の障害時と同じようなメッセージが飛び交い、一見すると重大な事象が発生しているようも見えてしまいます。

次にサービスダウン発生の連絡ですが、これは擬似的な社員やユーザ部門 (擬似的にカスタマーサクセスチーム等を名乗るのも良いでしょう)、開発者を想定して作成しておきます。以下に例を示します。

• ユーザ部門を想定したメッセージ

サービスAが利用できないとの問い合わせが多数入っております。こちらの対応をお願いできますでしょうか？また、影響範囲についても教えて頂けますと幸いです。

• 開発者を想定したメッセージ

開発用ダッシュボードに接続できなくなりました。こちらご確認頂くことは可能でしょうか？よろしくおねがいします。

状況確認の連絡も都度行うようにしましょう。

実際の障害では、影響や対象範囲、対応状況を社内で逐次共有することで、復旧が早くなったり、その後の対応に役立つことも考えられます。したがって障害訓練では、技術的課題の解決も重要ですが、報告・連絡・相談が円滑に実施できるか、エスカレーションフローは問題ないか等も重要な観点になります。

これらを意識させるためにも、状況確認の連絡をどのように行うかも決めておくと良いでしょう。

• 状況確認の一例

サービスAとサービスBはどちらも大切なサービスなので、それぞれ影響のあるユーザー数を特定して可能な限り影響範囲を小さく抑えてください。

擬似的なユーザトラフィックの発生方法

障害訓練を行う環境は、しばしば開発環境や試験環境であることもあります。Vesselチームでも障害訓練は、現状は試験環境で行っています。

そういった環境では、十分なユーザトラフィックがなく、実際の障害が表面化しづらかったり、影響が小さくなりすぎたりします。 また、影響を計測しようにも、そもそもアクセスがないと計測しようもありません。

したがって、事前に擬似的なユーザトラフィックを発生させておくことが好ましいでしょう。

Vesselチームでは、heyやvegeta、社内の負荷試験基盤等を使って擬似的な負荷を発生させることが多いです。

障害注入の内容

擬似的に障害を引き起こす操作や変更を検討しておきます。この障害注入の中身については、後で詳しく説明したいと思います。

ここで引き起こす擬似的な障害に対しては、原状復帰を前提に復旧方法も合わせて考えておくことをおすすめします。

復旧方法や出題のポイントも合わせて考えておくことが重要です。

実際にチームメンバにどんな知識を身に着けてもらいたいか、どのようなスキルを訓練したいかを事前に考えておきましょう。 中には根本的な復旧が難しい障害を注入して、報告・連絡・相談、または影響の緩和の訓練に重点を置いたシナリオも考えられます。

また、これらのポイントを整理しておくことで、ふりかえりやNext Actionの決定にも役立ちます。

最後に大切なことですが、このシナリオは出題日まで出題者のみが見られる状態で保存しましょう。

実施

シナリオに沿って障害訓練を実施します。

はじめに出題者と被訓練者は同じ会議室や会議チャットに集合します。

出題者が事前に説明すべきことがあれば、ここで説明をしておきます。その後、出題者は別室に移動するか、会議チャットから離脱する等して、被訓練者とコミュニケーションが取りづらい状況にします。

また、後で検証できるよう会議チャットの録画が可能であれば録画しておきます。

出題者は、上記で決めた時系列に沿って問題を出題しながら、都度状況確認の連絡やチャットでの質問に応じるようにしましょう。 このとき、障害そのものを解決するヒントは提示する必要はありません。

被訓練者は、リソースの挙動やログ、メトリクス、アラートなどを観察しながら、障害を特定・緩和します。

被訓練者が2人以上の場合、連絡・報告・相談についても意識をしながら作業を行うと良いでしょう。Vesselチームでは、障害時のメンバの対応フローを定めていますが、こういったものが定められている場合は、これを適用して対応していくと良いでしょう。

また、実際の障害にも通じることですが、障害時はユーザ影響を緩和することが第一です。したがって、障害の原因そのものを特定することより、まず障害がユーザに影響しないようにする対応を優先しましょう。同時多発的に障害が発生することも考えられますが、最もユーザ影響が大きい障害から対応すべきです。

こういった点を念頭に起きつつ、発生した擬似的な障害に対応していくと良いでしょう。障害対応に関する考え方については、Google社が公開している SRE Workbook - Incident Response [1] が大変詳しいので、参考にしてみてください。

ふりかえり

障害訓練で重要なのがふりかえりです。

これを経ることにより、実際に信頼性向上につながるアクションを洗い出したり、策定することができます。

例えば、現状の構成の耐障害性は向上できないか、対応完了までの時間は短縮できないか、対応時の連絡・報告・相談は問題ないか、備えているドキュメントに不足・更新不備はないか等を話し合います。

具体的にVesselチームでは、まず出題者が作成した障害シナリオを公開します。

その後、いくつかのふりかえりフレームワークを使いながら、実際のふりかえりを実施していきます。よく知られたものでは、KPT (Keep, Problem, Try) や YWT (やったこと、わかったこと、つぎやること) などのフレームワークを使っています。なお、Vesselチームでは、ふりかえりフレームワークの選定についても都度改良を行っています。

以下、YWTでのふりかえり例です (実例から抜粋)

- Y (やったこと)
  - 障害対応フローに従って対応することを意識した
  - 開発者に障害原因となった変更の意図を確認するように意識した
- W (わかったこと)
  - どこから調査を開始すればよいか迷う
    - 事象に応じたチェックリストとか欲しいかも
  - きちんとアラートに気付いていただけたので、シナリオで用意していたアプリ開発者からの問い合わせを実施せずに済んだ
- T (つぎやること)
  - ガードレールの強化について議論する
  - HTTP Response code の分布についての異常検知する

YWTでは、それぞれで発表・補足しながら、最終的にT (つぎやること) を洗い出します。 これをもとにNext Actionを策定していきます。

Next Actionの決定

ふりかえり実施後は T (つぎやること) からNext Actionを決めます。

Vesselチームでは、T (つぎやること) で出てきた課題に対し、事前に策定してあるトレードオフスライダーに沿って優先度を割り当てています。

このうち実際に作業が必要なものは、この時点でタスクチケットに切り出し実際の行動に落とし込みます。

T (つぎやること) が多く出過ぎたら、タスク化しない判断も必要でしょう。こういった優先度の考え方は、チームで既に合意しているものをそのまま活用すると良いと思います。

いずれのフレームワークを使ったふりかえりにするにせよ、VesselチームではNext Actionは必ず決めるようにしています。この実践により、障害に耐性のあるシステムやチームを目指しています。

障害注入の事例

ここからは、具体的な障害訓練の内容について話します。まずは、実際の障害訓練で注入したいくつかの障害を紹介します。

事例1: 必要なコンポーネントを欠損させる

システムの稼働に必要なDeploymentやStatefulSetを意図的に削除して、一部の機能を停止させます。

例えば、アプリケーションのデプロイ操作に必要なコンポーネントを削除して、開発者に影響が出るような障害を注入します。

出題のポイントは、一部のユーザ影響のない機能の欠損にアラートや監視の仕組みで気付けるか、コンポーネントの欠損を修正できるか等です。

障害注入では、Kubernetesやその他コンポーネントによるAuto Healingの動作に注意が必要です。上記が働く状態でコンポーネントを欠損させても、Kubernetes上で自動的に復旧し障害とならない可能性があります。

事例2: 内部通信用のネットワークのファイアウォールを誤って封鎖する

ファイアウォールに対し、内部の通信で必要となる経路に誤った拒絶ルールを追加する、また設定されていた許可ルールを削除・停止します。

これにより内部の通信を意図的に封鎖してしまいます。GCPをお使いの場合は、以下のようにVPCネットワークのファイアウォールルールを一時停止することができます。

• ファイアウォールルールの編集の最下段

出題のポイントは、ネットワークが一部不通となった場合にユーザ影響を緩和できるか、ネットワーク設定に関するミスオペによる障害に対応できるか等です。また、冗長設計を取っている場合はユーザ影響が出ないことも考えられますが、こういった一部のネットワーク障害にきづけるかもポイントになります。

事例3: 誤ったコンテナイメージ名を指定する

一部のコンポーネントに対し、誤ったコンテナイメージURLを指定することで、意図的にImagePullBackoffを発生させます。

これは、コンテナイメージURLで指定されたレジストリからイメージが削除されてしまった場合を想定しています。

例えば、あるパブリックリポジトリで提供されていたイメージが、運用の都合上アーカイブされてしまうと言った自体がこれにあたります。

出題のポイントは、ImagePullBackoffの原因にきづけるか、コンテナイメージURLを適切なものに設定できるかになります。

事例4: IAMの権限を誤って制限する

内部の動作で必要なIAMの権限から、意図的にロールデタッチするなどが考えられます。

例えば、GCPにおいてはCloud Monitoringにメトリクスを書き込むためには、ロール「roles/monitoring.metricWriter」が必要になります。これを必要なIAMからロールデタッチして、メトリクスの書き込みを無効化するなどが考えられます。

出題のポイントは、やはり一部機能の欠損にきづけるか、それがIAMの設定不備によるものであることに気付けるか等になります。後者は監査ログ等から判断することができるため、こういったログの扱い方の訓練にも適切です。

事例5: オペレーションの方法を忘れる

内部の設定変更や運用ルールを忘れた場合を想定した出題です。

出題者が被訓練者に対して、「運用ルールを忘れたので代わりに作業をしてほしい」旨のメッセージを送信します。

これは運用ルールを正しく運用できるか(忘れていないか)の確認として利用できます。また、運用ルールに関するドキュメント不備の確認・修正や、ドキュメントそのものの拡充にも利用でき、属人化の排除に役立ちます。

学びと改善

障害訓練を通しての学び

前段で述べたように、Vesselチームでは月1回の頻度で障害訓練を行っており、ふりかえりも実施しています。

この訓練を通して、様々な学びがありますが、ふりかえりで明らかとなったものを整理してみます。

• 作業前の関係者への連絡が十分でない、ステークホルダの事情を考慮できていない
• 一部のコンポーネントの障害がアラートや監視で検知できていない
• 障害対応に関するドキュメントの整備が不十分
• 耐障害性を高めることができる構成に変更できる部分がある
• 緩和作業を行うタイミングを明示しておきたい

このように、障害訓練ではふりかえりを通じて様々な学びや改善につながるアクションを見つけることができます。上記のような課題は、実際にVesselチームでも改善タスクが実施されています。

また、障害訓練を定期的に実践すること自体が、障害に対する自信につながります。ひいては、実際の事態にも冷静に対応することができるチームやメンバの育成につながると考えています。

運用改善につながった事例

実際に運用改善に繋がった事例として、障害ドキュメントの整備があります。

あらゆる障害を想定してドキュメントを整備することは不可能ですが、障害時に落ち着いて動くための情報を集めておくことはできます。

例えば、以下のようなものの拡充を進めました。

• 障害対応フロー
  • どのような障害発生時に誰に連絡が必要か、どんな対応が必要かを示すフローチャート
• 障害のトリアージフロー
  • 上記の障害対応フローに入れ込む形で、障害対応完了までの即応感を客観的に把握できる仕組みを導入
• 障害時に見るべきダッシュボードやログ・メトリクス
  • リンク集として整備、即座にログ・メトリクスにアクセスできるようにする
• ドキュメント集
  • 障害対応時に必要な運用ドキュメントに検索不要でアクセスできるようにする
• 過去事例・ワークアラウンド
  • 過去と同様の事例の場合、そのまま作業に活かすことができる

その他にも、アラートの拡充や耐障害性のある構成に変更する、障害が広範に波及しない仕組みの導入など、様々な運用改善が行われています。

今後の障害訓練の検討

実障害時の報告・連絡を想定した訓練

日経では、障害管理ツール hawkeye を内製しています。

このツールの運用については、日経SREの取り組み2021年版も合わせてご覧いただければ幸いです。

このツールは、障害時に障害対応チャンネルを自動でオープンしたり、対応メンバを自動アサインするなど、障害対応そのものを管理できるツールとなっています。 また、ポストモーテムという形で、障害の振り返りや再発防止に向けたアクションの決定とトラッキングを円滑に行うこともできる仕組みとなっています。

現状の障害訓練では、Slackの会話ベースで対応を行っていますが、これを徐々にhawkeyeを利用した形に変更したいと考えています。

これにより、実際の障害時と同じツールを使った報告・連絡を体験できます。普段から障害管理ツールの利用に慣れておくことは、実際の障害時にツールの使い方で手間取ること無く、対応に集中できるようになる点で重要です。

カオスエンジニアリング基盤の導入

これまでは人手による障害注入をメインに訓練シナリオを作ってきましたが、注入すべきポイントや方法を考えるにも限界があります。

また、人手での障害注入はミスオペレーションを模した問題が多くなりがちであり、リソースの劣化や通信の途絶など、開発者のオペレーションによらない障害を再現することが難しいです。

こういった課題を解決するために、Vesselチームではカオスエンジニアリング基盤の導入を検討しています。

具体的には、GremlinやLitmus、Chaos Meshなどを考えています。

これらを導入することで、実際の障害により近い状況を引き起こし、障害への対応力をより高めることができると考えています。

おわりに

GKEベースのアプリケーション基盤 Vesselの開発チームで実施している障害訓練を紹介しました。

日経では、報道機関としての使命を果たすべく、いつ何時でも、安定した信頼性の高い運用基盤の提供を目指しています。

障害訓練は定期的に行うことで、チームメンバのナレッジの涵養、障害対応への手順の再確認、そして対応への自信を身につけることに繋がります。

本稿が皆さまの障害訓練の参考になれば幸いです。

日本経済新聞社では、先進かつ信頼されるメディアを目指してSREエンジニアを募集中です。ご興味をお持ち頂けましたら、カジュアル面談やインターンもやっておりますので、ぜひご連絡いただければ幸いです。

参考文献

[1]: Betsy Beyer, Niall Richard Murphy, et al., "The Site Reliability Workbook", https://sre.google/workbook/.