【セッションレポート】Chaos Engineering ～入門と実例～を現地で見ました！【#AWSDevDay】

本セッションは共同登壇で前後半構成となってました。

登壇者

株式会社Cygames　和田 明久 氏
アマゾン ウェブ サービス ジャパン株式会社　畑 史彦 氏

前半「Chaos Engineeringの進化と今」

Chaos Engineeringとは

例えばAuto Scalingに所属させたインスタンスがいたとして、自信を持って、このAuto Scalingに所属するインスタンスを停止させることができるか（落ちてもサービスに影響なく自動復旧すると自信を持って言えるか）？

本番環境で実際にインスタンスを停止するのは勇気がいるので、それを実際に本番環境でテストしましょうよというのがChaos Engineeringの考え方。

Chaos Engineeringの歴史

• 2006年3月　Amazon S3がリリース
• 2006年8月　Amazon EC2がリリース
• 2010年12月14日　Four Reasons We Choose Amazon’s Cloud as Our Computing PlatformというブログがNetflix TechBlogより発表
• 2010年12月16日　5 Lessons We’ve Learned Using AWSというブログがNetflix TechBlogより発表

この「5 Lessons We’ve Learned Using AWS」には次のような記載がある。

The best way to avoid failure is to fail constantly.
〜〜〜
One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most — in the event of an unexpected outage.

　　

障害を避ける最も良い方法は障害を常に発生させること
〜〜〜

AWSでエンジニアが構築した最初のシステムの1つはChaos Monkeyと呼ばれます。 Chaos Monkeyの仕事は、アーキテクチャ内のインスタンスとサービスをランダムに強制終了することです。 故障しても成功する能力を常にテストしていないと、予期しない機能停止が発生した場合に、最も重要なときに機能しなくなる可能性があります。
引用元：https://medium.com/netflix-techblog/5-lessons-weve-learned-using-aws-1f2a28588e4c　※訳は引用者による

つまりこのChaos Monkeyが仕事をして、Auto Scaling内のインスタンスを停止したとしても、新たなインスタンスが配置されるはずであるという試みがこの頃から行われていた。

• 2011年６月 The Netflix Simian ArmyというブログがNetflix TechBlogより発表

ここでChaos Monkey以外の多数の猿を開発運用しているとブログで公表。
・Latency Monkey
・Conformity Monkey
・Doctor Monkey
・Janitor Monkey
・Security Monkey
・10–18 Monkey
・Chaos Gorilla

• 2014年10月 FIT: Failure Injection TestingというブログがNetflix TechBlogより発表

ここでは、FIT（Failure Injection Testing）というプラットフォームに言及。

FITとは、障害シミュレーションメタデータを用いて障害のシミュレーションを行い、狙い澄ましたポイントに障害をおこさせるもの。

このFITを構築した理由については次のように述べている。

Some of our Monkeys, by design, can go a little too wild when let out of their cages.
いくつかの猿は設計上ケージから出すと少しだけ野性的になります
引用元：https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2　※訳は引用者による

ここで主に言及しているのはLatency Monkeyについて。Latency Monkeyは、RESTfulのクライアント/サーバー通信レイヤーで人為的な遅延を引き起こし、サービスの低下を検知して、代わりのサービスが適切に応答するかどうかを測定する。 マイクロサービスで環境を構築していた場合、このLatency Monkeyが一つのサービスに影響を与えたことによって全体のサービスに影響を及ぼしてしまう可能性がある。そのため、障害のシミュレーションを行い、狙った範囲に極めて限定的なポイントに障害を発生させる試みを継続した。

• 2015年9月 Chaos Engineeringの5原則

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

• 2017年7月 CHAPとChaos Kongの発表

Chaos KongはAWSリージョン全体を強制終了するもの。 CHAPというブログではカオステストをする適切なタイミングはいつかについて言及しており、 デプロイが行われるほど、試験結果に対する自信が失われていくので、デプロイのタイミングで自動化してカオステストを行うようになった。

• 2020年6月 オライリーでChaos Engineeringの本発売予定

後半「Chaos Engineeringの進化と今」

なぜカオスエンジニアリングをするのか

システムが壊れる引き金には様々な要素が考えられる。 大規模な障害は年1、どこかしらのリージョンで発生。 内部で管理しているサービスのとある一週間のインシデントをまとめてみるとほぼ毎日何かしら起きていた。

障害によって受ける影響として次のようなものが考えられる。

• 機会
• 時間
• ユーザ、顧客
• ブランド、信頼

これらを回避するためにある一つの手法であると考えている。

私たちの４つのアプローチ

定常状態を仮定する

本番環境において以下のようなメトリクスを監視し、定常状態を仮定する。

• cpu使用率
• レイテンシ
• コネクション

仮説構築

上記の定常状態に対して仮説を立てる。

故障発生

実際に障害を発生させてみる。

仮説反証

反証された場合にはシステムを改善し、 反証されなかった場合には、より深刻な障害を発生させていく。

安全のメカニズム

影響の最小化を図る。

• 時間を短くする
• ユーザを絞る
• VM単位よりもコンテナ単位、アプリ単位で起こした方が影響は小さくなる

また、トラフィックを制御すれば安全に扱える。

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

• Route 53
• Lambda
• App Mesh
• ALB

トラフィック制御は本番で実施するためには必須。 ユーザにクリティカルな影響を与えないように気をつける。

感想

自分も前職ではそれなりにトラフィックのあるインフラを運用していたので、今日のChaos Engineeringは非常に面白かったです！発表も分かり易かったですね。

実際に本番環境とデータや状況、サードパーティのサービスも含めて全く同じ検証環境っていろんな事情で構築が難しかったりするケースってあると思うので、そういった場合には導入してみる価値のあるテストだと思いました。勿論、一歩間違うとユーザ影響が出てしまう試験なのでしっかりと可用性を担保した上で念入りな事前検証を踏まえてやらないとですが。

以上、深澤（@shun_quartet）でした！