t o k y o · 2020-06-06 · より精緻なmicroservices レベルでの障害注入 •...

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

T O K Y O2

01

9.1

0.0

3-

04


T O K Y O

20

19

.10

.03

-0

4

Chaos Engineering 〜入門と実例〜

Akihisa WadaInfrastructure EngineerCygames, Inc.

E - 2

Fumihiko HataSolutions ArchitectAmazon Web Services Japan


Who am I


AutoScaling?


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/

https://aws.amazon.com/jp/autoscaling/


だったらそれを実際にテストしてみよう、本番環境で。

こういう考え方が実際にあり、既に幅広く実践されています。


カオス・エンジニアリング

https://medium.com/netflix-techblog/chap-chaos-automation-platform-53e6d528371f

https://www.oreilly.com/library/view/chaos-engineering/9781491988459/


https://www.oreilly.com/library/view/chaos-engineering/9781491988459/


| | | | | | | | | | | | | | |

AWS

• 2006年3月Amazon S3がリリース

• 2006年8月Amazon EC2がリリース

https://aws.amazon.com/jp/aws_history/details/

https://aws.amazon.com/jp/aws_history/details/


| | | | | | | | | | | | | | |

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




| | | | | | | | | | | | | | |

Netflixの AWSへの移行と一匹目の猿





障害 (failure) を避ける最も良い方法は継続的に障害を起こ (fail) させること

つは Chaos Monkey と呼ばれますサービスをランダムに強制終了




| | | | | | | | | | | | | | |

その頃の AWSは？





障害 (failure) を避ける最も良い方法は継続的に障害を起こ (fail) させること

つは Chaos Monkey と呼ばれますサービスをランダムに強制終了

• 2010年4月AWSアジア初のリージョン：シンガポールリージョンがローンチ（東京は2011年）

• 2010年8月AWSの日本語サイトがオープン




Chaos Monkey: インスタンスをランダムに停止

Elastic Load Balancing

App

Server

App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client




App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client




App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client

Auto Scaling group


| | | | | | | | | | | | | | |

猿の仲間が増える

• 2011年6月The Netflix Simian Army (Netflix TechBlog)

https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116



| | | | | | | | | | | | | | |

猿の仲間が増える

• 2011年6月The Netflix Simian Army (Netflix TechBlog)


• Latency Monkey

• Conformity Monkey

• Doctor Monkey • Janitor Monkey • Security Monkey

• 10–18 Monkey • Chaos Gorilla



Simian Army: NW遅延の増加をシミュレートなど


App

Server

App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client

Auto Scaling group

A Microservice

Another

Microservice

Another Microservice


| | | | | | | | | | | | | | |

より精緻な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



| | | | | | | | | | | | | | |

より精緻なMicroservices レベルでの障害注入

• 2014年10月

FIT: Failure Injection Testing (Netflix TechBlog)

• Request Context (Failure Context, FIT Context) というメタデータ情報を伝播させることで、ダウンストリームのコンポーネントなどの狙いすましたポイントに Failure を作用させられる


a little too wild

少しワイルド過ぎる



猿たちと FITの決定的な違いは何か

Chaos Monkey, Simian Army

例えば、 EC2 Instanceの API でterminateする、 tcで NW遅延を追加する、などインフラ・レイヤを直接的に扱う

Blast Radius: 爆発半径の課題

• 作用範囲を特定の何かに限定しづらい

• 影響範囲を小さくしづらい


猿たちと FITの決定的な違いは何か

Chaos Monkey, Simian Army

例えば、 EC2 Instanceの API でterminateする、 tcで NW遅延を追加する、などインフラ・レイヤを直接的に扱う

Blast Radius: 爆発半径の課題

• 作用範囲を特定の何かに限定しづらい

• 影響範囲を小さくしづらい

FIT

例えば、ある UAのクライアント端末だけに障害注入する、テストフラグのあるユーザの通信においてのみ DB アクセスを遅延させる、などアプリケーション・レイヤで情報を伝播させ、アプリケーション・レイヤの情報を解釈する

