オンライン エンドポイントのデプロイとスコアリングのトラブルシューティング

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

この記事では、Azure Machine Learning オンライン エンドポイントのデプロイとスコアリングに関する一般的な問題のトラブルシューティングと解決方法について説明します。

このドキュメントは、推奨されるトラブルシューティング方法別に構成されています。

1. クラウドにデプロイする前に、ローカル デプロイを使用してモデルをローカルでテストおよびデバッグする。
2. 問題のデバッグにコンテナー ログを役立てる。
3. 発生する可能性がある一般的なデプロイ エラーとその修正方法について理解する。

「HTTP 状態コード」セクションでは、REST 要求でエンドポイントをスコアリングする際に呼び出しと予測のエラーを HTTP 状態コードにマップする方法について説明します。

前提条件

• 無料版または有料版の Azure Machine Learning を使用する有効な Azure サブスクリプション。 無料試用版の Azure サブスクリプションを取得してください。

要求トレース

次の 2 つのトレース ヘッダーがサポートされています。

• x-request-id はサーバー トレース用に予約されています。 Azure Machine Learning では、このヘッダーが有効な GUID であることを確認するためにオーバーライドされます。 失敗した要求のサポート チケットを作成する場合は、失敗した要求 ID を添付すると調査が迅速になります。 または、リージョン名とエンドポイント名を指定します。

• x-ms-client-request-id はクライアント トレース シナリオで使用できます。 このヘッダーは、英数字、ハイフン、アンダースコアのみを受け入れ、最大 40 文字に切り詰められます。

ローカルでのデプロイ

ローカル デプロイとは、ローカル Docker 環境にモデルをデプロイすることを意味します。 ローカル デプロイでは、ローカル エンドポイントの作成、更新、削除がサポートされ、エンドポイントからログを呼び出して取得できます。 ローカル デプロイは、クラウドにデプロイする前にテストやデバッグを行う場合に便利です。

Azure CLI または Python SDK を使用してローカルにデプロイできます。 Azure Machine Learning スタジオでは、ローカル デプロイまたはローカル エンドポイントはサポートされていません。

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

ml_client.begin_create_or_update(online_deployment, local=True)

次の手順は、ローカル デプロイ中に行われます。

1. Docker では、新しいコンテナー イメージをビルドするか、ローカルの Docker キャッシュから既存のイメージをプルします。 Docker は、既存のイメージが仕様ファイルの環境部分と一致する場合、そのイメージを使用します。
2. Docker では、モデルやコード ファイルなど、マウントされているローカルの成果物を使用して、新しいコンテナーを起動します。

詳細については、「ローカル エンドポイントを使用してローカルにデプロイおよびデバッグする」を参照してください。

コンテナー ログを取得する

モデルがデプロイされる仮想マシン (VM) に直接アクセスすることはできませんが、VM で実行されている一部のコンテナーからログを取得できます。 取得する情報の量は、デプロイのプロビジョニング状態によって異なります。 指定したコンテナーが稼働している場合は、そのコンソール出力が表示されます。 それ以外の場合は、後でもう一度試すよう求めるメッセージが表示されます。

次の種類のコンテナーからログを取得できます。

• 推論サーバー コンソール ログには、スコアリング スクリプト score.py コードからの出力関数とログ関数が含まれます。
• ストレージ初期化子ログには、コードとモデル データがコンテナーに正常にダウンロードされたかどうかに関する情報が含まれます。 推論サーバー コンテナーの実行が開始される前に、コンテナーが実行されます。

Kubernetes オンライン エンドポイントの場合、管理者は、モデルをデプロイするクラスターに直接アクセスし、Kubernetes のログを確認できます。 次に例を示します。

kubectl -n <compute-namespace> logs <container-name>

コンテナーからのログ出力を確認する

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

az ml online-deployment get-logs -h

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100
)

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100, container_type="storage-initializer"
)

一般的なデプロイのエラー

デプロイ操作の状態では、次の一般的なデプロイ エラーが報告される場合があります。

• ImageBuildFailure

  • Azure Container Registry の認可エラー
  • 仮想ネットワークを使用したプライベート ワークスペースでイメージ ビルド コンピューティングが設定されていない
  • イメージ ビルドのタイムアウト
  • 一般的または不明なエラー

• OutOfQuota

  • CPU
  • クラスター
  • ディスク
  • [メモリ]
  • ロールの割り当て
  • エンドポイント
  • リージョン全体の VM 容量
  • その他

• BadArgument

  マネージド オンライン エンドポイントと Kubernetes オンライン エンドポイントの両方で共通:

  • サブスクリプションが存在しない
  • 認証エラーが原因でスタートアップ タスクが失敗する
  • リソースへのロールの割り当てが不適切であるため、スタートアップ タスクが失敗する
  • mdc が有効になっているときにストレージ アカウントのロールの割り当てが正しくないため、スタートアップ タスクが失敗しました
  • テンプレート関数の指定が無効です
  • ユーザー コンテナー イメージをダウンロードできません
  • ユーザー モデルをダウンロードできません

  Kubernetes オンライン エンドポイントに限定:

  • リソース要求が制限を超えている
  • Kubernetes オンライン エンドポイントの Azureml-fe の準備ができていない

• ResourceNotReady

• ResourceNotFound

  • Azure Resource Manager が必要なリソースを見つけることができない
  • コンテナ レジストリがプライベートであるか、アクセスできません

• ワークスペース管理ネットワークの準備ができていません

• OperationCanceled

  • 優先度が高い別の操作によって操作が取り消されました
  • ロックの確認を待機している前の操作が原因で操作が取り消されました

• SecretsInjectionError

• InternalServerError

Kubernetes のオンライン デプロイを作成または更新している場合は、Kubernetes デプロイに固有の一般的なエラーも参照してください。

エラー: ImageBuildFailure

このエラーは、Docker イメージ環境がビルドされているときに返されます。 ビルド ログでエラーの詳細を確認できます。 ビルド ログは、Azure Machine Learning ワークスペースの既定のストレージにあります。

正確な場所は、エラーの一部として返される場合があります (例: "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'")。

次のセクションでは、イメージ ビルド エラーの一般的なシナリオについて説明します。

• Azure Container Registry の認可エラー
• 仮想ネットワークを使用したプライベート ワークスペースでイメージ ビルド コンピューティングが設定されていない
• イメージ ビルドのタイムアウト
• 一般的または不明なエラー

Azure Container Registry の認可エラー

