Transform your business, transcend expectations with our technologically advanced solutions. Copyright © NTT Communications Corporation. All rights reserved. いつもニコニコあなたの隣に 這い寄るカオスエンジニアリング！ Mahito Ogura (2019/07/23) @Mahito

Copyright © NTT Communications Corporation. All rights reserved. 2 @Mahito (小倉 真人) NTT Com 技術開発部 業務：クラウド関連の技術検証など ● Chaos Engineering ● CI / CD Pipeline ● Distributed Tracing ● Kubernetes, Container, OpenStack 業務：その他 ● エンジニア採用のお手伝い ● エンジニア向けのイベント開催 ● はたらく環境の改善 About me

Copyright © NTT Communications Corporation. All rights reserved. 3 本日のお話 Resilienceなシステム開発のために、 分散システムに携わる開発者、運用者に次の3つを紹介 ▪ カオスエンジニアリングの概要 ▪ カオスエンジニアリングでできること ▪ カオスエンジニアリングを実現するツールや情報の紹介

Copyright © NTT Communications Corporation. All rights reserved. 4 分散システムに対し意図的に障害を起こすことで、 障害時のシステムの振る舞いを把握するアプローチ 意図的に引き起こされた障害により問題が生じた際は、 修正することでシステムをより強固なものにすることができる（Resilience） カオスエンジニアリング　≒　疫学, 予防医学 カオスエンジニアリングとは

Copyright © NTT Communications Corporation. All rights reserved. 5 英和辞典： はね返り、とび返り、弾力、弾性、(元気の)回復力 英英辞典： the ability to become strong, happy, or successful again after a difficult situation or event 意訳：難しい状況や出来事のあとに、より良くなるための能力 resilience

Copyright © NTT Communications Corporation. All rights reserved. 6 分散システムの状態はシステムの数に比例して指数関数的に増大する すべての状態を把握するのは不可能 システムに意図的に障害を起こすことで開発/運用が意図しない障害を起こす →　障害による影響を把握 →　修正することでよりシステムを安定したものに (Resilience) なぜカオスエンジニアリングなのか？

Copyright © NTT Communications Corporation. All rights reserved. “The best way to avoid failure is to fail constantly.” Netflix TechBlog : https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c - Netflix

Copyright © NTT Communications Corporation. All rights reserved. 8 参考：TwitterとNetflixのMicroservices(2014) [1] : https://twitter.com/adrianco/status/441883572618948608 [2]: https://www.slideshare.net/BruceWong3/the-case-for-chaos

Copyright © NTT Communications Corporation. All rights reserved. 9 カオスエンジニアリングとFault injection, Failure testingは重複する部分が多い Netflixではカオスエンジニアリングの実現にFault injectionを利用 - Failure testing： 故障時に正しく動くことを確認する手段 - Fault injection: 障害時の状態をテストするためのアプローチ - Chaos Engineering: 新しい情報を作り出すためのアプローチ カオスエンジニアリング ≒ 障害試験？

Copyright © NTT Communications Corporation. All rights reserved. カオスエンジニアリングは ○ ：新しい情報を作り出すためのアプローチ ☓ ：Resilienceの確認や証明するアプローチ

Copyright © NTT Communications Corporation. All rights reserved. カオスエンジニアリングは ○ ：新しい情報を作り出すためのアプローチ ☓ ：Resilienceの確認や証明するアプローチ 新しい情報を作り出すとは？

Copyright © NTT Communications Corporation. All rights reserved. 12 担当 「障害試験は無事に終わりました」 偉い人 「想定外の障害はないのか？」 担当 「はい大丈夫です！（想定外って言われても・・・）」 〜　後日　〜 担当 「想定していない障害が起きました！」 偉い人 「どうしてその障害を想定できなかったんだ！？」 想定外は起きる

Copyright © NTT Communications Corporation. All rights reserved. 13 担当 「障害試験は無事に終わりました」 偉い人 「想定外の障害はないのか？」 担当 「はい大丈夫です！（想定外って言われても・・・）」 〜　後日　〜 担当 「想定していない障害が起きました！」 偉い人 「どうしてその障害を想定できなかったんだ！？」 想定外はいつもあなたのそばに 知らないことは対応はできない！

