はじめに
こんにちは。
Sansan事業部プロダクト開発部に所属しておりますインフラ領域のリードエンジニア兼プロダクトマネージャーの岩下です。
先日12月に開催されました re:Invent 2019 に今回も参加させていただきました。
相変わらず圧巻としか言いようのない規模でしたが、前回より15000人ほど増え、65000人ほどの人々が参加されていたと Keynote で発表されていたことを覚えています。
参加にあたって、以下の2点を個人的なテーマとして設定してみました。
- 今取り組んでいることは正解なのか答え合わせをする
- レベルアップのためのインプットを得る
上記を念頭に置きつつ事前にイベントカタログを眺めてみると、 Resiliency という単語が目に付いてしまう自分に気づきます。
昨年発生した AWS の AZ 障害の経験から Chaos Engineering の実現性を模索していたという背景もあり、この手のセッションには必ず参加しようと心に決めたのでした。
結果どうだったかといういうと、表題の通り Chaos Engineering の実践に本気で向き合おうと考えるに至っています。
Chaos Engineering とは
Chaos Engineering とはシステムの一部に偶発的な障害を発生させ、復旧作業を行うことでシステムや組織の不備を洗い出し、システムの信頼性を向上させる取り組みとして知られているように思えます。
Netflix 社が2015年に公開した文書 Principles of Chaos Engineering から広く認知されはじめたものと認識しておりますが、この文書によると Chaos Engineering は以下の様に定義されています。
経験に裏打ちされたシステムベースのアプローチは、分散システムの混沌な状態を大規模に対処し、現実的な条件に耐えるシステムの高い信頼性につながります。 私たちは、制御された検証においてそれを観察することによって、分散システムの動作について学びます。私たちはこれをカオスエンジニアリングと呼んでいます。
以上より、とりあえず破壊しても壊れないシステムを構築しよう！という意味ではなく、学びを得ることに軸足を置いているということがわかります。
本質が何であるのか、そのヒントを自分は re:Invent で得られたように思います。
参加したセッション
Improving resiliency with chaos engineering と題されたセッションに参加しました。
amazon.com における Chaos Engineering をテーマとしたセッションです。
以下、その内容をご紹介したいと思います。
Amazon における Chaos Engineering の歴史
セッションの導入は Amazon における Chaos Engineering の歴史からです。
ざっくりですが、以下のようなものでした。
- 2000年代初頭に Jesse Robins というエンジニアが Amazon に入社
- その後、 amazon.com の Master of Disaster なる称号を獲得している
- 数々の火消しを担当していたことから、障害における訓練を模索していた
- ある時、本番データベースが削除されるという事象が発生
- この時、当事者は何も訓練を受けたことがなく、ただ混乱していたばかりだった
- そんなこともあって Amazon 社としても障害におけるプラクティスを構築したいという欲求があり、2004年に Game Day なるものを開始した
称号が用意されるほどですので、Amazon におけるインシデントへの向き合いは組織的に非常に高いプライオリティであることが伺えます。
Game Day とは
本番環境で failure injection -> recovery を行うイベントとのことです。前述の Jesse Robins 氏が企画、命名したそうで、世界的に類を見ない最高のネーミングと絶賛されていました。
なお、Amazon Prime Video では月次程度の頻度で実施しているそうです。
Rise of the Monkeys
2011年に Netflix 社が投稿したブログ The Netflix Simian Army より、かの有名な Chaos Monkey や Chaos Gorrila など、 Netflix 社の サル軍団 が紹介されます。
サル軍団の攻撃力は☆5 SSRと表現できるほど超大であるため、その存在感に目が行きがちですが、 Chaos Engineering の本質はツールではないということが強調されます。
曰く、
Chaos Engineering は目的なくランダムに破壊することではなく、管理された環境を破壊し、十分に計画された実験から予期しない状態に耐える信頼性を構築するものである (意訳)
とのことです。
Chaos Engineering の前提条件
以下のスライドは本番環境でよくある障害として紹介されています。
Chaos Engineering でこれらの問題を炙り出すこともできるでしょうが、それぞれについての適切な対応方法がまるでなされていなければリカバリが大変すぎて学びを得るどころではないというのは容易に想像できます。
セッションの中では何らかのアプリケーションが依存しているサービスが停止した際に、 retry のループが嵐となり、NW や Connection を食い尽くし、二次障害を引き起こすといった点について熱く語っていたことが印象的でした。
また、さらっと AWS Well-Architected Tool についても触れられていましたが、たしかに前提条件の確認という意味において有用だろうと思われました。
Chaos Engineering のフェーズ
Chaos Engineering は以下のサイクルで実践するとよいと紹介されています。
STEADY STATE
システムにとっての定常状態を定義することは非常に重要です。
定常状態の定義なくしてシステムが正常に稼働しているかどうかを判断することは困難となるためです。
定常状態を定義するためのメトリクスとして、セッションでは以下の提言がなされています。
定常状態とは、システムの通常の振る舞いを意味する。CPU やメモリなどの内部的なメトリクスではなく、顧客の操作や経験に基づいたメトリクスを採用するとよい。
Amazon.com での例として、注文数 はよい指標であるとしています。
注文数が下がるということはシステムになんらかの問題があることを示唆しており、場合によっては検索パフォーマンスの劣化が原因であることもある、という具合です。
このような因果関係を発見して初めて定常状態を知ることができるため、定常状態の定義はシステムによって異なり、かつ、見つけ出すことは簡単ではありません。
さらに、定常状態は変化するものであり絶対的なメトリクスではないことから、扱いに関しては注意を要するでしょう。
ただ、それでも時間をかけて定義することには多くの価値がある、と説いていました。
HYPOTHESIS
次に以下のような もし何かが起きたら を仮定します。
- もしロードバランサーが壊れたら
- もしRedisが遅くなったら
- もしCassandraのホストが吹き飛んだら
そして、これらの仮説に対して何が起こるのかをドキュメント化することを提案しています。
たしかに、起こりうるシナリオに対するドキュメントはシステムにとって重要な仕様書となりえますので、障害対応における強力な拠り所となる可能性がありそうです。
また、このドキュメントを作成するにあたりプロダクト、またはサービスに関係する人々を巻き込み、問題に対する当事者意識を高めることも重要でしょう。
実際のインシデント発生時に、その場で発散した議論をするより、事前に整理しておくことで対応のスピードとクオリティが変わるのは明らかだろうと思われます。
スライド中に記載されていた Make it Everyone's Problem というワード、とても強い想いが込められていたように感じました。
RUN EXPERIMENT
仮定したら、どこからどのように始めるかを決める必要があります。
そのシステムの歴史において問題となりやすい箇所はどこだったかを探り、小さく実験的に始めなければ、実際の被害が甚大となり、実験どころでは済まないことは想像に難くありません。
どうやるか、という観点においては Failre Injection = 障害状態の注入が有用であり、Failure Injection には以下の様な方法があるとされています。
- Application Level (Exceptions, Errors, etc)
セッション内の説明ではアプリケーションに対する異常系のテストとほとんど同義のように思われました。
アプリケーションに対してわざとエラーや例外を発生させるような操作を行い、期待した結果となるかを確認するということのようです。
ファイルアップロードを提供しているならば不正なフォーマットのファイルをアップロードしたり、データ連携を行うサービスに対して期待されていない値を注入したりといったことと理解しました。
- Host Level (Services, Processes, etc)
- Resource Attacks (CPU, Memory, IO, etc)
- Network Attacks (Dependencies, Latency, Packet loss, etc)
これらも想像しやすい Failure Injection であると思います。
ただ、障害は単一の問題だけで発生することは少なく、細かい複数の問題の組み合わせで初めて顕在化することがあると言及されており、一歩踏み込んだ観点であると感じました。
例えば CPU 負荷と NW レイテンシーが同時に上昇するというケースは起こり得そうなシナリオでありながら、実際に実験しているシステムはそう多くはないのでは？と想像します。
- AZ Attack
- Region Attack
これらはより大規模な Failure Injection ということでしたが、規模的には Disaster Recovery と言っても差し支えないと思われました。
実際に破壊するという過激なアプローチもありますが、 subunet 単位ですべての通信を拒否する、ルーティングエントリを削除する、DNSレコードを不正な値にするなどのリカバリしやすい方法から始めるのがよさそうです。
- People Attack
こちらは Failure Injection を実施する際に、当該箇所に詳しい人と連絡を取ることができないという縛りを設けて属人性をあぶり出します。
セッション内では そこに神がいない状況 と表現されていました。
当事者はかなりドキドキしそうですが、訓練として多くの学びを得ることができそうです。
実際に弊社内でのインシデント訓練において、復旧担当者となった自分も同じような境遇で対応を行いましたが、自分のシステムへの理解において、明らかに不足している領域がどこであるかが明確になったという経験があります。
なお、 Failure Injection を本番環境で行うにあたっては緊急停止、またはロールバック戦略を事前に練っておくことが強く推奨されています。
特に State についてはロールバックできないケースがあることから細心の注意が必要です。
VERIFY
実験を行ったら次は検証です。
障害対応は多くの関係者と正確な情報共有を行う必要があるため、組織的な課題を炙り出すこともできるでしょう。
セッションでは以下の観点で検証を行うとよいとされています。
- Time to Detect?
発生した問題をいつ検知したかを確認します。
なんらかの理由でアラートを受け取れず、障害状態となっていることを Twitter で知ったというケースがおもしろおかしく紹介されていましたが、想像すると恐ろしいですね。
- Time for Notification And Escalation?
- Time to Public Notification?
ビジネスサイドとのコミュニケーションチャンネルの作成、顧客への報告といった組織内のイベントを検証します。
指揮系統の健全性、必要なコミュニケーションの粒度など、発生した事象がどのようにハンドリングされたかを振り返ることによる学びは組織的なインパクトをもたらす可能性があります。
- Time for Graceful Degradation to kick in?
- Time for Self-Healing to Happen?
- Time to Recovery? Partial and Full?
- Time to All-Clear and Stable?
いずれも Failure Injection の検証において極めて重要な項目と思われます。
これらを取得できないのならやらない方がいいレベルと感じますし、ログ、及びタイムラインの記録は改めて重要であると認識を新たにしました。
- Postmortem
以上の検証結果から Postmortem をまとめます。
Postmortem といえば Google による SRE で取り上げられていますが、 Amazon としては以下の観点であるようです。
- 何が起こったか
- ビジネスにどのようなインパクトを与えたか
- 原因は何か (非線形の5回のなぜ)
- どんなデータに助けられたか
- 何を学んだか
- 是正措置
IMPROVE
検証が済んだら改善です。 Postmortem で挙げられた是正措置を行う必要があります。
Amazon では週次で Operational Metrics Review というミーティングがあるそうで、是正措置のフォローアップを行っているそうです。
改善において銀の弾丸は存在しない という言葉もありましたが、地道に改善活動を行う中で各種自動化ツールを生産しているとのことです。
このようなミーティングは各社様々なようで、 Google では SRE 本にもあるように Production Meeting 、はてなでは Performance Working Group といった形で実施されていることが観測されます。
また、ツールありきではなく、顧客ために何を提供するかという観点で Chaos Engineering を実践するためのツールを構築することが重要であり、ツールはシステムによって異なると強調していたことが印象的でした。
まとめ
Chaos Engineering はシステムにとっても人々にとっても挑戦的であるため、始めることは非常に困難であると認識させられます。
Chaos Engineering が堅牢にするのは実はシステムではなく、人々である と言われていますが、文化的な変革を迫られるのは必然のように感じられます。
ただ、長期的な視点を持って Chaos Engineering に臨む文化を醸成できたら、その組織は強い弾力性を獲得できるのだろうというイメージを持つことができました。
顧客目線で定常状態とそのメトリクスを定義し、仮説を立て、小さく始めてみるということが最初のステップとなりそうです。
極めて難しい施策ですが、長期的に向き合っていきたいと思った次第です。
なお、このセッションの後半では Amazon Prime Video において Chaos Engineering をどのようにオンボーディングさせたかという話題に移ります。
非常に興味深い事例なのですが、長くなってしまったのでこの辺りで終わりたいと思います。
ここまで読んでいただきましてありがとうございました。
参考にさせていただいた記事
Chaos Engineering やっていく宣言
【Chaos Conf 2019 視察レポート】Chaos Engineeringの盛り上がりを実感
【開催報告】 Chaos Conf 2019 recap 勉強会
