デプロイ後のアクティビティ

耐障害性は継続的なプロセスであり、アプリケーションのデプロイ後もアプリケーションの耐障害性を継続して評価する必要があります。継続的な耐障害性評価など、デプロイ後アクティビティの結果では、耐障害性ライフサイクルの前半で実行した耐障害性アクティビティの一部を再評価して更新する必要が生じる場合があります。

耐障害性評価の実施

アプリケーションを本番環境にデプロイしたからといって、耐障害性の評価は終わりではありません。デプロイパイプラインが明確に定義され、自動化されていても、本番環境で変更が直接発生することがあります。さらに、デプロイ前の耐障害性検証でまだ考慮していない要素があるかもしれません。AWS Resilience Hub では、デプロイされたアーキテクチャが定義された RPO と RTO のニーズを満たすかどうかを評価できる一元的な場所を提供します。このサービスを使用すると、AWS のブログ記事「Continually assessing application resilience with AWS Resilience Hub and AWS CodePipeline」で説明されているように、アプリケーションの耐障害性をオンデマンドで評価したり、評価を自動化したり、CI/CD ツールに統合したりできます。これらの評価を自動化することは、本番環境で耐障害性体制を継続的に評価するのに役立つため、ベストプラクティスです。

DR テスト

「ステージ 2: 設計と実装」では、ディザスタリカバリ (DR) 戦略をシステムの一部として開発しました。ステージ 4 では、DR 手順をテストして、チームがインシデントに対して十分に準備でき、手順が期待どおりに機能することを確認する必要があります。フェイルオーバーやフェイルバックを含むすべての DR 手順を定期的にテストし、各演習の結果を確認して、可能な限り最良の結果を得るためにシステムの手順を更新するかどうかと、その方法について決定する必要があります。DR テストを最初に作成するときは、事前にテストを適切にスケジュールし、チーム全体が期待される内容、結果の測定方法、結果に基づいて手順を更新するために使用するフィードバックメカニズムを理解していることを確認します。スケジュールされた DR テストの実行に慣れたら、未発表の DR テストの実行を検討してください。実際の災害はスケジュールどおりに発生しないため、いつでも計画を実践する準備を整えておく必要があります。ただし、未発表とは計画外を意味するものではありません。主要な利害関係者は、引き続きイベントを計画し、適切なモニタリングが行われ、顧客や重要なアプリケーションに悪影響が及ばないようにする必要があります。

ドリフト検出

本番稼働用アプリケーションの設定に対する予期しない変更は、自動化や明確に定義された手順が設定されている場合でも発生する可能性があります。アプリケーションの設定に対する変更を検出するには、ドリフトを検出するメカニズムが必要です。これは、ベースライン設定からの偏差を指します。AWS CloudFormation スタックのドリフトを検出する方法については、AWS CloudFormation ドキュメントの「スタックとリソースに対するアンマネージド型設定変更の検出」を参照してください。アプリケーションの AWS 環境でドリフトを検出するには、AWS Control Tower ドキュメントの「AWS Control Tower でドリフトを検出および解決する」を参照してください。

合成テスト

合成テストは、エンドユーザーエクスペリエンスをシミュレートする方法でアプリケーションの API をテストするために、本番環境でスケジュールを基に実行される設定可能なソフトウェア作成プロセスです。これらのテストは、元々採炭業で使用されていた用語に関連して、Canary と呼ばれることがあります。合成テストでは、グレー障害の場合と同様に、障害が部分的または断続的であっても、アプリケーションの中断が発生すると早期警告が表示されることがあります。

カオスエンジニアリング

カオスエンジニアリングは、アプリケーションを意図的にリスク軽減の方法で破壊的なイベントにさらし、その対応を注意深くモニタリングし、必要な改善を実装する体系的なプロセスです。その目的は、このような中断を処理するアプリケーションの機能について、前提を検証または疑問視することです。カオスエンジニアリングは、これらのイベントを成り行きに任せるのではなく、エンジニアが制御された環境で実験をオーケストレーションできるようにし、通常はトラフィックが少なく、効果的な緩和のためのエンジニアリングサポートがすぐに利用できる期間に実施します。

カオスエンジニアリングは、検討中のアプリケーションの通常の動作状態 (定常状態と呼ばれます) を理解することから始まります。そこから、中断が発生してもアプリケーションの正常な動作を詳述する仮説を立て、実験を実行します。実験では、ネットワークレイテンシー、サーバー障害、ハードドライブエラー、外部依存関係の障害などを含みますが、それらに限定しない中断を意図的に注入します。次に、実験の結果を分析し、学習内容に基づいてアプリケーションの耐障害性を強化します。この実験は、パフォーマンスなど、アプリケーションのさまざまな側面を改善するための貴重なツールとして機能し、それ以外の場合では隠されていた可能性のある潜在的な問題を検出します。さらに、カオスエンジニアリングは、オブザーバビリティツールやアラームツールの欠陥を明らかにし、それらを改良するのに役立ちます。また、復旧時間の短縮と運用スキルの向上にも貢献します。カオスエンジニアリングは、ベストプラクティスの導入を加速し、継続的な改善という考え方を育みます。最終的には、チームが定期的な演習と反復により運用スキルを構築し、磨き上げることができるようになります。

AWS では、非本番環境でカオスエンジニアリング作業を開始することをお勧めしています。AWS Fault Injection Service (AWS FIS) を使用して、AWS に固有の障害だけでなく、汎用的な障害でもカオスエンジニアリングの実験を実行できます。このフルマネージドサービスには、停止条件アラームと完全なアクセス許可コントロールが含まれているため、安全性と信頼性に優れたカオスエンジニアリングを簡単に導入できます。