トラブルシューティング

クラウドでモデルのトレーニングや予測の取得を行うときに発生するエラーの原因を突き止めるのが難しいことがあります。このページでは、問題を見つけてデバッグする方法について説明します。

サードパーティのフレームワークに関するサポートを受ける

AI Platform では、サードパーティの機械学習フレームワークである scikit-learn または XGBoost を利用して、予測を行うことができます。ただし、AI Platform では、これらのサードパーティのフレームワークに対するサポートは行っていません。

サードパーティのフレームワークのバグや特徴に関するリクエストについては、次のように報告してください。

コマンドライン ツール

エラー: (gcloud)無効な選択肢: 'ml-engine'。

このエラーは、gcloud の更新が必要であることを示しています。gcloud を更新するには、次のコマンドを実行します。

gcloud components update
エラー: (gcloud)認識されない引数: --framework=SCIKIT_LEARN。

このエラーは、gcloud の更新が必要であることを示しています。gcloud を更新するには、次のコマンドを実行します。

gcloud components update
エラー: (gcloud)認識されない引数: --framework=XGBOOST。

このエラーは、gcloud の更新が必要であることを示しています。gcloud を更新するには、次のコマンドを実行します。

gcloud components update
エラー: (gcloud)モデルの読み込み失敗: 読み込みに失敗したモデル: /tmp/model/0001/model.pkl. '\x03'. (エラーコード: 0)

このエラーは、モデルのエクスポートに間違ったライブラリが使用されたことを意味します。この問題を解決するには、正しいライブラリを使用してモデルを再度エクスポートします。たとえば、model.pkl というモデルをエクスポートするには pickle ライブラリを使用し、model.joblib というモデルをエクスポートするには joblib ライブラリを使用します。

Python のバージョン

エラー: 不正なモデルが検出され、次のエラーが発生しました。「モデルの読み込み失敗: 読み込みに失敗した
モデル: /tmp/model/0001/model.pkl. サポートされていない pickle プロトコル: 3。必ず
モデルが Python 2 でエクスポートされていることを確認してください。それ以外の場合は、
モデルをデプロイするときに python_version パラメータを修正してください。現在、
python_version に指定できるのは 2.7 と 3.5 だけです。(エラーコード: 0)
このエラーは、Python 3 でエクスポートされたモデルファイルが、Python 2.7 が設定された AI Platform モデル バージョンのリソースにデプロイされたことを意味します。

この問題を解決するには:

  • 新しいモデル バージョンのリソースを作成して、python_version を 3.5 に設定します。
  • 同じモデルファイルを新しいモデル バージョンのリソースにデプロイします。

virtualenv コマンドが見つかりません

virtualenv をアクティブにしようとしたときにこのエラーが発生した場合、考えられる 1 つのソリューションは、virtualenv を含むディレクトリを $PATH 環境変数に追加することです。この変数を変更すると、ファイルの完全なパスを入力せずに virtualenv コマンドを使用できます。

まず、次のコマンドを実行して virtualenv をインストールします。

pip install --user --upgrade virtualenv

$PATH 環境変数の変更を促すプロンプトが表示され、virtualenv スクリプトのパスが指定されます。macOS では、/Users/[YOUR-USERNAME]/Library/Python/[YOUR-PYTHON-VERSION]/bin のようなパスが表示されます。

シェルが環境変数を読み込むファイルを開きます。macOS では、これは通常 ~/.bashrc または ~/.bash_profile です。

次の行を追加し、[VALUES-IN-BRACKETS] を適切な値に置き換えます。

export PATH=$PATH:/Users/[YOUR-USERNAME]/Library/Python/[YOUR-PYTHON-VERSION]/bin

最後に、次のコマンドを実行して、更新された .bashrc(または .bash_profile)ファイルを読み込みます。

source ~/.bashrc

ジョブログの使用

トラブルシューティングを行うには、最初に Stackdriver Logging によって記録されたジョブログを調べることをおすすめします。

オンライン予測のロギング

オンライン予測リクエストを行ったときに、デフォルトではログは生成されません。モデルリソースを作成するときに、次の方法で Stackdriver Logging を有効にすることができます。

gcloud

--enable-logging フラグを指定して、gcloud ml-engine models create を実行します。

Python

projects.models.create の呼び出しに使用する Model リソースで、onlinePredictionLoggingTrue に設定します。

ログを探す

ジョブログには、オンライン予測オペレーションのすべてのイベントが記録されます。エラーのトラブルシューティングの最初のステップは一般的に、そのプロセスのログを調べて、記録されたイベントのうちクラスタ内の他のプロセスのものを除外することです。このセクションの例では、このフィルタリングを示しています。

ログのフィルタリングは、コマンドラインからでも、Google Cloud Platform Console の [Stackdriver Logging] セクションからでも行うことができます。どちらの場合も、次に示すメタデータ値を必要に応じてフィルタの中で使用します。

メタデータ項目 次の条件を満たすものを表示するフィルタ
resource.type "cloud_ml_job" に等しい。
resource.labels.job_id ジョブ名に等しい。
resource.labels.task_name "master-replica-0" に等しい(マスター ワーカーのログエントリのみを読み取る場合)。
severity ERROR 以上(エラー状態に対応するログエントリのみを読み取る場合)。

コマンドライン

gcloud beta logging read を使用して必要なクエリを作成します。たとえば次のようなものがあります。

各例は、次に示す環境変数に依存しています。

PROJECT="my-project-name"
JOB="my_job_name"

好みに応じて、文字列リテラルを代わりに入力できます。

ジョブログを画面に出力するには:
gcloud beta ml-engine jobs stream-logs $JOB

gcloud ml-engine jobs stream-logs のすべてのオプションを参照してください。

マスター ワーカーのログを画面に出力するには:
gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\""
ログに記録されたエラーのうち、マスター ワーカーのものだけを画面に出力するには:
gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\" and severity>=ERROR"

上記の例は、AI Platform のトレーニング ジョブのログをフィルタリングする最も一般的なケースを示しています。Stackdriver Logging には、フィルタリングのための便利なオプションが多数あり、検索を絞り込む必要がある場合に使用できます。高度なフィルタリングのドキュメントに、これらのオプションの詳細な説明があります。

Console

  1. GCP Console で AI Platform の [ジョブ] ページを開きます。

    GCP Console でジョブを開く

  2. 失敗したジョブを [ジョブ] ページの一覧から選択して詳細情報を表示します。

AI Platform のジョブリストに、失敗したジョブが表示されています。

  1. [ログを表示] をクリックして Stackdriver Logging を開きます。

失敗したジョブのジョブ詳細ページ。

Stackdriver Logging に直接移動することもできますが、ジョブを見つけるというステップが必要になります。

  1. リソース セレクタを展開します。
  2. リソースリストで AI Platform のジョブを展開します。
  3. job_id リストの中でジョブ名を見つけます(ジョブ名の最初の数文字を検索ボックスに入力すると、表示されるジョブを絞り込めます)。
  4. ジョブのエントリを展開し、タスクリストから master-replica-0 を選択します。

ログ フィルタ セレクタがすべて展開されています。

ログからの情報の取得

ジョブの正しいログが見つかり、フィルタリングして master-replica-0 だけが表示される状態になったら、ログに記録されたイベントを調べて問題の発生源を見つけます。これには標準的な Python のデバッグ手順が含まれますが、次のことに注意してください。

  • イベントの重大度はいくつかのレベルに分かれています。イベントをフィルタリングすると、特定のレベル(エラーだけ、またはエラーと警告など)のイベントだけを表示できます。
  • 問題が発生したためトレーナーが回復不能なエラー状態(戻りコード > 0)で終了した場合は、例外としてログに記録され、その前にスタック トレースが記録されます。

どのセクションも展開されていないログエントリ

  • さらに情報を入手するには、記録された JSON メッセージの中のオブジェクトを展開します(右向き矢印付きで、内容は {...} と表示されています)。たとえば、jsonPayload を展開すると、スタック トレースはメインのエラーの説明よりも読みやすい形式で表示されます。

JSON ペイロード セクションが展開されているログエントリ

  • エラーの中には、再試行可能なエラーもあります。このようなエラーには一般的に、スタック トレースが含まれていないため、診断が難しくなることがあります。

予測のトラブルシューティング

このセクションでは、予測を取得するときに発生する一般的な問題をまとめています。

オンライン予測の特定の条件の処理

このセクションでは、一部のユーザーに影響を及ぼすことが知られているオンライン予測エラー条件に関するガイダンスを示します。

