REL08-BP03 デプロイの一部として回復力テストを統合する
意図的にシステムに障害を導入することで回復力テストを統合し、障害発生時のシステムの能力を測定します。回復力テストは、システムでの予期しない障害の特定に重点を置いているため、通常デプロイサイクルに統合されるユニットテストや機能テストとは異なります。本番稼働前に回復力テストの統合を始めても問題ありませんが、ゲームデーの一環として、これらのテストを本番環境に実装するという目標を設定します。
期待される成果 回復力テストは、本番環境の劣化に耐えられるシステムの能力に対する信頼を構築するのに役立ちます。テストによって障害につながる可能性のある弱点を特定することで、システムを改善し、障害や劣化を自動的かつ効率的に軽減できます。
一般的なアンチパターン:
-
デプロイプロセスにおけるオブザーバビリティとモニタリングの欠如
-
システム障害の解決を人間に依存する
-
低品質の分析メカニズム
-
システムの既知の問題に重点を置き、未知の問題点を特定するためのテストを行わない
-
障害を特定できるが、解決できない
-
検出結果とランブックが文書化されていない
このベストプラクティスを活用する利点: デプロイに統合された回復力テストは、システムの未知の問題のうち、テストを実行しないと気付かないものを特定するのに役立ちます。これらの問題は本番環境のダウンタイムにつながる可能性があります。システムでのこれらの未知の問題の特定は、検出結果の文書化、CI/CD プロセスへのテストの統合、およびランブックの作成に役立ち、効率的で反復可能なメカニズムを通じて、障害の緩和を簡素化します。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
システムのデプロイに統合できる最も一般的な回復力テストの形式は、ディザスタリカバリとカオスエンジニアリングです。
-
大規模なデプロイには、ディザスタリカバリ計画と標準運用手順 (SOP) の更新を含めます。
-
信頼性テストを自動デプロイパイプラインに統合します。AWS Resilience Hub
などのサービスを CI/CD パイプラインに統合 して、すべてのデプロイの一部として自動的に評価される、継続的な耐障害性評価を確立します。 -
AWS Resilience Hub でアプリケーションを定義します。耐障害性評価では、アプリケーションの AWS Systems Manager ドキュメントとして復旧手順を作成するのに役立つコードスニペットが生成され、推奨される Amazon CloudWatch モニタとアラームのリストが提供されます。
-
ディザスタリカバリ計画と SOP が更新されたら、ディザスタリカバリテストを実施して効果を確認します。ディザスタリカバリテストは、イベント後にシステムを復旧して通常の運用に戻ることができるかどうかを判断するのに役立ちます。さまざまなディザスタリカバリ戦略をシミュレートし、計画が稼働時間の要件を満たすのに十分であるかどうかを確認できます。一般的なディザスタリカバリ戦略には、バックアップと復元、パイロットライト、コールドスタンバイ、ウォームスタンバイ、ホットスタンバイ、アクティブ - アクティブなどがあり、コストと複雑さは戦略によって異なります。ディザスタリカバリテストの前に、目標復旧時間 (RTO) と目標復旧時点 (RPO) を定義して、シミュレートする戦略の選択を簡素化することをお勧めします。AWS には、計画とテストの開始に役立つ AWS Elastic Disaster Recovery
などのディザスタリカバリツールが用意されています。 -
カオスエンジニアリングのテストでは、ネットワーク障害やサービス障害などのシステムの中断を発生させます。制御された障害を使用してシミュレーションを行うことで、発生した障害の影響を抑えながら、システムの脆弱性を発見できます。他の戦略と同様に、AWS Fault Injection Service
のようなサービスを使用して、非本番環境で制御された障害シミュレーションを実行し、本番環境にデプロイする前に確信を得ることができます。
リソース
関連ドキュメント:
関連動画:
