このカオスモンキーは誰ですか？なぜ彼は私のサーバーをクラッシュさせたのですか？

私は完璧なサーバーを持っていて、とてもきれいで堅実だったので、ペトラと名付けました。あらゆる点で完璧であり、すべてが適切に構成および調整され、完全な100％のサービス記録と753日間の稼働時間がありました。それがうまく動作することを確認するために多くの時間と努力を費やしました。社内の他のサーバーはこれほど優れていませんでした。しかし昨夜、この邪悪なモンスターが理由もなくサーバーをクラッシュさせました。

もちろん、午前2時に通知され、朝までそれを起動して実行し、すべてを構成して調整するのに時間がかかりましたが、以前ほど良くなることはないでしょう。以前の栄光に戻るには数週間かかるかもしれません。今、私の稼働時間は過ぎ去りました。私はほんの3つの9さえ持っておらず、これが私の評判にどう影響するかを知っています。このカオスモンキーは誰ですか？なぜ彼は私のサーバーにそれをしましたか、そしてなぜ彼は私を台無しにしようとしているのですか？

TL; DR：カオスモンキーた2010年に開発されたのはNetflixと2012年に野生の中に放出の一部であるサル軍、の間で大人気の献身的な信者。カオスエンジニアリングの原則に基づいて構築された軍隊は、システムに絶え間ない障害を注入することにより、障害に対する回復力を高めます。

概念

Chaos MonkeyはAWS用に特別に開発されたもので、Auto Scaling Group内のインスタンスをランダムに強制終了します。エンジニアが警戒し、発見された障害に迅速に対応できる営業時間中に実行することを意図しています。

シミアン軍

軍隊のメンバーは他の手段で混乱をまきます：

• Latency Monkeyは、サービスにランダムな遅延を導入します。

• Chaos Gorilla（Kong）は、可用性ゾーン全体の停止をシミュレートします。

他のサルは役に立ち、群れの弱いメンバーを取り除きます：

• Conformity Monkeyは、ベストプラクティスに従っていないインスタンスをシャットダウンします。

• Security Monkeyは、構成およびサービスの既知のセキュリティ脆弱性を探します。

• Doctor Monkeyは、特定のメトリックに適合しない不健全なインスタンスをシャットダウンします。

• Janitor Monkeyは、未使用のリソースを探して回収します。

失敗は避けられない

システムの障害は避けられないものであり、常に何かがうまくいかないでしょう。何を選択することはできないかもしれませんが、いつ選択するかを試すことができます。1日を通して小さなエラーを導入することにより、エンジニアの存在を確認できます。準拠していないサービスを迅速に強制終了することにより、展開の前に障害が頻繁に発生するようにします。環境をより敵対的にすることで、サービスが本番環境に入る前に問題に遭遇するのは開発者であることを保証します。新しいサービスと古いサービスの統合フェーズでは、障害はすぐに明らかになりますが、それは問題ありません。古い本番サービスはすでに回復力があるからです。

ペットではなく牛

誰もが最近あなたに言うでしょう：あなたのサーバーをペットとして扱わないでください。数には力があり、単一障害点はシステムをダウンさせます。サーバーをどれだけうまくチューニングして最適化しても、どんなにハードなハードウェアを手に入れても、どれだけ処理できても、小さなスケーラブルなインスタンスの群れには決して合いません。カオスモンキーは、遅かれ早かれ、モンキーがやってくるので、すべての障害点を取り除くことを考えることをお勧めします！誰もが失敗し、Amazon S3でさえ予測不可能な停止がありました。

耐脆弱性

それでは、理論とは何で、なぜ機能するのでしょうか？Nassim Nicholas Talebは、Antifragileの本で、生きている自己認識システムが、ランダム性のわず​​かなレベルから利益を得て、逆境に直面して実際に良くなるという概念を説明しています。これはアニーリングに似ています。

彼はまた、システム内の部品の脆弱性が全体の反脆弱性に移行している進化的な方法についても説明しています。転送は次の2つのレベルで発生します。

1. 小さなランダムなバリエーション（開発者が変更を加える）により、環境に最も適したものが存続して伝播し、テストに合格してデプロイされます。標準開発ライフサイクル。

2. 環境内のより大きなレベルのランダム性に耐えることができない部分の故障により、それに耐えることができた残りの部分は、全体として以前よりも変化する環境によりよく対処できるシステムを構成します。これは本質的にカオスモンキーです。

2番目のアプローチを使用すると、より大きなレベルのランダム性に耐えることができます。

この質問に対するあなた自身の答えへの追加...

追加のサル

「カオスがパフォーマンスを向上させる方法」についての記事では、これらの猿のいくつかについてさらに説明しています。

• 10-18 Monkey：複数の地域の顧客にサービスを提供するインスタンスの構成および実行時の問題を検出します。
• Chaos Kong：アマゾン地域の停止をシミュレートします。

注：同じ記事では、「Chaos Gorilla：Amazonのアベイラビリティゾーンの停止をシミュレート」も言及していますが、これは「Chaos Kong：Amazonリージョンの停止をシミュレート」に名前が変更された可能性があります。カオス！私はこれまでに確認/ドキュメントを見つけることができませんでした、少なくとも問題キューには問題がないようです。文書化されていない変更がGitHubで本番環境に到達した可能性があります...

独自のMonkeyをセットアップして使用します。

githubに移動してSimian Armyに連絡してください（自分の回答の最初のリンクと同じリンク）。ここにあなたが見つけるものの引用があります：

Simian Armyは、さまざまな種類の障害を生成し、異常な状態を検出し、それらの生存能力をテストするためのクラウド内のサービス（サル）で構成されています。目標は、クラウドを安全、安全、高可用性に保つことです。詳細については、このブログをご覧ください。

現在、サルは、カオスモンキー、用務員猿、および適合モンキー。

Monkeyのセットアップと使用を開始するには、クイックスタートガイドを参照してください。

モンキーを設定して、ビジネスニーズに合うようにすることもできます。

これらのGithubリンク内（つまり、サポートリンク内）を深く掘り下げると、SimianArmy Googleグループに参加するためのリンクも見つかります。

1つのサーバーですべてを支配し、1つのサーバーでそれらを見つけ、
1つのサーバーですべてをもたらし、停止状態でそれらをバインドします

あなた、サウロンは、すべてのアプリケーションを支配したいという願いで、データセンターを暗くしてマウント・ドゥームの暗闇の中でこのOne Serverを偽造しました。
Devopsのフェローシップが団結して、次のことを伝えてくれれば幸いです。

長い戦いの後、Frodo the Chaos MonkeyはOne Serverを溶かし、すべてのアプリケーションに自由をもたらし、同時に再現可能なサーバーの道へと導きました。

クレジット：

• ロードオブザリングオブJRRトールキン
• CleverCloudプレゼンテーションからの写真