エラー メッセージに "container registry authorization failure" と表示されている場合、コンテナー レジストリに現在の資格情報でアクセスできません。 このエラーは、ワークスペース リソースのキーの非同期化によって発生する可能性があり、自動的に同期されるまでに時間がかかります。 ただし、az ml workspace sync-keys を使用してキー同期を手動で呼び出すことで、認可エラーを解決できる場合があります。

仮想ネットワークの背後にあるコンテナー レジストリも、正しく設定されていない場合にこのエラーが発生する可能性があります。 仮想ネットワークが正しく設定されていることを確認してください。

仮想ネットワークを使用したプライベート ワークスペースでイメージ ビルド コンピューティングが設定されていない

エラー メッセージに "failed to communicate with the workspace's container registry" と表示され、仮想ネットワークを使用していて、ワークスペースのコンテナー レジストリが非公開であり、プライベート エンドポイントを使用して構成されている場合、仮想ネットワークでイメージをビルドすることを Azure Container Registry に許可する必要があります。

イメージ ビルドのタイムアウト

イメージ ビルドのタイムアウトは、多くの場合、イメージが大きくなりすぎて、デプロイの作成期間内にビルドを完了できないことが原因です。 エラーで指定されている場所でイメージ ビルド ログを確認します。 ログは、イメージ ビルドがタイムアウトした時点で遮断されます。

これを解決するには、デプロイの作成時にのみイメージをプルするように、イメージを個別にビルドしてください。 ImageBuild のタイムアウトがある場合は、既定のプローブ設定も確認してください。

共通イメージビルドに失敗しました

ビルド ログでエラーの詳細を確認します。 ビルド ログで明確なエラーが見つからず、最後の行が Installing pip dependencies: ...working... である場合、依存関係がエラーの原因として考えられます。 conda ファイルでバージョンの依存関係を固定すると、この問題が解決する可能性があります。

モデルをクラウドにデプロイする前に、ローカルにデプロイして、モデルをテストおよびデバッグしてみてください。

エラー: OutOfQuota

Azure サービスを使用すると、次のリソースのクォータが不足する可能性があります。

• CPU
• クラスター
• ディスク
• [メモリ]
• ロールの割り当て
• エンドポイント
• リージョン全体の VM 容量
• その他

Kubernetes オンライン エンドポイントの場合のみ、Kbernetes リソースもクォータ不足になる可能性があります。

CPU クォータ

モデルをデプロイするのに十分なコンピューティング クォータが必要です。 CPU クォータは、サブスクリプションごと、ワークスペースごと、SKU ごと、リージョンごとに使用可能な仮想コアの量を定義します。 SKU の種類に基づいて、各デプロイメントのたびに使用可能なクォータが減少し、削除後に再び加わります。

削除できる未使用のデプロイがあるかどうかを確認したり、クォータの引き上げ要求を送信することができます。

クラスターのクォータ

OutOfQuota エラーは、十分な Azure Machine Learning コンピューティング クラスター クォータがない場合に発生します。 このクォータは、Azure クラウドに CPU または GPU ノードをデプロイするために同時に使用できるサブスクリプションあたりのクラスターの合計数を定義します。

ディスク クォータ

OutOfQuota エラーは、モデルのサイズが使用可能なディスク領域を超え、モデルをダウンロードできない場合に発生します。 より大きなディスク領域がある SKU を使用してみるか、イメージとモデルのサイズを小さくしてください。

メモリ クォータ

OutOfQuota エラーは、モデルのメモリ占有領域が使用可能なメモリよりも大きい場合に発生します。 より大きなディスク領域がある SKU を試してください。

ロールの割り当てクォータ

マネージド オンライン エンドポイントを作成するときに、マネージド ID がワークスペース リソースにアクセスするためのロールの割り当てが必要です。 ロールの割り当て制限に達した場合は、このサブスクリプションで使用されていないロールの割り当てをいくつか削除してみてください。 Azure portal で Azure サブスクリプションの [アクセスの制御] を選択することで、すべてのロールの割り当てを確認できます。

エンドポイント クォータ

このサブスクリプションで使用されていないエンドポイントをいくつか削除してみてください。 すべてのエンドポイントがアクティブに使用されている場合は、エンドポイント制限の引き上げを要求してみてください。 エンドポイントの制限について詳しくは、Azure Machine Learning オンライン エンドポイントとバッチ エンドポイントでのエンドポイント クォータに関する記事を参照してください。

Kubernetes クォータ

OutOfQuota エラーは、このデプロイでノードがスケジュールできないために、要求された CPU またはメモリを提供できない場合に発生します。 たとえば、ノードが切断されているか、使用できなくなっている可能性があります。

エラー メッセージは、通常、クラスター内のリソース不足を示します (例: OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...)。 このメッセージは、クラスター内にポッドが多すぎて、要求に基づいて新しいモデルをデプロイするのに十分なリソースがないことを意味します。

この問題に対処するために、次の軽減策を試してみてください。

• Kubernetes クラスターを維持する IT 担当者は、ノードを追加するか、クラスター内の未使用のポッドをクリアして、一部のリソースを解放することができます。

• モデルをデプロイする機械学習エンジニアは、デプロイのリソース要求を減らすことができます。

  • リソース セクションからデプロイ構成のリソース要求を直接定義している場合は、リソース要求を減らしてみてください。
  • instance_type を使用してモデル デプロイのリソースを定義している場合は、IT オペレーターに問い合わせてインスタンスの種類のリソース構成を調整してください。 詳細については、「インスタンスの種類の作成と管理」を参照してください。

リージョン全体の VM 容量

リージョンに Azure Machine Learning の容量がないため、サービスは指定された VM サイズをプロビジョニングできませんでした。 後で再試行するか、別のリージョンにデプロイしてみてください。

その他の割当

デプロイの一部として指定した score.py ファイルを実行するために、Azure は、score.py が必要とするすべてのリソースを含むコンテナーを作成します。 その後、Azure Machine Learning は、そのコンテナーでスコアリング スクリプトを実行します。 コンテナーを開始できない場合、スコアリングを行うことはできません。 コンテナーは、instance_type がサポートできるよりも多くのリソースを要求している可能性があります。 オンライン デプロイの instance_type を更新することを検討してください。

エラーの正確な理由を取得するには、次のアクションを実行します。

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100
)

ERROR: BadArgument

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

• サブスクリプションが存在しない
• 認証エラーが原因でスタートアップ タスクが失敗する
• リソースへのロールの割り当てが不適切であるため、スタートアップ タスクが失敗する
• テンプレート関数の指定が無効です
• ユーザー コンテナー イメージをダウンロードできません
• ユーザー モデルをダウンロードできません
• プライベート ネットワークを使った MLFlow モデル形式はサポートされていません

