モデルサービスメッシュの推論リクエストを高速化するための動的サブセット負荷分散の使用 - Alibaba Cloud Service Mesh

このトピックでは、サービスメッシュ（ASM）の動的サブセット負荷分散機能を使用して、リクエストを正しいランタイム環境にルーティングし、それによってモデルサービスメッシュの推論プロセスを高速化する方法について説明します。

背景情報

モデルサービスメッシュは、複数のモデルサービスの管理、デプロイ、およびスケジューリングのためのスケーラブルで高性能なインフラストラクチャを提供します。

モデルサービスメッシュで同時に複数の異なるモデルを実行する場合、特定のモデルは通常、特定のモデルサービングランタイムにロードされます。ただし、Kubernetes サービスは、推論リクエストを任意のモデルサービングランタイムにランダムに送信します。この推論リクエストは、正しいモデルサービングランタイムに送信されるまでに、モデルサービスメッシュ内で何度もルーティングされる可能性があります。

動的サブセット負荷分散は、モデルサービスメッシュの各ランタイムワークロードで実行されているモデルを識別できます。ASM ゲートウェイは、推論リクエストに対応するモデルを識別し、リクエストを正しいランタイムワークロードにルーティングします。このようにして、モデルサービスメッシュのルーティング決定が最適化され、推論リクエストへの応答が高速化されます。動的サブセット負荷分散の詳細については、「動的サブセット負荷分散」をご参照ください。

前提条件

V1.21.6.47 以降の ASM インスタンスが作成されていること。詳細については、「ASM インスタンスの作成」をご参照ください。
コンテナサービス Kubernetes 版（ACK）クラスタが ASM インスタンスに追加されていること。詳細については、「ASM インスタンスへのクラスタの追加」をご参照ください。
モデルサービスメッシュが有効になっており、sklearn-mnist モデルがデプロイされていること。詳細については、「モデルサービスメッシュを使用してマルチモデル推論サービスをロールアウトする」をご参照ください。

ステップ 1：モデルサービスメッシュに tf-mnist モデルをデプロイする

動的サブセット負荷分散の正確なルーティング機能は、主にマルチモデルシナリオで使用されます。したがって、この例では、追加の tf-mnist モデルがモデルサービスメッシュにデプロイされます。 tf-mnist モデルは、TensorFlow によって実装された mnist モデルであり、そのランタイム環境は Triton サービングランタイムによって提供されます。

説明

「モデルサービスメッシュを使用してマルチモデル推論サービスをロールアウトする」の手順を実行して作成された永続ボリュームクレーム（PVC）my-models-pvc は、tf-mnist モデルを保存するために使用されます。 mnist ディレクトリ内のすべてのコンテンツはモデルコンテンツです。

永続ボリュームに tf-mnist モデルを保存します。
1. kubeconfig ファイルの情報に基づいて kubectl を使用して ACK クラスタに接続します。次に、次のコマンドを実行して、mnist-svm.joblib モデルファイルを pvc-access ポッドの /mnt/models フォルダにコピーします。
```
kubectl -n modelmesh-serving cp mnist pvc-access:/mnt/models/
```
2. 次のコマンドを実行して、モデルが永続ボリュームに存在することを確認します。
```
kubectl -n modelmesh-serving exec -it pvc-access -- ls -alr /mnt/models/
```
  予期される出力：
```
-rw-r--r-- 1  502 staff 344817 Apr 23 08:17 mnist-svm.joblib
drwxr-xr-x 3 root root    4096 Apr 23 08:23 mnist
drwxr-xr-x 1 root root    4096 Apr 23 08:17 ..
drwxrwxrwx 3 root root    4096 Apr 23 08:23 .
```
推論サービスをデプロイします。
1. 次の内容で tf-mnist.yaml ファイルを作成します。
```
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: tf-mnist
  namespace: modelmesh-serving
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
spec:
  predictor:
    model:
      modelFormat:
        name: tensorflow
      storage:
        parameters:
          type: pvc
          name: my-models-pvc
        path: mnist
```
2. kubeconfig ファイルの情報に基づいて kubectl を使用して ACK クラスタに接続します。次に、次のコマンドを実行して tf-mnist 推論サービスをデプロイします。
```
kubectl apply -f tf-mnist.yaml
```
3. しばらく待ちます（待ち時間はイメージのプル速度によって異なります）。次に、次のコマンドを実行して、tf-mnist 推論サービスがデプロイされているかどうかを確認します。
```
kubectl get isvc -n modelmesh-serving
```
  予期される出力：
