Chaos Engineering 入門

Netflix 社を中心とした Chaos Engineering の発展の歴史と、そこから繋がる現在（2019年）の状況やツールなどについて概説しています。

この資料は AWS DevDay Tokyo 2019 の『Chaos Engineering ~入門と実例~ 』セッションの前半パート（＝入門）のみを抜粋しています。後半パート（＝実例）も読みたい方は以下をどうぞ
* 資料： https://pages.awscloud.com/rs/112-TZM-766/images/E-2.pdf
* 動画： https://www.youtube.com/watch?v=cVUO6Yt1EnA&feature=youtu.be

Transcript

1. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
2. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Who am I
3. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AutoScaling?
4. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AutoScaling アプリケーションをモニタリングしリソース量を自動で調整する機能 • 例１） ELB により負荷分散される EC2 Instance 群を20で維持させる → オペミスでインスタンスを1つ停止したとしても、新しいインスタンスを自動で起動・追加 → HW 障害でインスタンスが1つ停止したとしても、新しいインスタンスを自動で起動・追加 • 例２） ELB により負荷分散される EC2 Instance 群の Average CPU Utilization を監視し・・・ • 5秒間隔で 70% を3回連続で上回っていたら → インスタンスを2つ追加する • 5秒間隔で 30% を3回連続で下回っていたら → インスタンスを1つ停止する https://aws.amazon.com/jp/autoscaling/
5. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AutoScaling アプリケーションをモニタリングしリソース量を自動で調整する機能 • 例１） ELB により負荷分散される EC2 Instance 群を20で維持させる → オペミスでインスタンスを1つ停止したとしても、新しいインスタンスを自動で起動・追加 → HW 障害でインスタンスが1つ停止したとしても、新しいインスタンスを自動で起動・追加 • 例２） ELB により負荷分散される EC2 Instance 群の Average CPU Utilization を監視し・・・ • 5秒間隔で 70% を3回連続で上回っていたら → インスタンスを2つ追加する • 5秒間隔で 30% を3回連続で下回っていたら → インスタンスを1つ停止する https://aws.amazon.com/jp/autoscaling/
6. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. だったらそれを実際にテストしてみよう、本番環境で。 こういう考え方が実際にあり、既に幅広く実践されています。
7. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. カオス・エンジニアリング https://medium.com/netflix-techblog/chap-chaos-automation- platform-53e6d528371f https://www.oreilly.com/library/view/chaos- engineering/9781491988459/
8. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | AWS • 2006年3月 Amazon S3 がリリース • 2006年8月 Amazon EC2 がリリース https://aws.amazon.com/jp/aws_history/details/
9. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | Netflix の AWS への移行と一匹目の猿 • 2010年12月14日 Four Reasons We Choose Amazon’s Cloud as Our Computing Platform (Netflix TechBlog) 私達のコンピューティングプラットフォームとして Amazon のクラウドを選択した4つの理由 • 2010年12月16日 5 Lessons We’ve Learned Using AWS (Netflix TechBlog) AWS を使って学んだ5つのレッスン https://medium.com/netflix-techblog/four-reasons-we-choose-amazons-cloud-as-our-computing-platform-4aceb692afec https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c
10. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | Netflix の AWS への移行と一匹目の猿 • 2010年12月14日 Four Reasons We Choose Amazon’s Cloud as Our Computing Platform (Netflix TechBlog) 私達のコンピューティングプラットフォームとして Amazon のクラウドを選択した4つの理由 • 2010年12月16日 5 Lessons We’ve Learned Using AWS (Netflix TechBlog) AWS を使って学んだ5つのレッスン https://medium.com/netflix-techblog/four-reasons-we-choose-amazons-cloud-as-our-computing-platform-4aceb692afec https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c 障害 (failure) を避ける最も良い方法は 継続的に障害を起こ (fail) させること つは Chaos Monkey と呼ばれ ます サービスをランダムに強制終了
11. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | その頃の AWS は？ • 2010年12月14日 Four Reasons We Choose Amazon’s Cloud as Our Computing Platform (Netflix TechBlog) 私達のコンピューティングプラットフォームとして Amazon のクラウドを選択した4つの理由 • 2010年12月16日 5 Lessons We’ve Learned Using AWS (Netflix TechBlog) AWS を使って学んだ5つのレッスン https://medium.com/netflix-techblog/four-reasons-we-choose-amazons-cloud-as-our-computing-platform-4aceb692afec https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c 障害 (failure) を避ける最も良い方法は 継続的に障害を起こ (fail) させること つは Chaos Monkey と呼ばれ ます サービスをランダムに強制終了 • 2010年4月 AWS アジア初のリージョン：シンガポール リージョンがローンチ（東京は2011年） • 2010年8月 AWS の日本語サイトがオープン
12. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chaos Monkey: インスタンスをランダムに停止 Elastic Load Balancing App Server App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client
13. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chaos Monkey: インスタンスをランダムに停止 Elastic Load Balancing App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client
14. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chaos Monkey: インスタンスをランダムに停止 Elastic Load Balancing App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client new! Auto Scaling group
15. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | 猿の仲間が増える • 2011年6月 The Netflix Simian Army (Netflix TechBlog) https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116
16. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | 猿の仲間が増える • 2011年6月 The Netflix Simian Army (Netflix TechBlog) https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116 • Latency Monkey • Conformity Monkey • Doctor Monkey • Janitor Monkey • Security Monkey • 10–18 Monkey • Chaos Gorilla
17. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Simian Army: NW 遅延の増加をシミュレートなど Elastic Load Balancing App Server App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client Auto Scaling group A Microservice Another Microservice Another Microservice
18. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Simian Army: NW 遅延の増加をシミュレートなど Elastic Load Balancing App Server App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client Auto Scaling group A Microservice Another Microservice Another Microservice
19. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | より精緻な Microservices レベルでの障害注入 • 2014年10月 FIT: Failure Injection Testing (Netflix TechBlog) • Request Context (Failure Context, FIT Context) というメタデータ情報を伝播させることで、 ダウンストリームのコンポーネントなどの狙いすましたポイントに Failure を作用させられる https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2
20. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | より精緻な Microservices レベルでの障害注入 • 2014年10月 FIT: Failure Injection Testing (Netflix TechBlog) • Request Context (Failure Context, FIT Context) というメタデータ情報を伝播させることで、 ダウンストリームのコンポーネントなどの狙いすましたポイントに Failure を作用させられる https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2 a little too wild 少しワイルド過ぎる
21. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 猿たちと FIT の決定的な違いは何か Chaos Monkey, Simian Army 例えば、 EC2 Instance の API で terminate する、 tc で NW 遅延を 追加する、などインフラ・レイヤ を直接的に扱う Blast Radius: 爆発半径 の課題 • 作用範囲を特定の何かに限定し づらい • 影響範囲を小さくしづらい
22. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 猿たちと FIT の決定的な違いは何か Chaos Monkey, Simian Army 例えば、 EC2 Instance の API で terminate する、 tc で NW 遅延を 追加する、などインフラ・レイヤ を直接的に扱う Blast Radius: 爆発半径 の課題 • 作用範囲を特定の何かに限定し づらい • 影響範囲を小さくしづらい FIT 例えば、ある UA のクライアント端 末だけに障害注入する、テストフ ラグのあるユーザの通信において のみ DB アクセスを遅延させる、 などアプリケーション・レイヤで 情報を伝播させ、アプリケーショ ン・レイヤの情報を解釈する • 狙ったポイントで • 極めて限定した範囲に
23. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション・レイヤ？ Elastic Load Balancing App Server App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client Auto Scaling group A Microservice Another Microservice Another Microservice
24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション・レイヤ？ Elastic Load Balancing App Server App Server App Server App Server App Server MySQL instance MySQL instance Client Mobile client Auto Scaling group A Microservice Another Microservice Another Microservice Metadata (Request Context) Control Plane Metadata
25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Netflix の実際の構成 FIT における障害注入のポイント ゲートウェイサービスの Zuul 、障害や 遅延を特定してフォールバックを制御す るライブラリの Hystrix 、IPC (RPC) ライ ブラリの ribbon 、分散インメモリ DB の EVCache 、Cassandra のクライアン トライブラリの astyanax 、 内製のこういったツールは、障害を作用 させる格好のポイント。これらが、伝播 された Request Context の情報を解釈し 障害を適切な粒度でシミュレートする。 https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2
26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | 手法や技術だけでなく、エンジニアリング • 2015年9月 Principles of Chaos Engineering • 2015年9月※ Chaos Engineering Upgraded (Netflix TechBlog) • Chaos Kong を発表。リージョンの停止をシミュレートする 主に Monkey と Kong が今も継続的に使われている Chaos Monkey はこの翌年に v2 が公開され Spinnaker との統合など大きく機能強化される https://medium.com/netflix-techblog/netflix-chaos-monkey-upgraded-1d679429be5d ※ AWS re:Invent 2015『 Availability: The New Kind of Innovator’s Dilemma 』セッション によると Chaos Kong の利用は2013年から https://www.slideshare.net/AmazonWebServices/spot302-availability-the-new-kind-of-innovators-dilemma https://principlesofchaos.org (en), https://principlesofchaos.org/?lang=JAcontent (ja) https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa
27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://principlesofchaos.org (en), https://principlesofchaos.org/?lang=JAcontent (ja) カオスエンジニアリングとは 「対象とするシステムが本番環境における不安定な状況を 耐えることができる」という自信を構築するために 当該システムにおいて実施する 実験 の規律です。
28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 定常状態 2. 仮説 3. 現実世界の事象を反映する変数を導入 4. 仮説を反証 https://principlesofchaos.org (en), https://principlesofchaos.org/?lang=JAcontent (ja)
29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://principlesofchaos.org (en), https://principlesofchaos.org/?lang=JAcontent (ja)
30. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | 継続するには自動化、自動化するには他ツールとの連携 • 2017年7月 • ChAP: Chaos Automation Platform (Netflix TechBlog) • O’Reilly より Netflix のエンジニアら執筆による ebook 『 Chaos Engineering 』が公開 • 2017年11月 • AWS re:Invent 2017 KEYNOTE presented by Werner Vogels（CTO, Amazon.com）内にて 「Netflix - Chaos Engineering の道のりと Chaos がもらたすもの」by Nora Jones https://medium.com/netflix-techblog/chap-chaos-automation-platform-53e6d528371f https://www.youtube.com/watch?v=rgfww8tLM0A , https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/
31. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | 継続するには自動化、自動化するには他ツールとの連携 • 2017年7月 • ChAP: Chaos Automation Platform (Netflix TechBlog) • O’Reilly より Netflix のエンジニアら執筆による ebook 『 Chaos Engineering 』が公開 • 2017年11月 • AWS re:Invent 2017 KEYNOTE presented by Werner Vogels（CTO, Amazon.com）内にて 「Netflix - Chaos Engineering の道のりと Chaos がもらたすもの」by Nora Jones https://medium.com/netflix-techblog/chap-chaos-automation-platform-53e6d528371f https://www.youtube.com/watch?v=rgfww8tLM0A , https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/ • 自動化 CI/CD と統合 Spinnaker 自動的に モニタリング
32. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | Experiment 実施の自動化と Experiment 作成の自動化 • 2019年5月 論文『 Automating chaos experiments in production 』を公開 • Netfilix のエンジニアによる Chaos Engineering 関連の最新の論文。 Chaos Monkey から FIT 、ChAP に至る流れとなぜそれらが必要となったか、そして最新の学 びや課題が整理されている。 • 「自動化」という点では、単純に Chaos Experiment の実施を どう自動化するかだけではなく、効果的な Experiment を 効率的に作成・選定するためにはどうすれば良いか、という 「２つの自動化」について触れられている https://arxiv.org/pdf/1905.04648
33. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. | | | | | | | | | | | | | | | Further More in 2020 • 2020年6月（発売予定） 『 Chaos Engineering: System Resiliency in Practice 』 Netflix のエンジニアらによる新著 2020 https://www.amazon.co.jp/dp/1492043869 でも予約注文が可能です
34. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. A) クラウドに全面移行 B) クラウドではサーバの故障率を下げる、という耐障害性のアプローチはできない。どうするか？ → 予期せぬ深刻な障害を忌避するために、制御された小さな障害を受け入れる Chaos Monkey C) サーバ停止だけが障害か？ → サーバが落ちるより、中途半端に応答が遅くなるほうがやっかいなことも Latency Monkey → サーバ単位じゃなくて DC レベルで疎通しなくなる可能性だってなくはない Chaos Kong → 設定不備や脆弱性がある状態で稼働し続けるくらいなら停止させてしまえ Conformity Monkey, Security Monkey, などなど・・・ D) 注入する障害の Blast Radius （爆発半径）をもっと小さくかつ制御することはできないか？ → よりアプリケーション・レイヤでの障害注入方法： FIT (Failure Injection Testing) E) 手法やツールを整備するだけでは浸透しない、正しく理解されない → エンジニアリングとして改めて定義： Principles of Chaos Engineering F) 適切なタイミングかつ継続して Experiment を実施したい → 自動化が大事： ChAP (Chaos Automation Platform) → 自動化のためには、CI/CD や モニタリングとの機能統合や連携が不可欠 G) 論文『 Automating chaos experiments in production 』
35. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Netflix は Chaos Engineering に先進的に取り組み 積極的に情報発信する “Innovator” Netflix がぶつかった課題の多くに Chaos Engineering に取り組む多くの組織が後追いで直面 Chaos Engineering への取り組んで課題にぶつかったら ぜひ Netflix はどうしているか？の観点でも少し調べてみてください。
36. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chaos Engineering は Netflix 発祥？ 他の多数の組織で同様の取り組みや考え方はあった また、ツールセットや知見は徐々に充実
37. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chaos Engineering は Netflix 発祥？ 他の多数の組織で同様の取り組みや考え方はあった また、ツールセットや知見は徐々に充実
38. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. GameDay
39. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. GameDay game-day: 【形】試合がある日の • トラブルが起きたときしかトラブルシュートしなくて、 いざトラブルが起きた時にスムーズに対応できるでしょうか？ • 本番と同様の環境で、異常事態の対応を訓練 • AWS GameDay: 数人のチームに分かれて、AWS 上に払い出された 実際の環境をトラブルシュートしていく コンペティション形式のイベント https://eow.alc.co.jp/search?q=game-day https://aws.amazon.com/gameday/
40. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS GameDay
41. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS GameDay
42. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Gremlin
43. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Gremlin Inc. • Chaos Engineering のための仕組みやツールを提供する企業。 「 Gremlin 」は会社名かつサービス名。 • Chaos Test を運用するために必要なライブラリ、デーモン、Docker Image、ワークフロー管理コンソールなどが揃っている。 • デーモンベースの仕組みだけでなくアプリケーション・レイヤでの Injection の仕組みも昨年から提供： ALFI (Application-Level Fault Injection) • Co-founder CEO の Kolton Andrus • 前職は Netflix 。FIT の設計と開発に携わっていた。 • その前は Amazon 。どちらの会社でも Call Leader として 全社的なインシデント対応とその管理に携わっていたとのこと。 https://www.gremlin.com/team/ • 2018, 2019 年と San Francisco で「ChaosConf」をオーガナイズ https://www.gremlin.com/
44. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com https://www.gremlin.com/community/tutorials/gremlin-scenarios-walkthrough/
45. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com https://www.gremlin.com/community/tutorials/gremlin-scenarios-walkthrough/
46. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com https://www.gremlin.com/community/tutorials/gremlin-scenarios-walkthrough/
47. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com
48. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com
49. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. www.gremlin.com
50. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. OSS Tools?
51. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. OSS Tools ChaosTookit https://github.com/chaostoolkit • Experiment を定義し再利用可能な形に構成することが可能 • CUI ツールで、プラガブルな設計 • 自動化: Jenkins などと連携可能 • モニタリング: Humio などと 連携可能 • 開発をリードする Russ Miles O’Reilly『 Chaos Engineering Observability 』 O’Reilly『 Learning Chaos Engineering 』 $ chaos run ./experiment.json [2019-09-30 05:44:05 INFO] Validating the experiment's syntax [2019-09-30 05:44:05 INFO] Experiment looks valid [2019-09-30 05:44:05 INFO] Running experiment: Our default language is English [2019-09-30 05:44:05 INFO] Steady state hypothesis: Our hypothesis is that lang file is in English [2019-09-30 05:44:05 INFO] Probe: lookup-lang-file [2019-09-30 05:44:05 INFO] Probe: lookup-text-in-lang-file [2019-09-30 05:44:05 INFO] Steady state hypothesis is met! [2019-09-30 05:44:05 INFO] Action: switch-language-to-French [2019-09-30 05:44:05 INFO] Steady state hypothesis: Our hypothesis is that lang file is in English [2019-09-30 05:44:05 INFO] Probe: lookup-lang-file [2019-09-30 05:44:05 INFO] Probe: lookup-text-in-lang-file [2019-09-30 05:44:05 INFO] Steady state hypothesis is met! [2019-09-30 05:44:05 INFO] Let's rollback... [2019-09-30 05:44:05 INFO] Rollback: switch-language-back-to-English [2019-09-30 05:44:05 INFO] Action: switch-language-back-to-English [2019-09-30 05:44:05 INFO] Experiment ended with status: completed
52. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. OSS Tools: Others Awesome Chaos Engineering https://github.com/dastergon/awesome -chaos-engineering#notable-tools Chaos Engineering 関連の ツール、本、記事、講演などの 情報をまとめているリポジトリ 最近も更新は続いている
53. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. OSS Tools: Serverless aws-lambda-chaos-injection Chaos Injection library for AWS Lambda Python （現在はまだ α バージョン） リポジトリオーナーの Adrian Hornsby は AWS の Principal Evangelist Adrian と Gremlin の Ana のセッション 『 Breaking Containers: Chaos Engineering for Modern Applications on AWS (CON310)』 の 動画 と スライド も英語ですがぜひ https://medium.com/@adhorn/failure-injection-gain-confidence-in-your-serverless-application-ce6c0060f586 上記のように latency injection のデコレータを Lambda function のハンドラに付けて実行すると・・・ ↑レスポンスの中身は変わらないが、 ↓ Duration が実際にほぼ Delay の値であることが確認できる。
54. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. テストは重要、それでもなお基本的な設計も重要 Chaos Test に取り組むなら、最低限の可用性設計はできていることが 望ましい。特に本番での実施に臨むなら AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/ お客様のワークロードと AWS のベストプラクティスを比較し、安定した効率的なシステムを 作成するためのガイダンスを得るのに役立つ戦略。ホワイトペーパーや評価ツールも提供。 A ROADMAP TOWARDS CHAOS ENGINEERING @ChaosConf2019 https://speakerdeck.com/chaosconf/a-roadmap-towards-chaos-engineering そもそもこういう設計を意識した上で Chaos Test しようね、という設計パターンを整理（英語） スポットインスタンス ~ AWS でゲームサーバーの堅牢性を高めるシステム設計~ @CEDEC2019 https://cedil.cesa.or.jp/cedil_sessions/view/2068 （資料の閲覧には CEDiL への登録が必要です） クラウドに適した堅牢な設計について、スポットインスタンスの導入という観点から紹介
55. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 前半のまとめ • Chaos Engineering • 分散システムの信頼性を担保するのは難しい • どこで何が起きたときにどこに影響？ 複雑な依存関係 → テストしよう、本番環境で、安全に、継続的に。 • 手法と運用の進化 • 科学的検証、アプリケーション・レイヤでの障害注入、 自動化と継続性、モニタリングとの統合、CI/CDとの統合。 • サービスやツールなどエコシステムの発展 • まずは基本的な可用性設計を（あるいは開発環境での導入がおすすめ）