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