クラウドネイティブのアプリケーションとサービスが複雑になるにつれて、変更や新しいリリースをデプロイするのは困難な場合があります。 障害は、多くの場合、デプロイまたはリリースの障害が原因で発生します。 ただし、 デプロイ後、アプリケーションが実際のトラフィックを受信し始めるとき、特に高度に分散されたマルチテナント クラウド環境で実行され、複数の開発チームによって維持される複雑なワークロードでエラーが発生する可能性があります。 これらの環境では、再試行ロジックや自動スケールなど、より多くの回復性対策が必要です。通常、開発プロセス中にテストするのは困難です。
そのため、開発環境に 似た環境での継続的な検証が重要であるため、開発サイクルの早い段階で問題やバグを見つけて修正できます。 ワークロード チームは、開発プロセスの早い段階でテストし (左にシフト)、運用環境に近い環境で開発者がテストを行うのに便利にする必要があります。
ミッション クリティカルなワークロードには高可用性要件があり、ターゲットは 3、4、または 5 ナイン (それぞれ 99.9%、99.99%、または 99.999%) です。 これらの目標を達成するには 、厳密な自動テスト を実装することが重要です。
継続的な検証は、各ワークロードとアーキテクチャの特性によって異なります。 この記事では、Azure Load Testing と Azure Chaos Studio を定期的な開発サイクルに準備して統合するためのガイドを提供します。
1 – 予想されるしきい値に基づいてテストを定義する
継続的なテストは、適切な準備が必要な複雑なプロセスです。 何がテストされ、期待される結果が明確である必要があります。
PE:06 - パフォーマンス テストと RE:08 の推奨事項 - 信頼性テスト戦略の設計に関する推奨事項では、Azure Well-Architected Framework では、主要なシナリオ、依存関係、予想される使用状況、可用性、パフォーマンス、スケーラビリティのターゲットを特定することから始める必要があります。
次に、主要なシナリオの予想されるパフォーマンスを定量化するために、 測定可能なしきい値 のセットを定義する必要があります。
ヒント
しきい値の例としては、予想されるユーザー サインインの数、特定の API の 1 秒あたりの要求数、バックグラウンド プロセスの 1 秒あたりの操作などがあります。
テスト用と運用環境でのアプリケーションの運用用 の両方で、アプリケーションの正常性モデルを開発するには、しきい値を使用する必要があります。
次に、この値を使用して、アプリケーション ベースラインのパフォーマンスをテストしたり、予想されるスケール操作を検証したりするための現実的なトラフィックを生成する ロード テスト を定義します。 使用しないと実行時の問題を明らかにすることは困難であるため、運用前環境では持続的な人工ユーザー トラフィックが必要です。
ロード テストにより、アプリケーションまたはインフラストラクチャに加えられた変更によって問題が発生せず、システムが期待されるパフォーマンスとテスト条件を満たすことができます。 テスト条件を満たしていない失敗したテスト実行は、ベースラインを調整する必要がある、または予期しないエラーが発生したことを示します。
自動テストは日常的な使用状況を表しますが、システムが予期しないピークにどのように応答するかを確認するために 、手動ロード テストを定期的に実行する必要があります 。
継続的な検証の 2 番目の部分は、 障害の挿入 (カオス エンジニアリング) です。 この手順では、システムが障害にどのように応答するかをテストすることで、システムの回復性を検証します。 また、再試行ロジックや自動スケーリングなど、すべての回復性対策が想定どおりに動作していることを確認します。
2 - ロード テストと Chaos Studio を使用して検証を実装する
Microsoft Azure には、ロード テストとカオス エンジニアリングを実装するための次のマネージド サービスが用意されています。
- Azure Load Testing はアプリケーションとサービスに対して模擬ユーザー負荷を生成します。
- Azure Chaos Studio は、アプリケーション コンポーネントとインフラストラクチャに障害を体系的に挿入することで、混乱の実験を実行する機能を提供します。
Chaos Studio と Load Testing の両方を Azure portal 経由でデプロイして構成できますが、継続的な検証のコンテキストでは、 プログラムによって自動化された方法でテストをデプロイ、構成、実行するための API を用意することがより重要です。 これら 2 つのツールを組み合わせて使用すると、システムが問題に対してどのように反応し、インフラストラクチャまたはアプリケーションの障害に対応して自己修復する機能を観察できます。
次のビデオでは、Azure DevOps に統合された Chaos と Load Testing の統合された実装 を示します。
ミッション クリティカルなワークロードを開発している場合は、 Azure Well-Architected Framework の一部として提供される詳細なガイダンスを利用してください。
1 つのオプションは、個々の (ブランチ固有の) 開発環境を起動するために使用されるエンド ツー エンド (e2e) パイプライン内からロード テストを直接実行することです。
![[ロード テスト] チェック ボックスがオンの状態でパイプラインを実行します。](images/deployment-testing-pipeline-start.png)
パイプラインは、(選択に応じて) カオス実験の有無にかかわらず、ロード テストを自動的に並列で実行します。
注
ロード テスト中に混乱の実験を実行すると、待機時間が長くなり、応答時間が長くなり、一時的にエラー率が増加する可能性があります。 カオス実験を行わない実行と比較して、スケールアウト操作が完了するかフェールオーバーが完了するまでの応答時間と待機時間が長くなることが予想されます。
混乱テストが有効かどうかと実験の選択に応じて、"通常" 状態と "混乱" 状態でエラーの許容度が異なる可能性があるため、ベースライン定義が異なる場合があります。
3 – しきい値を調整し、ベースラインを確立する
最後に、通常の実行の ロード テストのしきい値を調整 して、アプリケーションが (まだ) 期待されるパフォーマンスを提供し、エラーが発生しないことを確認します。 予期されるエラー率の急増と一時的なパフォーマンスの低下を許容するカオス テスト用の別のベースラインを用意します。 このアクティビティは継続的であり、定期的に繰り返す必要があります。 たとえば、新機能の導入後、サービス SKU などを変更した後などです。
Azure Load Testing サービスには、テストに合格する必要がある特定の条件を指定できる、 テスト条件 と呼ばれる組み込みの機能が用意されています。 この機能を使用して、さまざまなベースラインを実装できます。
![応答時間とエラー条件が [失敗] としてマークされた [テスト条件] 画面。](images/deployment-testing-test-criteria.png)
この機能は、Azure portal とロード テスト API を介して利用できます。また、Azure Mission-critical の一部として開発されたラッパー スクリプトは、JSON ベースのベースライン定義を引き渡すオプションを提供します。
これらのテストを CI/CD パイプラインに直接統合し、機能開発の初期段階で実行することを強くお勧めします。
要約すると、複雑な分散システムでは障害が避けられないため、障害を処理するためにソリューションを設計 (およびテスト) する必要があります。 Well-Architected Framework のミッション クリティカルなワークロード ガイダンスとリファレンス実装は、Microsoft クラウドから最大値を引き出す信頼性の高いアプリケーションを設計および運用するのに役立ちます。
次のステップ
ミッション クリティカルなワークロードのデプロイとテストの設計領域を確認します。