システムの安定性に関する欠陥を積極的に発見: カオスエンジニアリング | JD クラウドテクニカルチーム

これは、カオスエンジニアリングの背景、現状、JD のカオスエンジニアリングの実践など、カオスエンジニアリングに関するより詳細な研究レポートであり、皆様がカオスエンジニアリング技術をより深く理解し、カオスエンジニアリング実験を通じてシステムをより適切にエスコートするのに役立つことを願っています。

I. 概要

1.1 研究の背景

Netflix は、カオスエンジニアリングの概念を初めて体系的に提案しました。2008 年 8 月、データベース障害により Netflix が 3 日間停止され、DVD オンラインレンタルビジネスが中断され、巨額の経済的損失が発生しました。そこで Netflix は、カオスエンジニアリングを使用して安定性保証システムを最適化する試みを開始しました。2010 年、Netflix はカオスエンジニアリングプログラム Chaos Monkey を開発し、2012 年に Simin Army プロジェクトでオープンソース化されました。このプログラムの主な機能は、運用環境で実行されている仮想マシンインスタンスとコンテナをランダムに終了し、システムインフラストラクチャの損傷をシミュレートすることです。 . システムサービスの堅牢性をテストするシナリオ。2019 年、アリババはカオスエンジニアリングプログラム ChaosBlade をオープンソース化し、カオスエンジニアリング実験のために Alibaba Cloud と組み合わせることができます。2020 年、PingCap は中国のデータベース分野における優れたオープンソース企業として、社内のカオスエンジニアリング実践プラットフォームである ChaosMesh をオープンソース化しました。

上記のオープンソースプロジェクトに基づいて、カオスエンジニアリングプロジェクトは中国の多くの企業の注目を集めており、システムの安定性を確保するためにカオスエンジニアリングを導入し始めたり、ソフトウェアシステムを回避するためにカオスエンジニアリングを通じて積極的に障害を挿入したりする企業が増えています。危機。図 1.1 は、ソフトウェアシステムの安定性危機とその対策開発スケジュールの対応関係を示しており、ソフトウェアシステムの規模の拡大、システムの複雑さの増加、開発サイクルの短縮に伴い、複数のソフトウェア危機が発生していることがわかります。同時に、次のソフトウェア危機のたびに、ソフトウェアシステムの安定性保証対策の継続的な改善が促進されています。しかし、現在のソフトウェアシステムの規模、複雑さ、開発の機敏性は再び新たな段階に入り、システムの安定性に関して新たな課題が生じています。このとき、システムの安定性の欠陥を積極的に発見するカオスエンジニアリングが登場し、現在のシステムの安定性保証手法の欠点を再び補いました。

図 1.1 ソフトウェアシステム安定性危機とその対策開発のタイムライン [出典: 中国情報通信技術院]

1.2 研究目的

タレブはかつて「反脆弱性」という本の中で、「システムが不確実性からどのように利益を得ることができるか」というアイデアを説明しました。カオスエンジニアリングはこの素晴らしいアイデアに基づいており、システムが不確実であることを真に検証するために一連の実験を使用することを提唱しています。現場でのパフォーマンスは、頻繁に多数の実験を実施することにより、システム自体の耐脆弱性を高め続けています。それぞれの障害から得られる利益により、システムは継続的に進化し、正のサイクルを形成し、システムの品質が徐々に向上し、システムの堅牢性が確保されます。したがって、カオスエンジニアリング研究の主な目的は、システムの安定性に関する欠陥を積極的に発見することです。表 1-1 には、近年発生したいくつかの重大なシステム安定性障害イベントがリストされており、側面からのシステム安定性保証の重要性が反映されています。

表 1-1 システム安定性障害イベント

会社名	発生時期	間隔	影響範囲	問題の原因
ビリビリ	2021年7月	約1時間	動画再生やライブブロードキャストなど複数の基幹サービスに影響	コンピュータ室障害、災害復旧システム障害
ディディ	2021年2月	約1時間	滴滴タクシーアプリ	内部システムエラー
グーグル	2020年12月	約1時間	Google の複数の事業	ストレージ制限を超えました
アマゾン	2020年11月	約5時間	一部のサーバーにアクセスできません	不適切なO&M操作によりシステムの脆弱性が引き起こされる
マイクロソフト	2020年9月	約5時間	Microsoft Office 36 オフィスソフトウェアと Azure クラウド製品	トラフィックの急増によりサービスが中断される

カオスエンジニアリングがシステムの安定性を保証する標準化された手段になると、システム全体の安定性がさらに向上します。カオスエンジニアリングプラットフォームを通じて、システムに障害をアクティブに挿入し、障害に耐えて通常の動作を維持するシステムの能力を検証および評価し、未知の欠陥を事前に特定して修復し、システムが制御不能な状況に十分に耐えられるようにします。運用環境を改善し、システムのパフォーマンスや全体的な安定性を効果的に向上させます。

1.3 研究の意義

カオスエンジニアリングの主な研究意義は、システムの安定性を向上させることであり、システムに障害を積極的に注入することで、システムの堅牢性を研究および改善し、システム障害時の受動的応答の欠点をある程度補います。、システムを削減し、障害のリスクとコストに対処します。表 1-2 にカオスエンジニアリング導入前後のシステム安定性保証方式の比較を示しますが、カオスエンジニアリング導入後のシステム安定性保証方式の方が優れていることがわかります。

表1-2 カオスエンジニアリング導入前後のシステム安定性保証手法の比較

内容を比較する	カオスエンジニアリングを使用する前に	カオスエンジニアリング使用後
バグを見つける方法	インライン欠陥発生時に認識を開始	アクティブに障害を挿入してシステムの欠陥を発見する
不具合への対処方法	事後対応、障害対応の開始時間は障害発生時期に依存	能動応答と欠陥応答の開始時間はカオスエンジニアリングの実験時間に依存する
欠陥の特定の効率化	低い、厳しいトリガー条件では潜在的な欠陥に時間がかかる可能性がある	さらに、積極的に障害を挿入することで、潜在的な欠陥ができるだけ早く露出されます。
不具合対応費用	コントロール性が悪い	コントロール性が良い

さらに、カオスエンジニアリングの実践は、さまざまな立場のスタッフにとっても独自の意味を持ちます。表 1-3 に示すように、カオスエンジニアリングは、システム関連担当者が潜在的な脆弱性を発見し、システムの安定性の欠陥によって引き起こされる可能性のある損失を軽減するのに役立ちます。同時に、カオスエンジニアリングを通じて障害を挿入すると、問題を発見して特定し、システムを迅速に復元するチームの能力を効果的に発揮できます。

表1-3 職種別カオスエンジニアリング実践の意義

位置	カオスエンジニアリングを実践することの意味
ソフトウェア開発エンジニア	システムへの理解をさらに深め、システムアーキテクチャの耐障害性を検証
テスト開発エンジニア	従来のテスト方法によって残されたギャップを補い、よりプロアクティブな方法でシステムの問題を発見します。
運用保守開発エンジニア	システム障害時の緊急効率を向上させ、障害警報、位置特定、復旧への効果的な対応を実現します。
プロダクトマネージャー	緊急時における製品のパフォーマンスを理解し、緊急時に製品を使用する際の顧客体験を向上させる

1.4 研究方法

図 1.2 カオスエンジニアリング実践システムとソフトウェア開発の一般的なプロセスの接続図 [出典: 中国情報通信技術院]