予測の完了までに時間がかかりすぎる(30~180 秒)

オンライン予測の遅さの原因として最も一般的なものは、処理ノードが 0 からスケールアップされることです。モデルに対する予測リクエストが絶えず行われる場合は、予測を処理できる状態のノードが 1 つ以上維持されます。モデルが予測を処理しない時間が長期に及んだ場合は、サービスが自動的に「スケールダウン」し、使用可能なノードは 0 になります。このようなスケールダウンの後に行われた予測リクエストは、結果が返されるまで通常よりも長い時間がかかりますが、これは処理するためのノードのプロビジョニングが必要になるためです。

HTTP ステータス コード

オンライン予測リクエストでエラーが発生すると、通常は HTTP ステータス コードがサービスから返されます。よく発生するコードと、オンライン予測におけるその意味を次に示します。

429 - メモリ不足

処理ノードでのモデルの実行中に、メモリの空きがなくなりました。予測ノードに割り当てられたメモリを増やす方法は、この時点ではありません。モデルを実行できるようにするには、次のことを試してみてください。

  • 次の方法でモデルを小さくします。
    • 精度の低い変数を使用する。
    • 連続データを量子化する。
    • 他の入力特徴のサイズを小さくする(たとえば、ボキャブラリのサイズを小さくする)。
  • バッチのインスタンス数を減らしてリクエストをもう一度送信する。
429 - 保留中のリクエストが多すぎます

モデルが処理できる以上のリクエストが発生しています。自動スケーリングを使用している場合は、システムがスケールアップできる速さを超えてリクエストが発生しています。

自動スケーリングを使用しているときは、指数バックオフを指定してリクエストを再送信してみてください。このようにすると、システムに調整する時間を与えることができます。

429 - 割り当て

Google Cloud Platform プロジェクトのリクエスト数は、100 秒あたり 10,000 件(1 秒あたり約 100 件)に制限されています。リクエストの一時的な急増によりこのエラーが発生した場合は、指数バックオフを使用して再試行するとすべてのリクエストを時間どおりに処理できることがあります。このコードが返されることが続く場合は、割り当ての増加をリクエストしてください。詳細については、割り当てのページをご覧ください。

503 - ご利用のコンピュータ ネットワークから通常以上のトラフィックが検出されました

単一の IP からモデルが受け取るリクエストの頻度が高すぎるため、サービス拒否攻撃が疑われています。リクエストの送信を 1 分間停止してから、頻度を下げて送信を再開してください。

500 - モデルを読み込めませんでした

システムがモデルを読み込むことができませんでした。次のステップを試してください。

  • トレーナーがエクスポートしているモデルが正しいことを確認します。
  • gcloud ml-engine local predict コマンドを使用してテスト予測を試します。
  • モデルを再度エクスポートして、再試行します。

リクエストの内容に関するエラー メッセージ

次に示すメッセージはすべて、予測入力に関係しています。

「リクエスト本文が空白であるか、不適切または無効な JSON があります」
リクエスト内の JSON を解析できなかったか、リクエストが空です。JSON を無効にするエラーや省略がメッセージにないかどうかを確認してください。
「リクエスト本文にインスタンス フィールドが見つかりません」
リクエスト本文の形式が正しくありません。リクエスト本文は、JSON オブジェクトであり、キーは 1 つだけで名前が "instances" であり、この中にすべての入力インスタンスのリストが格納されている必要があります。
リクエストの作成時に、JSON のエンコーディング エラーが発生しました

リクエストの中に base64 でエンコードされたデータがありますが、適切な JSON 形式ではありません。base64 でエンコードされた文字列はそれぞれ、"b64" という名前の単一のキーを持つオブジェクトで表す必要があります。次に例を示します。

{"b64": "an_encoded_string"}

base64 エラーは、base64 でエンコードされていないバイナリデータがある場合にも発生します。データをエンコードして、上記の例に示した形式で指定してください。

クラウドの予測に要する時間がデスクトップよりも長い

オンライン予測は、大量の予測リクエストを短時間で処理するスケーラブルなサービスとして設計されています。このサービスは、処理リクエストすべての全体的なパフォーマンスを高めるように最適化されています。スケーラビリティに重点を置いていることから、パフォーマンス特性はローカルマシンで少数の予測を生成する場合とは異なるものとなります。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

scikit-learn と XGBoost の AI Platform