カオス エンジニアリング: 意図的な破壊の芸術。 パート2

ノート。 翻訳。: この記事は、AWS テクノロジー エバンジェリストの Adrian Hornsby による一連の記事の続きです。彼は、IT システムの障害の影響を軽減するための実験の重要性を、シンプルかつ明確な方法で説明することを目指しています。

「計画を立てなければ、失敗するつもりだということになる。」 - ベンジャミンフランクリン

В 最初の部分 この一連の記事では、カオス エンジニアリングの概念を紹介し、それが本番環境の障害につながる前にシステムの欠陥を見つけて修正するのにどのように役立つかを説明しました。 また、カオス エンジニアリングが組織内でポジティブな文化的変化をどのように促進するかについても説明しました。

第 XNUMX 部の最後に、「システムに障害を導入するためのツールと方法」について話すと約束しました。 残念ながら、この点に関して私の頭では独自の計画があったため、この記事では、カオス エンジニアリングを始めようとする人々の間で生じる最も一般的な質問に答えようと思います。 最初に何を壊すか？

素晴らしい質問です！ しかし、このパンダのことは特に気にしていないようで……。

カオスパンダに手を出すな！

簡潔な答え: リクエスト パスに沿って重要なサービスをターゲットにします。

長くなりますが明確な答え: カオスの実験をどこから始めればよいかを理解するには、次の XNUMX つの領域に注意してください。

1. 調べる クラッシュ履歴 そしてパターンを特定します。
2. 決める 重要な依存関係;
3. いわゆる 自信過剰効果.

面白いですが、この部分も同様に簡単に呼び出すことができます。 「自己発見と啓発への旅」。 その中で、いくつかのクールな楽器で「演奏」を始めます。

1. 答えは過去にある

覚えていると思いますが、最初の部分で私はエラー修正 (COE) の概念を紹介しました。これは、テクノロジー、プロセス、または組織における間違いを分析して、その原因を理解し、防止するための方法です。将来的に再発する可能性があります。 一般に、ここから始める必要があります。

「現在を理解するには過去を知る必要がある。」 — カール・セーガン

障害の履歴を確認し、COE または事後分析でタグ付けして分類します。 問題を引き起こすことが多い一般的なパターンを特定し、COE ごとに次の質問を自問してください。

「これは予測できたので、フォールト挿入によって防ぐことができたでしょうか?」

私のキャリアの初期に一度失敗したことを覚えています。 単純なカオス実験をいくつか実行していれば、これは簡単に防ぐことができたでしょう。

通常の状態では、バックエンド インスタンスは次のヘルス チェックに応答します。 ロードバランサー (ELB)）。 ELB はこれらのチェックを使用して、リクエストを正常なインスタンスにリダイレクトします。 インスタンスが「異常」であることが判明すると、ELB はそのインスタンスへのリクエストの送信を停止します。 ある日、マーケティング キャンペーンが成功した後、トラフィック量が増加し、バックエンドのヘルス チェックへの応答が通常より遅くなり始めました。 これらの健康診断は、 深いつまり、依存関係の状態がチェックされました。

しかし、しばらくの間はすべてが順調でした。

その後、すでにかなりストレスの多い状況下で、インスタンスの 100 つが重要ではない通常の ETL cron タスクの実行を開始しました。 高トラフィックと cronjob の組み合わせにより、CPU 使用率がほぼ XNUMX% に達しました。 CPU の過負荷によりヘルスチェックへの応答がさらに遅くなり、ELB はインスタンスにパフォーマンスの問題が発生していると判断しました。 予想通り、バランサーはトラフィックの分散を停止し、その結果、グループ内の残りのインスタンスの負荷が増加しました。

突然、他のすべてのインスタンスもヘルスチェックに失敗し始めました。

新しいインスタンスを起動するにはパッケージのダウンロードとインストールが必要で、ELB が自動スケーリング グループ内でパッケージを XNUMX つずつ無効にするよりもはるかに長い時間がかかりました。 すぐにプロセス全体が臨界点に達し、アプリケーションがクラッシュしたことは明らかです。

その後、私たちは次の点を永遠に理解しました。