調査されたカオスエンジニアリングの実践経験によると、カオスエンジニアリングの研究開発手法は、図 1.2 のカオスエンジニアリングの実践体系として要約できます。その中で、カオスエンジニアリング実践のマッチングがカオスエンジニアリング実践成功の鍵であるため、実践チームはカオスエンジニアリング実践の戦略的計画をしっかりと行い、カオスエンジニアリング実践に関連する人材を訓練し、フォームを作成する必要があります。カオスエンジニアリングの文化を持ち、潜在的なリスクを特定して対処し、カオスエンジニアリングの実践で適切な仕事をし、効果的な評価を行います。これに基づいて、カオスエンジニアリング実験はカオスエンジニアリング研究の中核的な作業であり、カオスエンジニアリングはシステムの安定性の欠陥を研究および発見するための最小単位として実験を使用します。実験の一般的なプロセスは、実験計画、実験の実施、および結果の分析です。。具体的な内容には一般に、実験の要件と目的、実験の実現可能性評価、観察指標の設計、実験シーン環境の設計、実験ツールプラットフォームのフレーム選択、実験の計画とコミュニケーション、実験の実行と指標の収集、環境の清掃と修復、実験結果の分析、問題追跡、自動化された継続的検証。カオスエンジニアリングによってシステムの安定性の欠陥が発見された場合、実際の状況に応じて対応する解決策を与える必要があります構造的な欠陥がある場合には、安定性の欠陥を改善するために復元力のある設計を使用する必要がありますその他、境界条件や極端な場合には、状況が考慮されていない、またはコーディングエラーが比較的多く、繰り返し発生するという欠陥がある場合は、制度的規範の観点からソフトウェア開発プロセスをより適切に制御する必要があるかどうかを評価する必要があります。

カオスエンジニアリングのより具体的な理論と一般的な実験手順は、書籍『Chaos Engineering: The Way of Netflix System Stability』から入手できます。また、この書籍の電子版は、このレポートの付録にあります。この本はカオスエンジニアリングについて詳しく説明しています。図 1.3 はこの本のディレクトリ構造を示しています。

図 1.3 「Chaos Engineering: The Way of Netflix System Stability」カタログ

2. 研究状況

2.1 業界のカオスエンジニアリングツール

現在、業界ではさまざまな種類のカオスエンジニアリングツールが使用されています。表 2-1 は、この調査で見つかった、業界内で保守および更新されているいくつかのツールをまとめたものです。ツールごとに、異なる種類のフォールトインジェクションに重点が置かれています。

表 2-1 カオスエンジニアリングツールの概要

ツール名	最新バージョン	コア言語	シーンが含まれています	特定の依存関係
カオスブレード	1.7.0	行く	システムリソース、ネットワーク、アプリケーションレベルなどでさまざまな障害の挿入をサポートする実験的なフレームワーク。	特定の依存関係はありません
カオスメッシュ	2.3.1	行く	システムリソース、ネットワーク、アプリケーションレベルなどでさまざまな障害の挿入をサポートする実験的なフレームワーク。	K8s クラスターに依存する
カオスツールキット	1.12.0	パイソン	実験フレームワークでは、複数の IaaS または PaaS プラットフォームを統合し、複数のフォールトインジェクションツールを使用してシナリオをカスタマイズし、複数の監視プラットフォームと連携してインジケーター情報を観察および記録できます。	AWS/Azure/Google/K8s などのプラグインを通じて複数の IaaS および PaaS をサポート
オーケストレーター	3.2.6	行く	純粋な MySQL クラスターの障害シナリオ	特定の依存関係はありません
強力なシール	3.3.0	パイソン	K8、ポッドの終了、コンテナの終了、仮想マシンの終了	OpenStack/AWS/ローカルマシンをサポート
トキシプロキシ	2.5.0	行く	ネットワークプロキシ障害、ネットワーク障害	特定の依存関係はありません

2.2 業界カオスエンジニアリング実践プラットフォーム

業界のカオスエンジニアリングプラットフォームは通常、ユーザーインターフェイス、タスクスケジューリングモジュール、障害挿入、監視および警報システムの 4 つの部分で構成されます。

