Azure Load Testing と Azure Chaos Studio を使用した継続的検証

クラウドネイティブのアプリケーションとサービスがより複雑になるにつれて、変更や新しいリリースをデプロイするのが困難になる場合があります。 障害が発生する原因の多くは、正しくなデプロイまたはリリースです。 ただし、エラーは、デプロイ後、アプリケーションが実際のトラフィックを受信し始めるときに発生する場合もあります。特に高度に分散されたマルチテナント クラウド環境で実行され、複数の開発チームによって維持される複雑なワークロードの場合です。 これらの環境では、再試行ロジックや自動スケーリングなどのより回復性の高い対策が必要になります。これらは通常、開発プロセス中にテストを行うのが困難です。

そのため、運用環境に似た環境で継続的な検証をすることが重要です。これにより、開発サイクルの可能な限り早い段階で問題やバグを見つけて修正できるようになります。 ワークロード チームは、開発プロセスの早い段階でテストし (左にシフト)、運用環境に近い環境で開発者がテストを行うのに便利にする必要があります。

ミッション クリティカルなワークロードの高可用性要件は、スリーナイン、フォーナイン、ファイブナイン (それぞれ 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 - Load Testing と Chaos Studio を使用して検証を実装する

Microsoft Azure では、ロード テストとカオス エンジニアリングを実装するために、次のマネージド サービスを提供します。

• Azure Load Testing では、アプリケーションとサービスに対する合成のユーザー負荷が生成されます。
• Azure Chaos Studio では、アプリケーション コンポーネントとインフラストラクチャに障害を体系的に挿入することで、カオス実験を実行する機能が提供されます。

Chaos Studio とLoad Testing の両方を Azure portal 経由でデプロイして構成できますが、継続的な検証のコンテキストでは、プログラムによる自動化された方法でテストをデプロイ、構成、実行するための API を用意することがより重要です。 これらの 2 つのツールを組み合わせて使用することで、システムが問題にどのように反応するか、また、インフラストラクチャまたはアプリケーションの障害に対応して自己修復する機能を観察できます。

次のビデオでは、Azure DevOps に統合された Chaos と Load Testing の組み合わせの実装を示します。

ミッション クリティカルなワークロードを開発している場合は、Azure Mission-Critical プロジェクトと Azure Well-Architected Framework の一部として提供されている参照アーキテクチャ、詳細なガイダンス、サンプル実装、コード成果物を活用してください。

この Mission-Critical の実装では、Load Testing サービスが Terraform を介してデプロイされ、その API を介してサービスと対話するための PowerShell Core ラッパー スクリプトのコレクションが含まれています。 これらのスクリプトは、デプロイ パイプラインに直接埋め込むことができます。

この参照実装の 1 つのオプションとして、個々の (ブランチ固有の) 開発環境を起動するために使用されるエンド ツー エンド (e2e) パイプライン内からロード テストを直接実行することができます。

パイプラインは、(選択に応じて) カオスの実験を並列に行うかどうかにかかわらず、ロード テストを自動的に実行します。

Note

ロード テスト中にカオス実験を実行すると、待機時間の増加、応答時間の増大、エラー率の一時的な上昇などが生じる可能性があります。 カオス実験を行わない実行と比較すると、スケールアウト操作が完了するか、フェールオーバーが完了するまで、上記の数値の上昇が見られます。

カオス テストが有効になっているかどうかや実験の選択によっては、ベースライン定義が異なる場合があります。これは、"通常" 状態と "カオス" 状態とでエラーの許容度が異なる可能性があるためです。

3 – しきい値を調整してベースラインを確立する

最後に、通常の実行のロード テストしきい値を調整して、アプリケーションが (引き続き) 想定されるパフォーマンスを提供し、エラーが発生しないことを確認します。 想定されるエラー率の急増と一時的なパフォーマンスの低下を許容する、カオス テストの別のベースラインを用意します。 このアクティビティは継続的であり、定期的に繰り返す必要があります。 たとえば、新機能を導入した後や、サービス SKU を変更した後などです。

Azure Load Testing サービスには、テストで合格する必要がある特定の条件を指定できるテスト基準と呼ばれる組み込みの機能が用意されています。 この機能を使用して、さまざまなベースラインを実装できます。

この機能は Azure portal とロード テスト API を介して使用できます。また、Azure Mission-critical の一部として開発されたラッパー スクリプトでは、JSON ベースのベースライン定義を引き継ぐオプションが提供されます。

これらのテストを CI/CD パイプラインに直接統合し、機能開発の初期段階で実行することを強くお勧めします。 例については、Azure Mission-Critical リファレンス実装のサンプル実装を参照してください。

要約すると、あらゆる複雑な分散システムにおいて、障害は避けられないため、障害を処理するソリューションを設計 (およびテスト) する必要があります。 Well-Architected Framework のミッション クリティカル ワークロードのガイダンスと参照実装は、Microsoft クラウドから最大限の価値を引き出す信頼性の高いアプリケーションの設計と運用に役立ちます。

次のステップ

ミッション クリティカルなワークロードのデプロイとテストの設計領域を確認します。

設計領域: デプロイとテスト

関連リソース

• Azure ロードテストのドキュメント
• Azure Chaos Studio のドキュメント