前置き
この論文が出されたのが2019年5月だが紹介されているシステム(例えばVizceral)はもう既にNetflix内部では利用されていなかったりするので注意が必要。
まあAutomating Chaos Experiments in Productionに2017年3月に動画が出ているのでそういうことだと思うが。
要約
ChAP
Netflixでは1,000台以上のサーバーでマイクロサービスが動いていて、あるコンポーネントで障害が発生した際に可用性を維持するためにタイムアウトやリトライといった仕組みをシステムに入れているがそれがシステム全体に対してどう影響を与えるか等をテストするためにChaos Engineeringを行っている。
また、それを行うためにChaos Automation Platform(ChAP)という基盤を開発している。
ChAPではアプリケーションレベルでfault injectionを行い、failure(呼び出しの代わりに例外)とlatency(呼び出しを実行するときに遅延を入れる)をサポートしている。
experiment
実験を行う最初に2つのクラスター(apii-beseline, api-canary)をSpinnaker経由で作成する。
ランダムに選ばれた1%のユーザーが各々のクラスターにリクエストがいくようにEurekaというService Discoveryのためのツール(他のOSSでいうとCoreDNSとか
Consulとか色々ある)を使いリクエストを流す。
その2つのクラスターに対してfault injectionを行いKPIやCPU使用率等の結果を比べることで障害が起きた際のシステムに与える影響を確認している。
safety mechanism
fault injectionは障害を引き起こす可能性がある。そのリスクを軽減するためにいくつかの仕組みが導入されている。
- 働いている時間(9AM-5PM)のみ実行
- 顧客に多大な影響を与えた場合に自動的に止まる
- 総トラフィックの5%を超えないように
- failover時には実行できない
Monocle
ChAPは元々self-serveモデルを採用しユーザーが設定等を行っていたが、Monocleと呼ばれるシステムを作り設定を自動で行い実験を行うといったmanagedなモデルも採用した。
Monocleでは3つの種類の実験を生成することができる。これらは経験則に基づいて定義されるためよりシステムの脆弱な部分を見つけることができる。
- Failure
- Latency just below configured timeout (highest timeout - P99 latency over the past 7 days + 5% buffer)
- Latency causing failure (highest configured timeout + 5% buffer)
また、Criticality scoreを用いて実験の優先順位を決めている。このscoreは依存関係やリクエスト量等によって計算される。
fault injection
開発言語としてJavaを使っていたためHystrixというライブラリを開発し使っていたが、Node.jsでの開発もしたりで新しいライブラリを作る必要があったので、fault injectionの仕組みを言語ベースではなく別のアプローチとしてService Meshを採用しIstioを開発した。
感想
読みやすかったし面白かった。内容としては若干古いが考え方として参考になる部分も多いと思う。
これを書いてから気付いたけどthe morning paperというブログにまとめられていた。
Chaos Engineeringではないが仕事でバッチを開発した時にどこでエラーが起きてもリトライ可能なように設計をしたのだが、一定の確率でエラーが起きる前提で開発をすると冪等性の担保が簡単にできるようになったのでよかったことを思い出した。