翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
デプロイ前のアクティビティ
環境設計
アプリケーションをテストして評価する環境は、テストをどの程度徹底できるか、およびそれらの結果が本番環境で何が起こるかを正確に反映しているという信頼度に影響します。Amazon DynamoDB などのサービスを使用して、開発者マシンで一部の統合テストをローカルで実行できる場合があります (DynamoDB ドキュメントの「DynamoDB Local のセットアップ」を参照してください）。 DynamoDB ただし、結果の信頼性を最大限に高めるには、本番環境をレプリケートする環境でテストする必要があります。この環境にはコストがかかるため、パイプラインの後半に本番環境のような環境が表示される環境に対して、ステージングまたはパイプライン化されたアプローチを取ることをお勧めします。
インテグレーションテスト
統合テストは、アプリケーションの明確に定義されたコンポーネントが、外部依存関係で動作するときに正しく機能することをテストするプロセスです。これらの外部依存関係には、他のカスタム開発コンポーネント、アプリケーションに使用する AWS サービス、サードパーティーの依存関係、オンプレミスの依存関係などがあります。 このガイドでは、アプリケーションの耐障害性を示す統合テストに焦点を当てています。ソフトウェアの機能精度を示すユニットテストと統合テストがすでに存在することを前提としています。
サーキットブレーカーパターンや負荷分散など、実装した耐障害性パターンを具体的にテストする統合テストを設計することをお勧めします (「ステージ 2: 設計と実装」を参照）。耐障害性指向の統合テストでは、多くの場合、アプリケーションに特定の負荷を適用したり、 AWS Fault Injection Service （AWS FIS）
自動デプロイパイプライン
本番稼働前の環境へのデプロイとテストは、反復的で複雑なタスクであり、自動化に最適です。このプロセスを自動化することで、人的リソースが解放され、エラーが発生する機会が減ります。このプロセスを自動化するメカニズムは、多くの場合パイプラインと呼ばれます。パイプラインを作成するときは、本番稼働用設定にますます近づく一連のテスト環境を設定することをお勧めします。この一連の環境を使用して、アプリケーションを繰り返しテストします。最初の環境では、本番環境よりも機能が限られていますが、コストが大幅に削減されます。後続の環境では、サービスを追加し、本番環境をより正確に反映するようにスケーリングする必要があります。
まず、最初の環境でテストします。デプロイが最初のテスト環境ですべてのテストに合格したら、一定期間アプリケーションに一定の負荷をかけ、時間の経過とともに問題が発生するかどうかを確認します。発生した問題を検出できるように、オブザーバビリティが正しく設定されていることを確認します (このガイドの後半の「アラームの精度」を参照）。この観察期間が正常に完了したら、アプリケーションを次のテスト環境にデプロイし、プロセスを繰り返して、環境でサポートされている追加のテストまたはロードを追加します。この方法でアプリケーションを十分にテストしたら、以前に設定したデプロイ方法を使用してアプリケーションを本番環境にデプロイできます (このガイドの前半の「CI/CD 戦略を定義する」を参照）。記事「Amazon Builders' Library での安全なハンドオフデプロイの自動化」は、
負荷テスト
表面的には、負荷テストは統合テストに似ています。アプリケーションの個別の関数とその外部依存関係をテストして、期待どおりに動作することを確認します。その後、負荷テストは統合テストを超えて、明確に定義された負荷でアプリケーションがどのように機能するかに焦点を当てます。負荷テストでは正しい機能を検証する必要があるため、統合テストが成功した後に実行する必要があります。アプリケーションが予想される負荷でどの程度うまく応答するか、および負荷が予想される負荷を超えたときにどのように動作するかを理解することが重要です。これにより、アプリケーションの耐障害性を極端に高めるために必要なメカニズムが実装されていることを確認できます。での負荷テストの包括的なガイドについては AWS、 AWS ソリューションライブラリの「 での分散負荷テスト AWS