次の理由により、Kubernetes オンライン エンドポイントを使用する場合にのみ、このエラーが発生する可能性があります。

• リソース要求が制限を超えている
• Kubernetes オンライン エンドポイントの Azureml-fe の準備ができていない

サブスクリプションが存在しない

参照先の Azure サブスクリプションは、既存でアクティブである必要があります。 このエラーは、入力したサブスクリプション ID が Azure で見つからない場合に発生します。 このエラーは、サブスクリプション ID の入力ミスが原因である可能性があります。 サブスクリプション ID が正しく入力されていること、および現在アクティブであることを再確認してください。

認証エラー

デプロイの作成時にコンピューティング リソースをプロビジョニングすると、Azure はワークスペース コンテナー レジストリからユーザー コンテナー イメージをプルし、ユーザー モデルとコード成果物をワークスペース ストレージ アカウントからユーザー コンテナーにマウントします。 Azure はマネージド ID を使用してストレージ アカウントとコンテナー レジストリにアクセスします。

ユーザー割り当て ID と関連付けられたエンドポイントを作成する場合は、ユーザーのマネージド ID にはワークスペース ストレージ アカウントでのストレージ BLOB データ閲覧者のアクセス許可、ワークスペース コンテナー レジストリでの AcrPull のアクセス許可が必要です。 ユーザー割り当て ID に適切なアクセス許可があることを確認してください。

MDC が有効になっている場合、ユーザーのマネージド ID には、ワークスペース ストレージ アカウントに対する ストレージ BLOB データ共同作成者 アクセス許可が必要です。 詳細については、「 MDC が有効な場合のストレージ BLOB 承認エラー」を参照してください。

システム割り当て ID と関連付けられたエンドポイントを作成する場合は、Azure のロールベースのアクセス制御 (RBAC) のアクセス許可が自動的に付与されるので、それ以上のアクセス許可は必要ありません。 詳細については、「コンテナー レジストリの認証エラー」を参照してください。

テンプレート関数の指定が無効です

このエラーは、テンプレート関数を正しく指定しなかった場合に発生します。 ポリシーを修正するか、ポリシーの割り当てを削除してブロックを解除してください。 エラー メッセージには、このエラーのデバッグに役立つポリシー割り当て名とポリシー定義が含まれている場合があります。 テンプレートの障害を回避するためのヒントについては、「Azure ポリシー定義の構造」を参照してください。

ユーザー コンテナー イメージをダウンロードできません

ユーザー コンテナーが見つからない可能性があります。 コンテナー ログで詳細情報を確認してください。

コンテナー イメージがワークスペース コンテナー レジストリで使用できることを確認します。 たとえば、イメージが testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest の場合は、次のコマンドを使用してリポジトリを確認できます。

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

ユーザー モデルをダウンロードできません

ユーザー モデルが見つからない可能性があります。 コンテナー ログで詳細情報を確認してください。 モデルが、デプロイと同じワークスペースに登録されていることを確認します。

ワークスペース内のモデルの詳細を表示するには、次のアクションを実行します。 モデル情報を取得するには、バージョンまたはラベルを指定する必要があります。

az ml model show --name <model-name> --version <version>

ml_client.models.get(name="<model-name>", version=<version>)

また、BLOB がワークスペース ストレージ アカウント内に存在するかどうかを確認します。 たとえば、BLOB が https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl の場合は、次のコマンドを使用して BLOB が存在するかどうかを確認できます。

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>

BLOB が存在する場合は、次のコマンドを使用して、ストレージ初期化子からログを取得できます。

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

ml_client.online_deployments.get_logs(
  name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100, container_type="storage-initializer"
)

プライベート ネットワークを使った MLFlow モデル形式はサポートされていません

マネージド オンライン エンドポイントに対して従来のネットワーク分離方法を使用している場合は、MLflow モデル形式でプライベート ネットワーク機能を使用することはできません。 コードなしのデプロイ アプローチで MLflow モデルをデプロイする必要がある場合は、ワークスペースのマネージド 仮想ネットワークを使用してみてください。

制限を超えているリソース要求

リソースに対する要求は、制限以下でなければなりません。 制限を設定しない場合、ワークスペースにコンピューティングをアタッチするときに、Azure Machine Learning によって既定値が設定されます。 制限は、Azure portal または az ml compute show コマンドを使用して確認できます。

Azureml-fe の準備ができていない

デプロイされたサービスへ受信推論要求をルーティングするフロントエンド azureml-fe コンポーネントは、k8s-extension のインストール中にインストールされ、必要に応じて自動的にスケーリングされます。 このコンポーネントには、クラスター上に少なくとも 1 つの正常なレプリカが必要です。

Kubernetes オンライン エンドポイントまたはデプロイの作成または更新の要求をトリガーするときにコンポーネントを使用できない場合、このエラーが発生します。 ポッドの状態とログを確認して、この問題を解決します。 クラスターにインストールされている k8s 拡張機能を更新することもできます。

エラー: リソースが準備できていません

デプロイの一部として指定した score.py ファイルを実行するために、Azure では score.py に必要なすべてのリソースを含むコンテナーを作成し、そのコンテナーでスコアリング スクリプトを実行します。 このシナリオのエラーでは、実行中にこのコンテナーがクラッシュするため、スコアリングを行うことはできません。 このエラーは、次のいずれかの条件下で発生する可能性があります。

• score.py にエラーがある。 get-logs を使用して、次のような一般的な問題を診断します。

  • score.py がインポートしようとしたパッケージが Conda 環境に含まれていない
  • 構文エラー
  • init() メソッドのエラー

  get-logs でログが生成されない場合は、通常、コンテナーの起動に失敗したことを意味します。 この問題をデバッグするには、ローカルでデプロイしてみてください。

• レディネスプローブまたはライブネスプローブが正しく設定されていません。

• コンテナーの初期化に時間がかかりすぎて、準備または liveness probe が失敗しきい値を超えて失敗する。 この場合は、プローブ設定を調整して、コンテナーの初期化により多くの時間をかけられるようにします。 または、より大きなサポートされている VM SKU を試してみてください。初期化にかかる時間が短縮されます。

• 依存関係が不足しているなど、コンテナーの環境設定にエラーがある。

  TypeError: register() takes 3 positional arguments but 4 were given エラーが発生した場合は、flask v2 と azureml-inference-server-http の間の依存関係を確認してください。 詳細については、「HTTP サーバーの問題のトラブルシューティング」を参照してください。