```
NAME            URL                                               READY
sklearn-mnist   grpc://modelmesh-serving.modelmesh-serving:8033   True
tf-mnist        grpc://modelmesh-serving.modelmesh-serving:8033   True
```
  予期される出力は、異なるフレームワークを持つ 2 つのモデル、sklearn-mnist と tf-mnist がモデルサービスメッシュにデプロイされたことを示しています。

(オプション) ステップ 2：モデルサービスメッシュでの推論リクエストの処理レイテンシをテストする

fortio ストレステストツールをインストールします。詳細については、fortio プロジェクトのインストール手順をご参照ください。
fortio ストレステストツールを使用して、tf-mnist モデルに推論リクエストを送信します。ASMイングレスゲートウェイの IP アドレスを取得する方法の詳細については、「KServe と ASM を統合してクラウドネイティブ AI モデルに基づく推論サービスを実装する」をご参照ください。
```
ASM_GW_IP="ASMイングレスゲートウェイの IP アドレス"
fortio load -jitter=False -H 'model: tf-mnist' -c 1 -qps 100 -t 60s -payload '{"inputs": [{ "name": "inputs", "shape": [1, 784], "datatype": "FP32", "contents": { "fp32_contents": [ /* 省略 */ ] }}]}' -a ${ASM_GW_IP}:8008/v2/models/tf-mnist/infer
```
予期される出力：
詳細を表示するには展開します
```
 /* 省略 */ 
```
fortio の視覚的なストレステスト結果を表示します。
1. 次のコマンドを実行して、ローカル fortio サーバーを開きます。
```
fortio server
```
2. ブラウザを使用して localhost:8080 にアクセスします。インターフェースで saved results をクリックし、fortio サーバー上の JSON ファイルを選択して、ストレステストの視覚的な結果を表示します。
  前の図に示すように、モデルサービスメッシュに送信された一部の推論リクエストのレイテンシが増加しています。これは、リクエストがモデルサービスメッシュ内で再ルーティングされ、応答速度が低下するためです。

ステップ 3：モデルサービスメッシュの動的サブセット負荷分散を有効にする

推論リクエストは、modelmesh-serving 名前空間の modelmesh-serving サービスを介して、モデルサービスメッシュ内のすべての実行中モデルにアクセスします。このセクションでは、推論リクエストを異なるモデルサービングランタイムに正確にルーティングするために、modelmesh-serving サービスの動的サブセット負荷分散を構成する方法を示します。

次の内容を使用して、モデルサービスメッシュの modelmesh-serving サービスの動的サブセットを構成します。詳細については、「宛先ルールの管理」をご参照ください。
```
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: modelmesh-serving
  namespace: modelmesh-serving
spec:
  host: modelmesh-serving
  trafficPolicy:
    loadBalancer:
      dynamicSubset:
        subsetSelectors:
          - fallbackPolicy: ANY_ENDPOINT
            keys:
              - modelmesh.asm.alibabacloud.com
```
上記の宛先ルールは、modelmesh.asm.alibabacloud.com ラベルに基づいて、モデルサービングランタイムを動的にグループ化します。モデルサービスメッシュは、サービングランタイムにロードされたモデルに従って、ランタイムラベルを動的に更新します。
次の内容を使用して、vs-modelmesh-serving-service という名前の仮想サービスの内容を変更します。詳細については、「仮想サービスの管理」をご参照ください。
```
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-modelmesh-serving-service
  namespace: modelmesh-serving
spec:
  gateways:
    - grpc-gateway
  hosts:
    - '*'
  http:
    - headerToDynamicSubsetKey:
        - header: model
          key: modelmesh.asm.alibabacloud.com
      match:
        - port: 8008
      name: default
      route:
        - destination:
            host: modelmesh-serving
            port:
              number: 8033
```
headerToDynamicSubsetKey フィールドは、動的サブセット負荷分散の要件に基づいて上記の仮想サービスに追加されます。ASM ゲートウェイは、推論リクエストの model リクエストヘッダーをリクエストメタデータに変換して、モデルサービスメッシュの動的サブセットと一致させます。

(オプション) ステップ 4：最適化後のモデルサービスメッシュでの推論リクエストの処理レイテンシをテストする

fortio を使用してテストを再度実行し、視覚的な結果を表示します。詳細については、「ステップ 2」をご参照ください。

予期される結果は、ASM の動的サブセット負荷分散を最適化のために有効にした後、すべての推論リクエストのアクセスレイテンシが狭い範囲内に収まり、推論リクエストの処理レイテンシが大幅に短縮されることを示しています。