この記事では、運用ワークロードを効果的に処理できるように、モザイク AI モデル サービス エンドポイントをロード テストする基本的なプロセスについて説明します。 また、1 秒あたりの要求やコンカレンシーの制限などの主要なパフォーマンス メトリックを測定する方法を示すために、実際の例、実際の類推、ステップ バイ ステップの手順も提供します。そのため、エンドポイントのサイズを正しく設定し、ビジネス ニーズに合わせてモデルを自信を持ってデプロイできます。
ヒント
ロード テストは、運用環境の最適化に不可欠なコンポーネントです。 インフラストラクチャ、モデル、クライアント側の最適化を含む最適化戦略に関する包括的なガイドについては、「 運用のためのモデル サービス エンドポイントの最適化」を参照してください。
ロード テストとは
ロード テストは、エンドポイントにサービスを提供するモザイク AI モデルの実際の使用をシミュレートし、待機時間や 1 秒あたりの要求など、運用環境の要件を満たしていることを確認するテストです。 ロード テストは、さまざまなレベルのトラフィックでエンドポイントのパフォーマンスを測定し、遅延を引き起こさないようにエンドポイントのサイズを正しく設定するのに役立ちます。
写真は平日の午前8時で、街の中心部にある人気のカフェがオープンしています。 新鮮なコーヒーの香りが空気を満たします。 バリスタは準備が整い、マシンは温められ、カフェイン不足の顧客の列がすでにできています。
最初は、物事はスムーズに実行されます。 2人の顧客がステップアップし、注文を行い、バリスタは飲み物の準備を始めます。 30 秒かかる飲み物もあれば、複雑さに応じて 1 分かかる飲み物もあります。 バリスタは熟練した手際で効率良く複数の注文をさばきます。
しかし、すぐに、より多くの人々が到着します。 5 人の顧客が10人になり、その後20人に増えます。 それぞれが注文を行い、飲み物を待ち、カウンターで少しチャットをしています。 バリスタは今、プレッシャーを受けている。 2番目のバリスタが飛び込んでも、システムは緊張し始めます- ラインが大きくなり、注文が積み上がり、顧客はより長く待ち始めます。
ここで、顧客が不満を残し始める前に、カフェが 1 分あたりに提供できる飲み物の数を測定しようとしているとします。 これは ロード テストです。
この例では、次のようになります。
- 各顧客は、要求を送信する クライアント です。
- バリスタは、モデル推論を 1 つずつまたは並列で処理する サーバー を表します。
- 注文を受けて飲み物を提供する時間は、 モデルの実装 時間です。
- 通信、支払い、または注文の検索の遅延は、 ネットワークのオーバーヘッドです。
- 同時に多数の顧客が到着することをクライアントのコンカレンシーと呼びます。
- より多くのバリスタやマシンを追加することは、 サーバーのコンカレンシーを高めることに似ています。
良いカフェと同様に、スタッフが一度に処理できる量には制限があります。 たとえば、ピーク時にバリスタを増やして、先に計画を立てないと、人々は不満を残します。 負荷が高いシステムでも同様です。 ロード テストは、ボトルネックがどこにあるか、システムが処理できるトラフィックの量、およびサービスをスムーズにするために行う必要がある変更を特定するのに役立ちます。
エンドポイントでロード テストを実行する前に、次の作業を行う必要があります。
- ロード テストに関連するコンポーネントと概念を理解します。
- 運用環境の要件を決定して定義します。
- エンドポイントのベンチマーク時に使用するロード テスト フレームワークの代表的なペイロードを見つけます。
ロード テストの概念と定義
次の表では、ロード テストに関連する概念を定義します。
| 概念 | 説明 |
|---|---|
| クライアントコンカレンシー (クライアントの数) | 要求を同時にエンドポイントに並列で送信するクライアントの合計数。 これらは、上記の例のカフェの顧客です。 運用: エンドポイントを提供するモデルにトラフィックを送信するクライアントの合計インスタンス。 ロード テスト: Locust では、テスト対象のモデル配信エンドポイントにトラフィックを送信するユーザー数を指します。 |
| エンドポイントのコンカレンシー | 受信要求を処理できる推論プロセスまたはモデル インスタンスの数。 エンドポイントで同時に処理できる要求の数として表すこともできます。 上の例のバリスタの数です。 モザイク AI モデル サービス: モデル サービス エンドポイントは、コンピューティング スケールアウト サイズ用に構成できます。 たとえば、CPU エンドポイントの Small サイズを使用すると、エンドポイントにモデルの 4 つのインスタンスが作成されます。 |
| 遅延 | 要求の往復処理が完了するまでの時間 (ミリ秒)。 クライアントが応答を受信するまでの要求の送信後の合計時間 (エンドポイントの実行時間とネットワーク待機時間を含む) の測定値。 |
| PXX (P50,P90,P99) 待機時間 | XX パーセンタイルのリクエストが、それよりも短い時間で完了したことを示す待機時間 (ミリ秒)。 たとえば、30 ミリ秒の P90 は、すべての要求の 90% が 30 ミリ秒以下で完了したことを意味します。 |
| 1 秒あたりの要求数 (RPS) | 1 秒あたりに完了した要求の数。 完了とは、エンドポイントからクライアントに応答が返されることを意味します。 |
待機時間の要件
ビジネスと顧客の要件に基づいて、システムの理想的なパフォーマンスを定義します。 エンドポイントを提供するモデルでは、待機時間には、推論のためにデータを送信するときにクライアントが経験するラウンド トリップ時間が含まれます。 これには、ネットワークの待機時間と推論時間が含まれます。 要件が現実的であることを確認することが重要です。 たとえば、モデルがメモリに読み込まれるときに推論を実行するのに 15 ミリ秒かかる場合は、モデルサービスエンドポイントでサービスを提供するときにネットワーク待機時間の時間を増やす必要があります。
RPS、待機時間、コンカレンシーの関係
企業には、システムの成功に関するいくつかの定義された基準があります。 ML システムの場合、ビジネス条件は一般的に高品質の結果、低待機時間、高スループットです。 結果の品質はモデル自体に特に関連しますが、エンドツーエンドの待機時間とスループットはサービス システムの特性です。 エンドツーエンドの待機時間は、モデルの実行時間とネットワーク オーバーヘッドで構成されます。 スループット (または 1 秒あたりの要求またはクエリ) は、待機時間に逆に関連し、コンカレンシーに直接関連します。
- コンカレンシーが高いほどスループットが高くなります。
- 待機時間が高くなるほど、スループットは低下します。
一般に、特定のアプリケーションのサーバー側コンカレンシーに対するクライアント側コンカレンシーの最適な比率があります。 たとえば、「ラインシェフが同時に作業できるハンバーガーの数」です。 調理プロセスには多くの共通のステップがあるため、ラインシェフは一度に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 ミリ秒) であり、システムでは 1 秒あたり 20 件の要求 (QPS) のみが表示されます。
- クライアントの数: 1
- 設定された同時実行数: 1 -> 2
- オーバーヘッド待機時間: 10 ミリ秒
- モデルの実行時間 40 ミリ秒
シナリオ 3: システムに別のクライアントを追加します。
これで、2 つのクライアントが、2 つのプロビジョニングされたコンカレンシーを使用してエンドポイントに要求を行うようになりました。 この場合、各クライアントの要求は、エンドポイントによって個別に同時に処理されます (完全な負荷分散を想定)。 そのため、合計待機時間は 50 ミリ秒 (40 ミリ秒 + 10 ミリ秒) ですが、各クライアントが 20 qps を送信するため、システムは 1 秒あたり 40 個の要求を監視します。
- クライアントの数: 1 -> 2
- プロビジョニングされたコンカレンシー: 2
- オーバーヘッド待機時間: 10 ミリ秒
- モデルの実行時間 40 ミリ秒
プロビジョニングされた同時実行数とリクエストを行うクライアント数を増やすと、システムで観測される QPS の合計が増加し、待機時間にペナルティが発生することなくなります。
シナリオ 4: プロビジョンドコンカレンシーを減らしましょう
この最後のシナリオでは、クライアントの数がプロビジョニングされたコンカレンシーよりも多くなります。 このセットアップでは、システムにもう 1 つの変数であるキューが導入され、QPS と待機時間に及ぼす影響が生じます。
- クライアントの数: 2
- プロビジョニングされたコンカレンシー: 2 -> 1
- オーバーヘッド待機時間: 10 ミリ秒
- モデルの実行時間: 40 ミリ秒
ここでは、2 つのクライアントが同時に要求を行います。 ただし、エンドポイントは一度に 1 つの要求のみを処理できます。 これにより、最初の要求が処理される前に、2 番目の要求が強制的に待機されます。 2 番目の要求の待機、正確にはキューイングが、システムのレイテンシーに悪影響を及ぼす可能性があります。 サーバーでキューが許可されていると仮定すると (Databricks Model Serving で既定で有効になっています)、2 番目のクライアントの待機時間は 90 ミリ秒 (ネットワーク オーバーヘッド) + 40 ミリ秒 (キュー待機時間) + 40 ミリ秒 (モデルの実行時間) になります。 これは前に見た50ミリ秒よりもかなり悪いです。