概要

耐障害性テストとカオスエンジニアリングの比較

耐障害性テストは決定論的です。つまり、アプリケーションで実装されているサーキットブレーカー、再試行、フェイルオーバー、フォールバックなど、回復力メカニズムに関する既知の特性を検証します。これらのアプリケーションコンポーネントが、ユーザーへの影響を最小限に抑えながら、制御された中断をどのように吸収するかを確認します。したがって、耐障害性テストでは、合格/不合格の結果を生成することを目的として、アプリケーションコンポーネントに挿入される既知の障害モードの検証に焦点を当てています。レジリエンステストはパイプラインのステップとして継続的に実行し、レジリエンス体制にリグレッションが発生しないようにする必要があります。レジリエンステストでは、実際のコンポーネントに対してテストを実行するのではなく、特定のコンポーネントをシミュレートするモック APIsを実行することがよくあります。このアプローチにより、制御された環境で障害シナリオを一貫して再現可能なテストできるため、パイプライン統合と回帰の自動テストに適しています。

対照的に、カオスエンジニアリングは非決定的です。つまり、仮説に基づいており、アプリケーションとその依存関係 (人、プロセス、テクノロジー) が予期しない障害モードをどのように吸収、適応、最終的に回復するかについてメンタルモデルを検証します。したがって、カオスエンジニアリングは、未知の障害モードのend-to-endの検証に焦点を当て、欠陥を早期に発見し、大規模なイベントになる前に修復することを目指しています。カオスエンジニアリングは継続的な学習を促進し、デベロッパーのコードデプロイの生産性を妨げることなく、いつでも複数の実験を実行できるようにする別のカオスパイプラインまたはアドホック実験を通じて練習する必要があります。

カオスエンジニアリングプロセスは多くの場合、カオスゲームデーから始まります。カオスゲームデーは、チームが制御された障害や障害を意図的にアプリケーションに注入する専用のイベントです。ゲームデーはプログレッシブです: 低レベルの環境 (開発やテストなど) で始まり、信頼の構築に応じて徐々に高レベルの環境 (ステージングや本番稼働前など) に進みます。これらの環境を体系的に移行することで、チームは本番環境に到達する前に、挿入された障害をシステムが適切に許容していることを確認できます。この体系的な進行により、カオス実験が本番環境で実施されるまでに、チームはシステムの耐障害性能力に大きな自信を持てるようになります。ゲームデープロセスは、アプリケーションのアーキテクチャと運用プラクティスの弱点と脆弱性を特定する積極的なアプローチであり、予期しない本番稼働停止時の学習のストレスを排除します。

カオスエンジニアリングの価値

複雑なシステムは、今日の世界ではユビキタスです。金融市場から医療まで、私たちの生活のさまざまな側面で重要な役割を果たします。これらのシステムは常に動作することが想定されます。ただし、複雑なシステムは多くの場合、重大な結果をもたらす可能性のある予期しないイベントや動作に対して脆弱です。組織は、中断が発生するかどうかを考えるのではなく、中断を計画する必要があります。そのためには、クリティカルまたはミッションクリティカルなビジネスサービスにシナリオテストを適用します。そこでカオスエンジニアリングが登場します。

カオスエンジニアリングは、リスクを軽減し、レジリエンスを向上させるのに役立つ複雑なシステムを管理するアプローチを提供します。カオス実験に備えるプロセスでは、チームはシステムの動作に関する仮説を立てる必要があります。これにより、システムの構築方法と運用方法の理解が深まります。この準備により、多くの場合、メンタルギャップ、アーキテクチャ上のインサイト、運用上の知識が明らかになり、それ以外の場合は発見されないままになる可能性があります。カオスエンジニアリングは、複雑なシステムが障害にどのように反応するかを理解することで、システム設計と管理における透明性と説明責任の向上を促進します。組織がカオスエンジニアリングを実践する頻度が高いほど、運用上の準備が整います。カオスエンジニアリングは、ユーザーへの影響を最小限に抑えながら、コンポーネントの障害を克服できる回復力のあるアプリケーションを設計するためのベストプラクティスを確立するのに役立ちます。これにより、重要なアプリケーションが期待されるサービスレベルと耐障害性の範囲内で動作し、チームの独自のシステムに関する知識を継続的に強化できます。

悪影響に備える

を構築するときは AWS、Amazon Elastic Compute Cloud (Amazon EC2) などのゾーンサービス、Amazon Simple Storage Service (Amazon S3) などのリージョンサービス、 AWS Identity and Access Management (IAM) などのグローバルサービス、サードパーティーの Software as a Service (SaaS) サービス、オンプレミスサービスなど、さまざまなタイプのサービスを使用します。サービスのタイプごとに、考慮する必要があるさまざまな障害ドメインが公開されます。自己関連イベントや、組織が制御できないサードパーティーによって引き起こされるイベントに対して、どのように準備すればよいですか？

アプリケーションが悪条件にどのように反応するかを理解するために、 AWS Fault Injection Service (AWS FIS） を使用できます。 AWS FIS は、制御された方法でフォールトインジェクション実験を実行するためのフルマネージドサービスです。このサービスを使用して、アベイラビリティーゾーンの停電やリージョン間の接続の問題など、 AWS提供されたシナリオを挿入したり、サービスによって提供されるさまざまな障害アクションを連鎖させて独自の実験を構築したりできます。 AWS FIS を使用すると、チームはアプリケーションが一般的な障害にどのように反応するかを継続的に練習し、検出時に欠陥を修正できます。

制御されたカオスエンジニアリングの実践

制御されたカオス実験の主な原則は次のとおりです。

カオスエンジニアリングを正常にスケーリングするには、カオス実験を制御された方法で実装する必要があります。を使用すると AWS FIS、Amazon CloudWatch アラームを使用して停止条件を作成できます。これらの条件を実験テンプレートに組み込んで、範囲外の実験が停止し、最後の既知の状態にロールバックされるようにすることができます。 には、安全レバー AWS FIS も用意されています。これらのレバーをエンゲージすると、 は、マルチアカウント実験を含む AWS リージョン、 のアカウントで実行中のすべての実験 AWS FIS を停止してロールバックし、新しい実験の開始を防ぎます。これにより、取引時間、販売イベント、製品の発売などの特定の期間中、またはアプリケーションのヘルスアラームに応じて、フォールトインジェクションを防ぐことができます。安全レバーは、手動で解除されるまでエンゲージされたままになります。

カオス実験を実行するときは、特に実験が本番環境のアプリケーションに影響を与える可能性がある場合、環境内の望ましくない副作用を防ぐために保護を定義する必要があります。実験を計画するときは、環境内の他のアプリケーションに対する悪影響を予測します。たとえば、他のアプリケーションは、実験の一部であるアプリケーションから誤ったメッセージを受信したり、大量のリクエストボリュームが発生したり、インフラストラクチャを共有している場合にリソースの競合が発生したりする可能性があります。これらのリスクを文書化し、実験を実行する前に、既知の問題や許容できない問題に対処します。