カオスエンジニアリングとは 〜AWS FISの使い方に悩む人のために〜

AWS FISの紹介記事はちょくちょく転がっているのに ,そもそもカオスエンジニアリングについて知見がないからどうやって運用に組み込めばいいかわからない って人，多いですよね． 僕もその1人です.本記事ではカオスエンジニアリングとは，というのをざっくり把握して詳しく調べに行くための基盤になるようなサイトをざっくり紹介できればと思います．

What is “Chaos Engineering” ?

カオスエンジニアリングは本番環境のシステムに対してわざと障害を発生させ，復旧を繰り返すことによって

「このシステムは障害に耐えるシステムだよ．だって実際障害を起こしてるんだけど動いてるでしょ？」

という証明をするためものです．あらゆる側面の障害からのシステム自動復旧システムを開発せねばならない為，カオスエンジニアリングに取り組むことはシステムの可用性の強化につながります．

Netflix社が導入することで有名になりましたが，確かにNetflixで映画を見ている間にも「障害は故意に発生させられてる．けど快適に映画を見れてるな🤔」って思えたらいいですよね！

What is “Chaos” ?

カオス理論という言葉を聞いたことがあるでしょうか？

カオス理論（カオスりろん、英: chaos theory、独: Chaosforschung、仏: Théorie du chaos）とは、力学系の一部に見られる、数的誤差により予測できないとされている複雑な様子を示す現象を扱う理論である。カオス力学ともいう[1][2]。 wikipedia “カオス 理論”

こちらを見ると，きっと直訳の”混沌”とは違う印象をに感じられると思います．ざっくり捉えると，「ちょっとの変化から想像できない変化が起こる」というものです．

「蝶の羽ばたきが遠くの地で竜巻を起こすかもしれない」というバタフライエフェクト効果という言葉であれば聞き覚えがあるかもしれませんね．

カオスエンジニアリングにおいて

• 障害=蝶の羽ばたき
• 遠くの地の竜巻=分散システムの予期しない挙動

みたいに考えるといいかもしれません．

以下，カオスエンジニアリングについて調べるにあたって有用な資料を紹介したいと思います．

“Principles of chaos engineering” summary

この記事 ではカオスエンジニアリングの原則について言及されている. 日本語訳があるので，システムテストについて少しでも知見がある人は引用元を直接参照するのがいいかと.

カオスエンジニアリングの原則

• 通常の動作を示すシステムの測定可能な出力として「定常状態」を定義することから始める
• この定常状態は対照群及び実験群の両方で継続すると仮定する
• サーバのクラッシュ、ハードドライブの誤作動、ネットワーク接続の切断など、現実世界のイベントを反映する変数を導入する
• 対照群と実験群との間に定常状態の違いを調べることによって仮説を反証しようとする

個人的解釈

カオスエンジニアリングを実際に行う際の手法について言及されている.

• 実験対象の分散システムにおいて、どんな状態が正常かを事前に確認しておく必要がある.(カオスエンジニアリングを行った結果でわかるのは障害発生後の結果なので，対比させるパラメータの準備は不可欠である.)
• 対照群は(実験非対象)，実験群(実験対象)(文章まんま)
• 分散システムを運用する上で，「発生する可能性のある故障」を恣意的に発生させることができるようにする.プログラム上ではしっかり記述できているから上大丈夫といった考えではなく，「ネットワークを使っているシステムである以上ネットワークは故障する」といったシステム基盤自体を疑う考えが必要．
• 項目1との比較でシステムの可用性を評価する．

詳細な原則

どちらかというと実践する上での心得みたいな感じ

• 定常状態における振る舞いの仮説を立てる
• 実世界の事象は多様である
• 本番環境で実行する
• 継続的に実行する検証の自動化
• 影響範囲の局所化

個人的解釈

• システムの内部属性(こういう機能を持つとか)ではなく，測定可能なシステム出力(こういう振る舞いの結果を出す)に焦点を当てる． カオスエンジニアリングはシステムがどのように動くではなく，どう機能するかを検証するためのもの． (個人的には一番重要)
• カオス変数(原則の項目3つ目)は定常状態を破壊するものを考えると効果を発揮するの
• 本番環境，ステージング環境でも実際に運用されているか否か等の差異はある．本番環境を実験対象にするほうが，システムの実行の信頼性と現在の導入済みシステムの関連性の両方を保証するため，推奨される．(当然，障害発生後に元通りに戻せるような事前準備は不可欠)
• 継続的に振る舞いを評価するために，自動化すべき
• 本番環境での検証は顧客の不満を引き起こす可能性があるため，影響範囲を限定し，検証による被害が最小限に抑えられることを確認する責任と義務がある．