ユーザーインターフェイス:実験プラットフォーム用のカオスエンジニアリング実験タスクの配置および構成サービスを提供し、ユーザーがさまざまなカオスエンジニアリング実験タスクを管理するのを便利にします。カオスエンジニアリング実験が開始されると、ユーザーはタスク進行状況バー、サーバーインジケーター、その他の表示グラフを通じて実験の進行状況とシステムインジケーターをリアルタイムで確認できます。カオスエンジニアリング実験が終了すると、ユーザーは最終的なカオスエンジニアリング実験レポートを見ることができます。

タスクスケジューリングモジュール:このモジュールは、ユーザーインターフェイスとフォールトインジェクションの間の対話を担当し、その中核機能は、カオスエンジニアリングタスクのバッチ配信とスケジューリングを実現することです。

フォールト挿入:フォールト挿入は、タスクスケジューリングモジュールによって発行されたフォールト挿入タスクの受信、対応するフォールト挿入イベントの実装、およびフォールト挿入タスクの実行ステータスのフィードバックを担当します。

監視アラームシステム:このシステムは、システムによって生成されたすべてのデータを記録および管理し、アラームと関連統計を生成してユーザーにフィードバックする責任を負います。

2.3 カオスエンジニアリング実践能力の評価

カオスエンジニアリングの実践能力の評価は、チームがカオスエンジニアリングの実践の状況をよりよく理解するのに役立ちます。表 2-2 は、カオスエンジニアリング実験の成熟度のレベルを示しています。これは、現在のシステムのカオスを実行する能力を評価するために使用できます。エンジニアリングの実践。主にカオスエンジニアリングの実践の実現可能性、有効性、安全性を反映します。レベルが高くなるほど、カオスエンジニアリングの実践能力が強化されます。

表 2-2 カオスエンジニアリング実験の成熟度

3. JD カオスエンジニアリングの実践

Taishan Chaos Engineering Platform は、業界の成熟したソリューション ChaosBlade に基づいて設計および実装され、JD のビジネス特性と組み合わせられたセルフサービスの障害ドリルプラットフォームです。ユーザーは、自身のサービス特性に応じてターゲットを絞ったシーンの配置と障害の挿入を実行し、サービスの災害復旧機能を評価し、実験的な調査を通じてシステムの動作についての新たな理解を確立できます。混沌とした文化の確立を促進し、災害につながる可能性のあるシステム内の潜在的な脆弱なリンクを発見し、積極的な調査を通じて顧客に損害を与え、それらを排除し、システムをより堅牢で回復力のあるものにします。

図 3.1 は Taishan Chaos Engineering Exercise のフローチャートを示しており、Taishan Chaos Platform に基づいたレッドチームのタスクは次のとおりです。

(1) 訓練計画の作成: Taishan プラットフォームにアクセスし、パス: Safety Production - Chaos Engineering ページを入力します。このページには「訓練計画の作成」ボタンがあり、クリックして訓練設定ページに入ります。

(2) ドリル設定: [ドリル計画の作成] ボタンをクリックすると、ドリル設定ページに移動し、基本的なドリル情報とタスク設定項目 (ドリル設定 - アプリケーション関連 (タイプ、メソッド、シーン)、ドリル設定 -) を入力できます。実行関連)、図 3.1 中央の赤いフォントがこのドリルの主要な構成項目です。

(3) ドリルの実行：ドリルタスクを作成・保存した後、実行するドリルタスクを生成し、手動でドリルの実行ボタンをクリックします。

青色党の任務は次のとおりです。

(1) トラブルシューティング：訓練の実施中、青チームはまず警報情報を基に警報機を投下し、トラブルシューティングを実施した。

(2) 復旧計画: 訓練中に問題が発見された場合は、時間内に復旧し、訓練後に機械を再起動して復旧し、機械の正常な動作を確保する必要があります。

実験終了後は、訓練で見つかった問題点をまとめて分析し、同様のリスク問題が二度と起こらないよう訓練レビューを行う必要があります。

図 3.1 泰山カオスエンジニアリングドリルのフローチャート [出典: オムニチャネルカオスエンジニアリング実践記事]

3.1 コアコンピテンシー

プラットフォームの中核となる機能は、4 つの最新化と 1 つの柔軟性で要約できます。

