AI Platform Prediction: カスタム コンテナのコンセプト

このドキュメントでは、AI Platform Prediction のカスタム コンテナを使用して Google Cloud で機械学習(ML)モデルを提供する方法について説明します。

AI Platform Prediction は、Google Cloud のマネージド ML モデルサービス提供プラットフォームです。このプラットフォームは、マネージド サービスとして、インフラストラクチャのセットアップ、メンテナンス、管理を行います。AI Platform Prediction は、CPU と GPU 双方の推論をサポートし、Compute Engine でさまざまな n1-standard ノードの形状を提供しているため、要件に合わせてスケール ユニットをカスタマイズできます。

AI Platform Prediction サービスでは、必要なのはモデル アーティファクトを保存する場所の指定のみであるため、モデルサービスが簡素化されます。ただし、この簡素化により柔軟性が損なわれます。たとえば、サービスに組み込まれたフレームワークにしかサービスを提供できなくなります。カスタム コンテナでは、AI Platform Prediction によって抽象化レベルが下がるので、必要なフレームワーク、モデルサーバー、前処理、後処理を選択できます。

このドキュメントは、Google Cloud 上で高性能なモデルサービス提供プラットフォームを設計、構築、維持する ML エンジニアとアーキテクト向けのシリーズの一部です。

このドキュメントでは、AI Platform Prediction のカスタム コンテナに重点を置いてモデルサービス提供の選択肢について説明します。関連するドキュメントでは、Triton Inference Server と AI Platform Prediction のカスタム コンテナの統合に焦点を当てています。

AI Platform Prediction でカスタム コンテナを使用するタイミング

Google Cloud には、ML モデルを提供するためのオプションがいくつか用意されています。次の表は、予測のニーズに最適なプラットフォームを選択できるように、さまざまな要件に基づく一般的な選択肢を示しています。

予測のニーズ AI Platform Prediction Basic AI Platform Prediction のカスタム コンテナ Google Kubernetes Engine(GKE) Dataflow(予測パイプラインとして使用)
マネージド モデル予測サービス ×
低レイテンシの同期予測 ×
非同期ストリーミング分析 × × ×
バッチ予測 モデルサーバーに応じて異なる
フレームワークの組み込みサポート TensorFlow、scikit-learn、XGBoost なし、ユーザーによるコンテナ化 なし、ユーザーによるコンテナ化 ユーザーによる読み込み
サードパーティのモデルサーバーのサポート × ユーザーによるコンテナ化 ユーザーによるコンテナ化 該当なし
ノード マシンタイプの選択肢 mls1n1-standard n1-standard GKE でサポートされているすべて Dataflow でサポートされているすべて
GPU のサポート
モデルサーバーの外部でのカスタム処理 カスタム予測ルーティン 該当なし

以下のセクションでは、選択肢の検討に役立つ情報をさらに詳しく説明します。

有効化

モデルが提供された後にどのように消費されるのかを考慮することは重要です。通常、トランザクション リスクや広告配信などのアプリケーションには、同期オンライン予測が求められ、レイテンシが特に重要になります。一般に、お客様のライフタイム バリュー(CLV)の予測と推奨事項は、大規模で定期的なバッチでより効果的に処理されます。予測メンテナンス ユースケースは、通常、非同期的にテレメトリーをストリーミングします。その際、ユーザーはモデルを使用して失敗条件を特定します。すると予測は、テレメトリーの送信者ではない情報集約アプリケーションで消費されている場合があります。どの提供プラットフォームを選択するべきかは、どのようにモデルが消費されるかによって異なります。

コンピューティングのサポート

AI Platform Prediction Basic は、mls1n1-standard の両方のマシンタイプをサポートしています。AI Platform Prediction のカスタム コンテナは n1-standard マシンタイプをサポートしています。最適なパフォーマンスを得るために、n1-standard マシンタイプのみを検討してください。