IEEE “Fault injection technique and tools” introduction

カオスエンジニアリングというものは昨今，Netflix社が導入することによって脚光を浴びるようになったものであるが，故意に障害を起こしてテストするという考え方自体は以前からも存在していたようです．

FISの名前にもある通り，fault injectionについても軽く調査をするとより広い視野でカオスエンジニアリングについて理解が深まると思い，古いジャーナルではあるが， Fault injection technnique and tools(2004) について触れます．

概要

Fault injection is important to evaluating the dependability of computer systems. Researchers and engineers have created many novel methods to inject faults, which can be implemented in both hardware and software. The contrast between the hardware and software methods lies mainly in the fault injection points they can access, the cost and the level of perturbation. Hardware methods can inject faults into chip pins and internal components, such as combinational circuits and registers that are not software-addressable. On the other hand, software methods are convenient for directly producing changes at the software-state level. Thus, we use hardware methods to evaluate low-level error detection and masking mechanisms, and software methods to test higher level mechanisms. Software methods are less expensive, but they also incur a higher perturbation overhead because they execute software on the target system.

コンピュータシステムの信頼性を評価する上で，障害注入は重要である. 研究者や技術者は障害注入のための手法を多く開発しており，それらはハード，ソフトウェアの両方で実装することができる.ハードウェアとソフトウェアにおける手法の違いは注入する障害がアクセスできるポイント，コスト，そして障害の規模がある．

ハードウェアの手法ではチップピンやソフトウェアではアドレスで」指定できない組み合わせ回路やレジスタなどの内部の部品に対して障害を注入することができる.

一方，ソフトウェアでの手法は，ソフトウェアの状態の変化を直接的に発生させることができるのに便利である.

それゆえ，低レベルのエラー検出やマスキングメカニズムの評価にはハードウェア手法，高レベルのメカニズムのテストにはソフトウェア方式を使用する.ソフトウェアの手法はコストが低い反面，ターゲットシステム上で実行するため，障害のオーバヘッドが大きくなる．

本ジャーナルを見るにあたって．

概要から見てわかるように，ソフト面とハード面にそれぞれ焦点を分けて，障害注入について触れ，これをどうやって実現するかについて詳細に述べられているジャーナルです．図面を見るだけで，障害注入をどの箇所に適用するかがざっくりわかると思います．

有名なジャーナルなので，先人たちが知見をわかりやすくまとめてくれています. ざっくり理解した場合は こちらの記事 を是非とも参考にしてください.時代観も合わせて必要な箇所をまとめてくれている記事です．

以下コラムです．

AWS DEV DAY 2019 Chaos Engineering 入門と実例

残念ながら当時の動画を見ることは叶わなくなっていますが，AWS JapanのFumiiko Hataさんが2019年に開催されたAWS DEV DAYにおいて Chaos Engineering 入門と実例 という公演をされていました.

AWS FISが登場する前であるため，Netflix社が提供するChaosMonkeyとAWSのコラボレーションを見ることができます．資料をぱらっと見るだけでもFISの設計思想にこういうのがあったのかなぁなんて想像がふくらむので是非ご覧ください．

O’REILLY Chaos Engineering

2020年末，O’REILLYが Security Chaos Engineeringというメディアを出した.こちらについて軽く触れます．(以下で紹介するものはO’REILLYのアカウント登録が必要になります. )

カオスエンジニアリングとは，今まで話に上がってきた通り，分散システムの可用性を評価するためのものでした．

本メディアはカオスエンジニアリングをセキュリティ分野に応用し，都度セキュリティインシデントに対して対処していくといった従来の考え方から，こちらから積極的にシステムの可用性を上げていく方法に転換することを提案し，応用の方法等をまとめています．

こちら の記事に要約が体系的にまとまっているので，ぜひこちらを参照してみてください.

今回のメディアの他に，2017年に出された Chaos Engineeringについてのメディアもあります．これも こちら の記事にまとまっているので，顔スエンジニアリング 自体により興味がある方は一緒に参考にしてください．

このレポートとは別に，O’REILLY本としての Chaos Engineering system resiliency in practice という本を2020年4月に発行しているので，英語に強い人は挑戦してみるのも…

まとめ

以上のようなカオスエンジニアリングの原則，何を用意し，何を目的とするかをざっくり把握した上でAWS FISを眺めてみると，FISはただインスタンスを止めたりするだけのツールじゃ無くなっているかと思います．

原則にあるように，実験テンプレートを保存し繰り返し実行したり,CloudWatchでFISの影響を監視して対照したり…といった具合にカオスエンジニアリング的な視線からこのツールを眺めれるようになっていればなによりです．それでは！