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

# でのカオスエンジニアリングの実装 AWS
<a name="implementation"></a>

カオスエンジニアリングは、次の図に示すように、[AWS 耐障害性ライフサイクル](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-lifecycle-framework/introduction.html)の評価およびテスト段階の一部です。分散アプリケーションは他のアプリケーションやクライアントとは別に動作しないため、耐障害性ライフサイクル全体を確認することをお勧めします。分散アプリケーションの変化は、ネットワークが進化し、アップストリームアプリケーションとダウンストリームアプリケーションがシフトし、クライアントの使用状況が時間の経過とともに変化するにつれて一定です。

![AWS 耐障害性ライフサイクルの 5 つの主要なステージ。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/chaos-engineering-on-aws/images/resilience-lifecycle.png)


アプリケーションに対するこれらの変更がレジリエンスにどのように影響するかを理解するには、カオスエンジニアリングをday-to-dayの一部にします。カオス実験はさまざまな方法で実装できます。
+ **アドホック** – カオス実験を 1 回限りの実験として実行して、特定の問題や質問に対処できます。
+ **カオスゲームデー** – これらは、アプリケーションの信頼性と耐障害性を検証するように設計された構造化された定期的なイベントです。カオスゲームデーの目的は、人、プロセス、テクノロジー全体で潜在的なレジリエンスの問題や欠陥を特定し、インシデントを特定、軽減、対応するためのプロセスと手順を実践することです。
+ **カオスパイプライン** – 継続的インテグレーションと継続的デリバリー (CI/CD) は、新機能を構築し、環境全体に安全にデプロイすることです。カオスエンジニアリング実験を実装するには、CI/CD パイプラインとは別のカオスパイプラインを作成します。理由を理解するために、ダウンストリームコンポーネントのパケット損失が増加する CI/CD パイプラインに 1 つのカオスエンジニアリング実験を追加すると仮定します。この実験は 3 回実行され、毎回完了するまでに 5 分かかります。パケット損失は実行ごとに 10% から 20% から 30% に増加し、実験が完了するまでに全体で 15 分かかります。並列デプロイが 100 回ある場合は、1 回の実験が完了するまで 1500 分待つ必要があります。実行する実験が 10 件ある場合、デベロッパーへの影響は耐え難いものになります。大規模なカオスエンジニアリングには、ソフトウェア開発ライフサイクル (SDLC) プロセスと並行して実験を実行できるようにする独自のパイプラインが必要です。
+ **Canary デプロイ** — Canary はカオス実験用のテスト環境を提供します。トラフィックのごく一部を Canary サービスに誘導するか、トラフィックミラーリングやリプレイなどの方法を使用することで、安定した本稼働システムに影響を与えずに、新しいインフラストラクチャやコードの変更を検証できます。Canary に対して実験を実行し、必要に応じて障害を挿入できます。エンドユーザーへの影響の範囲を制限できるためです。
+ **スケジュールされた実験** – アプリケーションの予測可能な復旧メカニズムを検証するための実験をスケジュールできます。スケジュールされた実験を使用して、一般的に知られているイベントを再生し、自動スケーリンググループの背後にある EC2 インスタンスの終了、Kubernetes ポッドの削除、Amazon ECS タスクの削除などのイベントからシステムが回復する方法をキャプチャします。