エラー: リソースが見つかりません (ERROR: ResourceNotFound)

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

• Azure Resource Manager が必要なリソースを見つけることができない
• コンテナ レジストリがプライベートであるか、アクセスできません

Resource Manager がリソースを見つけることができない

このエラーは Azure Resource Manager が必要なリソースを見つけられない場合に発生します。 たとえば、指定されたパスにストレージ アカウントが見つからない場合、このエラーが発生する可能性があります。 パスまたは名前の仕様が正確でスペルミスがないか再確認してください。 詳細については、「リソースが見つからないエラーを解決する」を参照してください。

コンテナー レジストリの認証エラー

このエラーは、プライベートまたはアクセスできないコンテナー レジストリに属するイメージがデプロイ用に指定されている場合に発生します。 Azure Machine Learning API は、プライベート レジストリ資格情報を受け入れることはできません。

このエラーを軽減するには、コンテナー レジストリがプライベートでないことを確認するか、次の手順を実行します。

1. プライベート レジストリの acrPull ロールを、オンライン エンドポイントのシステム ID に付与します。
2. 環境の定義で、プライベート イメージのアドレスを指定し、イメージを変更またはビルドしないように指示します。

軽減策が成功した場合、イメージをビルドする必要がなくなり、最終的なイメージ アドレスが指定したイメージ アドレスになります。 デプロイ時に、オンライン エンドポイントのシステム ID によって、プライベート レジストリからイメージがプルされます。

診断について詳しくは、「ワークスペース診断の使用方法」を参照してください。

ERROR: ワークスペース管理ネットワークが準備できていません (WorkspaceManagedNetworkNotReady)

このエラーは、ワークスペースのマネージド仮想ネットワークを有効にするオンライン デプロイを作成しようとしても、マネージド仮想ネットワークがまだプロビジョニングされていない場合に発生します。 オンライン デプロイを作成する前に、ワークスペースのマネージド仮想ネットワークをプロビジョニングしてください。

ワークスペースのマネージド仮想ネットワークを手動でプロビジョニングするには、「マネージド VNET を手動でプロビジョニングする」の手順に従います。 その後、オンライン デプロイの作成を開始できます。 詳細については、「マネージド オンライン エンドポイントでのネットワークの分離」と「ネットワーク分離を使用してマネージド オンライン エンドポイントをセキュリティで保護する」を参照してください。

エラー: 操作がキャンセルされました

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

• 優先度が高い別の操作によって操作が取り消されました
• ロックの確認を待機している前の操作が原因で操作が取り消されました

優先度が高い別の操作によって取り消された操作

Azure の操作には、優先度レベルが割り当てられており、高いものから順に実行されます。 このエラーは、行っている操作が優先度の高い別の操作によって上書きされた場合に発生します。 操作を再試行すると、キャンセルせずに操作を実行できる場合があります。

ロックの確認を待機していて取り消された操作

Azure の操作には送信後短い待機期間があり、その間操作はロックを取得し、競合状態が発生しないようにしています。 このエラーは、送信した操作が他の操作と同じ場合に発生します。 その間、他の操作はロックを受け取ったかという確認を待ってから、続行されます。

最初の要求の後に同様の要求を送信した可能性があります。 最大 1 分待ってから操作を再試行すると、キャンセルせずに実行できる場合があります。

ERROR: SecretsInjectionError

オンライン デプロイの作成時のシークレットの取得と挿入では、ワークスペース接続またはキー コンテナーからシークレットを取得するために、オンライン エンドポイントに関連付けられた ID を使用します。 このエラーは、次のいずれかの理由で発生します。

• デプロイ定義で環境変数にマップされた参照としてシークレットが指定されている場合でも、エンドポイント ID には、ワークスペース接続またはキー コンテナーからシークレットを読み取るための Azure RBAC アクセス許可がありません。 ロールの割り当ての変更が有効になるには時間がかかる場合があります。

• シークレット参照の形式が無効であるか、指定されたシークレットがワークスペース接続やキー コンテナー内に存在しません。

詳細については、「オンライン エンドポイントでのシークレットの挿入 (プレビュー)」および「シークレット挿入を使用したオンライン デプロイからのシークレットへのアクセス (プレビュー)」を参照してください。

ERROR: サーバー内部エラー

このエラーは、Azure Machine Learning サービスに修正が必要な問題があることを意味します。 問題に対処するために必要なすべての情報を記載のうえ、カスタム サポート チケットを送信してください。

Kubernetes デプロイに固有の一般的なエラー

ID と認証のエラー:

• ACRSecretError
• TokenRefreshFailed
• GetAADTokenFailed (AADトークンの取得に失敗しました)
• 認証チャレンジ失敗
• ACRTokenExchangeFailed（トークン交換が失敗しました）
• Kubernetesアクセス不可

Crashloopbackoff エラー:

• ImagePullLoopBackOff
• DeploymentCrashLoopBackOff（デプロイメント クラッシュ ループ バックオフ）
• KubernetesCrashLoopBackOff

スクリプトエラーを評価する

• UserScriptInitFailed
• UserScriptImportError
• UserScriptFunctionNotFound

その他のエラー:

• NamespaceNotFound
• EndpointAlreadyExists
• ScoringFeUnhealthy
• スコアの検証に失敗しました
• 無効なデプロイメント仕様 (InvalidDeploymentSpec)
• PodUnschedulable
• PodOutOfMemory
• InferencingClientCallFailed（推論クライアント呼び出し失敗）

エラー: ACRSecretError

Kubernetes オンライン デプロイを作成または更新する場合、次のいずれかの理由でこのエラーが発生する可能性があります。

• ロールの割り当てが完了していません。 数秒待ってから、もう一度やり直してください。

• Azure Arc 対応 Kubernetes クラスターまたは AKS Azure Machine Learning 拡張機能のインストールや構成が正しく行われていません。 Azure Arc 対応 Kubernetes または Azure Machine Learning 拡張機能の構成と状態を確認してください。

• Kubernetes クラスターのネットワーク構成が不適切です。 プロキシ、ネットワーク ポリシー、または証明書を確認してください。

• プライベート AKS クラスターに適切なエンドポイントがありません。 Container Registry、ストレージ アカウント、および AKS 仮想ネットワーク内のワークスペースにプライベート エンドポイントを設定していることを確認してください。

• Azure Machine Learning 拡張機能のバージョンが v1.1.25 以下です。 拡張機能のバージョンが v1.1.25 以上であることを確認してください。

