ロード テストのベースラインを設定する

  • 5 分

ロード テストとしきい値を定義したので、それらを使用してベースラインを構築してみましょう。

ベースラインとは、テストが失敗したか成功したかを評価するために使用するメトリックの一連の条件です。 たとえば、条件は次のようになります。

  • 1 秒あたりの平均要求数
  • エラー率
  • 最大応答時間

ロード テストのベースラインを設定するには、次の手順を行う必要があります。

  1. 個々のユーザー フローとソリューション全体のベースラインとテスト条件を定義します。

  2. 通常の実行のしきい値を調整して、アプリケーションが引き続き想定されるパフォーマンスを提供し、エラーが発生しないことを確認します。

  3. 想定されるエラー率の急増と一時的なパフォーマンスの低下を許容する、カオス テスト用には別のベースラインを使用します。

このアクティビティは継続的であり、定期的に実行する必要があります。 たとえば、新しい機能を導入したり、サービス SKU を変更したりしたら、ベースラインを確認する必要があります。

Azure Load Testing を使用してしきい値を評価する

開発フェーズ中は、コンポーネントとリソース要件のパフォーマンスが明確にわかっていないことがよくあります。 ロード テストは、スケールアウト動作など、ソリューション全体とそのコンポーネントの予想されるパフォーマンスを特定するのに役立ちます。 また、ベースラインの構築に期待されるしきい値を特定するのにも役立ちます。

定期的に次の質問をして再評価を行います。

  • 個々の操作、ユーザー フロー、または API 呼び出しが完了するまでにどのくらいの時間がかかりますか?
  • コンポーネントが 1 秒あたりに提供できる要求、操作、同時ユーザーの数はいくつですか?
  • 消費されるリソースの数はいくつですか?
  • 10、50、100 の同時ユーザーは、基になるインフラストラクチャとバックエンド サービスにどのような影響を与えますか?
  • コンポーネントのスケールインとスケールアウトは、いつ行う必要がありますか?

答えはテストとしきい値につながります。 1 秒あたりの要求数、応答時間、エラー率はすべて、しきい値に該当する例です。

詳細を確認したら、値を使用して、ソリューション全体とそのコンポーネントのパフォーマンスを一貫した方法で分析および評価します。 また、ベースラインを使用して、予想されるパフォーマンスからの変更とドリフトの影響を特定します。

テストを実行する場合、特別なユース ケースでは、コンポーネントの障害や負荷の急増など、さまざまな要件が必要になる場合があります。 そのような場合は、1 秒あたりのエラー率が高かったり、1 秒あたりの要求数が少なかったりすることが予想され、それらが許容される場合があります。 それらの状況に対応するために、しきい値を調整した別のベースラインを設定できます。 次に例を示します。

  • スケールアウト操作が予想されてそれが求められる、高負荷シナリオ。 操作が完了するまで、一時的なパフォーマンスの低下が発生する可能性があります。
  • 継続的な検証パイプラインの一部としてのカオス実験。 回復性対策によってアプリケーションの自己回復が開始されるか、別のリージョンにフェールオーバーされるまで、より高いエラー率が予想されます。

Azure Load Testing を使用すると、定義されたしきい値と照らし合わせてシステムのパフォーマンスを評価できます。 このサービスには、組み込みのテスト条件機能が用意されています。 つまり、ロード テストに合格するのに必要な条件を指定できます。

テスト条件を使用して、さまざまなベースラインを実装できます。 次に例を示します。

Table that shows sample test criteria.

これらのテスト条件は JSON で指定し、API を使用してロード テストに追加できます。 次に例を示します。

[
    {
        "passFailMetrics": {
            "<guid>": {
                "clientmetric": "requests_per_sec",
                "aggregate": "avg",
                "condition": "<",
                "value": 1200.0,
                "actualValue": 0.0,
                "result": null,
                "action": "continue"
            },
            "<guid>": {
                "clientmetric": "response_time_ms",
                "aggregate": "avg",
                "condition": ">",
                "value": 75.0,
                "actualValue": 0.0,
                "action": "continue"
              },
              "<guid>": {
                "clientmetric": "error",
                "aggregate": "percentage",
                "condition": ">",
                "value": 0.0,
                "actualValue": 0.0,
                "action": "continue"
              }
        }
    }
]

継続的検証のもう 1 つの重要な側面は、実際の問題をシミュレートするテストを挿入することです。 次のユニットでは、検証プロセスにカオス実験を追加する方法について説明します。

知識チェック

1.

ベースラインはいくつ必要ですか?

2.

ベースラインでは、デプロイで提供できるパフォーマンスを定義しますか?

3.

ベースラインを評価して更新する必要があるのはどんなときですか?