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

  • 5 分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のスクリーンショットの例で示すように、テスト条件を使って、さまざまなベースラインを実装できます。

サンプルのテスト条件を示す Azure portal の表のスクリーンショット。

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

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

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

知識チェック

1.

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

2.

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

3.

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