• 新しいインスタンスを作成するときにソフトウェアをインストールするには時間がかかります。不変のアプローチを優先することをお勧めします。 ゴールデンアミ.
• 困難な状況では、ヘルスチェックと ELB への応答を優先する必要があります。残りのインスタンスの動作が複雑になることは絶対に避けてください。
• ヘルスチェックのローカル キャッシュは (たとえ数秒間であっても) 非常に役立ちます。
• 困難な状況では、cron タスクやその他の重要ではないプロセスを実行しないで、最も重要なタスクのためにリソースを節約してください。
• 自動スケーリングする場合は、より小さいインスタンスを使用します。 10 個の小さな標本からなるグループは、4 つの大きな標本からなるグループよりも優れています。 10 つのインスタンスに障害が発生した場合、最初のケースではトラフィックの 9% が 25 ポイントに分散され、XNUMX 番目のケースではトラフィックの XNUMX% が XNUMX ポイントに分散されます。

このように、 これは予見できたので、問題を導入することで防ぐことができたでしょうか?

はい、そしていくつかの方法で。

まず、次のようなツールを使用して高い CPU 使用率をシミュレートします。 stress-ng または cpuburn:

❯ stress-ng --matrix 1 -t 60s

ストレス-ng

次に、インスタンスをオーバーロードします。 wrk および他の同様のユーティリティ:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

実験は比較的単純ですが、実際の失敗によるストレスを経験することなく、考えるための良い材料を提供できます。

しかし そこで止まらないでください。 テスト環境でクラッシュを再現し、質問に対する答えを確認してください。これは予見できたので、障害を導入することで防止できたのでしょうか?」 これは仮説をテストするためのカオス実験の中のミニ カオス実験ですが、失敗から始まります。

それは夢だったのでしょうか、それとも本当に起こったのでしょうか？

したがって、失敗の歴史を研究し、分析してください EOC、「ヒット半径」、より正確には影響を受ける顧客の数によってそれらをタグ付けして分類し、パターンを探します。 この問題を導入することで、この事態を予測して防ぐことができたかどうかを自問してください。 答えを確認してください。

次に、範囲が最大の最も一般的なパターンに切り替えます。

2. 依存関係マップを構築する

アプリケーションについて少し考えてください。 その依存関係を示す明確なマップはありますか? 障害が発生した場合にどのような影響があるか知っていますか?

アプリケーションのコードにあまり精通していない場合、またはコードが非常に大規模になっている場合、コードの機能やその依存関係を理解するのが難しい場合があります。 これらの依存関係と、それらがアプリケーションとユーザーに与える可能性のある影響を理解することは、カオス エンジニアリングをどこから始めるべきかを知る上で重要です。開始点は、最大の影響範囲を持つコンポーネントです。

依存関係を特定して文書化することを「」と呼びます。依存関係マップの構築» (依存関係マッピング)。 これは通常、大規模なコード ベースを持つアプリケーションに対して、コード プロファイリング ツールを使用して行われます。 (コードプロファイリング) および計器類 (計装)。 ネットワーク トラフィックを監視してマップを作成することもできます。

ただし、すべての依存関係が同じというわけではありません (これにより、プロセスがさらに複雑になります)。 いくつかの 致命的、 他の - 二次的 (少なくとも理論上は、重要ではないと考えられていた依存関係の問題が原因でクラッシュが発生することが多いため).

重要な依存関係がなければ、サービスは機能しません。 重要ではない依存関係」してはいけない» 転倒時にサービスに影響を与えるため。 依存関係を理解するには、アプリケーションで使用される API を明確に理解する必要があります。 これは、少なくとも大規模なアプリケーションでは、思っているよりもはるかに難しい場合があります。