Copyright © NTT Communications Corporation. All rights reserved. 14 Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度

Copyright © NTT Communications Corporation. All rights reserved. 15 Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Failure Testing

Copyright © NTT Communications Corporation. All rights reserved. 16 Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Failure Testing Fault Injection

Copyright © NTT Communications Corporation. All rights reserved. 17 Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKnown Knownsにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Failure Testing Fault Injection Chaos Engineering Chaos Engineering

Copyright © NTT Communications Corporation. All rights reserved. 18 Do you know and understand a problem? Unknown Knowns ● 問題として起きていないが、 解決方法が明確なもの ● すぐにKKにできるもの Known Knowns ● 問題と解決方法を知っている ● 完全に理解した Unknown Unknowns ● 何が起きるのか知らない ● 起きてから対応が必要 Known Unknowns ● 問題として知っているが、 解決策がわからない ● 仮設を立て、テストと実験を繰り返し チームで解決すべき問題 データ / 経験 / 知識 理 解 度 Failure Testing Fault Injection Chaos Engineering Chaos Engineering カオスエンジニアリングで問題を知り 解決することでResilienceなシステムを作る！

Copyright © NTT Communications Corporation. All rights reserved. 19 何が起きるか知っていますか？ ▪ Region もしくは Data Center が障害 ▪ Message QueueのQueueが消える ▪ サービス間のレイテンシが増大 ▪ 対向サービスから例外が返ってくる ▪ サーバ間の時刻がずれている ▪ I/O エラー ▪ CPUコアが張り付く ▪ DNSの障害

Copyright © NTT Communications Corporation. All rights reserved. 20 システムに関係するありとあらゆる ものが障害を起こす原因になる 耐障害性を謳う分散システムも壊れること はある[1] カオスエンジニアリングで各レイヤーの問 題を知り、解決することでResilienceなシス テムができる いつもニコニコあなたの隣に Application Message Queue Database OS Hardware Network Data Center Filesystem [1]: 本当は恐ろしい分散システムの話 - https://www.slideshare.net/kumagi/ss-81368169

Copyright © NTT Communications Corporation. All rights reserved. 21 Q1. あなたのシステムは関連サービスの障害やNW遅延に耐えられますか？ No：システムの既知の問題にまず対処しましょう！ Yes：次の質問へ Q2. あなたはシステムの現在の状態を把握できますか？ No：システムの状態が把握できるような監視設定をしましょう！ Yes：カオスエンジニアリングをはじめてみましょう！ カオスエンジニアリングをはじめる前に

Copyright © NTT Communications Corporation. All rights reserved. 22 CHAOS IN PRACTICE [1] 1. 通常時の計測データから「定常状態」を定義 2. 対照群と実験群の両方で定常状態が続くと仮定 3. サーバ障害、ハードウェア故障、NWの切断など現実世界の イベントを反映する変数を導入する 4. 対照群と実験群の違いを探すことで仮説を確認 カオスエンジニアリングのはじめかた Chaos Engineering: the history, principles, and practice - https://www.gremlin.com/community/tutorials/chaos-engineering-the-history-principles-and-practice/ [1] : カオスエンジニアリングの原則 - http://principlesofchaos.org/?lang=JAcontent#

Copyright © NTT Communications Corporation. All rights reserved. 23 カオスエンジニアリングの詳細な原則[1] 1. Build a Hypothesis around Steady State Behavior 2. Vary Real-world Events 3. Run Experiments in Production 4. Automate Experiments to Run Continuously 5. Minimize Blast Radius [1] : カオスエンジニアリングの原則 - http://principlesofchaos.org/?lang=JAcontent#

Copyright © NTT Communications Corporation. All rights reserved. 24 定常状態から仮説を構築 システムを計測することで定常状態の指標に設定 ▪ スループット ▪ エラーレート ▪ レイテンシのパーセンタイル 定常状態の行動パターンから、カオスにおいてシステムが 「どのように動くか」ではなく「機能すること」を検証 1. Build a Hypothesis around Steady State Behavior