インフラストラクチャ レベルで予測プラットフォームを管理することに抵抗がなく、アプリケーションがステートレスで、無効になったリクエストを再試行するように設計されている場合は、プリエンプティブル ノードがある GKE を使用できます。プリエンプティブル ノードを使用すると、コンピューティングの費用を削減できます。ただし、プリエンプティブル ノードは最大 24 時間しか持続しない点に留意してください。本番環境でプリエンプティブル ノードを使用する場合は、ノードの消失を許容できるワークロードのみをデプロイしてください。チェックポインティングを使用した再起動可能なオフライン ジョブは、プリエンプティブル ノードに適しています。

サードパーティのモデルサーバー

Triton Inference Server や Facebook TorchServe などのカスタムモデル サーバーが必要な場合は、コンテナから直接サービスを提供できる予測プラットフォームを選択するか、カスタムモデルのサーバーを読み込む必要があります。

フレームワークの組み込みサポート

AI Platform Prediction Basic は、TensorFlowXGBoostscikit-learn を直接サポートするマネージド予測サービスです。サポートされているフレームワークとフレームワークのバージョンがモデルを直接提供できる場合は、AI Platform Prediction Basic をおすすめします。

データの前処理と後処理

予測のモデルをデプロイするときに、データの形がモデルのトレーニングに使用されたデータの形と一致することはほとんどありません。これはトレーニング / サービング スキューと呼ばれ、このために、モデルが予測リクエストを処理する前にデータを前処理する必要が生じます。予測された結果は、通常、なんらかの後処理でも使用されます。可能であれば、モデルに処理オペレーションを追加することをおすすめします。TensorFlow などのフレームワークは、サービング グラフにオペレーションを追加できます。これにより、ホップが減少するため、環境を簡素化できるだけでなく、パフォーマンスも向上します。

処理をモデルグラフに組み込むことができない場合もあります。たとえば、XGBoost で前処理を使用している場合や、前処理が PyTorch でトレーニングされたモデルで、分類が TensorFlow でトレーニングされたモデルである場合などです。AI Platform Prediction のカスタム予測ルーティンでは、このような前処理コードを挿入できますが、パフォーマンス上の理由からカスタム コンテナを使用することをおすすめします。カスタム予測ルーティンだと余分なホップが追加されてしまいます。そのうえ、余分なノードがパフォーマンスの低い mls1 型になります。

AI Platform Prediction でのカスタム コンテナのアーキテクチャ

次の図は、AI Platform Prediction のカスタム コンテナの中核となるコンポーネントを示しています。

コア コンポーネントには、コンテナ イメージ、後処理または前処理コード、モデル、モデルストアなどが含まれる。

以降のセクションでは、上の図で示した重要なコンセプトについて説明します。

ベースイメージ

モデルサーバーのベースイメージであるカスタム コンテナ イメージ(A)またはモデルサーバーのベースイメージから派生したイメージを指定します。AI Platform Prediction: NVIDIA Triton Inference Server の直接モデルサーバーの設定で提供されている例では、モデルサーバーは Triton Inference Server です。

前処理と後処理のコード

カスタムのルーティングや処理などの特別なコード(B)が必要な場合、新しい Dockerfile を使用してそれらのアーティファクトをコンテナに組み込むことができます。前処理コードは、受信リクエストをリッスンし、前処理を適用してから、前処理されたリクエストをモデルサーバーに渡します。後処理コードは、結果を実行し、クライアントに返す必要があります。

モデルストア

モデルの保管場所を選択するにあたっては、次の 2 つのオプションがあります。

  • Cloud Storage でモデルのアーティファクトへのパスを指定する。Cloud Storage から直接読み取りができるモデルサーバーには、このオプション(C)を使用することをおすすめします。これにより、新しいコンテナを作成する必要なく新しいモデル バージョンをデプロイできます。
  • モデル アーティファクトをコンテナに直接コピーする。このオプション(D)は、Cloud Storage から直接読み取りができないモデルサーバー向けです。このオプションでは、新しいモデル バージョンをデプロイするたびに新しいコンテナが必要になります。