• 狙ったポイントで

• 極めて限定した範囲に


アプリケーション・レイヤ？


App

Server

App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client

Auto Scaling group

A Microservice

Another

Microservice



アプリケーション・レイヤ？


App

Server

App

Server

App

Server

App

Server

App

Server

MySQL

instance

MySQL

instance

ClientMobile

client

Auto Scaling group

A Microservice

Another

Microservice


Metadata (Request Context)

Control

Plane

Metadata


Netflixの実際の構成

FITにおける障害注入のポイント

ゲートウェイサービスの Zuul、障害や遅延を特定してフォールバックを制御するライブラリの Hystrix、IPC (RPC)ライブラリの ribbon、分散インメモリ DBの EVCache、Cassandraのクライアントライブラリの astyanax、

内製のこういったツールは、障害を作用させる格好のポイント。これらが、伝播された Request Contextの情報を解釈し障害を適切な粒度でシミュレートする。


https://github.com/Netflix/zuul

https://github.com/Netflix/Hystrix

https://github.com/Netflix/Ribbon

https://github.com/Netflix/EVCache

https://github.com/Netflix/Astyanax



| | | | | | | | | | | | | | |

手法や技術だけでなく、エンジニアリング

• 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

https://medium.com/netflix-techblog/netflix-chaos-monkey-upgraded-1d679429be5d

https://www.slideshare.net/AmazonWebServices/spot302-availability-the-new-kind-of-innovators-dilemma

https://principlesofchaos.org/

https://principlesofchaos.org/?lang=JAcontent

https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa



カオスエンジニアリングとは「対象とするシステムが本番環境における不安定な状況を耐えることができる」という自信を構築するために当該システムにおいて実施する実験の規律です。




1.定常状態2.仮説3.現実世界の事象を反映する変数を導入4.仮説を反証





| | | | | | | | | | | | | | |

継続するには自動化、自動化するには他ツールとの連携

• 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://www.youtube.com/watch?v=rgfww8tLM0A , https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/


https://www.youtube.com/watch?v=rgfww8tLM0A

https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/


| | | | | | | | | | | | | | |

継続するには自動化、自動化するには他ツールとの連携

• 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://www.youtube.com/watch?v=rgfww8tLM0A , https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/

• 自動化CI/CDと統合 Spinnaker

自動的にモニタリング


https://www.youtube.com/watch?v=rgfww8tLM0A

https://aws.amazon.com/jp/about-aws/events/reinvent2017-1130/


| | | | | | | | | | | | | | |

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

https://arxiv.org/pdf/1905.04648


| | | | | | | | | | | | | | |

Further More in 2020

• 2020年6月（発売予定）『 Chaos Engineering: System Resiliency in Practice』

Netflixのエンジニアらによる新著

2020

https://www.amazon.co.jp/dp/1492043869でも予約注文が可能です

https://www.amazon.co.jp/dp/1492043869


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』


Netflixは Chaos Engineeringに先進的に取り組み積極的に情報発信する “Innovator”

Netflixがぶつかった課題の多くにChaos Engineeringに取り組む多くの組織が後追いで直面

Chaos Engineeringへの取り組んで課題にぶつかったらぜひ Netflixはどうしているか？の観点でも少し調べてみてください。


Chaos Engineeringは Netflix発祥？

他の多数の組織で同様の取り組みや考え方はあった

また、ツールセットや知見は徐々に充実


GameDay


GameDay

game-day: 【形】試合がある日の

• トラブルが起きたときしかトラブルシュートしなくて、いざトラブルが起きた時にスムーズに対応できるでしょうか？

• 本番と同様の環境で、異常事態の対応を訓練

• AWS GameDay: 数人のチームに分かれて、AWS上に払い出された実際の環境をトラブルシュートしていくコンペティション形式のイベント

https://eow.alc.co.jp/search?q=game-day

https://aws.amazon.com/gameday/

https://eow.alc.co.jp/search?q=game-day

https://aws.amazon.com/gameday/


AWS GameDay


Gremlin


Gremlin Inc.

