カスタム コンテナーを使用してモデルをオンライン エンドポイントにデプロイする

適用対象:Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)

カスタム コンテナーを使用して、Azure Machine Learning のオンライン エンドポイントにモデルをデプロイする方法について学びます。

カスタム コンテナーのデプロイでは、Azure Machine Learning によって使用される既定の Python Flask サーバー以外の Web サーバーを使用できます。 これらのデプロイのユーザーは、Azure Machine Learning の組み込みの監視、スケーリング、アラート、認証を引き続き利用できます。

次のテーブルに、TensorFlow Serving、TorchServe、Triton Inference Server、Plumber R パッケージ、Microsoft Azure Machine Learning Inference Minimal イメージなどのカスタム コンテナーを使用するさまざまなデプロイ例を示します。

スクリプト (CLI) 説明
minimal/multimodel deploy-custom-container-minimal-multimodel Azure Machine Learning Inference Minimal のイメージを拡張して、複数のモデルを単一のデプロイに配置します。
minimal/single-model deploy-custom-container-minimal-single-model Azure Machine Learning Inference Minimal のイメージを拡張して、単一のモデルをデプロイします。
mlflow/multideployment-scikit deploy-custom-container-mlflow-multideployment-scikit Azure Machine Learnin Inference Minimal のイメージを使用して、異なる Python 要件を持つ 2 つの MLFlow モデルを、単一のエンドポイントの背後にある 2 つの個別のデプロイに配置します。
r/multimodel-plumber deploy-custom-container-r-multimodel-plumber Plumber R パッケージを使用して 3 つの回帰モデルを 1 つのエンドポイントに配置する
tfserving/half-plus-two deploy-custom-container-tfserving-half-plus-two 標準モデル登録プロセスを使用して TensorFlow Serving カスタム コンテナーを使用して、Half Plus Two モデルを配置します。
tfserving/half-plus-two-integrated deploy-custom-container-tfserving-half-plus-two-integrated モデルをイメージに統合した TensorFlow Serving カスタム コンテナーを使用して、シンプルな Half Plus Two モデルを配置します。
torchserve/densenet deploy-custom-container-torchserve-densenet TorchServe カスタム コンテナーを使用して単一のモデルを配置します。
triton/single-model deploy-custom-container-triton-single-model カスタム コンテナーを使用して、Triton モデルをデプロイする

この記事では、TensorFlow Serving を使用した TensorFlow (TF) モデルの提供に焦点を当てています。

警告

Microsoft では、カスタム イメージが原因で発生した問題のトラブルシューティングを行うことができない場合があります。 問題が発生した場合は、問題がイメージに固有のものであるかどうかを確認するために、既定のイメージ、または Microsoft が提供するイメージのいずれかを使用するように求められることがあります。

前提条件

この記事の手順に従う前に、次の前提条件が満たされていることをご確認ください。

  • ユーザーまたは使用するサービス プリンシパルには、ワークスペースを含む Azure リソース グループへの 共同作成者アクセス権が必要です。 クイックスタートの記事に従ってワークスペースを構成していれば、そのようなリソース グループが得られます。

  • ローカルに展開するには、Docker エンジンをローカルで実行する必要があります。 この手順は強くお勧めします。 これは、問題のデバッグに役立ちます。

ソース コードのダウンロード

このチュートリアルに従うには、GitHub からソース コードを複製してください。

git clone https://github.com/Azure/azureml-examples --depth 1
cd azureml-examples/cli

環境変数を初期化する

環境変数を定義します。

BASE_PATH=endpoints/online/custom-container/tfserving/half-plus-two
AML_MODEL_NAME=tfserving-mounted
MODEL_NAME=half_plus_two
MODEL_BASE_PATH=/var/azureml-app/azureml-models/$AML_MODEL_NAME/1

TensorFlow モデルをダウンロードする

入力を 2 で除算して結果に 2 を加算するモデルをダウンロードして解凍します。

wget https://aka.ms/half_plus_two-model -O $BASE_PATH/half_plus_two.tar.gz
tar -xvf $BASE_PATH/half_plus_two.tar.gz -C $BASE_PATH