まずはすべての API を確認してください。 一番強調する 重要かつ重要な。 取る зависимости コードリポジトリからチェックしてください 接続ログ、表示します ドキュメンテーション (もちろん、それが存在する場合は、そうでない場合はまだ残っていますоもっと大きな問題）。 ツールを使用して、 プロファイリングとトレース、外部呼び出しを除外します。

次のようなプログラムを使用できます netstat - システム内のすべてのネットワーク接続 (アクティブなソケット) のリストを表示するコマンド ライン ユーティリティ。 たとえば、現在の接続をすべてリストするには、次のように入力します。

❯ netstat -a | more 

AWS では次のことができます フローログ (フロー ログ) VPC は、VPC 内のネットワーク インターフェイスに送受信される IP トラフィックに関する情報を収集できる方法です。 このようなログは、他のタスクにも役立ちます。たとえば、特定のトラフィックがインスタンスに到達しない理由の答えを見つけるなどです。

使用することもできます AWS X 線。 X 線を使用すると、詳細な「究極の」情報を得ることができます。 （端から端まで） リクエストがアプリケーション内を移動する際の概要を把握し、アプリケーションの基礎となるコンポーネントのマップも作成します。 依存関係を特定する必要がある場合に非常に便利です。

AWS X-Ray コンソール

ネットワーク依存関係マップは部分的な解決策にすぎません。 はい、どのアプリケーションがどのアプリケーションと通信しているかが表示されますが、他にも依存関係があります。

多くのアプリケーションは DNS を使用して依存関係に接続しますが、他のアプリケーションはサービス検出を使用したり、構成ファイル内でハードコーディングされた IP アドレスを使用したりする場合もあります (例: /etc/hosts).

たとえば、次のように作成できます。 DNSブラックホール 経由 iptables そして何が壊れるか見てみましょう。 これを行うには、次のコマンドを入力します。

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNSブラックホール

場合 /etc/hosts または他の設定ファイルを使用すると、何も知らない IP アドレスが見つかることがあります (はい、残念ながら、これも起こります)。再び助けを求めることができます。 iptables。 あなたが発見したとしましょう 8.8.8.8 そして、これが Google のパブリック DNS サーバー アドレスであることを知りません。 を使用することで iptables 次のコマンドを使用して、このアドレスへの送受信トラフィックをブロックできます。

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

アクセスを閉じる

最初のルールは、Google のパブリック DNS からのすべてのパケットをドロップします。 ping 動作しますが、パケットが返されません。 XNUMX 番目のルールは、システムから Google のパブリック DNS に向かうすべてのパケットをドロップします。 ping 得る 操作は許可されていない.

注: この特定のケースでは、を使用する方がよいでしょう。 whois 8.8.8.8, しかし、これはほんの一例です。

TCP と UDP を使用するすべてのものは実際には IP にも依存するため、ウサギの穴をさらに深く調べることができます。 ほとんどの場合、IP は ARP に関連付けられます。 ファイアウォールも忘れずに…

赤い薬を飲めばワンダーランドに留まり、ウサギの穴がどれだけ深いか教えてあげる。」

より根本的なアプローチは、 切断する 車を一台ずつ見て、何が壊れているかを確認してください...「カオスモンキー」になります。 もちろん、多くの実稼働システムはそのようなブルー​​ト フォース攻撃向けに設計されていませんが、少なくともテスト環境では試すことができます。

依存関係マップの構築は、多くの場合、非常に時間のかかる作業です。 私は最近、数百のマイクロサービスとコマンドの依存関係マップを半自動的に生成するツールの開発にほぼ 2 年を費やしたクライアントと話をしました。

ただし、その結果は非常に興味深く、有益です。 システム、その依存関係、操作について多くのことを学ぶことができます。 繰り返しますが、辛抱強く待ってください。最も重要なのは旅そのものです。

3. 自信過剰に注意

「どんなことを夢見る人は、それを信じます。」 — デモステネス

聞いたことはありますか 自信過剰効果?

ウィキペディアによると、自信過剰効果とは、「特に自信のレベルが比較的高い場合に、自分の行動や決定に対する人の自信が、それらの判断の客観的な正確さよりも大幅に大きくなる認知バイアス」です。

本能と経験に基づいて...

私の経験では、この歪みはカオス エンジニアリングをどこから始めるべきかについての大きなヒントとなります。

自信過剰なオペレーターに注意してください。

チャーリー：「これはXNUMX年間落ちてないよ、大丈夫だよ！」
クラッシュ：「待ってください…すぐに行きます！」

自信過剰の結果としての偏見は、それに影響を与えるさまざまな要因により、潜伏性があり危険ですらあります。 これは、チームメンバーがテクノロジーに心血を注いだ場合、またはテクノロジーの「修正」に多くの時間を費やした場合に特に当てはまります。

まとめ

カオス エンジニアリングの出発点を探すと、常に予想以上の結果が得られます。チームはすぐに物事を壊し始めると、(カオス) のよりグローバルで興味深い本質を見失います。エンジニアリング - クリエイティブなアプリケーション 科学的方法 и 経験的証拠 （ソフトウェア）システムの設計、開発、運用、保守および改善のため。

これで第 XNUMX 部は終了です。 レビューを書いたり、意見を共有したり、手をたたいたりしてください M。 次のパートでは、 本当に システムに障害を導入するためのツールと方法を検討します。 それまで！

翻訳者からの追伸

私たちのブログもお読みください:

• «カオス エンジニアリング: 意図的な破壊の芸術。 パート1";
• «Kubernetes で高可用性を実現する方法";
• «モニタリングと Kubernetes (レビューとビデオ レポート)";
• «Kubernetes での kube-proxy とノードの非可用性の実験'。

出所： habr.com