カオスエンジニアリングとは何ですか?
顧客、クライアント、訪問者、さらには社内の従業員は、すべてシステムに依存して、常に機能し、利用可能になり、実行しています。 完璧な世界では、システム、アプリケーション、サービスがダウンしても決してないが、これは完璧な世界ではなく、残念ながら、時には計画通りに進まないこともある。 停止やダウンタイムは、企業に数百万ドルの費用がかかる可能性があります。 時には、最良の計画は、まさにカオスエンジニアリングが解決しようとしているものです予期しない計画です。 カオス・テストとも呼ばれるカオス・エンジニアリングは、予期しない故障や状況に耐えられるシステムのテストと構築に対する規律、つまりアプローチと考えることができます。
DevOpsプラクティスの出現により、スタートアップから企業までの組織は、独自のカオステスト プラクティスを開発ワークフローに徐々に採用してきました。 カオスエンジニアリングが特定のチームによって行われるか、 または現場の信頼性エンジニア(SR)の責任の一部として行われるかにかかわらず、カオスエンジニアリングの実践は、システム、アプリケーション、およびサービス内の隠された弱点を発見し、完全な回復力のために最も極端な状況に立ち向かうことができるように設計されています。
カオスエンジニアリングとパフォーマンステスト
ストレス テストや負荷テストと同様に、カオス エンジニアリングは、チームが異常な環境や不安定な環境を作成することによって、障害点や障害を特定するのに役立ちます。 しかし、カオスエンジニアリングと パフォーマンステスト の主な違いの1つは、カオスエンジニアリングは、いくつかの重要な要素に焦点を当てるだけでなく、通常の明白なテストの範囲外の一見無制限の要素で構成される可能性があるという点です。 大規模な分散ネットワーク環境では、システムが障害を起こす可能性があります。 これらの脆弱性を明らかにすることで、チームは弱点の位置を把握し、潜在的な障害が発生するのを防ぐことができます。
カオス(工学)が生まれる
カオスエンジニアリングの実践は、Netflixが ストリーミングサービスを正式に開始した後、2008年頃に始まりました。 2011年頃の データベース 破損の問題に続いて、NetflixはAWS(アマゾンウェブサービス)を介してデータセンターをクラウドに移行することを計画しました。 実際、最終的に移行を完了するのに8年かかりました。 2015年、 AWSは停止を経験し、Netflixが数時間ダウンしました。 これらはクラウド コンピューティングの初期の時代であったため、堅牢で安定したフェイル セーフではありませんでした。 クラウドへの移行によって、スケーラビリティ、稼働時間、単一障害点の回避など、期待したメリットの一部が生み出されないことに気付いたとき、 自動スケーリングなど、彼らはこれらの予期しないものをテストする方法が必要であると判断しました サービスが稼働していることを確認するための問題、そして最終的には、 ユーザーへの影響とフラストレーションの原因. この経験からカオス工学が生まれました。
カオスエンジニアリングの原則とステップ
カオス工学は、カオスを作り出すためだけにカオスを作ろうとはしません。 むしろ、一連の正確な原則と手順に基づいて、大規模な分散システムとネットワーク内のリスクを軽減する方法を学ぶことを唯一の目的として、計画と実験を慎重に作成するように設計されています。 以下にリストされているのは、カオス実験の一般的な ガイドライン を作成する手順です。
ステップ 1: 仮説を作成する
これは、システムが通常の環境と比較して不安定な要因や条件を導入する際にどのように応答するかについての一般的な仮定を行う上で構成されています。 また、混乱実験中にエラー率、待機時間、スループットなどの測定基準を決定する場所でもあります。
ステップ 2: 変数を識別し、効果を予測する
これらの架空の出来事が現実の状況で起こったときに何が起こるかを考えてみましょう。 たとえば、サーバーが予期せずクラッシュしたり、 トラフィックが大幅に増加したりした場合、システム全体にどのような影響がありますか?
ステップ 3: 実験を開始する
理想的には、ライブの運用環境でカオス実験を実行します。 ただし、さらに悪いシナリオが発生するのを防ぐための保護が必要です。 実験が横に進む場合は、環境を制御する必要があります。 これは、ブラスト半径の制御とも呼ばれます。 これらの実験は、より良い分析のために自動化することができ、手動で実行するよりも持続可能です。 本格的なテスト環境を利用する方法もありますが、実際の環境で起こることを反映していない可能性もあります。
ステップ 4: 影響を測定する
結果は最初の仮説までどのように測定されますか? 仮説に設定された指標に基づいて、実験が制限されすぎたのか、それともエラーや障害をよりよく識別するためにスケールアップする必要があるのか。 爆風半径が限られすぎなかったか? 実際のシナリオで発生する障害をオフに設定するには、スケーリングする必要があります。 この実験では、調査が必要なその他の問題も明らかになります。
カオスエンジニアリングツール
Netflixでのカオスエンジニアリングの紹介に戻りましょう。 攻撃に出てエンジニアリングチームのリソースを捧げるためのプロセスを開始することを決定したら、エンジニアリングチームが混乱テストを実施するのを支援するための正式な一連のプラクティスとツールを作成する必要がありました。 Netflixが導入した初期のアプリケーションの1つは、 カオスモンキーと呼ばれていました。 毎日、このアプリケーションはランダムに一連のクラスターを選択し、そのインスタンスを 1 日のある時点でオフにして、残りのシステムがどのように応答するかを観察します。 明らかに、これは毎日対処するのに十分なネットワーク頭痛を抱えているエンジニアリングチームにとって痛みを伴う経験を生み出しますが、一日の終わりには、ネットワークに関するだけでなく、ユーザーへの影響の面でも、これらの停止の影響を理解するためのより良い位置にチームを置きます。
リソースと個人を「壊す」ことを回避するために捧げることは直感に反するように思えるかもしれませんが、これらのカオステストを積極的に実行することで、より回復力のあるネットワークを構築し、より優れた信頼性の高い ユーザーエクスペリエンスを作成できます。 現実の世界は、制御されたテスト環境では機能しません。 カオスモンキーの設立以来、それはいくつかの更新を経て、人気のオープンソースアプリケーションとなっています。 そして、一時は、シミアン軍と呼ばれるツールのカオスエンジニアリングスイートの一部に過ぎませんでした。 シミアン軍のスイートは2018年に解散しましたが、次のタスク固有のカオスエンジニアリングユーティリティが含まれていました。
カオスコング
Chaos Kong は、完全な AWS リージョンがドロップまたは削除される様子をシミュレートして、パフォーマンスの低下なしにトラフィックを別のリージョンに移動してシステムがどのように回復し、応答するかを確認するように設計されています。 繰り返しますが、これはめったに起こりませんが、カオスエンジニアリングの範囲内では、何も範囲外ではありません。
適合性モンキー
適合性 Monkey は、事前定義されたルールに準拠していないインスタンスを識別するために、AWS で実行されるサービスです。 ルールに準拠していないインスタンスは、カスタマイズして異なる頻度で実行できるように十分な柔軟性を持ち、所有者またはグループに電子メール通知を送信しました。 その後、コンフォーシティモンキーはスピネーカーサービスに移されました。
カオスゴリラ
カオスゴリラはカオスモンキーのようなものですが、より壮大なスケールです。 単一の AWS インスタンスで障害をシミュレートする代わりに、Chaos Gorilla は AWS ゾーン全体の障害をシミュレートしました。 このユーティリティは、大規模な災害が別の地域のユーザーや顧客にどのような影響を与え た かを示すように設計されており、Netflixのインフラストラクチャとビジネスモデルの設定方法に最適でした。 ロード バランサーが適切に応答し、サービスが中断されたままであることを適切に確認することで、クラウド プラットフォームがこのテストに耐えられる場合は、クラウド プラットフォームでスローされるものに耐えることができます。
レイテンシーモンキー
名前が示すように、Latency Monkey は、ネットワークの遅延または完全な障害に対するサービスをテストするために使用され、これらのシミュレートされた遅延に対するサービスとその依存関係の応答方法を特定するのに役立ちます。 しかし、一般的に Web サービスと同様に、一見簡単に識別できない可能性のある他のアプリケーション内に未知の結果が生じる可能性があるため、Latency Monkey のようなユーティリティは、サービス全体でフォールト トレランスを測定する上で非常に重要です。
ドクターモンキー
Doctor Monkeyユーティリティは、個々のインスタンス間でヘルスチェックを実行し、システム全体のヘルス(CPU負荷、メモリ、リソースなど)を監視するために使用されました。さらに、Doctor Monkeyはインスタンスのステータスを報告し、システム全体に適さないと判断したインスタンスをサービスから削除できます。
10-18 モンキー
10-18 Monkeyの名前は、ローカリゼーションと国際化とローカリゼーションの略語、L10nおよびi18nから来ています。 数字は、最初と最後の文字の間の文字の数を表します。 Netflixのお客様は世界中に存在するため、さまざまな地域でストリーミングサービスの信頼性を監視する方法を持つことが最も重要でした。 10-18 Monkey ユーティリティの利点は、異なる言語や文字セットを提供し、使用する複数の地理的リージョンでの構成とパフォーマンスの問題をチェックできることです。
ジャニトールモンキー
未使用の AWS リソースは何ですか? 管理人猿を入力してください。 Janitor Monkey ユーティリティの目的は、未使用のリソースを検索して削除することです。 カオスモンキーのように、他のクラウドプロバイダと一緒に使用できるほどカスタマイズ可能で拡張可能です。 ユーザーは一連のルールを提供し、Janitor Monkeyは作業に行き、クリーンアップと削除の候補である未使用のリソース、グループ、ボリュームを特定して通知を送信します。 時間が経つにつれて、機能はスワビーと呼ばれる新しいサービスに置き換えられました。
結論: カオスエンジニアリング – 原則、例、ツール
時間が経つにつれて、カオスエンジニアリングは、独自の本格的な産業に成長してきました。 現在、リトマスカオス、グレムリン、カオスメッシュなど、組織が利用できる無数のオープンソースツールや商用ツールがあります。 レジリエントなシステムの構築は 、テクノロジー企業だけのものではありません。 分散システムはより複雑になり、障害を予測するのが難しくなっています。 また、さまざまな規制およびコンプライアンスの問題により、銀行、政府機関、製薬会社、教育機関などは、システムとサービスを定期的にテストして、ビジネスおよびミッションクリティカルな要件を満たしていることを確認する必要があります。 パフォーマンス テスト とカオス テストは、障害を観察して回復力のあるシステムを構築する方法を学習するためのプロアクティブなアプローチです。