1. 自動化: 訓練プロセス全体にわたる自動スケジュール設定、プラグイン展開、障害挿入、およびオンサイト回復。

2. 視覚化: 訓練中、MDC インジケーター、UMP サービス監視インジケーター、および障害挿入の進行状況の変化をリアルタイムで観察できます。

3. 精度：IP、グループ、コンピュータ室、ネットワーク POD を指定することで、演習の影響範囲を明確に制限でき、演習の効果がより実際の現場に即したものになります。

4. スケール: このプラットフォームは、1 つのタスクに対して 1,000 以上の訓練ターゲットをサポートし、同時に複数の訓練タスクをスケジュールする機能をサポートするように設計されており、さまざまな不測の事態に備えた訓練、攻撃的および防御的な訓練、および組織内での正規化されたカオステストを強力にサポートします。グループ。

5. 柔軟な制御: 訓練中にキャンセル、終了、完全終了などの操作を柔軟に実行でき、障害シナリオに対して多次元の構成と調整が可能、訓練の期間とスケジュール方法は実行中に調整できます。。

3.2 サポートされているフォールト挿入タイプ

Taishan Chaos Engineering Experimental Platform は、豊富なカオスシーン機能をサポートします。表 3-1 は、プラットフォームによってサポートされる基本的なリソース障害シナリオのリストであり、主に、リソース仕様を最適化するために、基本リソースまたはビジネス監視アラームの適時性と有効性 (介入手段) を検証します。、展開規模とコンピュータルーム間での展開を強化し、プロセスの生存と URL の生存の監視を強化したいと考えています。表 3-2 は、プラットフォームによってサポートされる JAVA プロセス障害およびミドルウェア依存関係障害のシナリオをリストしています。これは主に、JVM パラメーターの調整や適切なガベージコレクターの使用などのために、ビジネスおよび JVM 監視アラームの適時性と有効性 (介入手段) を検証するためです。 .、同時に、ミドルウェアクラスター構成の調整、劣化スキームの管理、キャッシュ戦略の最適化などを行います。演習を通じて、システムアーキテクチャをさらに理解し、強い依存関係と弱い依存関係を整理し、サービスのパフォーマンスを管理し、ダウンストリームの評価を行うことができます。サービス能力。

表 3-1 基本的なリソース障害シナリオ

混沌とした現場	訓練の目的	実現原理
CPU負荷が高い	ビジネス処理スループットへの影響に焦点を当てる	CPU タイムスライスを消費します
メモリ使用量	-	コードを使用してメモリ実装を適用する
ディスク IO 負荷が高い	ディスクの読み取りと書き込みに敏感なビジネスへの影響を評価する	dd コマンドを使用して実現します
ディスクフィル	ログディレクトリの満杯などサービスへの影響を主に検証	実現するには、fallocate および dd コマンドを使用します。
ネットワーク遅延	ビジネスのネットワーク遅延に対する許容度を評価し、タイムアウトと再試行メカニズムの設定が適切かどうかを評価し、連鎖的な事故を防止します。	tc コマンドを使用して実現します
ネットワークパケット損失	ネットワークパケット損失に対するサービス耐性を評価する	tc コマンドを使用して実現します
一時停止アニメーションの処理	負荷分散の適時性とビジネス上の機密性を監視する	kill -STOP {pids}
プロセスが終了しました	負荷分散の適時性とビジネスの機密性を観察する (Nginx と Tomcat)	kill -9 {pids}

表 3-2 JAVA プロセスの障害とミドルウェアの依存関係の障害のシナリオ