• Chaos Engineering のための仕組みやツールを提供する企業。「 Gremlin」は会社名かつサービス名。

• Chaos Testを運用するために必要なライブラリ、デーモン、DockerImage、ワークフロー管理コンソールなどが揃っている。

• デーモンベースの仕組みだけでなくアプリケーション・レイヤでの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/

https://www.gremlin.com/team/

https://www.gremlin.com/


www.gremlin.com

https://www.gremlin.com/community/tutorials/gremlin-scenarios-walkthrough/

https://www.gremlin.com/community/tutorials/gremlin-scenarios-walkthrough/


www.gremlin.com


OSS Tools?


OSS Tools

ChaosTookit https://github.com/chaostoolkit

• Experimentを定義し再利用可能な形に構成することが可能

• CUIツールで、プラガブルな設計

• 自動化: Jenkinsなどと連携可能

• モニタリング: Humioなどと連携可能

• 開発をリードする Russ MilesO’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 langfile 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 langfile 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

https://github.com/chaostoolkit

https://www.humio.com/chaos-observability

https://www.oreilly.com/library/view/learning-chaos-engineering/9781492050995/


OSS Tools: Others

Awesome Chaos Engineering

https://github.com/dastergon/awesome-chaos-engineering#notable-tools

Chaos Engineering関連のツール、本、記事、講演などの情報をまとめているリポジトリ

最近も更新は続いている

https://github.com/dastergon/awesome-chaos-engineering#notable-tools


OSS Tools: Serverless

aws-lambda-chaos-injection

Chaos Injection library forAWS 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の値であることが確認できる。

https://github.com/adhorn/aws-lambda-chaos-injection

https://www.youtube.com/watch?v=B1nUzbuVEUs

https://www.slideshare.net/AmazonWebServices/breaking-containers-chaos-engineering-for-modern-applications-on-aws-con310-aws-reinvent-2018pdf

https://medium.com/@adhorn/failure-injection-gain-confidence-in-your-serverless-application-ce6c0060f586


テストは重要、それでもなお基本的な設計も重要

Chaos Testに取り組むなら、最低限の可用性設計はできていることが望ましい。特に本番での実施に臨むなら

✅ AWS Well-Architected Frameworkhttps://aws.amazon.com/jp/architecture/well-architected/

お客様のワークロードと AWS のベストプラクティスを比較し、安定した効率的なシステムを作成するためのガイダンスを得るのに役立つ戦略。ホワイトペーパーや評価ツールも提供。

✅ A ROADMAP TOWARDS CHAOS ENGINEERING @ChaosConf2019https://speakerdeck.com/chaosconf/a-roadmap-towards-chaos-engineering

そもそもこういう設計を意識した上で Chaos Testしようね、という設計パターンを整理（英語）

✅ スポットインスタンス ~ AWS でゲームサーバーの堅牢性を高めるシステム設計~ @CEDEC2019https://cedil.cesa.or.jp/cedil_sessions/view/2068 （資料の閲覧には CEDiLへの登録が必要です）

クラウドに適した堅牢な設計について、スポットインスタンスの導入という観点から紹介

https://aws.amazon.com/jp/architecture/well-architected/

https://speakerdeck.com/chaosconf/a-roadmap-towards-chaos-engineering

https://cedil.cesa.or.jp/cedil_sessions/view/2068


前半のまとめ

• Chaos Engineering• 分散システムの信頼性を担保するのは難しい

• どこで何が起きたときにどこに影響？複雑な依存関係→テストしよう、本番環境で、安全に、継続的に。

• 手法と運用の進化• 科学的検証、アプリケーション・レイヤでの障害注入、自動化と継続性、モニタリングとの統合、CI/CDとの統合。

• サービスやツールなどエコシステムの発展• まずは基本的な可用性設計を（あるいは開発環境での導入がおすすめ）


Chaosconf

Gremlin, Inc主催

Sep25-26 , 2019

@San Fransisco

参加者数約600名(昨年約400名)

公演数 13 本

Day0 Bootcamp

Day1 Session


