翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR の ErrorDetail 情報を含むエラーコード
EMR クラスターがエラーで終了すると、`DescribeCluster` と `ListClusters` の各 API からエラーコードとエラーメッセージが返ります。クラスターエラーによっては、`ErrorDetail` データ配列が障害のトラブルシューティングに役立つ場合があります。
`ErrorDetail` 配列を持つエラーでは、次の情報を確認できます。
**`ErrorCode`**
プログラムによるアクセスに使用できる一意のエラーコード。
**`ErrorData`**
キーと値のペアを示す識別子のリスト。識別子は、プログラミングや手動検索に使用できる。エラーコード内の `ErrorData` 値の詳細については、エラーコードのトラブルシューティングページを参照してください。
**`ErrorMessage`**
エラーの説明。Amazon EMR ドキュメントの詳細情報へのリンクが記載されている。
`ErrorMessage` のテキストは、変更される可能性があるため、解析はお勧めしません。
**Topics**
+ [ブートストラップ障害](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [内部エラー](emr-troubleshoot-error-errordetail-internal.md)
+ [検証の失敗](emr-troubleshoot-error-errordetail-validation.md)
# Amazon EMR のブートストラップ障害のエラーコード
次のセクションでは、ブートストラップ障害のエラーコードに対するトラブルシューティングについて説明します。
**Topics**
+ [BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md)
+ [BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md)
# BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE
## 概要:
クラスターが `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE` エラーで終了した場合、プライマリインスタンスでブートストラップアクションが失敗したことを示しています。ブートストラップアクションの詳細については、[Amazon EMR クラスターで追加のソフトウェアをインストールするブートストラップアクションを作成する](emr-plan-bootstrap.md) を参照してください。
## 解決策
このエラーを解決するには、返った API エラーの内容を確認して、ブートストラップアクションスクリプトを変更します。その後、更新したブートストラップアクションを使用して、クラスターを新規作成します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
ブートストラップアクションが失敗したプライマリインスタンスの ID。
**`bootstrap-action`**
失敗したブートストラップアクションの序数。`bootstrap-action` 値 `1` を持つスクリプトによって、そのインスタンスで最初のアクションが実行されます。
**`return-code`**
失敗したブートストラップアクションのリターンコード。
**`amazon-s3-path`**
ブートストラップアクションが失敗した、Amazon S3 のロケーション。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
ブートストラップアクションエラーの根本原因を特定して修正するには、次のステップを実行し、その後、新規クラスターを起動します。
1. Amazon S3 のブートストラップアクションログファイルを確認して、障害の根本原因を特定します。Amazon EMR ログの表示方法については、[Amazon EMR ログファイルを表示する](emr-manage-view-web-log-files.md) を参照してください。
1. インスタンスの作成時にクラスターログを有効にした場合は、`stdout` ログで詳細を確認してください。ブートストラップアクションの `stdout` ログは、次に示す Amazon S3 のロケーションにあります。
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
クラスターログの詳細については、「[Amazon EMR クラスターのログ記録とデバッグを設定する](emr-plan-debugging.md)」を参照してください。
1. ブートストラップアクションが失敗したかどうかを判断するには、`stdout` ログ内の例外と `return-code` 内の値を確認します。`ErrorData`
1. 前のステップで得た情報に基づいてブートストラップアクションを修正し、例外の回避や、例外が発生した際の適切な処理を行えるようにします。
1. 更新したブートストラップアクションを使用して新規クラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## 概要:
クラスターが `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` エラーで終了した場合、プライマリインスタンスが指定された Amazon S3 のロケーションからブートストラップアクションスクリプトをダウンロードできなかったことを示しています。この場合、次の原因が考えられます。
+ ブートストラップアクションスクリプトファイルが、指定した Amazon S3 のロケーションにない。
+ クラスターの Amazon EC2 インスタンスに設定されたサービスロール (*Amazon EMR の EC2 インスタンスプロファイル*とも呼ばれます) に、ブートストラップアクションスクリプトのある Amazon S3 バケットへのアクセス権限がない。サービスロールの詳細については、「[クラスター EC2 インスタンスのサービスロール (EC2 インスタンスプロファイル)](emr-iam-role-for-ec2.md)」を参照してください。
ブートストラップアクションの詳細については、[Amazon EMR クラスターで追加のソフトウェアをインストールするブートストラップアクションを作成する](emr-plan-bootstrap.md) を参照してください。
## 解決策
このエラーを解決するには、プライマリインスタンスがブートストラップアクションスクリプトに適切にアクセスできるようにします。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
ブートストラップアクションが失敗したプライマリインスタンスの ID。
**`bootstrap-action`**
失敗したブートストラップアクションの序数。`bootstrap-action` 値 `1` を持つスクリプトによって、そのインスタンスで最初のアクションが実行されます。
**`amazon-s3-path`**
ブートストラップアクションが失敗した、Amazon S3 のロケーション。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
ブートストラップアクションエラーの根本原因を特定して修正するには、次のステップを実行し、その後、新規クラスターを起動します。
**トラブルシューティングのステップ**
1. `ErrorData` 配列の `amazon-s3-path` 値を使用して、関連するブートストラップアクションスクリプトを Amazon S3 内で検索します。
1. インスタンスの作成時にクラスターログを有効にした場合は、`stdout` ログで詳細を確認してください。ブートストラップアクションの `stdout` ログは、次に示す Amazon S3 のロケーションにあります。
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
クラスターログの詳細については、「[Amazon EMR クラスターのログ記録とデバッグを設定する](emr-plan-debugging.md)」を参照してください。
1. ブートストラップアクションが失敗したかどうかを判断するには、`stdout` ログ内の例外と `return-code` 内の値を確認します。`ErrorData`
1. 前のステップで得た情報に基づいてブートストラップアクションを修正し、例外の回避や、例外が発生した際の適切な処理を行えるようにします。
1. 更新したブートストラップアクションを使用して新規クラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## 概要:
`BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` エラーは、プライマリインスタンスが、指定された Amazon S3 バケットから自分でダウンロードしたブートストラップアクションスクリプトを見つけられないことを示しています。
## 解決策
このエラーを解決するには、プライマリインスタンスがブートストラップアクションスクリプトに適切にアクセスできるようにします。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
ブートストラップアクションが失敗したプライマリインスタンスの ID。
**`bootstrap-action`**
失敗したブートストラップアクションの序数。`bootstrap-action` 値 `1` を持つスクリプトによって、そのインスタンスで最初のアクションが実行されます。
**`amazon-s3-path`**
ブートストラップアクションが失敗した、Amazon S3 のロケーション。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
ブートストラップアクションエラーの根本原因を特定して修正するには、次のステップを実行し、その後、新規クラスターを起動します。
1. 関連するブートストラップアクションスクリプトを Amazon S3 内で検索するには、`ErrorData` 配列の `amazon-s3-path` 値を使用します。
1. Amazon S3 のブートストラップアクションログファイルを確認して、障害の根本原因を特定します。Amazon EMR ログの表示方法については、[Amazon EMR ログファイルを表示する](emr-manage-view-web-log-files.md) を参照してください。
**注記**
クラスターのログを有効にしていない場合は、同じ設定とブートストラップアクションを使用して、クラスターを新規作成する必要があります。クラスターログが有効になっていることを確認するには、「[Amazon EMR クラスターのログ記録とデバッグを設定する](emr-plan-debugging.md)」を参照してください。
1. ブートストラップアクションの `stdout` ログを確認して、プライマリインスタンスの `/emr/instance-controller/lib/bootstrap-actions` フォルダにあるファイルを削除するカスタムプロセスがないことを確認します。ブートストラップアクションの `stdout` ログは、次に示す Amazon S3 のロケーションにあります。
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. 更新したブートストラップアクションを使用して新規クラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY
## 概要:
`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` エラーは、必要なソフトウェアをインストールする時にプライマリインスタンスに十分なディスク容量がないことを示します。
## 解決策
このエラーを解決するには、プライマリインスタンスにルートボリュームに十分なディスク容量があることを確認します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
ディスク容量が不十分なプライマリインスタンスの ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
1. クラスターの EBS ルートデバイスボリュームのベストプラクティスを確認します。「*Amazon EMR 管理ガイド*」の「[Amazon EBS ルートデバイスボリュームのカスタマイズ](emr-custom-ami-root-volume-size.md)」を参照してください。
1. より大きな EBS ルートデバイスボリュームサイズで新しいクラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER
## 概要:
`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` エラーは、必要なソフトウェアをインストールする時に、1 つ以上のワーカーインスタンスに十分なディスク容量がないことを示します。
## 解決策
このエラーを解決するには、ワーカーインスタンスにルートボリュームに十分なディスク容量があることを確認します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`worker-instance-ids`**
ディスク容量が不十分なワーカーインスタンスの ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
1. クラスターの EBS ルートデバイスボリュームのベストプラクティスを確認します。「*Amazon EMR 管理ガイド*」の「[Amazon EBS ルートデバイスボリュームのカスタマイズ](emr-custom-ami-root-volume-size.md)」を参照してください。
1. より大きな EBS ルートデバイスボリュームサイズで新しいクラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## 概要:
`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` エラーは、プライマリインスタンスが設定された外部 Hive メタストアへの接続を確立できないことを示します。
## 解決策
このエラーを解決するには、外部 Hive メタストアが正しく設定されており、プライマリインスタンスが接続できることを確認します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
設定された外部 Hive メタストアへの接続を確立できないプライマリインスタンスの ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
1. Hive の外部メタストアを設定するためのベストプラクティスを確認してください。「[Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html)」を参照してください。
1. 更新したクラスター設定を使用して、新規クラスターを起動します。
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## 概要:
`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` エラーは、1 つ以上のワーカーインスタンスが、設定された外部 Hive メタストアへの接続を確立できないことを示します。
## 解決策
このエラーを解決するには、外部 Hive メタストアが正しく設定されており、ワーカーインスタンスが接続できることを確認します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`worker-instance-ids`**
設定された外部 Hive メタストアへの接続を確立できないワーカーインスタンスの ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
1. Hive の外部メタストアを設定するためのベストプラクティスを確認してください。「[Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html)」を参照してください。
1. 更新したクラスター設定を使用して、新規クラスターを起動します。
# Amazon EMR の内部エラーコード
次のセクションでは、内部エラーのコードに対するトラブルシューティングについて説明します。容量の不足や容量の欠如のコードを含みます。
**Topics**
+ [INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md)
# INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ
## 概要:
クラスターが `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` エラーで終了した場合、選択されたアベイラビリティーゾーンに Amazon EC2 インスタンスタイプのリクエストを満たすだけのキャパシティがなかったことを示しています。クラスターに選択したサブネットによって、アベイラビリティーゾーンが決まります。Amazon EMR のサブネットの詳細については、「[Amazon EMR 用の VPC でネットワークを設定する](emr-plan-vpc-subnet.md)」を参照してください。
## 解決策
このエラーを解決するには、インスタンスタイプの設定を変更し、更新済みのリクエストによって、クラスターを新規作成します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`instance-type`**
容量が不足しているインスタンスタイプ。
**`availability-zone`**
サブネットが関連付けられたアベイラビリティーゾーン。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
クラスター設定エラーの根本原因を特定して修正するには、次のステップを実行します。
+ クラスター設定のベストプラクティスを確認します。「*Amazon EMR 管理ガイド*」の「[Amazon EMR クラスターインスタンスタイプの設定とスポットインスタンスのベストプラクティス](emr-plan-instances-guidelines.md)」を参照してください。
+ 起動に関する問題をトラブルシューティングし、設定を確認します。「*Amazon EC2 ユーザーガイド*」の「[インスタンス起動に関する問題のトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html)」を参照してください。
+ 更新したクラスター設定を使用して、新規クラスターを起動します。
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## 概要:
クラスターが `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` エラーで終了した場合、最大スポット料金以下でインスタンスを利用できず、Amazon EMR がプライマリノードのスポットインスタンス要求を処理できなかったことを示しています。詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)」を参照してください。
## 解決策
このエラーを解決するには、クラスターのインスタンスタイプを対象料金の範囲内で指定するか、そのインスタンスタイプの料金の上限を引き上げてください。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
障害が発生したクラスターのプライマリインスタンス ID。
**`instance-type`**
容量が不足しているインスタンスタイプ。
**`availability-zone`**
サブネットが存在するアベイラビリティーゾーン。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
次のステップを実行してクラスター設定戦略のトラブルシューティングを行い、新規クラスターを起動してください。
1. Amazon EC2 スポットインスタンスのベストプラクティスと、クラスター設定戦略の両方を確認します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 スポットのベストプラクティス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)」と、「[Amazon EMR クラスターインスタンスタイプの設定とスポットインスタンスのベストプラクティス](emr-plan-instances-guidelines.md)」を参照してください。
1. インスタンスタイプ設定またはアベイラビリティーゾーンを変更し、更新済みのリクエストでクラスターを新規作成します。
1. 問題が解決しない場合は、オンデマンドキャパシティをプライマリインスタンスに使用してください。
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## 概要:
クラスターが `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` エラーで終了した場合、プライマリノードのスポットインスタンスリクエストを満たすだけのキャパシティがなかったことを示しています。詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)」を参照してください。
## 解決策
このエラーを解決するには、クラスターのインスタンスタイプを対象料金の範囲内で指定するか、そのインスタンスタイプの料金の上限を引き上げてください。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`primary-instance-id`**
障害が発生したクラスターのプライマリインスタンス ID。
**`instance-type`**
容量が不足しているインスタンスタイプ。
**`availability-zone`**
サブネットが関連付けられたアベイラビリティーゾーン。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
次のステップを実行してクラスター設定戦略のトラブルシューティングを行い、新規クラスターを起動してください。
1. Amazon EC2 スポットインスタンスのベストプラクティスと、クラスター設定戦略の両方を確認します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 スポットのベストプラクティス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)」と、「[Amazon EMR クラスターインスタンスタイプの設定とスポットインスタンスのベストプラクティス](emr-plan-instances-guidelines.md)」を参照してください。
1. インスタンスタイプ設定を変更し、更新済みのリクエストでクラスターを新規作成します。
1. 問題が解決しない場合は、オンデマンドキャパシティをプライマリインスタンスに使用してください。
# Amazon EMR の検証失敗のエラーコード
次のセクションでは、検証失敗のエラーコードに対するトラブルシューティングについて説明します。
**Topics**
+ [VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md)
+ [VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md)
# VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC
## 概要:
クラスターが `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` エラーで終了した場合、クラスターのサブネットと、クラスターの参照先サブネットが異なる Virtual Private Cloud (VPC) に属していることを示しています。Amazon EMR でクラスターを起動するには、VPC のサブネット全体でインスタンスフリート設定を使用します。インスタンスフリートの詳細については、「*Amazon EMR 管理ガイド*」の「[Amazon EMR クラスターのインスタンスフリートの計画と設定](emr-instance-fleet.md)」を参照してください。
## 解決策
このエラーを解決するには、対象クラスターのサブネットが属する VPC のサブネットを使用します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`vpc`**
各サブネット: VPC ペア、サブネットが属する VPC の ID。
**`subnet`**
各サブネット: VPC ペア、サブネット ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
エラーを特定し、修正するには、次のステップを実行します。
1. `ErrorData` 配列にリストされているサブネット ID を確認し、それらが EMR クラスターを起動する VPC に属していることを確認します。
1. サブネットの設定を変更します。次のいずれかの方法を使用すると、VPC 内の利用可能なパブリックサブネットとプライベートサブネットをすべて検索できます。
+ Amazon VPC コンソールに移動します。**Subnets** を選択し、クラスターの 内に存在するすべてのサブネットを一覧表示 AWS リージョン します。パブリックサブネットまたはプライベートサブネットのみを検索するには、**[パブリック IPv4 アドレスの自動割り当て]** フィルターを適用します。クラスターが使用する VPC 内のサブネットを検索して選択するには、**[VPC でフィルタリング]** オプションを使用します。サブネットの作成方法の詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[サブネットの作成](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)」を参照してください。
+ AWS CLI を使用して、クラスターが使用する VPC で使用可能なすべてのパブリックサブネットとプライベートサブネットを検索します。詳細については、[describe-subnets](https://amazonaws.com/ec2/describe-subnets.html) API を参照してください。VPC にサブネットを新規作成する方法については、[create-subnet](https://amazonaws.com/ec2/create-subnet.html) API を参照してください。
1. クラスターと同じ VPC のサブネットを使用して新規クラスターを起動します。
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## 概要:
クラスターが `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` エラーで終了した場合、クラスターのセキュリティグループと、クラスターに割り当てたセキュリティグループが異なる Virtual Private Cloud (VPC) に属していることを示しています。セキュリティグループの詳細については、「[Amazon EMR マネージドセキュリティグループと追加セキュリティグループを指定する](emr-sg-specify.md)」と「[Amazon EMR クラスターのセキュリティグループを使用してネットワークトラフィックを制御する](emr-security-groups.md)」を参照してください。
## 解決策
このエラーを解決するには、対象クラスターのセキュリティグループが属する VPC のセキュリティグループを使用します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`vpc`**
セキュリティグループ: VPC ペア、セキュリティグループが属する VPC の ID。
**`security-group`**
セキュリティグループ: VPC ペア、セキュリティグループ ID。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
エラーを特定し、修正するには、次のステップを実行します。
1. `ErrorData` 配列にリストされているセキュリティグループ ID を確認し、それらが EMR クラスターを起動する VPC に属していることを確認します。
1. Amazon VPC コンソールに移動します。**[セキュリティグループ]** を選択すると、選択したリージョン内のセキュリティグループがすべて一覧表示されます。クラスターと同じ VPC のセキュリティグループを検索し、セキュリティグループの設定を変更します。
1. クラスターと同じ VPC のセキュリティグループを使用して新規クラスターを起動します。
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## 概要:
クラスターが `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` エラーで終了した場合、プライマリインスタンスへの SSH 接続時に、有効でない Amazon EC2 キーペアが使用されたことを示しています。キーペア名が正しくないか、リクエストされた にキーペアが存在しない可能性があります AWS リージョン。キーペアの詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 のキーペアと Linux インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
## 解決策
このエラーを解決するには、有効な SSH キーペア名を使用してクラスターを新規作成します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`ssh-key`**
クラスターを作成したときに指定した SSH キーペア名。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
エラーを特定し、修正するには、次のステップを実行します。
1. *keypair*.pem ファイルを確認し、Amazon EMR コンソールに表示される SSH キーの名前と一致することを確認します。
1. Amazon EC2 コンソールに移動します。使用した SSH キー名が、クラスター AWS リージョン が使用する で使用可能であることを確認します。アカウント ID の AWS リージョン 横の は、 の上部にあります AWS マネジメントコンソール。
1. 有効な SSH キー名を使用して新規クラスターを起動します。
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## 概要:
クラスターが `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` エラーで終了した場合、クラスターの AWS リージョン とアベイラビリティーゾーンが、指定したインスタンス (1 つ以上のインスタンスグループに属している) のタイプをサポートしていないことを示しています。リージョン内のアベイラビリティーゾーンによっては、インスタンスタイプが Amazon EMR のサポート対象となる場合とならない場合があります。リージョン内のアベイラビリティーゾーンは、クラスター用に選択したサブネットによって決定されます。Amazon EMR がサポートするインスタンスタイプとリージョンのリストについては、「[Amazon EMR でサポートされているインスタンスタイプ](emr-supported-instance-types.md)」を参照してください。
## 解決策
このエラーを解決するには、クラスターをリクエストするリージョンとアベイラビリティーゾーンで Amazon EMR がサポートする、クラスターのインスタンスタイプを指定します。
障害が発生した EMR クラスターのトラブルシューティングを行うには、`DescribeCluster` と `ListClusters` の各 API から返った `ErrorDetail` の情報を参照してください。詳細については、「[Amazon EMR の ErrorDetail 情報を含むエラーコード](emr-troubleshoot-error-errordetail.md)」を参照してください。返った `ErrorDetail` 内の `ErrorData` 配列によって、次の情報を確認できます。
**`instance-types`**
サポートされていないインスタンスタイプのリスト。
**`availability-zones`**
サブネットが関連付けられたアベイラビリティーゾーンのリスト。
**`public-doc`**
エラーコードドキュメントの公開 URL。
## 完了すべきステップ
エラーを特定し、修正するには、次のステップを実行します。
1. を使用して AWS CLI 、アベイラビリティーゾーンで使用可能なインスタンスタイプを取得します。これを行うには、 `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` コマンドを使用して、使用可能なインスタンスタイプを場所 (AWS リージョン またはアベイラビリティーゾーン) でフィルタリングします。例えば、次のコマンドを使用すると、指定した AZ (`us-east-2a`) で提供されているインスタンスタイプが返ります。
```
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort
```
利用可能なインスタンスタイプを確認にする方法については、「[Amazon EC2 インスタンスタイプの検索](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)」を参照してください。
1. 対象のクラスターと同じリージョンとアベイラビリティーゾーンで利用可能なインスタンスタイプを確認したら、次の解決策のいずれかを選択して実行します。
1. クラスターを新規作成します。次に、選択したインスタンスタイプが利用可能で Amazon EMR によってサポートされているアベイラビリティーゾーンに属するクラスターのサブネットを選択します。
1. 障害が発生したクラスターが属していたリージョンと Amazon EC2 サブネットに新しいクラスターを作成します。ただし、使用するインスタンスタイプは、Amazon EMR がそのロケーションでサポートしているタイプを選択します。
Amazon EMR がサポートするインスタンスタイプとリージョンのリストについては、「[Amazon EMR でサポートされているインスタンスタイプ](emr-supported-instance-types.md)」を参照してください。インスタンスタイプの機能を比較するには、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types)」を参照してください。