モデル

AI Platform Prediction は、モデルとモデル バージョンに基づくアーキテクチャ パラダイムを使用します。ここで、モデルはモデル バージョンの論理グループです。通常、このパラダイムは継続的にトレーニングされます。特定のモデル用に設計されたアプリケーションはそのモデルを使用しますが、時間の経過とともにモデルが再トレーニングされると、新しいモデル バージョンを採用します。

モデル バージョン

AI Platform Prediction のモデル バージョンは、特定のデータセット、構成、ハイパーパラメータを使用してトレーニングされたモデルのインスタンスです。AI Platform Prediction では、モデル バージョンは不変として扱われます。モデルを更新する必要がある場合(新しいデータセットでモデルを再トレーニングする場合など)は、新しいモデル バージョンを作成してロールアウトする必要があります。モデル バージョンを使用すると、カナリア ロールアウトを簡素化できます。モデル バージョンはモデル内に存在するため、モデル バージョンを作成する前にモデルを作成する必要があります。

カスタム コンテナ

カスタム コンテナ(E)はモデル バージョンのインスタンスです。カスタム コンテナはカスタム コンテナ イメージから作成します。

推論クライアント

モデルサーバーを構成すると、推論クライアント(F)は AI Platform Prediction と通信します。

カスタム コンテナ パターン

このシリーズでは、カスタム コンテナの 2 つの一般的なアーキテクチャ パターン(直接モデルサーバー パターンと、リスナーを含むモデルサーバーのパターン)について説明します。リスナー パターンには、カスタムの前処理と後処理を含めることができます。次の表は、ニーズに最適なモデル提供パターンを選択できるように、各パターンでサポートされるユースケースを示しています。

予測のニーズ 直接モデルサーバー リスナーを含むモデルサーバー
シンプルなデプロイ ×
可能な限り低いレイテンシ 処理によって異なる
シングルモデルのサポート
複数モデルのスタック ×
モデルサーバーの外部での複雑な前処理と後処理 ×
ルーティングのカスタマイズまたは方法の選択 ×

以降のセクションでは、2 つのコンテナ パターンについて説明します。

直接モデルサーバー

次の図に示すように、直接モデルサーバー パターンは、中間接続なしで AI Platform からモデルサーバーに直接アクセスします。

モデルサーバーはカスタム コンテナに保存され、直接アクセスされる。

このパターンは、次のような要件があるときに有効です。

  • 1 つの予測ルート。モデルサーバーによっては、1 つ以上のモデルをサポートするには、複数のルートが必要な場合があります。モデルを 1 つしか提供しない場合、または 1 つの予測ルートのみを使用してモデルサーバーを管理できる場合は、直接モデルサーバー パターンがおすすめです。通常、このパターンの構成が最も簡単です
  • 低レイテンシ。AI Platform とモデルサーバーとの間の直接的な通信により、中間で引き起こされる可能性のある遅延が排除されます。
  • モデルの前処理と後処理をカプセル化する機能。TensorFlow などのフレームワークでは、前処理と後処理のオペレーションをコンピューティング グラフに追加できます。一般に、このアプローチはプロセス全体でメモリ マーシャリングを最小限にするため、前処理と後処理を処理する方法として最も効率的です。Triton Inference Server などの一部のモデルサーバーは、あるモデルの出力が別のモデルの入力として使用できるアンサンブル モデリングを提供しています。この機能により、モデルサーバー内のアップストリームの前処理とダウンストリームの後処理が可能になります。

リスナーを含むモデルサーバー

このパターンでは、次の図に示すように、AI Platform とモデルサーバー間のリスナーを設定します。

カスタム コンテナには、モデルサーバーと、前処理コードまたは後処理コードを含むリスナーが保存されます。

