オンライン予測ロギングを使用する

AutoML 表形式モデル、AutoML 画像モデル、カスタム トレーニング モデルの場合、モデルのデプロイまたはエンドポイントの作成中に予測ログを有効または無効にできます。このページでは、さまざまな種類の予測ログと、それらのログを有効または無効にする方法を説明します。

予測ログの種類

予測ノードから情報を取得するために、いくつかの予測ログを使用できます。

  • コンテナ ロギング。予測ノードから Cloud Logging に stdout ストリームと stderr ストリームが記録されます。これらのログはデバッグに必要です。

    • v1 サービス エンドポイントでは、コンテナ ロギングがデフォルトで有効になっています。モデルをデプロイするときに無効にできます。また、デプロイしたモデルを変更するときに、ロギングを無効または有効にすることもできます。

    • v1beta1 サービス エンドポイントでは、コンテナ ロギングがデフォルトで無効になっています。モデルをデプロイするときに有効にできます。また、デプロイしたモデルを変更するときに、ロギングを無効または有効にすることもできます。

  • アクセス ロギング。Cloud Logging に各リクエストのタイムスタンプやレイテンシなどの情報が記録されます。

    v1 と v1beta1 のサービス エンドポイントの両方で、アクセス ロギングはデフォルトで無効になっています。エンドポイントにモデルをデプロイするときに、アクセス ロギングを有効にできます。

  • リクエスト / レスポンス ロギング。オンライン予測リクエストとレスポンスのサンプルが BigQuery テーブルに記録されます。

    リクエスト / レスポンス ロギングを有効にするには、予測エンドポイントを作成するか、パッチを適用します。

各タイプのログを個別に有効または無効にできます。

予測ログの設定

エンドポイントの作成時、エンドポイントへのモデルのデプロイ時、デプロイしたモデルの変更時、オンライン予測ログを有効または無効にできます。

アクセスログの設定を更新するには、モデルのデプロイを解除してから、新しい設定でモデルを再デプロイする必要があります。モデルを再デプロイすることなく、コンテナログの設定を更新できます。

秒間クエリ数（QPS）が非常に多いオンライン予測の場合、かなりの数のログが生成される可能性があります。これらのログには Cloud Logging の料金が適用されます。オンライン予測ログの料金を見積もるには、ロギングの請求の見積もりをご覧ください。この費用を減らすには、予測ロギングを無効にします。

予測ログを有効または無効にする

次の例では、デフォルトのログ設定を変更する場所がハイライト表示されています。

コンソール

Google Cloud コンソールでモデルをデプロイするか、新しいエンドポイントを作成するときに、[ロギング] ステップで有効にする予測ログの種類を指定できます。チェックボックスを選択してアクセス ロギングまたはコンテナ ロギングを有効にします。これらのログを無効にするにはチェックボックスをオフにします。

REST API を使用して、コンテナログの設定を更新します。

REST API を使用してリクエスト / レスポンス ロギングを有効にします。Google Cloud コンソールと gcloud CLI では、リクエスト / レスポンス ロギング構成がサポートされていません。

モデルをデプロイする方法については、Google Cloud コンソールを使用したモデルのデプロイをご覧ください。

gcloud

デプロイされたモデルで有効なログのデフォルトの動作を変更するには、gcloud コマンドにフラグを追加します。

v1 サービス エンドポイント

gcloud ai endpoints deploy-model を実行します。

gcloud ai endpoints deploy-model ENDPOINT_ID\
  --region=LOCATION \
  --model=MODEL_ID \
  --display-name=DEPLOYED_MODEL_NAME \
  --machine-type=MACHINE_TYPE \
  --accelerator=count=2,type=nvidia-tesla-t4 \
  --disable-container-logging \
  --enable-access-logging

v1beta1 サービス エンドポイント

gcloud beta ai endpoints deploy-model を実行します。

gcloud beta ai endpoints deploy-model ENDPOINT_ID\
  --region=LOCATION \
  --model=MODEL_ID \
  --display-name=DEPLOYED_MODEL_NAME \
  --machine-type=MACHINE_TYPE \
  --accelerator=count=2,type=nvidia-tesla-t4 \
  --enable-access-logging \
  --enable-container-logging

