Chaos Engineering（カオスエンジニアリング）導入にあたり
メディア統括本部 サービスリライアビリティグループ（SRG）の片岡です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
今回は、カオスエンジニアリングの導入を進める上で整理すべきこと、それに期待することについて記したいと思います。
実際に導入してからの気づきや詰まったところなどは続編として投稿していきたいと思います。
カオスエンジニアリングとは
Netflix の Chaos Monkey の開発から始まり、障害を前提としたシステム構成を目指す考え方（Design for Failure）が広がりました。
パブリッククラウドの急速な普及、マイクロサービス構成など、システムが複雑化し、その変更は早く予測不可能な障害の可能性が高まっています。
そこで、自ら障害を注入し、未知の障害に対するシステム（サービス）の弱点を洗い出し、レジリエンスの確保を目指すことができるのがカオスエンジニアリングとなります。
本番導入されているところもありますが、ステージングまでの導入に留めているところや、導入したいがまわりの反対が多いところと、様々な事情により上手く導入が進んでいないところがまだまだ多いようにも見受けられます。
障害を注入するというと不安や反対が強いですし、無闇矢鱈に障害を起こすことをイメージされることもありますが、”注入する障害自体はコントール可能”なので、十分な検証を行うことでその不安や反対も乗り切れると思います。 導入することだけを目的に置いてしまうと、本番環境でそれによる余計な障害を引き起こしてしまうなど、本来の意義や目的を失ってしまう可能性があります。
機能するまではそれなりに長い道のりだと思いますが、機能することで我々が解決すべき課題が明確になり、サービス信頼性の向上につながると考えています。
導入にあたって
今回の記事では実際にプロダクトに導入するところの話はありませんが、自分が導入の対象している弊社のOSSプロダクトである Bucketeer （フィーチャーフラグマネジメント・A/Bテストプラットフォーム）のプロダクトオーナーの方とはBucketeerの信頼性を高める目的としてカオスエンジニアリングによって得たいものについてすり合わせを行いましたので、簡単にまとめたものを記します。
- SLI/SLO の具体的な根拠を示し、常に担保できる状態にしたい
- レジリエンスを高め安定性を利用者に証明したい
また、カオスエンジニアリングにおいては多くの活用メリットがあります。例えば、障害対応訓練やMTTRの削減、脆弱性検出、SPOFの検証、直感的に解決したと思っている課題に対してよいアプローチとなります。
そこでは次の5つの原理が定義されています。
- 影響範囲を局所化する（Minimize Blast Radius）
- 定常状態における振る舞いの仮説を立てる（Build a Hypothesis around Steady State Behavior）
- 実世界の事象は多様である（Vary Real-world Events）
- 本番環境で検証を実行する（Run Experiments in Production）
- 継続的に実行する検証の自動化（Automate Experiments to Run Continuously）
まずは定常状態の定義、仮説の設計、変数の定義についてプロダクト側とのすり合わせが特に重要であると感じました。
またカオスエンジニアリングを進める上で特に以下の準備がとても重要だと考えます。
- 本番とステージング（検証用）環境との差異がないこと
- ロギング、メトリクス、トレース
- 負荷試験環境（本番同様のリクエストが流せる環境）
- SLI/SLO の導入
原則に従って完璧に進めているつもりでも、これらが疎かになってしまっては、導入にかかった労力がすべて無駄になってしまいます。
逆に言えば、カオスエンジニアリングの導入を進めることによってSREの活動において足りていないものが洗い出され、整備することにも繋がります。
そして今回 GKE で動くサービスに対して導入をしたいということもあり、 Chaos Mesh を採用しました。
その他、注目したカオスエンジニアリングツールも記しておきます。
Managed Service
- Gremlin
- AWS Fault Injection Simulator
- Azure Chaos Studio
Hosted Service
- Chaos Mesh
- Chaos Toolkit
- Litmus Chaos
- PowerfulSeal（Kraken）
カオスエンジニアリングに限った話ではありませんが、ツールがすべてを解決するわけではないので、カオスエンジニアリングの活動・運用を通して、普段の経験則や習慣を見直すなど、視野を広げ、チーム全員でシステムと向き合っていくことが重要だと思います。
Chaos Mesh を触ってみる
Chaos Mesh を使って簡単な障害をローカルで試してみます。
Chaos Mesh では、Kubernetes や Hosts に対して様々な障害を注入することができます。
特にやっていきたいところとしては
- Simulate GCP Faults（GCPインスタンスの障害シナリオをシミュレート）
- Simulate Pod Faults（Pod またはコンテナの障害シナリオをシミュレート）
- Simulate Stress Scenarios（CPUやメモリへ単純な負荷をかける）
- Simulate HTTP Faults（HTTPリクエスト、レスポンス中の障害シナリオをシミュレート）
あたりです。
では試しに、Nginx の Podが3つ動いている環境で Pod Fault の Pod Kill を試してみたいと思います。
対象の Namespace を default とし、対象のラベル app: nginx を指定し、ランダムに 1 Pod だけ Kill するような障害を注入します。
すぐにpodがkillされたのが分かります。
Pod が落ちた原因が本当に Chaos Mesh で寄るものかはイベントを見ることで分かります。
障害タイプによりますが、Duration の指定をしたり、継続実行、スケジュール実行なども可能ですので、即時に単発で実行するだけではなく、定期的（長く）障害を注入し続け、負荷試験と組み合わせるなどすることで、よりシステムの挙動が捉えやすくなると思います。
今回は非常にシンプルな例を上げてみましたが、このときにシステムがどういう挙動を取るのか、常にアクセスがある状態ではリクエストはどうなるのか、レイテンシはどうなるのかなどに注目し、システムの理解を深めていくことができます。
そのためにも、先程上げた事前準備や仮説の設計が非常に重要となってきます。
終わりに
カオスエンジニアリングを始めるにあたって、以下の記事や書籍が非常に参考になりました。ぜひ興味ある方は読んでみてください。中途半端に終わらないように引き続き学び、思考していきたいと思います。そして、これからは実践編として検証したことや、運用を通してハマったことなども記事にしていけたらと思います。
※ カオスエンジニアリングの導入に興味がある方、すでに実践されている方はぜひ情報交換させていただければと思います。
参考
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