エラー: TokenRefreshFailed

このエラーは、Kubernetes クラスター ID が適切に設定されていないため、拡張機能で Azure からプリンシパル資格情報を取得できないため発生します。 Azure Machine Learning 拡張機能を再インストールしてもう一度お試しください。

エラー: GetAADTokenFailed

このエラーは、Kubernetes クラスター要求 Microsoft Entra ID トークンが失敗またはタイムアウトしたために発生します。ネットワーク アクセスを確認してから、もう一度やり直してください。

• 「Kubernetes コンピューティングを使用する」の手順に従って送信プロキシを確認し、クラスターがワークスペースに接続できることを確認します。 ワークスペース エンドポイントの URL は、クラスター内のオンライン エンドポイントのカスタム リソース定義 (CRD) にあります。

• ワークスペースでパブリック アクセスが許可されているかどうかを確認します。 AKS クラスター自体がパブリックかプライベートかに関係なく、プライベート ワークスペースで公衆ネットワーク アクセスが無効になっている場合、Kubernetes クラスターはプライベート リンクを介してのみそのワークスペースと通信できます。 詳細については、「セキュリティで保護された AKS 推論環境」を参照してください。

エラー: ACR 認証チャレンジ失敗

このエラーは、Kubernetes クラスターが認証チャレンジを実行するためにワークスペース Container Registry サービスに到達できないために発生します。 ネットワーク (特に Container Registry 公衆ネットワーク アクセス) を確認してから、もう一度やり直してください。 「GetAADTokenFailed」のトラブルシューティング手順に従って、ネットワークをチェックします。

エラー: ACRTokenExchangeFailed

このエラーは、Microsoft Entra ID トークンがまだ承認されておらず、Kubernetes クラスター交換の Container Registry トークンが失敗するために発生します。 ロールの割り当てには時間がかかるため、少し待ってからやり直してください。

このエラーは、Container Registry サービスに対する同時要求が多すぎることが原因である可能性もあります。 このエラーは一時的なもので、後でもう一度試すことができます。

エラー: Kubernetes にアクセスできません

Kubernetes モデルのデプロイ中に、次のエラーが発生する場合があります。

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

このエラーを軽減するには、クラスターの AKS 証明書をローテーションします。 新しい証明書は 5 時間後に更新されるため、5 時間待ってから再デプロイできます。 詳細については、「Azure Kubernetes Service (AKS) での証明書のローテーション」を参照してください。

エラー: ImagePullLoopBackOff

Kubernetes オンライン デプロイを作成または更新する場合に、コンテナー レジストリからイメージをダウンロードできず、イメージのプル エラーが発生するため、このエラーが発生する可能性があります。 クラスター ネットワーク ポリシーとワークスペース コンテナー レジストリを確認して、クラスターがコンテナー レジストリからイメージをプルできるかどうかを確認します。

エラー: DeploymentCrashLoopBackOff

Kubernetes オンライン デプロイを作成または更新する場合に、初期化時にユーザー コンテナーがクラッシュしたため、このエラーが発生する可能性があります。 このエラーの原因は以下の 2 つが考えられます。

• ユーザー スクリプト score.py に、初期化時に例外を発生させる構文エラーまたはインポート エラーがあります。
• デプロイ ポッドに必要なメモリが上限を上回っています。

このエラーを軽減するには、まずデプロイ ログ内で、ユーザー スクリプトに例外がないか確認します。 エラーが解決しない場合は、リソース/インスタンスの種類のメモリ制限を拡張してみてください。

エラー: KubernetesCrashLoopBackOff

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、次のいずれかの理由で、このエラーが発生する可能性があります。

• 1 つ以上のポッドが CrashLoopBackoff 状態でスタックしています。 デプロイ ログが存在し、ログにエラー メッセージがないか確認します。
• スコア コードを初期化するときに、score.py にエラーがあり、コンテナーがクラッシュしました。 ERROR: ResourceNotReady の指示に従います。
• スコアリング プロセスで必要なメモリが、デプロイ構成の制限を超えています。 メモリ制限を大きくしてデプロイを更新を試してください。

エラー: NamespaceNotFound

Kubernetes オンライン エンドポイントを作成または更新する場合に、Kubernetes コンピューティングで使用されている名前空間がクラスターで使用できないため、このエラーが発生する可能性があります。 ワークスペース ポータルで Kubernetes コンピューティングを確認し、Kubernetes クラスター内の名前空間を確認します。 名前空間が使用できない場合は、レガシ コンピューティングをデタッチし、再アタッチして新しいコンピューティングを作成し、クラスターに既に存在する名前空間を指定します。

エラー: UserScriptInitFailed

アップロードした init ファイルの 関数で例外が発生したため、Kubernetes オンライン デプロイを作成または更新する場合に、このエラーが発生する可能性があります。 デプロイ ログで例外メッセージの詳細を確認し、例外を修正します。

エラー: UserScriptImportError

Kubernetes オンライン デプロイを作成または更新する場合に、アップロードした score.py ファイルが使用できないパッケージをインポートするため、このエラーが発生する可能性があります。 デプロイ ログで例外メッセージの詳細を確認し、例外を修正します。

エラー: UserScriptFunctionNotFound

Kubernetes オンライン デプロイを作成または更新する場合に、アップロードした score.py ファイルに init() または run() という名前の関数がないため、このエラーが発生する可能性があります。 コードを確認し、関数を追加します。

エラー: EndpointNotFound

Kubernetes オンライン デプロイを作成または更新する場合に、クラスター内のデプロイのエンドポイント リソースがシステムで見つからないため、このエラーが発生する可能性があります。 既存のエンドポイントにデプロイを作成するか、最初にクラスターでエンドポイントを作成します。

ERROR: エンドポイントは既に存在します

Kubernetes オンライン エンドポイントを作成する場合に、クラスターに既にエンドポイントが存在するため、このエラーが発生する可能性があります。 エンドポイント名はワークスペースごと、クラスターごとに一意である必要があるため、別の名前でエンドポイントを作成します。

エラー: ScoringFeUnhealthy

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、クラスターで実行されている azureml-fe システム サービスが見つからないか異常であるため、このエラーが発生する可能性があります。 この問題を軽減するには、クラスター内の Azure Machine Learning 拡張機能を再インストールまたは更新します。

ERROR: スコアリングの検証に失敗しました

Kubernetes オンライン デプロイを作成または更新する場合に、モデルの処理中にスコアリング要求 URL の検証が失敗したため、このエラーが発生する可能性があります。 エンドポイント URL を確認し、再デプロイを試みます。