Copyright © NTT Communications Corporation. All rights reserved. 25 実世界のイベントを反映 ▪ ハードウェア障害 ▪ ソフトウェア障害 ▪ トラフィックのスパイク ▪ etc... 影響度合いや推定頻度から優先順位付けを行う 定常状態を破壊可能なイベントは、検証において潜在的な変数となる 2. Vary Real-world Events

Copyright © NTT Communications Corporation. All rights reserved. 26 本番環境のトラフィックで直接検証することを推奨 ▪ システムは環境やトラフィックパターンによって動きが異なる ▪ 実トラフィックの抽出は確実にリクエストパスをキャプチャ可能 ▪ 本番環境との関連性や実行方法の信頼性を保証するためには、 本番環境のトラフィックで直接検証することが望ましい Netflixは本番環境でのChaos Engineeringを実際にやってる とは言ってもsandbox環境で試してからやるべきという意見[1]も勿論ある 3. Run Experiments in Production [1]:https://medium.com/@njones_18523/chaos-engineering-traps-e3486c526059

Copyright © NTT Communications Corporation. All rights reserved. 27 各システムが依存する他システムの障害を予測し許容できるように設計 一方でサービスの性質上、一部が障害を起こしデグレをしても、 ユーザに対して大きな影響が出ないため、許容されているようにも見える 参考：Netflix We’re designing each distributed system to expect and tolerate failure from other systems on which it depends. If our recommendations system is down, we degrade the quality of our responses to our customers, but we still respond. We’ll show popular titles instead of personalized picks. If our search system is intolerably slow, streaming should still work perfectly fine. Netflix TechBlog : https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c

Copyright © NTT Communications Corporation. All rights reserved. 28 4. Automate Experiments to Run Continuously 検証は自動化し、継続して実行 手作業の検証は手間が多く長続きしない・・・ カオスエンジニアリングは、 オーケストレーションと分析を行うためにシステムの自動化も大事

Copyright © NTT Communications Corporation. All rights reserved. 29 影響範囲を局所化する > 3. Run Experiments in Production カオスエンジニアリングは本番環境で行うことを推奨しているが、 本番環境での検証は顧客へ不必要な影響を引き起こす可能性がある 問題が起きた際に短期的にネガティブな影響が出ることはあるが、 それを最小限に抑えるように計画し確認する責任と義務がある 5. Minimize Blast Radius

Copyright © NTT Communications Corporation. All rights reserved. 30 原則を踏まえて 1. システムのメトリックスを取り定常状態を定義 2. 実世界の障害を元に仮説を立てる 3. 影響範囲を見積もる 4. Rollbackの計画を立てる 5. 実施 6. 仮説の確認 Chaos Engineering: the history, principles, and practice - https://www.gremlin.com/community/tutorials/chaos-engineering-the-history-principles-and-practice/

Copyright © NTT Communications Corporation. All rights reserved. 31 Chaos Engineering Tools Chaos Engineeringを実現するツールたち - Chaos Monkey - kube-monkey - Pumba - Envoy - etc...

Copyright © NTT Communications Corporation. All rights reserved. 32 Chaos Monkey [1] NetflixがOSSとして公開しているVMやコンテナをランダムに落とすためのツール NetflixがプロダクションでChaos Monkeyを使ったChaos Engineeringをしている話が有名 でありChaose Engineering ≒ Chaos Monkey のイメージが広まっている Chaos Monkey v2からはSpinnakerと連携することにより対象のクラウドを抽象化してお り、Spinnakerが対応しているクラウドであれば対応可能（なはず） AWS, GCE, Kubernetesでの動作確認はされていると書いてあるが、 KubernetesでDeploymentを使った際に動作しないバグが有る [1]:https://github.com/Netflix/chaosmonkey

Copyright © NTT Communications Corporation. All rights reserved. 33 参考：Simian Army[1] is retired 猿の軍団は引退しました [1]: https://github.com/Netflix/SimianArmy

