ライブデプロイを設定して使用する

ライブデプロイは、API エンドポイントを介して操作できる、リリース用の永続的でスケーラブルなデプロイです。 ライブデプロイは、モデリング目標内でバッチデプロイとともに管理でき、自動アップグレード、観測可能性、権限構造によるメリットをすべて同様に受けられます。ライブデプロイは、目標を必要とせず、モデルページで直接設定することもできるようになりました。

要件

新しいライブデプロイを作成する前に、モデリング目標に、対応するタグ（ステージングまたは本番）が付いた既存のリリースが含まれている必要があります。

デプロイを作成する

新しいライブデプロイを作成するには、モデリング目標の下部にあるデプロイセクションに移動し、青い + デプロイを作成するボタンを選択します。

デプロイ名と説明を入力し、このデプロイのベースとなるモデルを、現在ステージングにリリースされているモデルと本番にリリースされているモデルのどちらにするかを指定します。設定が完了したら、デプロイを作成するを選択します。

新しく作成したデプロイを選択して詳細を開くと、最新のリリースと推論コードを含むコンテナイメージがデプロイされていることを示す、処理中のステータスが表示されます。

関数を公開する

デプロイ用の関数を公開すると、Workshop、Vertex、その他のエンドユーザー向けアプリケーションで、ライブ推論にモデルを使用できるようになります。

関数を公開するには、デプロイの詳細ページに移動し、関数を公開を選択します。これにより、モデルと同じ入力および出力 API を持つラッパー関数が作成されます。この関数を関数リポジトリからインポートして呼び出すことで、カスタムのビジネスロジックを追加できます。

関数の動作、バージョンアップグレード、設定オプションの詳細については、モデル関数開発者ガイドを参照してください。

ステータスと健全性

デプロイの更新が完了すると、ステータスと健全性の両方に緑色のチェックマークが表示されるはずです。これらは、デプロイがクエリを受け付ける準備が整い、最新のリリース済みモデルを含むように正常に更新されたことを示します。

ライブデプロイをテストする

デプロイの詳細ページのクエリタブに移動すると、ライブデプロイのエンドポイントをテストできます。入力リクエストを作成してライブエンドポイントに送信し、モデルの出力レスポンスを表示できます。クエリには、単一 I/O と複数 I/O の2種類があります。

単一 I/O クエリは単一の表形式の入出力のみをサポートし、複数 I/O クエリはモデルアセットで定義された ModelAdapter API のみをサポートします。モデルアセットは単一 I/O と複数 I/O の両方のクエリをサポートしますが、データセットを元にしたデプロイは単一 I/O クエリのみをサポートします。

コマンドの例

以下は、transform エンドポイントで単一 I/O を使用し、curl を介してライブデプロイにクエリを実行する例です。

Copied!
1
2
3
4
curl -X POST https://<URL>/foundry-ml-live/api/inference/transform/ri.foundry-ml-live.main.live-deployment.<RID>
-H "Authorization: <BEARER_TOKEN>" -H "Accept: application/json" -H "Content-Type: application/json" -d
'{"requestData":[{"house-location":"New York", "bedrooms":3,"bathrooms":1.5}],
 "requestParams":{}}'

また、以下の例では、transformV2 エンドポイントで複数 I/O を使用し、curl を介してライブデプロイにクエリを実行する方法を示します。

Copied!
1
2
3
curl -X POST https://<URL>/foundry-ml-live/api/inference/transform/ri.foundry-ml-live.main.live-deployment.<RID>/v2
-H "Authorization: <BEARER_TOKEN>" -H "Accept: application/json" -H "Content-Type: application/json" -d
'{"input_df":[{"house-location":"New York", "bedrooms":3,"bathrooms":1.5},{"house-location":"San Francisco", "bedrooms":2,"bathrooms":1}]}'

デプロイの操作

管理操作

実行中のライブデプロイには、次の2つの操作を行えます。

• 無効にするを選択すると、デプロイを停止しますが、再び有効にして同じ Target RID を利用できます。
• 削除を選択すると、デプロイを完全に削除します。以前の Target RID に対してクエリを実行できなくなります。

無効にしたライブデプロイは、引き続き目的のデプロイページに表示され、再び有効にできます。

リソース設定

ライブデプロイには、最小および最大レプリカ数の範囲と、CPU および GPU の数を設定します。これにより、リクエスト量に基づく自動水平スケーリングが可能になります。