エラー: InvalidDeploymentSpec (無効なデプロイメント仕様)

Kubernetes オンライン デプロイを作成または更新する場合に、デプロイ仕様が無効であるため、このエラーが発生する可能性があります。 エラー メッセージを調べて、instance count が有効であることを確認します。 自動スケーリングを有効にしている場合は、minimum instance count と maximum instance count が両方とも有効であることを確認します。

エラー: PodUnschedulable

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、次のいずれかの理由で、このエラーが発生する可能性があります。

• クラスター内のリソースが不足しているため、ポッドをノードにスケジュールすることができません。
• ノード アフィニティ セレクターと一致するノードがありません。

このエラーを軽減するには、次の手順に従います。

1. 使用した node selector の instance_type 定義と、クラスター ノードの node label 構成を確認します。
2. AKS クラスターの instance_type とノード SKU サイズ、または Azure Arc 対応 Kubernetes クラスターのノード リソースを確認します。
3. クラスターのリソースが不足している場合は、このインスタンスの種類に対するリソース要件を減らすか、リソース要件が少ない別のインスタンスの種類を使用します。
4. クラスターにデプロイの要件を満たすリソースがもうない場合は、リソースを解放するために一部のデプロイを削除します。

エラー: PodOutOfMemory

オンライン デプロイを作成または更新する場合に、デプロイに対して指定したメモリ制限が不十分であるため、このエラーが発生する可能性があります。 このエラーを軽減するために、メモリ制限の設定値を大きくするか、もっと大きなインスタンスの種類を使用することができます。

エラー: InferencingClientCallFailed

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、Kubernetes クラスターの k8s 拡張機能が接続できないため、このエラーが発生する可能性があります。 この場合は、コンピュートを切り離してから再接続します。

再アタッチによるエラーのトラブルシューティングを行うには、他のエラーを回避するために、デタッチされたコンピューティングと同じ構成 (コンピューティング名や名前空間など) を使用して再アタッチしてください。 それでも解決しない場合は、クラスターにアクセスできる管理者に、kubectl get po -n azureml を使用して中継サーバー ポッドが実行されているかどうか検査してもらってください。

モデルの使用に関する問題

エンドポイント invoke 操作状態に起因する一般的なモデル使用エラーには、帯域幅制限の問題、CORS ポリシー、さまざまな HTTP 状態コードが含まれます。

帯域幅の制限の問題

マネージド オンライン エンドポイントには、エンドポイントごとに帯域幅の制限があります。 制限の構成は、「オンライン エンドポイントの制限」で確認できます。 帯域幅の使用量が制限を超えると、要求が遅延します。

帯域幅の遅延を監視するには、[ネットワーク バイト] メトリックを使用して現在の帯域幅の使用状況を把握します。 詳細については、「マネージド オンライン エンドポイントを監視する」を参照してください。

帯域幅の制限が適用されている場合は、次の 2 つの応答トレーラーが返されます。

• ms-azureml-bandwidth-request-delay-ms は、要求ストリームの転送にかかった延期期間 (ミリ秒単位) です。
• ms-azureml-bandwidth-response-delay-ms は、応答ストリームの転送にかかった延期期間 (ミリ秒単位) です。

CORS ポリシーによってブロックされる

V2 オンライン エンドポイントは、クロスオリジン リソース共有 (CORS) をネイティブでサポートしていません。 Web アプリが CORS プレフライト要求を適切に処理せずにエンドポイントを呼び出そうとすると、次のエラー メッセージが表示されます。

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

CORS プレフライト要求を処理するための中間レイヤーとして、Azure Functions、Azure Application Gateway、または別のサービスを使用できます。

HTTP 状態コード

REST 要求でオンライン エンドポイントにアクセスしたときに返される状態コードは、HTTP の状態コードの標準に準拠しています。 次のセクションでは、エンドポイント呼び出しと予測エラーが HTTP 状態コードにどのようにマップされるかについて詳しく説明します。

マネージド オンライン エンドポイントの一般的なエラー コード

次の表に、REST 要求でマネージド オンライン エンドポイントを消費するときの一般的なエラー コードを示します。

kubernetes オンライン エンドポイントの一般的なエラー コード

次の表に、REST 要求で Kubernetes オンライン エンドポイントを消費するときの一般的なエラー コードを示します。

503 状態コード エラーを防ぐ方法

Kubernetes オンライン デプロイでは、自動スケーリングがサポートされているため、レプリカを加えて、追加の負荷に対応することができます。 詳細については、「Azure Machine Learning 推論ルーター」を参照してください。 スケールアップまたはスケールダウンの決定は、現在のコンテナー レプリカの使用率に基づきます。

2 つのアクションは、503 状態コード エラーを防ぐのに役立ちます。新しいレプリカを作成するために使用率レベルを変更するか、レプリカの最小数を変更します。 これらの方法は、個別に、または組み合わせて使用できます。

• autoscale_target_utilization を小さい値に設定して、自動スケーリングによって新しいレプリカが作成される使用率ターゲットを変更します。 この変更により、レプリカの作成時間が短縮されるのではなく、使用率のしきい値が低くなります。 たとえば、値を 30% に変更すると、サービスの使用率が 70% になるまで待機するのでなく、使用率が 30% になった段階でレプリカが作成されます。

• レプリカの最小数を変更して、受信の増加を処理できる大きなプールを提供します。

インスタンスの数を計算する方法

インスタンスの数を増やすために、次のように必要なレプリカの数を計算できます。

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

現在の最大数のレプリカが Kubernetes オンライン エンドポイントによって既に使用されていて、503 状態コードが引き続き発生する場合は、autoscale_max_replicas の値を大きくして、レプリカの最大数を増やします。

ネットワークの分離に関する問題

このセクションでは、ネットワークの分離に関する一般的な問題について説明します。

v1 レガシ モードに関するメッセージが表示され、オンライン エンドポイントの作成が失敗する

マネージド オンライン エンドポイントは、Azure Machine Learning v2 API プラットフォームの機能です。 Azure Machine Learning ワークスペースが v1 レガシ モード用に構成されている場合、マネージド オンライン エンドポイントは機能しません。 具体的には、 v1_legacy_mode ワークスペースの設定が true に設定されている場合、v1 レガシ モードが有効になり、v2 API はサポートされません。

v1 レガシ モードをオフにする方法については、 Azure Resource Manager の新しい API プラットフォームによるネットワーク分離の変更に関するページを参照してください。

キーベースの認証を使用したオンライン エンドポイントの作成が失敗する