タイプ	混沌とした現場	訓練の目的
JAVAプロセスの失敗	プロセス CPU がフルロードされています	サービスノードの CPU がフル負荷になった場合のサービスへの影響を評価する
メモリ不足	サービスに対する GC の影響を評価する
インターフェース遅延	インターフェイス障害が SLA 全体に及ぼす影響を評価する
インターフェースが例外をスローする	インターフェイス障害が SLA 全体に及ぼす影響を評価する
インターフェースの戻り値の改ざん	予期しないインターフェイスの戻りの処理を評価する
スレッドプールがいっぱいです	スレッドプールの満杯がサービスに及ぼす影響を評価する
ミドルウェアの依存関係の失敗	JSFリクエストの遅延	ミドルウェア障害がそれ自体に及ぼす影響を評価する
JSF リクエストが例外をスローする	ミドルウェア障害がそれ自体に及ぼす影響を評価する
JIMDB リクエストの遅延	ミドルウェア障害がそれ自体に及ぼす影響を評価する
JIMDB リクエストが例外をスローする	ミドルウェア障害がそれ自体に及ぼす影響を評価する
MYSQLリクエストの遅延	ミドルウェア障害がそれ自体に及ぼす影響を評価する
MYSQL リクエストが例外をスローする	ミドルウェア障害がそれ自体に及ぼす影響を評価する

表 3-3 は Taishan Chaos Experimental Platform の障害使用統計をまとめたもので、使用状況から、現在は基本的なリソース障害シナリオが主に使用されていることがわかります。図 3.2 は、Taishan Chaos Engineering Practice Platform の障害使用タイプが基本リソース障害であることをより直観的に示しています。

表 3-3 泰山カオスエンジニアリング実験プラットフォームの断層種類の統計表

故障の種類	運動の割合
ネットワーク障害	31%
メモリが枯渇した	13%
CPUがいっぱいです	23%
ディスク障害	9%
異常なプロセス	3.5%
Javaプロセスの失敗	6.5%
外部依存関係の失敗	14%

3.3 よくある質問

Taishan Chaos Engineering の実践を調査すると、いくつかの一般的な問題が次のように要約できます。

(1) アラームが設定されていません (MDC、UMP、生存)。

(2) 警報閾値が不当、間隔が不当、連絡が取れない、連絡権限が不十分。

(3) プロセスはアニメーションを一時停止し、警察に報告しませんでした。URL 生存アラームを設定する必要があります。

(4) 警報が停止され、作動が間に合わなかった。

(5) 当直担当者が緊急時対応計画に習熟しておらず、社内システムツールの使用にも習熟していない（社内研修の強化）。

(6) グループ内でのフィードバック後、それに対応する適切な同僚がおらず、責任分担が明確ではない。

(7) 内部ツールの設計が不合理であり、さまざまなシナリオ (例: 複数のコンピューター室のグループでの異常) に対応できない。

(8) 時折発生する問題は無視され、その後の範囲の拡大 (例: 低バージョンの Linux カーネル処理) への対応が困難です。

4. まとめと考え方

4.1 研究の概要と考え方

本次调研涵盖了混沌工程的起源，发展，以及在京东的落地情况。通过研究，我进一步体会到：（1）混沌工程最先进的，是它大胆超前的思维理念和安全受控的方法论。（2）故障注入只是手段，而不是混沌工程的全部。场景再多，也不代表韧性就够好。（3）如果只是根据稳态假说，写测试用例，然后再使用故障注入工具进行试验，最后结果验证，这只能算是混沌工程最基本的内容。（4）混沌工程的使命是探索问题，而不仅仅是验证问题。总体而言，混沌工程的核心就是增强系统信心，保证系统在某个场景下的能力不退化。

4.2 混沌工程未来发展

混沌工程的目标是主动发现问题，因此，未来依然离不开这个核心目标，但是在未来，可以使得这个目标更加智能化的实现。通过调研发现，业界中部分企业已经开始探索将混沌工程和人工智能、机器学习等领域相结合，通过注入故障时系统指标的变化和定位的历史数据进行相关模型的训练，使得模型可以通过指标变化自动识别故障，这将有助于解决混沌工程在结果分析和故障恢复环节的自动化问题。其次，当下的混沌工程演练平台的交互性和可视化等能力在未来可以做到更好。此外，混沌工程的量化指标也需要进一步完善。