カオスエンジニアリング
障害をプロアクティブに発生させ改善させることで学び、改善のサイクルを回す。
ネットフリックスでは、Chaos Monkeyという、インスタンス一つをランダムに停止させるツールや、
Chaos Kongという、リージョン一つを停止させるツールがある。
主に、次の情報源から、実際にカオスエンジニアリングをやることは無理だとしても改善のヒントとして学べる観点はないか、という点でまとめた。
関連情報
書籍
カオスエンジニアリングの原則
過去qiitaのバズ記事
いまいち馴染みがなかった、プロアクティブという言葉の意味
1.本番環境を壊す？
本番環境を壊して検証する、というイメージが強い。実際にそれをやっているビッグテックもあり、LinkedinのLinkedoutなど各社はそれ用のツールを準備したり、カオスツールと呼ばれる、Gremlinなどのカオスを発生させるツールがある。
これは一面では正しいが、そのようなマイナスな言い方ではなく、プロアクティブに障害によるフィードバックループを回すこと全般を指すと理解できた。
あらゆるシステムは成功と失敗を本質的に含んでいる。
失敗しないのだとしたら学んでいないということ.
p.94
2.人間のカオス ~カオスはシステムだけではない。~
書籍に、人間的な要素という章があるように、カオスエンジニアリングの領域は人にも及ぶ。
誰かだけがこのことを知っている、他部署が関わる、といったわかりやすいものから、
誰かはスラックは見るが反応が遅いといったものまで。
これらは全て実際の障害に影響する。
3.シンプルなシステム？
シンプルなシステムは氷山の一角である(p.93)
小さなウェブサイトであっっても、運用者、ブラウザ、インフラ、OS、ストレージなど、水面下ではたくさんの複雑性が存在していて、考慮することが多くある。
4.人々はループの中にいる。
実験手法を考える上で、このような観点があった。
人々はループの中にいる。
ループであれば自動化できるか、と考えるがそうではない。
次にようなことを考える必要がある。
(自動化における)設計者の誤りが、動作上発生する問題の主な要因となる可能性があります。
(自動化における)設計者は、運用者を取り除こうとしますが、どうやって自動化したら良いか設計者がわからないタスクを引き続き運用者に任せ続けます。
p.172
そうそう、これだよね、という感じ。
これは Ironny of automationという、論文にも詳しいらしい。
5.どのように障害を注入するか。
具体的な注入方法がなるほど、という感じだった。
p.254
・正常な動作を示しているシステムの計測可能な出力として、定常状態を定義する。
・定常状態に関する仮説を発展させる。
・実世界のインシデントを反映するような変数を導入する。
・定常状態からの逸脱を障害として検知することにより、仮説を検証する。
これで興味深いと思ったのは、定常状態を定義できるということだ。
ここでの例だと、監視システムで、QPS(単位秒のクエリ件数)とレイテンシ、CPU、メモリに関する観測値を使っていた。ある一つのkey valueストアのレイヤーを分離すると、まずQPSが下がり、そこからすぐに回復して、安定状態に移る、という観測は、安定状態、を定義することでできる。
次に、故障注入手段について見ていく。
5-1.アプリケーションによる故障注入
p.256
| 目的 | 手法・ステップ |
|---|---|
| 耐障害性・復旧 | プロセスをランダムに、強制的にkill(SIGKILLを使用)するか、グレースフルにkill(SIGTERMを使用)してから上げ直す |
| プロセスをSIGSTOPを使用して停止後、SIGCONTで再開する | |
| 並行処理時のバグ | reniceを使用して、プロセスの優先度を変更する |
| pthread_setaffinity_npを使用してスレッドの親和性を変更する |
5-2.CPUとメモリにおける故障注入
p.256
| 目的 | 手法・ステップ |
|---|---|
| 飽和状態とパフォーマンス問題 | while(true){}ループを回し続けてCPUの限界に達させる(100%の使用率) |
| 制限された条件下でのパフォーマンス | cgroupを使用して特定のプロセスのCPUとメモリ使用率を制御する |
5-3.ネットワークにおける故障注入
p.256
a. 完全な分断：グループ1とグループ2は全く通信できません。
b. 部分的な分断:グループ1とグループ2は直接通信はできませんが、グループ3を通じて通信できます。
c. 片方向の分断：グループ1はグループ2に接続できますが、グループ2からグループ1へ接続することはできません。
ネットワークの他のパターン
・tcを使ってネットワークレイテンシを増加させる。
・tcを使ってネットワークパケットの順番を変える。
・帯域を使い切るようなアプリケーションを起動する。
・プロキシを使って特定のTCP接続を制御する。
・iptablesを使って特定の接続を制限する。
5-4.ファイルシステムの故障注入
これは実現が難しく、次のような実現例が紹介されていた。
アプリ↔️(I/0フック) ↔️マウントされたディレクトリ↔️(ループバック)↔️故障注入ツール↔️ループバック
これら5-1,2,3,4は、普段、障害が起きた後に修正してテストするような時にも、再現するためのアイデアとして活用できるような内容だと思った。
カオスの自動化
上記のようなテストは、機能のリリース前の最終段階での故障の検証としても活用しうる。
書籍では、自動実験プラットフォームが紹介されていた。
最後に
カオスエンジニアリングをchaos monkey、kongレベルで導入できなくとも、観点として導入、活用する方法はある、有効なものだと思った。
カオスの自動化までできれば、かなりの有意義なものだと思う。