リソース要件は、デプロイの作成時に設定できるほか、作成後にも編集できます。ランタイム設定を編集すると、デプロイの再実行が自動的にトリガーされ、ダウンタイムなしでエンドポイントがアップグレードされます。

新しいライブデプロイを設定するには、デプロイを作成するを選択し、デプロイタイプでライブを選択してから、最小および最大レプリカ数の範囲とリソース設定を入力します。

設定済みのレプリカ数の範囲とリソースを編集するには、モデリングプロジェクトのデプロイセクションに移動し、一覧からデプロイを選択して、ランタイム設定の下にある編集ボタンを選択します。

デプロイのサービスログを表示する

各ライブデプロイから、デプロイの起動の進行状況を示す一連のログが発行されます。これらのログには、デプロイがダウンロードとインストールを試みるリリース環境内の Conda パッケージの URI や、モデル自体のダウンロードに関する詳細が含まれます。デプロイの起動に失敗した場合は、関連する警告レベルまたはエラーレベルのログが、何が起きたかを把握するのに役立つことがあります。

実行中のライブデプロイからサービスログを直接表示するには、デプロイの詳細ページでログとメトリクスタブに移動します。検索対象の時間ウィンドウを指定したり、任意のフィールドでログを絞り込んだり、表示する列を追加または削除したりできます。また、右上隅のダウンロードボタンを使って、すべてのログをテキストファイルとしてダウンロードできます。

デプロイを複数のレプリカで実行するように設定している場合、一見重複したログが表示されることがあります。各ログのまとまりは、異なるレプリカから発行されたものです。ただし、各ログには一意の node_id を持つタグが含まれており、必要に応じてレプリカで絞り込むために使用できます。このためには、次の表記法を使用できます。

Copied!
1
tags.node_id:{Insert UUID here}

モデルから直接ログを発行するには、Python の標準 logging モジュールを使用できます。ライブデプロイでは、各ログ行をログとメトリクスタブからクエリできます。

Copied!
1
2
3
4
import logging

log = logging.getLogger('model-logger')
log.info("Emitting info directly from the model")

コンテナを基盤とするモデルからログを発行するには、モデルバージョンの設定時にテレメトリを有効にします。

ライブデプロイのログの保持期間は7日間です。この期間を過ぎると、表示もダウンロードもできなくなります。

デプロイのメトリクスを表示する

ログとメトリクスタブでは、Kubernetes ホストと推論コンテナの2種類のメトリクスを利用できます。モデルを適切に監視し、デバッグするために、これらのメトリクスの種類の違いを理解してください。

Kubernetes ホストのメトリクス

Kubernetes ホストのメトリクスは、特定のモデルに関連するプロセスだけではなく、ホスト上で実行されているすべてのプロセスによるメモリーおよび CPU の使用率を示します。これらのメトリクスは、スケジューリングやリソースのスロットリングに関する問題のデバッグに重要です。たとえば、モデルの処理が遅く、ホストのメトリクスが100%に達している場合、モデルが Kubernetes ホストによってスロットリングされている可能性があります。

推論コンテナのメトリクス

推論コンテナのメトリクスは、Python モデルとモデルアダプターのロジックにおけるリソース使用量のデバッグに役立ちます。これらのメトリクスは、Kubernetes ホスト全体とは独立して、推論コンテナの正確なメモリー使用量と CPU コア使用量を示します。現在、コンテナベースのモデルでは使用量のメトリクスは利用できません。

Spark モデルのサポート

現在、すべてのライブデプロイは、JDK と Spark ディストリビューションの両方がインストールされた状態で初期化されます。これにより、Spark モデルをライブデプロイで使用できます。この対話型環境ではローカル Spark のみがサポートされるため、すべての処理は単一の JVM 内で行われます。

モデルが Spark DataFrame の入力を想定している場合、リクエストは JSON として送信されるため、データ変換の問題が発生しやすくなります。Spark DataFrame を想定するカスタムモデルを開発する際は、前処理段階または transform 関数内で直接、この変換を手動で行う必要があります。以下に簡単な例を示します。

Copied!
1
2
3
4
5
6
7
import pandas as pd
from pyspark.sql import SparkSession

def _transform(model, df):
    if isinstance(df, pd.DataFrame):
        df = SparkSession.builder.getOrCreate().createDataFrame(df)
    return model.predict_spark_df(df)