このパターンは、次の処理を行う場合に便利です。

  • 複雑なルーティングや複数モデルのスタッキング。一部のモデルサーバーは同じインスタンス内の複数のモデルをサポートしており、モデルにアクセスするには別のルートが必要です。通常、予測ルートを多重化するには、リスナーと、別の場所(ヘッダーなど)に埋め込まれた宛先のルート情報が必要になります。
  • 複雑な前処理と後処理。前処理と後処理のロジックを埋め込めない一部のフレームワークには、推論プロセスの範囲外の処理が必要です。また、前処理の手順で別のサービスへの外部呼び出しが必要になる場合もあります。このようなパターンは、グラフに含めるのが困難または不可能になります。
  • 推論フォーマットの変換。複数のモデルサーバーをまたいでさまざまなフォーマットをサポートするには、リスナーを使用してフォーマット変換を行います。

リスナーはモデルサーバーと AI Platform の間にあるため、プロセスのレイテンシが増加することを理解することが重要です。このレイテンシの影響は、負荷の重いモデルよりも負荷の軽いモデルの方が大きくなります。たとえば、負荷が重いディープ ラーニング モデルの推論時間が 50 ミリ秒(ms)で、20 ms の前処理を行う場合、その 20 ms は 40% の増加となります。同じ 20 ms を負荷の軽い XGBoost モデルの 10 ms の推論時間に追加する場合、その 20 ms は 200% の増加となります。

モデルとモデル バージョンの計画

AI Platform Prediction は、プロジェクト モデルのバージョンの階層でモデル アーティファクトを整理します。たとえば、1 つの企業が複数の Google Cloud プロジェクトを持っているとします。各プロジェクトには複数のモデルがあり、各モデルには複数のモデル バージョンがあります。この場合、構造は次のようになります。

  • サンプルの組織
    • SalesOps プロジェクト
      • CustomerPropensity モデル
        • v20201131 モデル バージョン
        • v20201107 モデル バージョン
        • v20201009 モデル バージョン

モデルとモデル バージョンについて詳しくは、予測の概要をご覧ください。

モデル バージョンを作成する前に、モデルを作成する必要があります。モデルを作成する REST リクエストの形式は次のとおりです。

POST -d "{'name': 'MODEL_NAME'}" \
    ENDPOINT/projects/PROJECT_ID/models/

