Test

The presented Microsoft Azure Well-Architected Framework recommendations in this guidance include Reliability Stage “3 - Test (Workload Testing)” and associated resources and their settings.

Before deploying the system, comprehensive tests are conducted to validate the design and implementation. This stage is crucial for identifying any weaknesses that could compromise reliability.

アプリケーションは、可用性と復元力を確保するためにテストする必要があります。可用性は、アプリケーションが重大なダウンタイムなしに正常な状態で実行される時間を表します。復元力は、アプリケーションが障害からどれだけ早く回復するかを表します。

可用性と回復力を測定できると、次のような質問に答えることができます。
- どのくらいのダウンタイムが許容されますか?潜在的なダウンタイムにより、ビジネスにどのくらいのコストがかかりますか?
- 可用性の要件は何ですか?
- アプリケーションの可用性を高めるためにどれくらい投資していますか?
- コストとリスクは何ですか?
- テストは、アプリケーションがこれらの要件を満たしていることを確認する上で重要な役割を果たします。

キーポイント：
- 定期的にテストを行って、既存のしきい値、目標、仮定を検証します。
- 可能な限りテストを自動化します。
- 主要なテスト環境と運用環境の両方でテストを実行します。
- 断続的な障害状況下でエンドツーエンドのワークロードがどのように実行されるかを検証します。
- パフォーマンスに関する重要な機能要件および非機能要件に対してアプリケーションをテストします。
- 予想されるピークボリュームで負荷テストを実施し、負荷時のスケーラビリティとパフォーマンスをテストします。
- 障害を挿入してカオス テストを実行します。

Improves uptime and speeds recovery

分散システムでは、アプリケーションがエラーから確実に回復できるようにすることが重要です。アプリケーションをテストしてエラーや障害を防ぐことはできますが、さまざまな問題に備える必要があります。テストでは常にすべてを把握できるわけではないため、エラーを処理し、潜在的な失敗を防ぐ方法を理解する必要があります。

基盤となるクラウド インフラストラクチャやサードパーティのランタイム依存関係など、分散システム内の多くのものは、制御範囲やテスト手段の範囲外にあります。いずれ何かが失敗することは確実なので、備えが必要です。

キーポイント：
- 一時的なアプリケーション障害および内部または外部の依存関係による一時的な障害を処理するための再試行ロジックを実装します。
- アプリケーションの再試行ロジックの問題や障害を明らかにします。
- コンポーネント間の呼び出しを管理するためにリクエストのタイムアウトを構成します。
- ロード バランサーとトラフィック マネージャーの正常性プローブを構成してテストします。
- アプリケーション データ ストア全体で読み取り操作を更新操作から分離します。

Enhances recovery and error management

災害復旧は、壊滅的な損失の後にアプリケーションの機能を復元するプロセスです。

クラウド環境では、障害が発生することを事前に認識しています。障害を完全に防止しようとするのではなく、単一のコンポーネントに障害が発生した場合の影響を最小限に抑えることが目標です。

テストは、これらの影響を最小限に抑える 1 つの方法です。可能な場合はアプリケーションのテストを自動化する必要がありますが、失敗した場合に備えておく必要もあります。障害が発生した場合、バックアップとリカバリの戦略を立てることが重要になります。災害時の機能低下に対する許容度はビジネス上の決定であり、アプリケーションごとに異なります。一部のアプリケーションが一時的に利用できなくなったり、機能が低下したり処理が遅延したりして部分的に利用可能になったりすることは許容される場合があります。他のアプリケーションでは、機能の低下は受け入れられません。

キーポイント：
- 主要な障害シナリオを使用して、災害復旧計画を定期的に作成し、テストします。
- ほとんどのアプリケーションを機能を制限して実行できるように災害復旧戦略を設計します。
- ビジネス要件とアプリケーションの状況に合わせたバックアップ戦略を設計します。
- フェイルオーバーとフェイルバックのステップとプロセスを自動化します。
- フェイルオーバーとフェイルバックのアプローチが少なくとも 1 回は正常にテストおよび検証されます。

Enhances recovery speed and reliability

理想的には、カオス原理を継続的に適用する必要があります。ソフトウェアとハードウェアが実行される環境は常に変化するため、変化を監視することが重要です。コンポーネントにストレスや障害を常に加えることにより、小さな問題が他の多くの要因によって悪化する前に、問題を早期に発見することができます。

次の場合にカオス エンジニアリングの原則を適用します。
- 新しいコードをデプロイします。
- 依存関係を追加します。
- 使用パターンの変化を観察します。
- 問題を軽減します。

Early issue detection, prevents compounding

高可用性は、データベース アプリケーションに対して透過的に機能する SQL データベース プラットフォームの基本的な部分です。ただし、計画的または計画外のイベント中に開始された自動フェイルオーバー操作がアプリケーションにどのような影響を与えるかを、アプリケーションを実稼働環境にデプロイする前にテストしたい場合があることを私たちは認識しています。特別な API を呼び出してデータベースまたはエラスティック プールを再起動することで、フェールオーバーを手動でトリガーできます。

ゾーン冗長サーバーレスまたはプロビジョニングされた汎用データベースまたはエラスティック プールの場合、API 呼び出しにより、古いプライマリの可用性ゾーンとは異なる可用性ゾーン内の新しいプライマリにクライアント接続がリダイレクトされます。そのため、フェイルオーバーが既存のデータベース セッションにどのような影響を与えるかをテストするだけでなく、ネットワーク遅延の変化によりエンドツーエンドのパフォーマンスが変化するかどうかも検証できます。

再起動操作は煩雑であり、多数の操作がプラットフォームに負荷をかける可能性があるため、データベースまたはエラスティック プールごとに 15 分ごとに 1 回のフェールオーバー呼び出しのみが許可されます。

Enhances fault resilience testing