Copyright © NTT Communications Corporation. All rights reserved. 34 kube-monkey [1] KubernetesのCluster内のPodをランダムに削除することで、システムの対障害性や回復 性を確認するためのツール 動作時間や動作間隔、削除対象のラベル、Podの削除割合などを指定可能 1日1回スケジューリングを行い削除するPodをランダム決める （もしくは削除しないことを決める） ソースコードを読むと動作は平日（Weekday）に固定されている模様 [1]: https://github.com/asobti/kube-monkey

Copyright © NTT Communications Corporation. All rights reserved. 35 Pumba [1] Docker向けのChaos testingとネットワークエミュレーションを行うツール コンテナ単位で以下が可能 - コンテナを壊す(kill/rm) - コンテナを止める(pause/stop) - NWのエミュレーション - 遅延 - パケットロス / 重複 / 破損 Chaos Monkeyやkube-monkeyと異なり１回もしくは一定期間で繰り返し動作する [1]: https://github.com/alexei-led/pumba

Copyright © NTT Communications Corporation. All rights reserved. 36 Envoy[1][2] クラウドネイティブなアプリケーションのためのEdge & Service Proxy Envoy の機能としてNW遅延とエラーレスポンスのfault injectionが可能[3] - エラーレスポンス（HTTP） - NW遅延 - gRPC - Mongo - Redis operation - Delay proxying of TCP connections. [1]: https://www.envoyproxy.io/ [2]: https://github.com/envoyproxy/envoy [3]: https://github.com/envoyproxy/envoy/tree/master/examples/fault-injection

Copyright © NTT Communications Corporation. All rights reserved. 37 Chaos for FileSystem errfs [1] CharybdeFS [2] どちらもFUSE (Filesystem in Userspece)ベースのファイルシステムに対する Fault injection [1]: https://github.com/aganesan4/CORDS [2]: https://github.com/scylladb/charybdefs

Copyright © NTT Communications Corporation. All rights reserved. 38 Resilience as a Service Gremlin [1] カオスエンジニアリングをサービスとして利用可能 ▪ Shutdown, Process Killer ▪ CPU, Disk, IO, Memory ▪ DNS ▪ Latency ▪ Black Hole, Packet Loss, ▪ Time Travel ▪ Application Level [1]: https://www.gremlin.com/

Copyright © NTT Communications Corporation. All rights reserved. 39 Gremlin曰く「アプリケーション内にFault-injectionのしくみを作る」とのこと In serverless environments ? In serverless environments such as AWS Lambda, Google Cloud Functions, and Azure Functions, this access is impossible. In these cases, it is necessary to include the fault-injection mechanism within the application itself. - Application Layer > Overview | Gremlin Docs

Copyright © NTT Communications Corporation. All rights reserved. 40 OpenStack Eris[1] OpenStackに様々な負荷をかけ、OpenStackの性能改善やResilienceにするための、テス トフレームワークやテストスイートを作るプロジェクト Load Injection, Fault Injectionの機能もできる（らしいが開発進んでなさそう） [1]:https://docs.openstack.org/self-healing-sig/latest/eris/

Copyright © NTT Communications Corporation. All rights reserved. 41 各社本番環境においてカオスエンジニアリングをしている可能性がある（推測） - GCP : Preemptible VM - AWS : Spot Instance - Azure : low-priority VMs 表向きは余剰リソースを格安で提供しているが、 サービス特性をみるとカオスエンジニアリングの検証を行っている可能性がある Compute Engine は、システム イベントにより、いつでもプリエンプティブ インスタンスを終了する可能性がありま す。Compute Engine がシステム イベントによってプリエンプティブ インスタンスを終了する可能性は通常は低い ですが、そのときの状況に応じて、日々ゾーンごとに異なることがあります。 プリエンプティブ VM インスタンス | Compute Engine ドキュメント | Google Cloud クラウド事業者のカオスエンジニアリング

