いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！ / CNDT-OSDT-2019-2G1

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

“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

View Slide

参考：TwitterとNetflixのMicroservices(2014)
[1] : https://twitter.com/adrianco/status/441883572618948608
[2]: https://www.slideshare.net/BruceWong3/the-case-for-chaos

View Slide

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

View Slide

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

View Slide

新しい情報を作り出すとは？

View Slide

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

View Slide

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

View Slide

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

View Slide

Unknown Knowns
Known Knowns
Unknown Unknowns
Known Unknowns
理
解
度
Failure Testing

View Slide

Unknown Knowns
Known Knowns
Unknown Unknowns
Known Unknowns
理
解
度
Failure Testing
Fault Injection

View Slide

Unknown Knowns
Known Knowns
Unknown Unknowns
Known Unknowns
理
解
度
Failure Testing
Fault Injection
Chaos Engineering
Chaos Engineering

View Slide

Unknown Knowns
● すぐにKKにできるもの
Known Knowns
Unknown Unknowns
Known Unknowns
理
解
度
Failure Testing
Fault Injection
Chaos Engineering
Chaos Engineering
カオスエンジニアリングで問題を知り
解決することでResilienceなシステムを作る！

View Slide

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

View Slide

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

View Slide

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

View Slide

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#

View Slide

カオスエンジニアリングの詳細な原則[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#

View Slide

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

View Slide

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

View Slide

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

View Slide

各システムが依存する他システムの障害を予測し許容できるように設計
一方でサービスの性質上、一部が障害を起こしデグレをしても、
ユーザに対して大きな影響が出ないため、許容されているようにも見える
参考：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

View Slide

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

View Slide

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

View Slide

原則を踏まえて
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/

View Slide

Chaos Engineering Tools
Chaos Engineeringを実現するツールたち
- Chaos Monkey
- kube-monkey
- Pumba
- Envoy
- etc...

View Slide

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

View Slide

参考：Simian Army[1] is retired
猿の軍団は引退しました
[1]: https://github.com/Netflix/SimianArmy

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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/

View Slide

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

View Slide

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

View Slide

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

View Slide

情報収集
▪ 書籍
▪ Slack
▪ Conference
▪ Working Group

View Slide

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

View Slide

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

View Slide

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

View Slide

今年は９月にサンフランシスコで開催
昨年の発表などは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

View Slide

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#

View Slide

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/

View Slide

まとめ

View Slide


View Slide

“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節より

View Slide

May the chaos engineering
be with you !

View Slide

Presentation by NTT Communications

View Slide

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

View Slide

いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！ / CNDT-OSDT-2019-2G1

いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！ / CNDT-OSDT-2019-2G1

Mahito

More Decks by Mahito

Other Decks in Technology

Featured

Transcript