# Automating chaos experiments in production Conference/Journal: ICSE Created: June 7, 2021 5:00 PM URL: https://blog.acolyer.org/2019/07/05/automating-chaos-experiments-in-production/ Year: 2019 [Automating chaos experiments in production | the morning paper](https://blog.acolyer.org/2019/07/05/automating-chaos-experiments-in-production/) NetflixのResilience Engineering teamからの論文。 あなたのシステム保証プログラムを次のレベルに引き上げる準備はできていますか？これは、NetflixのResilience Engineeringチームのメンバーが、彼らのカオスエンジニアリングの取り組みについて説明した興味深い論文です。この論文では、Gray failure条件の下でシステムがどのように動作するかについての仮説を検証し、弱点を調査して洗い出すために、制御された自動実験を行っています。制御された」という部分が重要なのは、テスト対象となる環境の規模と複雑さを考えると、これを行う意味があるのは実際のユーザーがいる本番環境だけだからです。 [[Gray failure - the Achilles’ heel of cloud-scale systems]] 恐ろしく聞こえるかもしれませんが、本稿がもたらす興味深い視点の一つは、本番環境に展開する他の変更（バグ修正、設定変更、新機能、A/Bテストなど）と実際にはそれほど変わらないことに気づかせてくれることです。どのような場合でも、システムへの影響を注意深く監視し、うまくいかなくなったら手を引くことができなければなりません。さらに、A/Bテストのように、実験中にメトリクスを収集し、最後に統計分析を行って結果を解釈します。 Netflixのシステムは、相互作用するマイクロサービスの複雑なセットとしてパブリッククラウド上に展開されています。 > このような環境では、インフラ自体に起因するもの（ハードウェアの劣化、一時的なネットワークの問題など）や、Netflixのエンジニアが実施した変更が意図した効果を発揮しなかったことが原因となるものなど、多くの障害原因が考えられます。 これらの障害の影響を軽減するために、タイムアウト、リトライ、フォールバックを組み合わせて使用していますが、これらはハッピーパスほど頻繁に実行されるわけではないので、呼び出されたときに意図したとおりに動作すると確信することはできません。さらに、複数のコンポーネント間の相互作用から生じる、予測困難な創発的な動作もあります）。Netflixには、そのような自信を与える手助けをする役割を持つChAPがあります：Chaos Automation Platformです。 > ほとんどのChAP実験では、サービスの1つが劣化しても、システム全体が健全に保たれるかどうかを評価することに重点を置いています。ここでは、サービスの速度低下（応答遅延の増加）とサービスの完全な失敗（エラーの発生）の2つの障害モードに注目しています。 ChAPは、他の多くのNetflixシステムと連携してタスクを実行します。障害注入用のFIT、ベースラインおよびカナリアクラスターのプロビジョニング用のSpinnaker、カナリアまたはベースラインへのユーザートラフィックのルーティングを管理するZuul、実験中の遠隔測定用のAtlasおよびMantis、メトリクスデータを表示するLumenダッシュボード、そしてKayenta自動カナリア分析システムです。 仮説の例としては、ブックマークサービス（ビデオの中で最後に見た場所を記憶するサービス）がダウンしても、ユーザーはビデオをストリーミングすることができるというものがあります。これを検証するために、NetflixのエンジニアはChAP UIを使って、"ブックマークサービスへのRPCを失敗させ、システム全体とAPIサービスが健全であることを検証する "という実験を行うことができます。 通常、実験のためにデプロイされるベースラインおよびカナリアクラスターは、オリジナルクラスターの1％のサイズになります。カナリアグループに選ばれたユーザーは、ブックマークサービスへのコールを失敗させるフォールト・インジェクション・ルールが追加されたカナリアクラスターにルーティングされます。 > 注入された障害がシステムの健全性に悪影響を与えているかどうかを判断するために使用するメトリックには、主に2種類あります。(i) カナリアグループのユーザーとベースライングループのユーザーのKPI（主要業績評価指標）、(ii) カナリアクラスタとベースラインクラスタのヘルスメトリクス。 実験終了後、Kayentaはカナリアクラスターから収集したメトリクスを統計的に分析し、ベースラインクラスターから収集したメトリクスと比較して、関心のあるメトリクスに統計的に有意な影響があったかどうかを判断します。 > Kayentaはもともとカナリアの健全性を評価するために設計されたものですが、ChAP実験の結果を分析するのにも適していることがわかりました。 ### Safeguards ChAPでは、実験の爆発半径を最小限に抑えるために、さまざまな安全策を講じています。 - 実験は平日の営業時間内にのみ行われる。 - 実験は、独立した理由でリージョンがフェイルオーバーされた場合には実行されません。 - 同時に実行されるすべてのChAP実験（多くの実験が継続的に実行される可能性があるため、専用のベースラインおよびカナリア・クラスターが必要となる）は、1つの地域の総トラフィックの5％以上に影響を与えることはできない。 - 実験中にChAPが顧客への過剰な影響を検出した場合、実験は直ちに中止されます。 ### Defining and running experiments 当初ChAPは、チームが独自の実験を定義して実行できるセルフサービスモデルで展開されていました。このモードは現在も利用できますが、多忙なサービスチームからの利用は限られていました。そこでレジリエンスエンジニアリングチームは、サービスの依存関係を自動的に明らかにし、その情報を使って実験を自動的に生成・実行するサービス「Monocle」を開発しました。 #dependency カオスモンキーや友人たちの初期の障害注入テストメカニズムは、無差別な破壊行為のようなものでした。Monocleは、サービスが持つ弱点を探し出す、より知的なプローブです。 Monocleの依存性分析の部分は、実験の生成に入る前から、それだけでかなりクールです。Monocleは、Atlasの遠隔測定システム、トレースシステム、ランタイムサーバーに時間値などの設定情報を問い合わせることでデータを取得します。NetflixでのRPCは、Hystrixのコマンドとしてラップされます。このようなコマンドごとに、Monocleは以下の情報を表示します。 - コマンドの起動のきっかけとなったインバウンドリクエストの割合 - 失敗しても安全だと思われるかどうか - フォールバックが設定されているか - 設定されているタイムアウト - 過去2週間に観測されたレイテンシー（P90、P99、P99.5) - スレッドプールのサイズ - 過去2週間に観測されたアクティブなスレッドの数 0 コマンドがラップしている RPC クライアント（ある場合）。 - そのコマンドに関連する既知の影響 すべてのRPCクライアントに対してMonocleは表示します。 - タイムアウトとリトライの設定 - RPC 呼び出しのトリガーとなるインバウンドリクエストの割合 - 過去2週間に観測された最大呼び出し率 - Hystrixのコマンドがある場合は、それを包んでいるもの、およびそれらが失敗しても安全であるかどうか - RPCクライアントまたはそれを実装するコマンドに関連する既知の影響 上のダッシュボードのスクリーンショットでは、警告や脆弱性を強調する黄色と赤の注意アイコンが表示されています。これらには、より詳細なツールチップが付いています。 > 警告 Hystrix Command Timeout is Misaligned with RPC Client. タイムアウト(1000ms)が、ラップされたRPCクライアントの最大計算タイムアウト(4000ms)よりも小さくなっています。これは、HystrixがRPCの待ち時間を放棄することを意味します。 これらの情報をすべて使用して、MonocleはRPCクライアントとHystrixコマンドの依存関係に対して弾力性のある実験を自動的に生成します。各依存関係には、3つの基本的な実験タイプがあります。 1. 失敗 2. 設定されたタイムアウトをわずかに下回るレイテンシー（最高のタイムアウト - 過去 7 日間の P99 レイテンシー + 5% バッファ 3. 故障の原因となるレイテンシー（設定されている最高のタイムアウト＋5％のバッファー ご想像の通り、多くのサービスと大きなファンアウトがあるため、実行可能な実験の数は膨大になります。 > Monocleはヒューリスティックスを用いて、脆弱性を発見する可能性が最も高い実験を特定しようとしています。 各依存関係には、依存関係の優先度（HystrixコマンドはRPCクライアントよりも優先される）、クラスタ内の他のすべての依存関係と比較した依存関係のトリガー頻度、再試行係数、および依存関係にあるクライアントの数の積である重要度スコアが割り当てられます。 重要度のスコアは、安全度のスコアおよび実験の重み（障害実験、次に遅延、障害誘発遅延よりも）と組み合わされ、最終的な優先順位のスコアとなります。優先順位付けされたリストは、安全でない実験、すでに実行されている実験、失敗した状態の実験（以前に失敗し、まだユーザーに検査されていない）、最近実行された実験を取り除くためにフィルタリングされます。その後、Monocleは仕事に取り掛かり、残りの実験を優先順に実行し始めます。 MonocleとカオスエンジニアリングがNetflixのレジリエンスを定量的、定性的に向上させたことについて、もっと詳しく知りたいところですが、今のところはこの一文で満足するしかなさそうです。 > これまでにMonocle社が行った実験では、タイムアウトの設定が間違っていたり、フォールバックによりサービスがオーナーの意図した以上にビジネスクリティカルであることが判明したケースがいくつかありました。 自動実験によって潜在的な脆弱性が発見された場合、レジリエンスエンジニアリングチームのメンバーは、オーナーにフラグを立てる前に、実験結果の分析に手動で時間を費やします。これは誤検出率を減らし、システムへの信頼を築くのに役立つが、同時に現在のプロセスのボトルネック（「これは一般的に時間のかかる退屈なプロセスだった」）にも聞こえる。 ### On error rates SREの本を読んだことがある人は、「4つのゴールデンシグナル」（P60）と呼ばれる、レイテンシー、スループット、エラーレート、サチュレーションに出会ったことがあるだろう。だからこそ、ここに書かれていることは興味深いですね。 > 直感的には、エラーレートはシステムの問題を特定するための信頼できるシグナルのように思えますが、実験的な尺度として使用するには好ましくない特性があることがわかりました。 この問題は、1つのデバイスが何度もエラーを起こすことで、エラー数が増え、結果的にエラーレートが上昇することに起因しているようです。つまり、エラーを起こしやすい機器がたまたまカナリアクラスターに割り当てられていると、実験の観点からは偽のエラー信号が発生してしまうのです。このため、自動停止の安全機構の閾値を大幅に上げる必要がありました。デバイスごとのエラーレートを追跡することで、この問題を解決できるかもしれません）。 ### There are many types of controlled experiment > ChAPの当初の目的は、フォールト・インジェクション実験を行うことでしたが、このプラットフォーム自体が他の種類の実験にも使用できることがわかりました。現在、ChAPを拡張して、RedLinerと同様の負荷テスト実験をサポートしています。さらに、セルフサービスのユーザーの中には、ChAPが提供する追加の分析機能を利用して、ChAPをカナリアのデプロイメントに使用する実験を始めた人もいます。 フォローアップのための記事。 [Chaos Engineering Traps. Here we are. Where are we going? | by Nora Jones | Medium](https://medium.com/@njones_18523/chaos-engineering-traps-e3486c526059)