このリクエストには次の値が含まれます。

  • MODEL_NAME: 作成するモデルの名前(例: buyer_recommendation
  • ENDPOINT: https://ml.googleapis.com/v1 の AI Platform サービス
  • PROJECT_ID: このモデルを作成する Google Cloud プロジェクト

次の POST リクエストを使用して、このモデルに後続のモデル バージョンを作成できます。

POST -d @version_spec.json \
    ENDPOINT/projects/PROJECT_ID/models/MODEL_NAME/versions

詳細については、AI Platform Prediction リファレンスの REST コマンドをご覧ください。

以下に、Triton Inference Server のサンプル version_spec.json ファイルを示します。

{
  "name": "v3",
  "deployment_uri": "gs://model-artifacts-source-location",
  "container": {
    "image": "gcr.io/my_project/triton:20.06",
    "args": ["tritonserver",
             "--model-repository=$AIP_STORAGE_URI"
    ],
    "env": [
    ],
    "ports": [
      { "containerPort": 8000 }
    ]
  },
  "routes": {
    "predict": "/v2/models/$AIP_MODEL_NAME/infer",
    "health": "/v2/models/$AIP_MODEL_NAME"
  },
  "machine_type": "n1-standard4",
  "acceleratorConfig": {
    "count":1,
    "type":"nvidia-tesla-t4"
  },
  "autoScale": {
    "minNodes":1
  }
}

次の表に、上記の JSON 仕様の要素を示します。

要素(* は必須) 説明
name* モデル バージョン名。
deployment_uri Cloud Storage 内のモデルの場所。モデル バージョンが作成されると、AI Platform はこの場所からアーティファクトをコピーして、AIP_STORAGE_URI 環境変数で使用できるようになります。
container:image* コンテナ イメージのパス。
container:args コンテナの起動時に使用するコマンドと引数。
container:env 環境変数。これらのユーザー指定の環境変数は、実行時にコンテナで使用可能になります。
container:ports* AI Platform がコンテナとの通信に使用するネットワーク ポート。ポートが指定されていない場合、デフォルトのポートは 8080 です。
routes:predict

AI Platform が予測リクエストをコンテナに転送するために使用するコンテナ エンドポイントのルート。この要素が存在しない場合、デフォルトで次のエンドポイントのルートが使用されます。

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME:predict

routes:health

AI Platform がモデル バージョン コンテナの正常性を確認するために使用するコンテナ エンドポイントのルート。レスポンスに成功した後(HTTP GET を含むコンテナからの 200 HTTP ステータス コード)でのみ、モデル バージョンのこのインスタンスにトラフィックが送信されます。この要素が指定されていない場合、デフォルトで次のエンドポイントのルートが使用されます。

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME

machine_type* 推論ノードの仮想マシンタイプ。
acceleratorConfig:Count GPU が必要な場合、各ノードの GPU の数。
acceleratorConfig:Type GPU が必要な場合、GPU のタイプ。
autoScale:minNodes 自動スケーリング モードでの最小ノード。この要素は manualScale 要素では使用できません。
manualScale:nodes 手動スケーリング モードでのノード数。この要素は autoScale 要素では使用できません。

spec.json の接頭辞が AIP_ の環境変数が存在するのは、モデル バージョン コンテナの作成後だけです。上記のサンプル version_spec.json ファイルから、以下を考慮します。

  • $AIP_STORAGE_URIモデル バージョンを作成すると、AI Platform は deployment_uri からモデル アーティファクトをコピーします。コンテナはオンラインになると、そのモデルアセットの $AIP_STORAGE_URI を探します。サンプルでは、Triton Inference Server モデル リポジトリのフラグを --model-repository=$AIP_STORAGE_URI として定義します。
  • $AIP_MODEL_NAMETriton Inference Server や TorchServe などのモデルサーバーは複数のモデルを同時にサポートし、リクエストの推論を実行するモデルを指定するためのリクエスト エンドポイント パスを求めます。この環境の値は、モデル バージョンの作成時に ${MODEL_NAME} から取得されます。

次の表に、コンテナで使用できるいくつかの一般的な AIP_ 環境変数を示します。

環境変数 説明
AIP_PROJECT_NUMBER モデルが作成されるプロジェクトのプロジェクト番号。
AIP_MODEL_NAME モデル バージョンが作成されるモデルの名前。名前は、モデルの作成に使用する POST コマンド${MODEL_NAME} 値から取得されます。
AIP_VERSION_NAME モデル バージョンの名前。モデル バージョンの名前は、モデルの作成に使用する前述の JSON 仕様name 値から取得されます。
AIP_HTTP_PORT AI Platform が通信するカスタム コンテナ内のリスナーのターゲット ポート。リスナーは、モデルサーバー自体、またはモデルサーバーにアップストリームされるデータ前処理などの中間コンポーネントです。このポートは、前述の JSON 仕様container:ports から取得されます。
AIP_PREDICT_ROUTE AI Platform がカスタム コンテナと通信するときに予測リクエストを転送するためのルート。このルートは、前述の JSON 仕様routes:predict から取得されます。
AIP_HEALTH_ROUTE AI Platform がカスタム コンテナの健全性の確認に使用するルート。このルートは、前述の JSON 仕様routes:health から取得されます。
AIP_STORAGE_URI 前述の JSON 仕様deployment_uri からモデルアセットがコピーされる場所。この環境変数は、モデルサーバーがモデル アーティファクトを検索する場所を定義します。

次のステップ