第84条
カオスエンジニアリング
一度も試されていない耐障害性は仮説にすぎない。予定を組もうと組むまいと、本番がいずれそれを試す。
心得
本番に壊される前に、自分で壊して確かめる
どうするか
依存先を一つ選び、それが落ちている間の定常状態がどうあるべきかを書き出す。そのうえで業務時間中に、中止スイッチと見張り役を用意して、本番でその依存先を取り除く。トラフィックのごく一部から始め、システムが持ちこたえてから範囲を広げる。落ちると見込んでいるサービスでは実験しない。
なぜ起きるか
フェイルオーバー、リトライ、冗長構成は、何かが壊れたときにしか動かない。だから障害と障害の間に劣化していく。設定がずれる、依存が増える、タイムアウトが変わる。そうした変化に、本物の障害が来るまで誰も気づかない。ステージングでは本番のトラフィックもデータも結合も再現できないので、そこでの試験から分かる、人が実際に使うシステムのことは期待するより少ない。定常状態についての仮説を立て、本番で意図的に障害を注入すれば、弱点は深夜3時ではなく、エンジニアが見ている平日の午後に表に出る。Netflix は AWS への移行初期に、インスタンスを無作為に落とす Chaos Monkey を作り、どのサービスにもインスタンスを一台失っても動き続けることを求めた。
実際にあったこと
2014年9月末、AWS は Xen の脆弱性を塞ぐため、EC2 のおよそ1割を急に再起動した。Netflix の本番 Cassandra ノード2,700台超のうち218台が再起動され、22台は戻らなかったが、その週末のダウンタイムはゼロだったと Netflix は報告した。チームはその1年前から Cassandra に Chaos Monkey を走らせていたことを理由に挙げた。それで故障ノードを見つけて置き換える自動化を作らざるをえなかったのだ。
記録を読む当てはまらなくなるとき
まず害をなさない：実際の顧客が頼っているシステムをわざと劣化させれば、その顧客の信頼を削ることになる。同じ知見の多くは、障害注入テスト、ゲームデイ、設計レビューでもっと安く得られる。もろいと分かっているシステムで実験しても分かっていたことを確かめるだけなので、まず直す。
出典
『Principles of Chaos Engineering』(principlesofchaos.org, 2019 年 3 月最終更新)。定義、定常状態の仮説、本番での実験、影響範囲の最小化の出典。Netflix Technology Blog『5 Lessons We've Learned Using AWS』(2010) は Chaos Monkey を初めて紹介した記事。
原典を読む引用するとき
Hammurabi『第84条 カオスエンジニアリング』 https://kanywst.github.io/hammurabi/ja/laws/chaos-engineering/
BibTeX
@misc{hammurabi-chaos-engineering,
title = {カオスエンジニアリング},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 84},
url = {https://kanywst.github.io/hammurabi/ja/laws/chaos-engineering/}
}