TF Serving イメージをローカル環境で実行して動作することをテストする

docker を使用して、テストのためにローカル環境でイメージを実行します。

docker run --rm -d -v $PWD/$BASE_PATH:$MODEL_BASE_PATH -p 8501:8501 \
 -e MODEL_BASE_PATH=$MODEL_BASE_PATH -e MODEL_NAME=$MODEL_NAME \
 --name="tfserving-test" docker.io/tensorflow/serving:latest
sleep 10

イメージに liveness とスコアリングの要求を送信できることを調べる

最初に、コンテナーが "アライブ" であること、つまりコンテナー内部のプロセスがまだ実行されていることを確認します。 200 (OK) 応答を受け取る必要があります。

curl -v http://localhost:8501/v1/models/$MODEL_NAME

次に、ラベル付けされていないデータに関する予測を取得できることを確認します。

curl --header "Content-Type: application/json" \
  --request POST \
  --data @$BASE_PATH/sample_request.json \
  http://localhost:8501/v1/models/$MODEL_NAME:predict

イメージを停止する

ローカル環境でのテストが済んだので、イメージを停止します。

docker stop tfserving-test

オンライン エンドポイントを Azure にデプロイする

次に、オンライン エンドポイントを Azure にデプロイする

エンドポイントおよびデプロイ用の YAML ファイルを作成する

YAML を使用してクラウド デプロイを構成できます。 この例で使用する YAML の例をご覧ください。

tfserving-endpoint.yml

$schema: https://azuremlsdk2.blob.core.windows.net/latest/managedOnlineEndpoint.schema.json
name: tfserving-endpoint
auth_mode: aml_token

tfserving-deployment.yml

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: {{MODEL_VERSION}}
  path: ./half_plus_two
environment_variables:
  MODEL_BASE_PATH: /var/azureml-app/azureml-models/tfserving-mounted/{{MODEL_VERSION}}
  MODEL_NAME: half_plus_two
environment:
  #name: tfserving
  #version: 1
  image: docker.io/tensorflow/serving:latest
  inference_config:
    liveness_route:
      port: 8501
      path: /v1/models/half_plus_two
    readiness_route:
      port: 8501
      path: /v1/models/half_plus_two
    scoring_route:
      port: 8501
      path: /v1/models/half_plus_two:predict
instance_type: Standard_DS3_v2
instance_count: 1

この YAML または Python パラメーターには、注意すべき重要な概念がいくつかあります。

ベース イメージ

基本イメージは、環境内のパラメーターとして指定され、この例では docker.io/tensorflow/serving:latest が使用されています。 コンテナーを調べると、このサーバーが ENTRYPOINT を使用してエントリ ポイント スクリプトを開始していることがわかります。これにより、MODEL_BASE_PATHMODEL_NAME のような環境変数を受け取り、8501 のようなポートを公開します。 これらの詳細はすべて、この選択したサーバーの特定の情報です。 サーバーに関するこの理解に基づいて、デプロイを定義する方法を決定できます。 たとえば、デプロイ定義で MODEL_BASE_PATHMODEL_NAME の環境変数を設定した場合、サーバー (この場合は TF Serving) はサーバーを開始するための値を受け取ります。 同様に、デプロイ定義でルートのポートを 8501 に設定すると、該当するルートへのユーザー要求が TF Serving サーバーに正しくルーティングされます。

この具体的な例は TF Serving のケースに基づいていますが、稼働状態を維持し、liveness、readiness、スコアリング ルートに関する要求に応答する任意のコンテナーを使用できることに注意してください。 他の例を参照して、コンテナーを作成するために dockerfile がどのように構成されているか (たとえば、ENTRYPOINT の代わりに CMD を使用しているなど) を確認できます。

推論の構成

推論構成は環境内のパラメーターであり、3 種類のルート (liveness、readiness、スコアリング ルート) のポートとパスを指定します。 マネージド オンライン エンドポイントを使用して独自のコンテナーを実行する場合は、推論構成が必要です。

readiness ルートと liveness ルート

