エンドポイントを提供するための負荷テスト
この記事では、 Mosaic AI Model Serving エンドポイントが本番運用ワークロードを効果的に処理できることを確認するための負荷テストの基本的なプロセスについて説明します。 また、Locust ロード テスト フレームワークを使用した実用的な例、実際の例え、ステップバイステップの手順も提供し、1 秒あたりのリクエスト数や同時実行制限などの主要なパフォーマンス メトリクスを測定する方法を示し、エンドポイントのサイズを正しく設定し、ビジネス ニーズに合わせてモデルを自信を持ってデプロイできるようにします。
ロード テストとは
負荷テストは、 Mosaic AI モデルサービングエンドポイントの実際の使用状況をシミュレートし、レイテンシやリクエスト/秒などの本番運用要件を満たしていることを確認するテストです。 ロードテストでは、さまざまなトラフィックレベルでのエンドポイントのパフォーマンスを測定し、遅延を引き起こさないようにエンドポイントのサイズを適切に設定するのに役立ちます。
想像してみてください:平日の午前8:00、街の中心部にある人気のカフェがオープンしたばかりです。淹れたてのコーヒーの香りが漂います。バリスタの準備が整い、マシンが温まり、カフェインを摂取しない顧客の列はすでに形成されています。
最初は、物事はスムーズに実行されます。 数人のお客様が歩み寄って注文をすると、バリスタが飲み物の準備を始めます。 30秒で終わるものもあれば、1分で終わるものもあり、複雑さにもよります。バリスタは、複数の注文を練習した効率でジャグリングします。
しかし、すぐにさらに多くの人々が到着します。5人の顧客が10人になり、さらに20人になります。それぞれが注文をし、飲み物を待ち、カウンターで少しおしゃべりをしています。バリスタは今、プレッシャーにさらされています。2人目のバリスタが飛び込んでも、システムは緊張し始め、行列ができ、注文が山積みになり、顧客はより長く待ち始めます。
ここで、顧客がイライラして帰る前に、カフェが毎分何杯の飲み物を提供できるかを測定しようとしていると想像してみてください。 これが 負荷テスト です。
この例えでは、次のようになります。
- 各顧客は、リクエストを送信する クライアント です。
- バリスタは、モデルの推論を 1 つずつ、または並行して処理する サーバー を表します。
- 注文を受けて飲み物を提供する時間がモデル の実装 時間です。
- 通話、支払い、または注文の検索の遅延は、 ネットワークのオーバーヘッド です。
- 一度に到着する顧客が多いのは 、クライアントの同時実行性 です。
- バリスタやマシンを増やすことは、 サーバーの同時実行性 を高めるようなものです。
どんな良いカフェでもそうですが、スタッフが一度に対応できる量には限界があります。前もって計画を立てないと、例えばピーク時にバリスタを増員するなど、人々は不満を抱いて去っていきます。負荷がかかっているシステムについても同じことが言えます。ロード テストは、ボトルネックがどこにあるか、システムが処理できるトラフィックの量、およびよりスムーズなサービスのためにどのような変更を加える必要があるかを特定するのに役立ちます。
エンドポイントで負荷テストを実行する前に、次のことを行う必要があります。
- ロード テストに関連するコンポーネントと概念を理解します。
- 本番運用の要件を決定し、定義します。
- エンドポイントのベンチマーク時に使用する負荷テストフレームワークの代表的なペイロードを見つけます。
ロード テストの概念と定義
次の表では、ロード テスト関連の概念を定義しています。
概念 | 説明 |
|---|---|
クライアントの同時実行性 (クライアントの数) | エンドポイントに同時に要求を並列に送信するクライアントの合計数。これらは、上記の例のカフェの顧客です。 本番運用: モデルサービング エンドポイントにトラフィックを送信しているクライアントの合計インスタンス数。 負荷テスト: Locust では、負荷テスト対象のモデルサービングエンドポイントにトラフィックを送信するために作成されたユーザーの数です。 |
エンドポイントの同時実行性 | 受信要求を処理できる推論プロセスまたはモデルインスタンスの数。エンドポイントで同時に処理できる要求の数として表すこともできます。上記の例のバリスタの数です。 Mosaic AI Model Serving: モデルサービング エンドポイントは、コンピュート スケール アウト サイズ用に構成できます。 たとえば、CPU エンドポイントの |
レイテンシー | 完全なラウンドトリップ要求が完了するまでの時間 (ミリ秒単位)。クライアントが要求を送信してから応答が受信されるまでの合計時間の尺度 (エンドポイントの実行時間とネットワーク遅延を含む)。 |
PXX(P50、P90、P99)レイテンシ | リクエストのXXパーセンタイルが次の時間より速く終了したレイテンシ(ミリ秒単位)。たとえば、P90 が 30 ミリ秒の場合、すべてのリクエストの 90% が 30 ミリ秒以内に完了したことを意味します。 |
1 秒あたりの要求数 (RPS) | 1 秒あたりに完了した要求の数。完了 は、エンドポイントからクライアントに応答が返されることを意味します。 |
レイテンシの要件
ビジネス要件と顧客要件に基づいて、システムの理想的なパフォーマンスを定義します。モデルサービングエンドポイントでは、レイテンシーには、クライアントが推論のためにデータを送信するときに発生するラウンドトリップ時間が含まれます。 これには、ネットワーク遅延と推論時間が含まれます。要件が現実的であることを確認することが重要です。たとえば、モデルがメモリに読み込まれたときに推論を実行するのに 15 ミリ秒かかる場合、モデルサービング エンドポイントで提供されるときには、ネットワーク待機時間の追加時間を考慮する必要があります。
RPS、レイテンシ、同時実行性はどのように関連していますか?
ビジネスには、システムの成功のためのいくつかの定義された基準があります。ML システムの場合、ビジネス基準は一般に、高品質の結果、低レイテンシ、高スループットです。結果の品質は特にモデル自体に関連していますが、エンドツーエンドのレイテンシとスループットはサービングシステムの特性です。エンドツーエンドのレイテンシは、モデルの実行時間とネットワークのオーバーヘッドで構成されます。スループット (またはリクエスト数またはクエリ数/秒) は、レイテンシに反比例し、コンカレンシーに直接関連します。
- コンカレンシーが高いほど、スループットは高くなります。
- レイテンシが高ければ高いほど、全体のレイテンシは低くなります。
一般に、特定のアプリケーションには、クライアント側の同時実行性とサーバー側の同時実行の最適な比率があります。例えば、「ラインシェフが同時にどれだけのハンバーガーを作れるか」です。調理プロセスには多くの共通ステップがあるため、ラインシェフは一度に1つだけを調理するのではなく、4つのハンバーガーを同時に最適に調理できる可能性があります。この並列化には限界があり、ある時点で、シェフが 1000 個のハンバーガーにチーズを追加する必要がある場合など、多くの並列処理を実行する行為によって待機時間が長くなりすぎます。
ロード テストの中心的な目標の 1 つは、アプリケーションに最適な比率を決定することです。最適な比率により、RPS が最大化され、遅延要件を満たし、キューイングを回避できます。この比率を使用して、最も要求の厳しい負荷に合わせてエンドポイントのサイズを正確に設定することができます。
エンドポイントが要求を十分な速度で処理できない場合は、行が形成され始めます。これはキューと呼ばれます。キューが形成されると、通常、各リクエストが処理されるまでに待機する時間が増えるため、エンドツーエンドのレイテンシがはるかに長くなります。リクエストが処理可能な速度よりも速くリクエストが到着し続けると、キューが拡大し、レイテンシーがさらに増加します。このため、エンドポイントで発生する可能性のあるピーク需要の種類を理解し、負荷テストで正しくサイズが設定されていることを確認することが重要です。
ロード テスト シナリオの例示
ロード テストでは、実際のシステムと同様に、クライアントの同時実行性、サーバーの同時実行性、および待機時間の関係は動的で相互依存しています。この関係を簡単な例で見てみましょう。
シナリオ 1: 簡単なセットアップ
この設定では、1 つのクライアントがリクエストを順番に送信し、レスポンスを待ってから次のリクエストを発行します。要求ごとの合計時間はモデルの実行とオーバーヘッドのレイテンシ (40 ミリ秒 + 10 ミリ秒) の合計であるため、測定されたエンドツーエンドのレイテンシは 50 ミリ秒です。
- クライアント数:1
- プロビジョニングされたコンカレンシー: 1
- オーバーヘッド遅延: 10 ミリ秒
- モデルの実行時間 40 ミリ秒
その結果、クライアントは 50 ミリ秒ごとに 1 つの要求を完了し、これは 1 秒あたり 20 件の要求または1 秒あたりにクエリに相当します。
シナリオ 2: プロビジョニングされた同時実行数を増やす
この場合、プロビジョニングされたコンカレンシーが 2 倍になり、1 つのクライアントが順番にリクエストを行います。これは、合計遅延が 50 ミリ秒 (40 ミリ秒 + 10 ミリ秒) のままであり、システムが認識している要求/秒 (QPS) は 20 件に過ぎないことを意味します。
- クライアント数:1
- プロビジョニングされた同時実行数: 1 から > 2
- オーバーヘッド遅延: 10 ミリ秒
- モデルの実行時間 40 ミリ秒
シナリオ 3: システムに別のクライアントを追加します。
これで、2 つのクライアントが 2 つのプロビジョニングされた同時実行を持つエンドポイントにリクエストを送信しています。この場合、各クライアントのリクエストは、エンドポイントによって同時に独立して処理できます(完全なロードバランシングを前提としています)。したがって、合計遅延は 50 ミリ秒 (40 ミリ秒 + 10 ミリ秒) のままですが、各クライアントは 20 qps を送信するため、システムは 1 秒あたり 40 の要求を監視します。
- クライアント数: 1 -> 2
- プロビジョニングされた同時実行数: 2
- オーバーヘッド遅延: 10 ミリ秒
- モデルの実行時間 40 ミリ秒
プロビジョニングされた同時実行数とリクエストを行うクライアントの数を増やすと、システムで観測される QPS の合計が増加し、レイテンシーが損なわれることはありません。
シナリオ 4: プロビジョニングされたコンカレンシーを減らしましょう
この最後のシナリオでは、クライアントの数がプロビジョニングされた同時実行数を超えています。この設定では、システムに別の変数であるキューイングが導入され、QPS とレイテンシへの影響が発生します。
- クライアント数:2
- プロビジョニングされた同時実行数: 2 から > 1
- オーバーヘッド遅延: 10 ミリ秒
- モデルの実行時間: 40 ミリ秒
ここでは、2 つのクライアントが同時に要求を行っています。ただし、エンドポイントは一度に 1 つのリクエストしか処理できません。これにより、最初の要求が処理されるまで、2 番目の要求が強制的に待機します。2 番目の要求の待機 (より正確にはキューイング) は、システムの待ち時間に悪影響を与える可能性があります。サーバーがキューイングを許可している ( Databricks モデルサービングの デフォルト で有効) と仮定すると、2 番目のクライアントには 90 ミリ秒の遅延が発生します: 10 ミリ秒 (ネットワーク オーバーヘッド) + 40 ミリ秒 (キュー待ち時間) + 40 ミリ秒 (モデル実行時間)。 これは、前に見られた 50 ミリ秒よりも大幅に悪化しています。