の計画 AWS FIS 実験 - AWS 障害インジェクションサービス
基本原則とガイドライン実験計画ガイドライン

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

の計画 AWS FIS 実験

障害挿入は、サーバーの停止やAPIスロットリングなどの破壊的なイベントを作成して、テスト環境や本番環境でアプリケーションにストレスを与えるプロセスです。システムの応答を観察することで、改善を実装できます。システム上で実験を実行すると、システムに依存している顧客に影響を与える前に、システム上の弱点を制御された方法で特定するのに役立ちます。そうすれば、問題をプロアクティブに解決して、予測不可能な結果を防ぐことができます。

を使用してフォールトインジェクション実験の実行を開始する前に AWS FISでは、以下の原則とガイドラインを理解しておくことをお勧めします。

重要

AWS FIS は実際のアクションを実際の で実行します AWS システム内の リソース。したがって、 の使用を開始する前に AWS FIS 実験を実行するには、まず本番稼働前環境またはテスト環境で計画フェーズとテストを完了することを強くお勧めします。

基本原則とガイドライン

で実験を開始する前に AWS FIS、次の手順を実行します。

  1. 実験のターゲット展開を特定する — まず、ターゲットデプロイを特定します。これが最初の実験の場合は、プリプロダクションまたはテスト環境で開始することをお勧めします。

  2. アプリケーションアーキテクチャを確認する: 各コンポーネントのすべてのアプリケーションコンポーネント、依存関係、およびリカバリ手順を特定していることを確認する必要があります。まず、アプリケーションアーキテクチャを見直します。アプリケーションに応じて、「」を参照してください。 AWS Well-Architected フレームワーク 。

  3. 定常状態の動作の定義 — レイテンシー、CPUロード、1 分あたりのサインイン失敗、再試行回数、ページロード速度など、重要な技術的およびビジネス上のメトリクスの観点からシステムの定常状態の動作を定義します。

  4. 仮説を形成する — 実験中にシステムの動作がどのように変化すると予想されるかについての仮説を作成します。仮説の定義は次の形式に従います。

    If fault injection action が実行され、business or technical metric impact は を超えないようにしてください value.

    例えば、認証サービスの仮説を次のように設定します。ネットワーク遅延が 10% 増加すると、サインイン失敗が 1% 未満増加する。実験の完了後、アプリケーションの復元力がビジネスおよび技術的な期待に沿っているかどうかを評価します。

を使用するときは、以下のガイドラインに従うことをお勧めします。 AWS FIS:

  • 常に で実験を開始する AWS FIS テスト環境の 。決して本番環境では開始しないでください。フォールトインジェクション実験を進めていくと、テスト環境以外の制御環境でも実験できるようになります。

  • アプリケーションの復元力に対するチームの自信を構築するには、以下を実行するなど、小規模で簡単な実験から始めましょう。ターゲットに対する aws:ec2:stop-instances アクション。

  • フォールトインジェクションは、実際の問題を引き起こす可能性があります。慎重に進み、顧客が影響を受けないように、最初のフォールトインジェクションがテストインスタンス上にあることを確認してください。

  • テスト、テスト、テストを繰り返します。フォールトインジェクションは、十分に計画された実験で制御された環境で実装されることを意図しています。これにより、乱流条件に耐えるアプリケーションやツールの能力に自信を持たせることができます。

  • 始める前に、優れた監視およびアラートプログラムを用意することを強くお勧めします。それがなければ、持続可能なフォールトインジェクションの実践に不可欠な実験の影響を理解したり測定したりすることはできません。

実験計画ガイドライン

で AWS FIS、 で実験を実行します。 AWS 障害条件下でのアプリケーションまたはシステムの動作の理論をテストするための リソース。

以下は、 を計画するための推奨ガイドラインです。 AWS FIS 実験。

  • 停止履歴の確認 - システムの以前の停止とイベントを確認します。これは、システムの全体的な健全性と回復力を把握するのに役立ちます。システムで実験を実行する前に、システムの既知の問題と弱点に対処する必要があります。

  • 最も大きな影響を持つサービスを特定する - サービスを確認し、エンドユーザーまたは顧客に障害が発生した場合や正常に機能しない場合に、最も大きな影響を与えるサービスを特定します。

  • ターゲットシステムを特定する — ターゲットシステムは、実験を実行するシステムです。を初めて使用する場合 AWS FIS または、以前にフォールトインジェクション実験を実行したことがない場合は、本番稼働前システムまたはテストシステムで実験を実行することから始めることをお勧めします。

  • チームに相談する — 彼らが心配しているものを聞いてください。仮説を立てて、彼らの懸念を証明または反証することができます。また、チームに心配していないことを聞くこともできます。この質問は、2つのよくある誤謬を明らかにすることができます。サンクコスト誤謬と確認バイアスの誤謬です。チームの回答に基づいて仮説を形成すると、システムの状態の現実に関する詳細情報を提供できます。

  • アプリケーションアーキテクチャを確認する - システムまたはアプリケーションのレビューを実施し、すべてのコンポーネントのすべてのアプリケーションコンポーネント、依存関係、およびリカバリ手順を特定していることを確認します。

    を確認することをお勧めします。 AWS Well-Architected フレームワーク。このフレームワークは、アプリケーションとワークロードのために、安全で、高パフォーマンス、耐障害性、および効率的なインフラストラクチャを構築するのに役立ちます。詳細については、「」を参照してくださいAWS Well-Architected 。

  • 該当するメトリクスを特定する — 実験が に与える影響をモニタリングできます。 AWS Amazon CloudWatch メトリクスを使用する リソース。これらのメトリクスを使用して、アプリケーションが最適に実行されているときのベースラインまたは「定常状態」を判断できます。その後、実験中または実験後にこれらのメトリクスを監視して、影響を判断できます。詳細については、「Amazon CloudWatch による AWS FIS 使用状況メトリクスのモニタリング」を参照してください。

  • システムの許容可能なパフォーマンスしきい値を定義する — システムの許容可能な定常状態を表すメトリクスを特定します。このメトリクスを使用して、実験の停止条件を表す 1 つ以上の CloudWatch アラームを作成します。アラームがトリガーされると、実験は自動的に停止します。詳細については、「AWS FIS の停止条件」を参照してください。