Copyright © NTT Communications Corporation. All rights reserved. 42 情報収集 ▪ 書籍 ▪ Slack ▪ Conference ▪ Working Group

Copyright © NTT Communications Corporation. All rights reserved. 43 Chaos Engineering [Book] - O'Reilly [1] カオスエンジニアリングについてNetflixのエンジニアが書いた本（無料） 体系的にまとめられているのでオススメ 文末に情報やツールについてもまとめられている 書籍 [1]:https://www.oreilly.com/library/view/chaos-engineering/9781491988459/

Copyright © NTT Communications Corporation. All rights reserved. 44 Chaos Engineering Slack[1] カオスエンジニアリングに関する情報が共有される ▪ 技術的な話題 ▪ イベント情報 ▪ カオスエンジニアリング関連のブログポスト ▪ 直近に起きた有名な障害の情報 ▪ 社員募集 ▪ etc... [1]:https://slofile.com/slack/chaosengineering

Copyright © NTT Communications Corporation. All rights reserved. 45 Awesome Chaos Engineering [1] 各種情報がまとまっているサイト ▪ 情報へのリンク ▪ 学習関連 ▪ ツール ▪ サービス ▪ 論文 ▪ ブログ 古い情報も残ってあるので注意・・・ [1]:https://github.com/dastergon/awesome-chaos-engineering

Copyright © NTT Communications Corporation. All rights reserved. 46 今年は９月にサンフランシスコで開催 昨年の発表などはYoutubeで視聴可能[2] Chaos Engineering Slackの #chaosconf にプロモーションコードあり($50引き) Chaos Conf 2019 [1] [1]:https://chaosconf2019.splashthat.com/ [2]:https://www.youtube.com/playlist?list=PLLIx5ktghjqKtZdfDDyuJrlhC-ICfhVAN

Copyright © NTT Communications Corporation. All rights reserved. 47 CNCF: Chaos Engineering Working Group Cloud Native Computing FoundationのChaos Engineering WGにおいて、 「ベンダーがソリューションを提供するために統一されたAPI」を検討中[1] https://github.com/chaoseng/wg-chaoseng なお、1年近く活動がないがCNCFのSlackを覗いてみると、 隔週ミーティングはキャンセル続きだがやる気のある人はまだいるらしく、 9月頃から再開・・・らしい・・・？ [1]:https://docs.google.com/document/d/1BeeJZIyReCFNLJQrZjwA4KMlUJelxFFEv3IwED16lHE/edit?ts=5af1d0d9#

Copyright © NTT Communications Corporation. All rights reserved. 48 Chaos Toolkit [1][2] カオスエンジニアリングのためのOpen APIとToolkitを提供 エクステンションとして各種インフラやアプリ、監視、通知向けのものが存在 ▪ k8s, Cloud Foundry, AWS, Microsoft Azure, Google Cloud Engine ▪ gremlin, toxiproxy, sprint ▪ prometeus ▪ slack ▪ etc… [1]:https://github.com/chaostoolkit/chaostoolkit [2]:https://docs.chaostoolkit.org/

Copyright © NTT Communications Corporation. All rights reserved. まとめ

Copyright © NTT Communications Corporation. All rights reserved. カオスエンジニアリングは ○ ：新しい情報を作り出すためのアプローチ ☓ ：Resilienceの確認や証明するアプローチ

Copyright © NTT Communications Corporation. All rights reserved. “Beware that, when fighting monsters, you yourself do not become a monster… for when you gaze long into the abyss. The abyss gazes also into you.” フリードリヒ・ニーチェ 「善悪の彼岸」146節より

Copyright © NTT Communications Corporation. All rights reserved. May the chaos engineering be with you !

Presentation by NTT Communications

Copyright © NTT Communications Corporation. All rights reserved. 54 - PRINCIPLES OF CHAOS ENGINEERING - Chaos Engineering Bootcamp - SREcon 2018 - Chaos Engineering やっていく宣言 - Re:silience から始めるカオスエンジニアリング生活 - Chaos Engineering: the history, principles, and practice - Chaos Engineering Traps 参考情報