実験の計画 - AWS Fault Injection Simulator

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

実験の計画

障害注入は、サーバーの停止や API スロットリングなど、中断を伴うイベントを作成することによって、テスト環境や運用環境でアプリケーションを強調するプロセスです。システムがどのように反応するかを観察することから、改善を実装することができます。あなたのシステム上で実験を実行すると、それらの弱点は、あなたのシステムに依存する顧客に影響を与える前に、制御された方法で全身的な弱点を識別するのに役立ちます。その後、問題をプロアクティブに解決して、予測不可能な結果を防ぐことができます。

フォルトインジェクション実験を開始する前に、次の原則とガイドラインに精通することをお勧めします。

基本原則とガイドライン

実験を開始する前にAWS FIS次の手順に従います。

  1. 実験のターゲット配置を特定する— まず、ターゲットデプロイを特定します。これが最初の実験である場合は、運用前またはテスト環境で開始することをお勧めします。

  2. アプリケーションアーキテクチャのレビュー:各コンポーネントのアプリケーション・コンポーネント、依存関係、リカバリ手順をすべて特定しておく必要があります。まず、アプリケーション・アーキテクチャの確認を行います。アプリケーションに応じて、AWSWell-Architected

  3. 定常状態の動作を定義する:レイテンシー、CPU 負荷、1 分あたりのサインイン失敗、再試行回数、ページ読み込み速度など、重要な技術的およびビジネス指標の観点から、システムの定常動作を定義します。

  4. 仮説を形成する— 実験中にシステムの動作がどのように変化するかを予測する仮説を形成します。仮説の定義は、次の形式に従います。もし障害注入アクションが実行されると、ビジネス指標または技術指標の影響超えてはならない。認証サービスの仮説は、次のように解釈されます。ネットワークの遅延が 10% 増加すると、サインインエラーが 1% 未満になります。実験が完了したら、アプリケーションの耐障害性がビジネスおよび技術的な期待に合致しているかどうかを評価します。

また、以下のガイドラインに従うことをお勧めしますAWS FIS:

  • 常に試し始めるAWS FISテスト環境で。本番環境では開始しないでください。障害注入実験を進めるにつれて、テスト環境以外の制御された環境でも実験できます。

  • アプリケーションの耐障害性に対するチームの信頼を築くには、小規模な簡単な実験から始めて、aws: ec2: stop-instアクションを 1 つのターゲットで実行します。

  • 障害注入は、実際の問題を引き起こす可能性があります。注意して進め、最初の障害注入がテストインスタンスにあることを確認し、お客様が影響を受けないようにします。

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

  • 開始する前に、優れた監視および警告プログラムを用意しておくことを強くお勧めします。それがなければ、持続可能な故障注入の実践に不可欠な、実験の影響を理解または測定することはできません。

実験計画のガイドライン

とAWS FISで実験を実行すると、AWSリソースを使用して、アプリケーションまたはシステムが障害条件下でどのように動作するかについての理論をテストできます。

重要

AWS FIS実際の上で実際の行動を行うAWSシステムのリソースを削除します。したがって、使用を開始する前にAWS FISを使用して実験を実行する場合は、まず計画フェーズとテストを運用前またはテスト環境で完了することを強くお勧めします。

次のガイドラインは、AWS FIS実験。

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

  • 最大の影響を持つサービスを特定:サービスを見直し、エンドユーザーや顧客がダウンした場合や正常に機能しない場合に、最も大きな影響を及ぼすサービスを特定します。

  • ターゲット・システムの識別— ターゲットシステムは、実験を実行するシステムです。を初めて使用する場合AWS FISまたは以前に故障注入実験を実行したことがない場合、プロダクション前またはテストシステムで実験を実行することから始めることをお勧めします。

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

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

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

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

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