Day1


50%

25%

9%

8%8%

industory

IT

Retail

Media

Apparel

23%

8%

8%61%

Chaos Target System

MicroService

Monolith

Human

Unknow

IT業界に限らない Micro Serviceに限らない

Movie https://www.twitch.tv/videos/486647178 Slides https://speakerdeck.com/chaosconf/

登壇企業の統計

https://www.twitch.tv/videos/486647178

https://speakerdeck.com/chaosconf/


Agenda

Why do chaos ?

Our 4 Step Approach

Our Next Approach


Who am I


“Everything fails all the time”

Werner Vogels, Amazon CTO


システムが壊れる（不安定になる）引き金

Ops Dev Vendor


障害は不可避

• 大規模な障害は年１〜、どこかしらのRegionで発生

• Not if, but when …

https://aws.amazon.com/premiumsupport/technology/pes/

https://aws.amazon.com/premiumsupport/technology/pes/


ある１週間のインシデント

• サービス別に色分け

• サイズ＝インシデント規模

• ほぼ毎日何かが起きている


0

2

4

6

8

10

12

201120122013201420152016201720182019

Cygames Mobile Game Titles

• 設立以来運用タイトル増傾向

• 運用タイトル増 ≠ Ops人員増

• 障害に未然に防止、軽減して運用コストの減少へ

運用作業の低減


障害により影響を与えるもの…


Why do chaos ?

• Everything fails all the time

• 障害を前提とした設計か？検証

• 障害発生は Not if , but when

• 事前認知と対策によるOpsコスト低減

• ユーザ離れの回避

• ブランド信頼失墜の回避


Basic 4 STEP

principles をベースとして

次の4 step で実施した

• 定常状態

• 仮説設定

• 故障発生

• 仮説反証

Chaos Loop と名付けた

https://principlesofchaos.org



定常状態

仮説反証故障発生

仮説構築

Chaos Loop


Step1 定常状態を仮定する

システムの振舞いを示す指標を用いて定常状態を定義

e.g.

CPU Usage < 60% Connection < 2000Latency 99th < 5s


Step 2 仮説を構築する

定常状態が通常と実験グループで継続する仮説を構築

e.g.

● EC2 インスタンスが全対比1%停止しても稼働率は99.99%● CPU Usage 80 % 超過しても平均レイテンシーは 200ms 以内● RDS で Failover が発生してもロールバックが正常実行


Step 3 故障を発生させる

実際に起きうるイベントをシステムに付加する

e.g.

インスタンス停止 Network 遮断 CPU Usage 100%


例 AWS API

AWS API

EC2 Stop, Reboot, Kernel Panic

ElastiCache Stop, Reboot

ECS Stop Task

RDS(Mysql) Reboot, Failover

RDS(Aurora) Reboot, Failover, Fault Injection Queries

Network Switch Security Group, Network ACL Allow / Deny


例 Linux command

linux command

CPU stress

Memory stress

Disk dd

Network tc


Step 4 反証をあげる

通常と実験グループのシステム出力を振り返り反証をあげる

● 反証された場合

○ 同様のイベントに対する対策

○ 構成変更やプログラム修正を行う

● 反証されない場合

○ さらに故障度を上げても同様の振る舞いになるか


事例 : ElastiCache Reboot

• Dev環境で実施（Not production)

• Web / Cache / DB 3Tiear で Monolith な構成

• Web サーバと Cache Node 間の接続は、WEBサーバ内のプロキシを経由

• プロキシは接続不能となった Cache Node をプールから除外

定常状態

仮説反証故障発生

仮説構築

Chaos Loop

99th percentile < 5s起動中の ElastiCacheに

切替る

反証された ElastiCache Reboot


AWS Cloud

Application Load

Balancer Amazon EC2

Amazon ElastiCache

Amazon RDS


AWS Cloud

Application Load

Balancer Amazon EC2

Amazon RDS

Node NodeNode


AWS Cloud

Application Load

Balancer

Amazon RDS

Node NodeNode

Instance

Instance

Instance


AWS Cloud