次のコマンドを使用して、ワークスペース用の Azure Key Vault のネットワーク規則の一覧を取得します。 <key-vault-name> は、実際のキー コンテナーの名前に置き換えます。

az keyvault network-rule list -n <key-vault-name>

このコマンドの応答は、次の JSON コードのようになります。

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

bypassの値がAzureServicesされていない場合は、「Azure Key Vault ネットワーク設定を構成する」のガイダンスを使用して、AzureServicesに設定します。

イメージのダウンロード エラーでオンライン デプロイが失敗する

1. egress-public-network-access フラグの値がデプロイのdisabledかどうかを確認します。 このフラグが有効で、コンテナー レジストリの可視性がプライベートである場合、この失敗が予想されます。

2. プライベート エンドポイント接続の状態を調べるには、次のコマンドを使います。 <registry-name> は、実際のワークスペースの Azure Container Registry の名前に置き換えます。

   az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{ID:id, status:privateLinkServiceConnectionState.status}"
   

   応答コードで、status フィールドが Approved に設定されていることを確認します。 値が Approvedされていない場合は、次のコマンドを使用して接続を承認します。 <private-endpoint-connection-ID>を、前のコマンドが返す ID に置き換えます。

   az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"
   

スコアリングエンドポイントを解決できません

1. スコアリング要求を発行しているクライアントが、Azure Machine Learning ワークスペースにアクセスできる仮想ネットワークであることを確認します。

2. エンドポイント ホスト名の nslookup コマンドを使用して、IP アドレス情報を取得します。

   nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com
   

   たとえば、コマンドは次のようになります。

   nslookup endpointname.westcentralus.inference.ml.azure.com
   

   応答には、仮想ネットワークによって提供される範囲内にある必要があるアドレスが含まれています。

   注釈

   • Kubernetes オンライン エンドポイントの場合、エンドポイント ホスト名は、Kubernetes クラスターで指定されている CName (ドメイン名) である必要があります。
   • エンドポイントが HTTP を使用する場合、IP アドレスはエンドポイント URI に含まれ、スタジオ UI から取得できます。
   • エンドポイントの IP アドレスを取得するその他の方法については、「 FQDN を使用して DNS を更新する」を参照してください。

3. nslookup コマンドでホスト名が解決されない場合は、次のいずれかのセクションのアクションを実行します。

マネージド オンライン エンドポイント

1. 次のコマンドを使用して、仮想ネットワークのプライベート ドメイン ネーム システム (DNS) ゾーンに A レコードが存在するかどうかを確認します。

   az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name
   

   結果に、*.<GUID>.inference.<region> のようなエントリが含まれている必要があります。

2. 推論値が返されない場合は、ワークスペースのプライベート エンドポイントを削除してから、再作成します。 詳しくは、プライベート エンドポイントを構成する方法に関するページをご覧ください。

3. プライベート エンドポイントを持つワークスペースで カスタム DNS サーバーが使用されている場合は、次のコマンドを実行して、カスタム DNS サーバーからの解決が正しく動作することを確認します。

   dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com
   

Kubernetes オンライン エンドポイント

1. Kubernetes クラスターの DNS 構成を確認します。

2. Azure Machine Learning 推論ルーター (azureml-fe) が期待どおりに動作するかどうかを確認します。 このチェックを実行するには、次の手順を実行します。

   1. azureml-fe ポッドで次のコマンドを実行します。

      kubectl exec -it deploy/azureml-fe -- /bin/bash
      

   2. 次のいずれかのコマンドを実行します。

      curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
      "Swagger not found"
      

      HTTP の場合は、次のコマンドを使用します。

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
      "Swagger not found"
      

3. curl HTTPS コマンドが失敗するかタイムアウトしても HTTP コマンドが機能する場合は、証明書が有効かどうかを確認します。

4. 上記のプロセスで A レコードへの解決に失敗した場合は、次のコマンドを使用して、解決が Azure DNS 仮想パブリック IP アドレス 168.63.129.16 から機能するかどうかを確認します。

   dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com
   

5. 上記のコマンドが成功した場合は、カスタム DNS での Azure Private Link の条件付きフォワーダーのトラブルシューティングを行います。

オンライン デプロイをスコアリングできない

1. 次のコマンドを実行して、スコア付けできないデプロイの状態を確認します。

   az ml online-deployment show -e <endpoint-name> -n <deployment-name> --query '{name:name,state:provisioning_state}' 
   

   Succeeded フィールドの値stateは、デプロイが成功したことを示します。

2. デプロイを成功させるには、次のコマンドを使用して、トラフィックがデプロイに割り当てられていることを確認します。

   az ml online-endpoint show -n <endpoint-name>  --query traffic
   

   このコマンドからの応答では、各デプロイに割り当てられているトラフィックの割合を一覧表示する必要があります。

   ヒント

   このデプロイをターゲットにするために要求で azureml-model-deployment ヘッダーを使用している場合、この手順は必要ありません。

3. トラフィックの割り当てまたはデプロイ ヘッダーが正しく設定されている場合は、次のコマンドを使用してエンドポイントのログを取得します。

   az ml online-deployment get-logs  -e <endpoint-name> -n <deployment-name> 
   

4. デプロイに要求を送信するときにスコア付けコードの実行に問題があるかどうかを確認するには、ログを確認します。

推論サーバーの問題

このセクションでは、Azure Machine Learning 推論 HTTP サーバーの基本的なトラブルシューティングのヒントについて説明します。

インストールしたパッケージを確認する

インストールされているパッケージに関する問題に対処するには、次の手順に従います。

1. Python 環境にインストールされているパッケージとバージョンに関する情報を収集します。

2. 環境ファイルで、指定されている azureml-inference-server-http Python パッケージのバージョンを確認します。 Azure Machine Learning 推論 HTTP サーバー のスタートアップ ログで、表示されている推論サーバーのバージョンを確認します。 2 つのバージョンが一致することを確認します。

   場合によっては、pip 依存関係リゾルバーによって予期しないパッケージ バージョンがインストールされます。 インストールされているパッケージとバージョンを修正するには、pip を実行する必要がある場合があります。

3. Flask またはその依存関係を環境内で指定した場合は、これらの項目を削除します。

   • 依存パッケージには、flask、jinja2、itsdangerous、werkzeug、markupsafe、click が含まれます。
   • flask パッケージは、推論サーバー パッケージの依存関係として一覧表示されます。 最適な方法は、推論サーバーが flask パッケージをインストールできるようにすることです。
   • 新しいバージョンの Flask をサポートするように推論サーバーが構成されている場合、推論サーバーはパッケージの更新プログラムが使用可能になると自動的に受信します。