REST API を使用して、コンテナログの設定を更新します。

REST API を使用してリクエスト / レスポンス ロギングを有効にします。Google Cloud コンソールと gcloud CLI では、リクエスト / レスポンス ロギング構成がサポートされていません。

モデルをデプロイする方法の詳細については、Vertex AI API を使用したモデルのデプロイをご覧ください。

REST

デプロイされたモデルで有効なログのデフォルトの動作を変更するには、関連するフィールドを True に設定します。

v1 サービス エンドポイント

コンテナ ロギングを無効にするには、projects.locations.endpoints.deployModel または projects.locations.endpoints.mutateDeployedModel の呼び出し時に disableContainerLogging フィールドを True に設定します。

アクセス ロギングを有効にするには、projects.locations.endpoints.deployModel でモデルをデプロイするときに enableAccessLogging を True に設定します。

v1beta1 サービス エンドポイント

コンテナ ロギングを有効にするには、projects.locations.endpoints.deployModel または projects.locations.endpoints.mutateDeployedModel の呼び出し時に enableContainerLogging フィールドを True に設定します。

アクセス ロギングを有効にするには、projects.locations.endpoints.deployModel でモデルをデプロイするときに enableAccessLogging を True に設定します。

モデルをデプロイする方法の詳細については、Vertex AI API を使用したモデルのデプロイをご覧ください。

リクエスト / レスポンス ロギング

リクエスト / レスポンス ロギングを有効にできるのは、projects.locations.endpoints.create を使用してエンドポイントを作成する場合か、projects.locations.endpoints.patch を使用して既存のエンドポイントにパッチを適用する場合のみです。

リクエスト / レスポンス ロギングはエンドポイント レベルで行われるため、同じエンドポイントのデプロイメント モデルに送信されたリクエストはログに記録されます。

エンドポイントを作成またはパッチ適用するときに、エンドポイント リソースの predictRequestResponseLoggingConfig フィールドに次のエントリを入力します。

  • enabled: リクエスト / レスポンス ロギングを有効にするには、True に設定します。

  • samplingPercentage: ログに記録するリクエストの割合を定義する 0～1 の数値。たとえば、すべてのリクエストをログに記録するにはこの値を 1 に設定し、リクエストの 10% をログに記録する場合は 0.1 に設定します。

  • BigQueryDestination: ロギングに使用される BigQuery テーブル。プロジェクト名のみを指定した場合、新しいデータセットが logging_ENDPOINT_DISPLAY_NAME_ENDPOINT_ID という名前で作成されます。ここで、ENDPOINT_DISPLAY_NAME は BigQuery の命名規則に従います。テーブル名を指定しない場合、request_response_logging という名前の新しいテーブルが作成されます。

    BigQuery テーブルのスキーマは次のようになります。

    フィールド名型モード
    endpointSTRINGNULLABLE
    deployed_model_idSTRINGNULLABLE
    logging_timeTIMESTAMPNULLABLE
    request_idNUMERICNULLABLE
    request_payloadSTRINGREPEATED
    response_payloadSTRINGREPEATED

次に、構成の例を示します。

{
   "predict_request_response_logging_config": {
     "enabled": true,
     "sampling_rate": 0.5,
     "bigquery_destination": {
       "output_uri": "bq://PROJECT_ID.DATASET_NAME.TABLE_NAME"
     }
   }
}

リクエスト / レスポンス ロギングと Model Monitoring v1

リクエスト / レスポンス ロギングと Model Monitoring v1 は、バックエンドで同じ BigQuery テーブルを使用して受信リクエストをログに記録します。この BigQuery テーブルへの予期しない変更を防ぐため、両方の機能を同時に使用すると次の制限が適用されます。

  • エンドポイントで Model Monitoring が有効になっている場合、同じエンドポイントに対してリクエスト / レスポンス ロギングを有効にすることはできません。

  • リクエスト / レスポンス ロギングを有効にしてから同じエンドポイントで Model Monitoring を有効にすると、リクエスト / レスポンス ロギングの構成を変更できません。

次のステップ