Application Load

Balancer

Amazon RDS

Node NodeNode

Instance

Instance

Instance

reboot


AWS Cloud

Application Load

Balancer

Amazon RDS

Node NodeNode

Instance

Instance

Instance


振り返り

結果

• Cache Node は正常に Pool から外れるが…

• Web サーバ内プロキシの状態が、サーバ毎に一致しないパターンを確認

• リクエストが到達するWeb サーバによって結果が変わってしまう…

アクション

• Monitoring と Alerting を仕込む

• Cache Proxy の状態が異常な場合は ELB から除外→再起動→再投入

障害の種を事前に発見、対策までできた１例


その他の実験内容や効果など

http://tech.cygames.co.jp/archives/3178/

http://tech.cygames.co.jp/archives/3178/


よりアグレッシブな実験をするために

• プロダクションでの実施

• オートメーション

• 影響の最小化

https://principlesofchaos.org



どんな方法が考えられるか


Traffic Control に着目する


Netflixではどうやっているか

https://arxiv.org/abs/1905.04648



canary deployment を応用

一時的な baseline / canary クラスタ




安全のメカニズム

• ビジネスアワー 9am to 5pm に制限

• 異常なインパクトを検知したら自動停止

• 実験トラフィックの総量は全体の５％未満

• Failover : 別リージョンへの Traffic 退避

Netflix では Chaos と言えども、規律に基づいて実験をしている

トラフィックを安全に扱えば影響を最小化でき、

Chaos Engineering を適用する幅は広げられる


AWSでトラフィックを制御するには

Feature Routing target

Amazon Route 53 Weight Routing X% users

AWS Lambda Traffic shifting with aliases X% users

AWS App Mesh Virtual Router X% users / specific users

Application Load

BalancerContent-based Routing specific users


Amazon Route53

• Weighted routing policy

• 一つのドメインに複数のリソースを紐付ける

• 各リソースへの重みを0~255の整数値で設定


Amazon Lambda

• Traffic Shifting Using Aliases

• Aliasで 2 version までの Traffic Shifting を設定可能

• アプリケーションコード内へのfault injection 実装が必要となる


App Mesh

• Fargate / EC2 / ECS / EKS / Kubernetes on EC2 に適用可能なサービスメッシュ

• Virtual Router にどの Virtual Nodeに何％のトラフィックを振り分けるかを明示

• Headers based routing も可能


Application Load Balancer

• Content-based Routing で様々な条件でリクエストを振り分けることが可能• Host-based Routing

• Path-based Routing

• HTTP header-based routing

• HTTP method-based routing

• Query string parameter-based routing

• Source IP address CIDR-based routing


AWS上でのトラフィック制御

• 本番で実施するためには必須• ユーザにクリティカルなインパクトを与えない

• VM・Container・Serverlessにも適用できる• ALB / Lambda / App Mesh / Route 53 でのトラフィック制御

• Chaos engineering を安全に行う土台がAWSにはある

今後は、

トラフィック制御を有効活用して適用範囲を拡大する（予定）

production 環境でも実行にもチャレンジする（予定）


We are hiring chaos engineer !

https://www.cygames.co.jp/recruit/engineer/

https://www.cygames.co.jp/recruit/engineer/


アンケートご協力のお願いお手持ちの受講票のアンケート用QRコードから

アンケートにお答えいただくと、記念品を差し上げております。

※イメージです

プレゼントの引き換えは、神田明神の会場出口付近（屋外）までお越しください

IT情報安全守護

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

申し込み受付中

AWS 最新アップデート / コンテナ / AIML / AWS アンチパターン /

認定試験対策講座など60セッション

オンラインで参加できるカンファレンス、全 60 セッション

10/9, 10/15 ライブ配信AWS エキスパートへの

Q&A

修了証明書の発行業務時間に視聴

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

Application Development

Container

Serverless

オンラインで参加できるカンファレンス、全 60 セッション

おすすめセッション

t o k y o · 2020-06-06 · より精緻なmicroservices レベルでの障害注入 •...

Documents