ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

自前のChaos Monkeyを構築する

2012念に Netflix は クラウド言語でクールな響きの名前の一つを導入しました。

Chaos Monkeyができることは、非常にシンプルです。 It それはAmazon Web Service上で稼動し、唯一の目的はランダムにプロダクションのインスタンスを一掃することです。

それらの意図的な失敗の背後にある理論的根拠は、しっかりしています。

Chaos Monkeyをインフラストラクチャに設定することで、いろいろなことを処理してくれて、アプリの強化に役立ちます。復旧が進み、定期的に改善できるようになると、ユーザーへの多大な影響はなく、実際の問題に対処できるようになります。

当社のMonkey

当社は、AWSやJavaを使用していないので、簡単なPythonスクリプトの形で自社のライトなMonkeyを構築することを決めました。結果としては、同じです。そこで当社は、それをシステム上に解き放ち、それがランダムにプロダクションのインスタンスを探し出し、破壊するのを観察しました。

それらの自傷行為のインシデントから観察したこと、その後でインフラストラクチャ上でChaos Monkeyを使用する際に考慮すべきかについて、注意事項を以下に紹介します。

Monkey Island - 3 つ頭のサル

設計上で考慮すべき点

1.営業時間中にカオスのイベントを引き起こす

夜中に不要なオンコールイベントでエンジニアを起こすことは、決して良いことではありません。しかし、実際の故障は、毎日24時間起こりうります。Chaos Monkeyに関しては、それらに対応して修正する人たちがいる際に、失敗を引き起こすのが最善です。

2.どれだけ不確定要素を入れるか決める

Pythonスクリプトが、カオスのイベントを引き起こす時には、HipChatルームでメッセージを受け取り、誰もが何かおかしなことがないかを確認できます。

メッセージは、どのような障害が何であるかは指定しません。そのため、実際の障害停止の場合と同じように、アラートを選別し、どこに障害があるかを判断する必要があります。すべてのこの「ソフト」の警告は、エラーの発生の見過ごしを軽減するだけです。

3. いくつかの故障モードを発生させる

インスタンスを強制終了するのは、障害をシミュレーションするには良い方法ですが、それではすべての不測の事態をカバーしていません。Server Density では完全または部分的な障害を引き起こすために、SoftLayer APIを使用しています。

例えば、サーバーの電源停止は、完全な故障​​の原因となります。一方で、インターフェイスをネットワーク無効にすることで、ホストが稼動し続けることができる部分を故障させます(そしておそらく当社の監視サービスにレポートを送信します)。

4.連続的なイベントを引き起こさない

もし、Chaos Monkeyを解き放つのに悪いタイミングがあるとすれば、それは以前のカオスのイベントのすぐ後です。特に、発見したバグがまだある場合は、また修正されていません。

当社では、次の失敗を引き起こす前に、数時間を待つことをお勧めします。チームが問題解決のために一日中時間を費やしたいなら話は別ですが。

5.イベントの発生確率を調整する

現実のインシデントは、少しも期待している時に起こる傾向があります。カオスのイベントについても同じです。たまに起こるように設定してください。。ランダムにしてください。数日など間隔をおいてください。それはオンコールの準備ができているかのテストの最適な方法です。

初期の結果

当社は、かなりの長い期間に渡り、カオスのイベントを引き起こしてきました。これまでに発見した問題のいずれも、サーバーソフトウェアによって引き起こされたものではありませんでした。実際には、ロードバランサ(Nginx) 及びデータベース( MongoDBの)でのフェイルオーバーのようなシナリオが非常にうまくいきました。

当社が見つけた一つ一つのバグは、自身のコードの中にありました。当社のアプリがフェールオーバーモードでどうやりとりしているか、自分たちで書き込んでいないライブラリがほとんどの原因でした。

当社の一番最近のカオスの実行では、2つの連続したMongoDBサーバーのフェールオーバー中に、不可解なパフォーマンスの遅延がありました。長いダウンタイムになるようサーバーを再起動すことは、実行可能な長期的な解決法はありませんでした (>5 分)。

当社が適切にMongoDBのドライバを起動していなかったと分かるまで、調査に数日間を要しました。

カオスによって引き起こされるアプリの遅延が勤務時間中に起きました。当社のオンコールエンジニアが通知される待つのではなく、すぐに問題を発見することができ、調査が困難である場合には応答することができます。

このようなことを発見で、バグの報告や、当社のソフトウェアの耐障害性の向上に役立ちます。もちろん、それはエンジニアリングにとっての余分な時間と正しく物事を遂行するための努力を意味します。

ようやく

Chaos Monkeyはインフラが未知の障害状態の下で、どのように動作するかテストするための優れたツールです。ランダムシステム障害にを引き起こし、対処することによって、製品やサービスを強化し、より弾力性ができます。稼働時間の指標やサービスの全体的な品質への利点は明らかです。
もし、このすべての練習にクールな名前あれば、なお良しということです。

*編集者注:この記事は元々は2013年11月21日に掲載され、正確性と包括性のために、改訂されました。 *