【レポート】Chaos Engineeringという考え方　– ChaosConf2019 recap-

2019/11/14 登壇スライドを追加しました。

こんにちは。AWS Loft好きなKyoです。

先日参加したGameDayでChaos Engineeringに興味をもったので、ChaosConf2019 recapに参加しました。 その中のセッション「Chaos Engineeringという考え方」についてレポートします。

登壇者

NTTコミュニケーションズ株式会社

小倉真人 様

概要

Chaos Engineeringの基本的な知識や考え方を、 Chaos Confに登壇した企業が語った内容を併せてお話します。

登壇スライド

レポート

カオスエンジニアリングとは

• システムに対し、意図的に障害をおこすとこで、障害時のシステムの振る舞いを把握するアプローチ
• 意図的に引き起こされた障害により問題が生じた際は、問題を治すことでシステムをより強固なものにすることができる(Resilience)

Resilience: はね返り、とび返り、弾力、弾性、(元気の)回復力

カオスエンジニアリング≒予防医学や疫学

なぜカオスエンジニアリング

• システムのすべての状態を把握するのは不可能
• 意図的に障害を起こすことで、開発/運用が意図しない障害を引き起こす
  • 影響範囲の把握
  • 修正によりシステムを安定したものに(Resilience)

カオスエンジニアリング ≒ 障害試験？

言葉の定義

• Failure testing: 故障時に正しく動くことを確認する手段
• Fault injection: 障害時の状態をテストするためのアプローチ
• Chaos Engineering: 新しい情報を作り出すためのアプローチ

カオスエンジニアリングとFailure testing, Fault injectionは重複する部分が多い

改めてカオスエンジニアリングとは？

○: 新しい情報を作り出すためのアプローチ

△: Resilienceの確認や証明するアプローチ

そもそもテストとは？

テストとはエラーを見つけるためにプログラムを実行する過程（Myersによる定義）

(おそらく以下が出典かと思われます。)

Software testing is a process, or a series of processes, designed to make sure computer code does what it was designed to do and that it does not do anything unintended. （GJ Myers, The Art of Software Testing より引用）

問題のタイプの分類

理解度	データ・経験・知識	内容
Unknown	Knowns	問題として起きてないが、解決方法が明確なもの。すぐknown knownsにできるもの
Known	Knowns	問題と解決方法を知っている。完全に理解した。
Unknown	Unknowns	何が起きるのか知らない。起きてから対応が必要。
Known	Unknowns	問題として知っているが、解決策がわからない。仮説を立て、テストと実験をくり返しチームで解決すべき問題

Chaos Engineeringの役割

• Unknown knowns => Known Knowns
• Unknown Unknowns => Known Unknowns

Fault injectionの役割

• Unknown Unknowns => Know Unknowns

Failure testingの役割

• Known Knownsの確認

分散システムに限らないカオスエンジニアリング

• PRINCIPLES OF CHAOS ENGINEERING
• カオスエンジニアリングの原則 （言語が異なるだけで同じドキュメントです）

Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

• 英語版の序文からは過去あった「distributed」という文字が消えている（2019/11/12現在で日本語版にはまだ残っている）。

モノリシックなアーキテクチャへの適応例

カオスエンジニアリングの効果

ナレッジをシェアし、共感を産む

障害時何が起こるか知っていますか？

• RegionもしくはData Centerの障害
• Message QueueのQueueのロスト
• サービス間のレイテンシが増大
• などなど

Open Chaos Experiment Catalog

• カオスエンジニアリングで何が起こるかをまとめたカタログ
  • Kubernetes, Azure, AWS など情報は色々

避難訓練的に障害を発生させ、オペレーションを行うことは価値があるかもしれない

カオスエンジニアリングの組織への適応

• 企業も分散システムである
• 一番複雑なのはソフトやハードではなく人間
• 注入する障害の例
  • チームの重要人物に発言をさせない
  • メール等でのレスポンスを極端に遅くする（レイテンシ）
  • 嘘をつかせる

組織に対してカオスエンジニアリングを適応することで、組織のSPoF(単一障害点）が明らかになる

カオスエンジニアリングを3行でまとめ

• 新しい情報を作り出すためのアプローチ
• ITだけでなく、人間も含んだ広い意味でのシステムに適応可能
• 学びの場、ナレッジを共有する方法

所感

Gamedayの際にも感じましたが、カオスエンジニアリングにおいて今何が起こっているかを正しく把握するためのモニタリング系は必須だと思いました。障害の種類ごとのビジネスインパクトをモニタリングできれば、効率的なシステム改修が行えると思われます。

異分野の話にはなりますが、医療現場で問題になっている病原菌の薬剤耐性獲得という現象があります。これは、抗菌剤（菌にとって致死的な障害）に晒された菌が変異によって自身の薬剤の排出系や分解系を強化することで起こります。この現象はカオスエンジニアリングとその後のシステム改修によく似ているのではないかと思いました。企業もシステムであるという話のように、生物をシステムと見なすとエンジニアにとって新たな気づきに繋がるかもしれません。

以上、何かの参考になれば幸いです。