推論サーバーのバージョンを確認する

サーバー パッケージ azureml-inference-server-http は PyPI に公開されています。 PyPI ページには、変更ログとパッケージのすべてのバージョンが一覧表示されます。

初期パッケージ バージョンを使用する場合は、構成を最新バージョンに更新します。 次の表は、安定したバージョン、よくある問題、推奨される調整をまとめたものです。

パッケージの依存関係を確認する

サーバー パッケージ azureml-inference-server-http に最も関連のある依存パッケージには、次のものが含まれます。

• flask
• opencensus-ext-azure
• inference-schema

Python 環境で azureml-defaults パッケージを指定した場合、 azureml-inference-server-http パッケージは依存パッケージです。 依存関係は自動的にインストールされます。

推論サーバーの起動時の TypeError

推論サーバーの起動時に、次の TypeError が発生することがあります。

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

このエラーは、Python 環境に Flask 2 がインストールされているが、azureml-inference-server-http パッケージ バージョンが Flask 2 をサポートしていない場合に発生します。 Flask 2 のサポートは、 azureml-inference-server-http 0.7.0 パッケージ以降のバージョンと、 azureml-defaults 1.44 パッケージ以降のバージョンで利用できます。

• Azure Machine Learning Docker イメージで Flask 2 パッケージを使用しない場合は、最新バージョンの azureml-inference-server-http または azureml-defaults パッケージを使用します。

• Azure Machine Learning Docker イメージで Flask 2 パッケージを使用する場合は、イメージビルドのバージョンが July 2022 以降であることを確認します。

  イメージのバージョンは、コンテナー ログで確認できます。 たとえば、次のログ ステートメントを参照してください。

  2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
  2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
  2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
  2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
  2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
  2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
  2022-08-22T17:05:02,190557998+00:00 | gunicorn/run | 
  

  イメージのビルド日は、Materialization Build 表記の後に表示されます。 前の例では、イメージのバージョンは 20220708(2022 年 7 月 8 日)です。 この例のイメージは Flask 2 と互換性があります。

  類似のメッセージがコンテナー ログ内にない場合、そのイメージは古く、更新する必要があります。 コンピューティング統合デバイス アーキテクチャ (CUDA) イメージを使用していて、新しいイメージが見つからない場合は、 AzureML-Containers リポジトリを確認して、イメージが非推奨かどうかを確認します。 非推奨のイメージに対し、指定された代替バージョンを見つけることができます。

  オンライン エンドポイントで推論サーバーを使用する場合は、Azure Machine Learning Studio でログを見つけることもできます。 エンドポイントのページで、[ ログ ] タブを選択します。

SDK v1 を使用してデプロイし、デプロイ構成でイメージを明示的に指定しない場合、推論サーバーはローカル SDK ツールセットに一致するバージョンで openmpi4.1.0-ubuntu20.04 パッケージを適用します。 ただし、インストールされているバージョンは、イメージの利用可能な最新バージョンではない可能性があります。

SDK バージョン 1.43 の場合、推論サーバーは既定で openmpi4.1.0-ubuntu20.04:20220616 パッケージ バージョンをインストールしますが、このパッケージ バージョンは SDK 1.43 と互換性がありません。 デプロイに最新の SDK を使用していることを確認します。

イメージを更新できない場合は、環境ファイルに azureml-defaults==1.43 エントリまたは azureml-inference-server-http~=0.4.13 エントリをピン留めすることで、一時的に問題を回避できます。 これらのエントリは、 flask 1.0.xを使用して古いバージョンをインストールするように推論サーバーに指示します。

推論サーバーの起動時に ImportError または ModuleNotFoundError が発生する

推論サーバーの起動時に、ImportError、ModuleNotFoundError、opencensus、jinja2など、特定のモジュールでmarkupsafeまたはclickが発生する場合があります。 次の例は、エラー メッセージを示しています。

ImportError: cannot import name 'Markup' from 'jinja2'

インポートとモジュールのエラーは、Flask の依存関係を互換性のあるバージョンにピン留めしないバージョン 0.4.10 以前のバージョンの推論サーバーを使用すると発生します。 この問題を回避するには、新しいバージョンの推論サーバーをインストールします。

その他の一般的な問題

その他の一般的なオンライン エンドポイントの問題は、Conda のインストールと自動スケーリングに関連しています。

Conda のインストールに関する問題

MLflow デプロイに関する問題は、一般に、conda.yml ファイルに指定されたユーザー環境のインストールに関する問題に起因しています。

Conda のインストールに関する問題をデバッグするには、次のステップを試してください。

1. Conda のインストール ログを確認します。 コンテナーがクラッシュした場合、または起動に時間がかかりすぎる場合は、Conda 環境の更新が正しく解決できなかった可能性があります。
2. conda env create -n userenv -f <CONDA_ENV_FILENAME> コマンドを使用して mlflow conda ファイルをローカルにインストールします。
3. ローカルでエラーが発生した場合は、再デプロイする前に、Conda 環境を解決し、機能環境を作成してみてください。
4. ローカルで解決されてもコンテナーがクラッシュする場合は、デプロイに使用される SKU サイズが小さすぎる可能性があります。
   • Conda パッケージのインストールは実行時に行われるため、SKU サイズが小さすぎて conda.yml 環境ファイルのすべてのパッケージに対応できない場合、コンテナーがクラッシュする可能性があります。
   • Standard_F4s_v2 VM は SKU の開始サイズとして適していますが、Conda ファイルで指定されている依存関係によっては、より大きな VM が必要になる場合があります。
   • Kubernetes オンライン エンドポイントの場合、Kubernetes クラスターには、少なくとも 4 つの vCPU コアと 8 GB のメモリが必要です。

自動スケール機能の問題

自動スケーリングで問題が発生した場合は、「Azure Monitor の自動スケーリングのトラブルシューティング」を参照してください。

Kubernetes オンライン エンドポイントの場合、Azure Machine Learning 推論ルーターは、Kubernetes クラスター上のすべてのモデル デプロイの自動スケーリングを処理するフロントエンド コンポーネントです。 詳細については、「Kubernetes 推論ルーティングの自動スケーリング」を参照してください。

関連するコンテンツ

• オンライン エンドポイントを使用して機械学習モデルをデプロイおよびスコア付けする
• オンライン エンドポイントの安全なロールアウト
• オンライン エンドポイント YAML の参照
• Kubernetes コンピューティングのトラブルシューティング