クラウドでモデルのトレーニングや予測の取得の際に発生するエラーの原因を特定することは困難な場合があります。ここでは、AI Platform Prediction で発生した問題の検出とデバッグの方法を説明します。使用している機械学習フレームワークで問題が発生した場合は、機械学習フレームワークのドキュメントをご覧ください。
コマンドライン ツール
- エラー: （gcloud）無効な選択肢: 'ai-platform'。
このエラーは、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ライブラリを使用します。- エラー: （gcloud.ai-platform.jobs.submit.prediction）引数 --データ形式: 無効な選択肢: 'json'.
このエラーは、バッチ予測ジョブの送信時に、
--data-formatフラグの値としてjsonが指定されたことを意味します。JSONデータ形式を使用するには、--data-formatフラグの値としてtextを指定する必要があります。
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 Prediction モデル バージョンのリソースにデプロイされたことを意味します。
この問題を解決するには:
- 新しいモデル バージョンのリソースを作成して、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
ジョブログの使用
トラブルシューティングを行うには、最初に Cloud Logging によって記録されたジョブログを調べることをおすすめします。
さまざまなタイプのオペレーションのロギング
ログの内容は、次の各セクションで示すようにオペレーションのタイプによって異なります。
バッチ予測のログ
すべてのバッチ予測ジョブがログに記録されます。
オンライン予測のログ
オンライン予測リクエストを行ったときに、デフォルトではログは生成されません。モデルリソースを作成するときに、次の方法で Cloud Logging を有効にできます。
gcloud
gcloud ai-platform models create を実行するときに、--enable-logging フラグを指定します。
Python
projects.models.create に対する呼び出しに使用する Model リソースで onlinePredictionLogging を True に設定します。
ログを探す
ジョブのログには、オペレーションのすべてのイベントが記録されています。分散トレーニングを使用しているときは、クラスタ内のすべてのプロセスからのイベントがログに記録されます。分散型トレーニング ジョブを実行する場合は、ジョブレベルのログはマスター ワーカー プロセスのものとして報告されます。エラーのトラブルシューティングの最初のステップは一般的に、そのプロセスのログを調べて、記録されたイベントのうちクラスタ内の他のプロセスのものを除外することです。このセクションの例では、このフィルタリングを示しています。
ログのフィルタリングは、コマンドラインからでも、Google Cloud コンソールの [Cloud Logging] セクションからでも行えます。どちらの場合も、次に示すメタデータ値を必要に応じてフィルタの中で使用します。
| メタデータ項目 | 次の条件を満たすものを表示するフィルタ |
|---|---|
| resource.type | "cloud_ml_job" に等しい。 |
| resource.labels.job_id | ジョブ名に等しい。 |
| resource.labels.task_name | "master-replica-0" に等しい（マスター ワーカーのログエントリのみを読み取る場合）。 |
| 重要度 | ERROR 以上（エラー状態に対応するログエントリのみを読み取る場合）。 |
コマンドライン
gcloud beta logging read を使用して必要なクエリを作成します。たとえば次のようなものがあります。
各例は、次に示す環境変数に依存しています。
PROJECT="my-project-name"
JOB="my_job_name"
必要に応じて、文字列リテラルを代わりに入力することもできます。
ジョブログを画面に出力するには:
gcloud ai-platform jobs stream-logs $JOB
gcloud ai-platform 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 Prediction のトレーニング ジョブのログをフィルタリングする最も一般的なケースを示しています。Cloud Logging には、フィルタリングのための便利なオプションが多数あり、検索を絞り込む必要がある場合に使用できます。高度なフィルタリングのドキュメントに、これらのオプションの詳細な説明があります。
Console
Google Cloud コンソールで AI Platform Prediction の [ジョブ] ページを開きます。
失敗したジョブを [ジョブ] ページの一覧から選択して詳細情報を表示します。
- [ログを表示] をクリックして Cloud Logging を開きます。
Cloud Logging に直接移動することもできますが、ジョブを見つけるというステップが必要になります。
- リソース セレクタを展開します。
- リソースリストで AI Platform Prediction のジョブを展開します。
- job_id リストの中でジョブ名を見つけます（ジョブ名の最初の数文字を検索ボックスに入力すると、表示されるジョブを絞り込めます）。
- ジョブのエントリを展開し、タスクリストから
master-replica-0を選択します。
ログからの情報の取得
ジョブの正しいログが見つかり、フィルタリングして master-replica-0 だけが表示される状態になったら、ログに記録されたイベントを調べて問題の発生源を見つけます。これには標準的な Python のデバッグ手順が含まれますが、次のことに注意してください。
- イベントの重大度はいくつかのレベルに分かれています。イベントをフィルタリングすると、特定のレベル（エラーだけ、またはエラーと警告など）のイベントだけを表示できます。
- 問題が発生したためトレーナーが回復不能なエラー状態（戻りコード > 0）で終了した場合は、例外としてログに記録され、その前にスタック トレースが記録されます。
- さらに情報を入手するには、記録された JSON メッセージの中のオブジェクトを展開します（右向き矢印付きで、内容は {...} と表示されています）。たとえば、{...} を展開すると、スタック トレースはメインのエラーの説明よりも読みやすい形式で表示されます。
- エラーの中には、再試行可能なエラーもあります。このようなエラーには一般的に、スタック トレースが含まれていないため、診断が難しくなることがあります。
ロギングを最大限に活用
AI Platform Prediction トレーニング サービスは、自動的に次のイベントを記録します。
- サービス内部のステータス情報。
- トレーナー アプリケーションから
stderrに送信されるメッセージ。 - トレーナー アプリケーションから
stdoutに送信される出力テキスト。
トレーナー アプリケーションのエラーのトラブルシューティングを容易にするには、次のようにプログラミングすることをおすすめします。
- 意味のあるメッセージを stderr に送信します（たとえば logging を使用します）。
- なんらかの問題が生じたときは、最も論理的で記述的な例外を発生させます。
- 説明の文字列を例外オブジェクトに追加します。
Python のドキュメントに、例外に関する詳しい情報が記載されています。
予測のトラブルシューティング
このセクションでは、予測を取得するときに発生する一般的な問題をまとめています。
オンライン予測の特定の条件の処理
このセクションでは、一部のユーザーに影響を及ぼすことが知られているオンライン予測エラー条件に関するガイダンスを示します。
予測の完了までに時間がかかりすぎる（30～180 秒）
オンライン予測の遅さの原因として最も一般的なものは、処理ノードが 0 からスケールアップされることです。モデルに対する予測リクエストが絶えず行われる場合は、予測を処理できる状態のノードが 1 つ以上維持されます。モデルが予測を処理しない時間が長期に及んだ場合は、サービスが自動的に「スケールダウン」し、使用可能なノードは 0 になります。このようなスケールダウンの後に行われた予測リクエストは、結果が返されるまで通常よりも長い時間がかかりますが、これは処理するためのノードのプロビジョニングが必要になるためです。
HTTP ステータス コード
オンライン予測リクエストでエラーが発生すると、通常は HTTP ステータス コードがサービスから返されます。よく発生するコードと、オンライン予測におけるその意味を次に示します。
- 429 - メモリ不足
処理ノードでのモデルの実行中に、メモリの空きがなくなりました。予測ノードに割り当てられたメモリを増やす方法は、この時点ではありません。モデルを実行できるようにするには、次のことを試してみてください。
- 次の方法でモデルを小さくします。
- 精度の低い変数を使用する。
- 連続データを量子化する。
- 他の入力特徴のサイズを小さくする（たとえば、ボキャブラリのサイズを小さくする）。
- バッチのインスタンス数を減らしてリクエストをもう一度送信する。
- 次の方法でモデルを小さくします。
- 429 - 保留中のリクエストが多すぎます
モデルの処理能力を超えたリクエスト数が発生しています。自動スケーリングを使用している場合は、システムがスケーリングできる速さを超えてリクエストが発生しています。さらに、最小ノード値が 0 の場合は、この構成により、最初のノードが使用可能になるまで 100% のエラー率が発生する「コールド スタート」のシナリオになる可能性があります。
自動スケーリングを使用しているときは、指数バックオフを指定してリクエストを再送信してみてください。 指数バックオフを使用してリクエストを再送信すると、システムに調整する時間を与えることが可能です。
デフォルトでは、自動スケーリングは CPU 使用率が 60% を超えた場合にトリガーされ、構成可能です。
- 429 - 割り当て
Google Cloud Platform プロジェクトのリクエスト数は、100 秒あたり 10,000 件（1 秒あたり約 100 件）に制限されています。リクエストの一時的な急増によりこのエラーが発生した場合は、指数バックオフを使用して再試行するとすべてのリクエストを時間どおりに処理できることがあります。このコードが返されることが続く場合は、割り当ての増加をリクエストしてください。詳細については、割り当てのページをご覧ください。
- 503 - ご利用のコンピュータ ネットワークから通常以上のトラフィックが検出されました
単一の IP からモデルが受け取るリクエストの頻度が高すぎるため、サービス拒否攻撃が疑われています。リクエストの送信を 1 分間停止してから、頻度を下げて送信を再開してください。
- 500 - モデルを読み込めませんでした
システムがモデルを読み込むことができませんでした。次のステップを試してください。
- トレーナーがエクスポートしているモデルが正しいことを確認します。
gcloud ai-platform local predictコマンドを使用してテスト予測を試行します。- モデルを再度エクスポートして、再試行します。
予測リクエストのフォーマット エラー
次に示すメッセージはすべて、予測入力に関係しています。
- 「リクエスト本文が空白であるか、不適切または無効な JSON があります」
- リクエスト内の JSON を解析できなかったか、リクエストが空です。JSON を無効にするエラーや省略がメッセージにないかどうかを確認してください。
- 「リクエスト本文にインスタンス フィールドが見つかりません」 リクエスト本文の形式が正しくありません。
- リクエスト本文は、JSON オブジェクトであり、キーは 1 つだけで名前が
"instances"であり、この中にすべての入力インスタンスのリストが格納されている必要があります。 - リクエストの作成時に、JSON のエンコード エラーが発生しました
リクエストの中に base64 でエンコードされたデータがありますが、適切な JSON 形式ではありません。base64 でエンコードされた文字列はそれぞれ、
"b64"という名前の単一のキーを持つオブジェクトで表す必要があります。例:{"b64": "an_encoded_string"}base64 エラーは、base64 でエンコードされていないバイナリデータがある場合にも発生します。データをエンコードして、次のようにフォーマットします。
{"b64": base64.b64encode(binary_data)}詳細については、バイナリデータのフォーマットとエンコーディングをご覧ください。
クラウドの予測に要する時間がデスクトップよりも長い
オンライン予測は、大量の予測リクエストを短時間で処理するスケーラブルなサービスとして設計されています。このサービスは、処理リクエストすべての全体的なパフォーマンスを高めるように最適化されています。スケーラビリティに重点を置いていることから、パフォーマンス特性はローカルマシンで少数の予測を生成する場合とは異なるものとなります。
次のステップ
- サポートを利用する。
- Google API のエラーモデルの詳細を確認する。特に、
google.rpc.Codeで定義されている正規のエラーコードと、google/rpc/error_details.proto で定義されている標準エラーの詳細について学習する。 - トレーニング ジョブをモニタリングする方法を確認する。
- Cloud TPU での AI Platform Prediction の実行時、Cloud TPU についてのトラブルシューティングとよくある質問を参照して、診断と問題解決を行う。