選択した API サーバーによって、サーバーの状態を確認する方法が提供される場合があります。 指定できるルートには、livenessreadiness の 2 種類があります。 liveness ルートは、サーバーが実行されているかどうかを調べるために使用されます。 readiness ルートは、サーバーが作業を行う準備ができているかどうかを調べるために使用されます。 機械学習推論のコンテキストでは、サーバーはモデルを読み込む前に liveness 要求に対して 200 OK を応答でき、また、サーバーはモデルがメモリに読み込まれた後でのみ、readiness 要求に対して 200 OK を応答できます。

一般的な liveness および readiness probe の詳細については、Kubernetes のドキュメントを参照してください。

liveness および readiness ルートは、前の手順でコンテナーをローカルでテストするときに特定したように、選択した API サーバーによって決定されます。 この記事のデプロイ例では、TF Serving で liveness ルートだけが定義されているため、liveness と readiness の両方に同じパスを使用することに注意してください。 ルートを定義するさまざまなパターンについては、他の例を参照してください。

スコアリング ルート

選択した API サーバーによって、作業するペイロードを受け取る方法が提供されます。 機械学習推論のコンテキストでは、サーバーは特定のルートを介して入力データを受信します。 API サーバーのこのルートは、前の手順でコンテナーをローカルでテストするときに特定し、作成するデプロイを定義するときに指定します。 デプロイが正常に作成されると、エンドポイントのscoring_uri パラメーターも更新されることに注意してください。これは az ml online-endpoint show -n <name> --query scoring_uri を使用して確認できます。

マウントされたモデルの配置

モデルをオンライン エンドポイントとしてデプロイすると、Azure Machine Learning によってモデルがエンドポイントに "マウント" されます。 モデルがマウントされると、新しい Docker イメージを作成することなく、モデルの新しいバージョンをデプロイできます。 既定では、名前 foo およびバージョン 1 で登録されたモデルは、デプロイされたコンテナーの内部の次のパスに配置されます: /var/azureml-app/azureml-models/foo/1

たとえば、ローカル コンピューター上にディレクトリ構造 /azureml-examples/cli/endpoints/online/custom-container があり、モデルの名前 がhalf_plus_two 場合は、次のようになります。

ローカル ディレクトリ構造のツリー ビューを示す図。

tfserving-deployment.yml には次のものが含まれます。

model:
    name: tfserving-mounted
    version: 1
    path: ./half_plus_two

その後、デプロイの /var/azureml-app/azureml-models/tfserving-deployment/1 の下にモデルが配置されます。

配置ディレクトリ構造のツリー ビューを示す図。

必要に応じて、model_mount_path を構成することもできます。 これにより、モデルがマウントされているパスを変更できます。

重要

model_mount_path には、Linux (コンテナー イメージの OS) で有効な絶対パスを指定してください。

たとえば、以下のように tfserving-deployment.ymlmodel_mount_path パラメーターを含めることができます。

name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: 1
  path: ./half_plus_two
model_mount_path: /var/tfserving-model-mount
.....

その後、デプロイの /var/tfserving-model-mount/tfserving-deployment/1 にモデルが配置されます。 azureml-app/azureml-models ではなく、ご自分で指定したマウント パスの下に配置されます。

mount_model_path を使用した場合の配置ディレクトリ構造のツリー ビューを示す図

エンドポイントとデプロイを作成する

YAML の構築方法がわかったので、ご自分でエンドポイントを作成してください。

az ml online-endpoint create --name tfserving-endpoint -f endpoints/online/custom-container/tfserving-endpoint.yml

デプロイの作成には数分かかる場合があります。

az ml online-deployment create --name tfserving-deployment -f endpoints/online/custom-container/tfserving-deployment.yml --all-traffic

エンドポイントを呼び出す

デプロイが完了したら、デプロイされたエンドポイントにスコアリング要求を行うことができるかどうかを確認します。

RESPONSE=$(az ml online-endpoint invoke -n $ENDPOINT_NAME --request-file $BASE_PATH/sample_request.json)

エンティティを削除する

エンドポイントで正常にスコアリングできたので、それを削除できます。

az ml online-endpoint delete --name tfserving-endpoint