カオスエンジニアリング ―回復力のあるシステムの実践

4章Slackの惨劇シアター

Richard Crowley

元来、あなたのチームやツールにカオスエンジニアリングが備わっていないのだとしたら、一体どうやって始めたらよいのでしょう？　コンピュータが長時間にわたって稼働でき、しかも実際に稼働するはずという考え方で設計されたシステムに対してカオスを組み込むことは、とてつもなく大変で実現不可能なタスクのようにも感じられます。このような想定のもとに生まれた複雑なシステムは、昨今のクラウドネイティブのシステムと比べ、基盤となるコンピュータの急激な変化に耐えられない傾向が強いです。このようなシステムは、理想的な条件のもとではおそらく非常にうまく動くものの、障害発生時にはたちまち、ときに大惨事につながるような形で劣化してしまいます。

もしかすると、あなたはそのようなシステムの誇り高き所有者かもしれません。あらかじめカオスを受け入れるように設計されていなくても、システムの規模が拡大し、進行中の開発を通じて多くの処理をより速く、より信頼性高く行うよう求められれば、好む好まざるに関わらずカオスは確実にやってきます。すでに脅威が迫っている中で、システムを書き直す時間はありません。新しいカオスエンジニアリングの実践を古いシステムに適用することは、事態を悪化させることにも繋がりかねません。ここでは異なる戦略が必要となるでしょう。

本章では、必ずしもカオスエンジニアリングを念頭に設計されたわけではない複雑なシステムを、安全かつシステマティックにテストするための一つの戦略として、障害やネットワークの分断を、注意深く制御された方法で導入することについて説明します。これは自動化ではなくプロセスであり、ソフトウェアがどれほど脆弱かをチームが理解し、改善への機運を高め、予期される障害にシステムが耐えうるかを検証するものです。このプロセスを、Slackは2018年の初めから実運用しています。20回以上もの演習を通じて脆弱性が発見され、新旧のシステムの安全性が証明され、多くのエンジニアリングチームのロードマップに影響を与えました。 ...