翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon EMR クラスターオペレーション中のリソースエラー 次は、クラスターのリソースの制約により引き起こされる一般的なエラーです。このガイダンスでは、各エラーについて説明し、トラブルシューティングのヘルプを提供します。 **Topics** + [NO\$1SLAVE\$1LEFT で Amazon EMR クラスターが終了し、FAILED\$1BY\$1MASTER でコアノードが終了する](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md) + [Amazon EMR クラスターエラー: Cannot replicate block, only managed to replicate to zero nodes.](enough-hdfs-space.md) + [Amazon EMR クラスターエラー: EC2 QUOTA EXCEEDED](emr-EC2.md) + [Amazon EMR クラスターエラー: Too many fetch-failures](emr-troubleshoot-error-resource-1.md) + [Amazon EMR クラスターエラー: File could only be replicated to 0 nodes instead of 1](emr-troubleshoot-error-resource-2.md) + [Amazon EMR クラスターエラー: Deny-listed nodes](emr-troubleshoot-error-resource-3.md) + [Amazon EMR クラスターでのスロットリングエラー](emr-throttling-error.md) + [Amazon EMR クラスターエラー: インスタンスタイプはサポートされていません](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md) + [Amazon EMR クラスターエラー: EC2 is out of capacity](emr-EC2_INSUFFICIENT_CAPACITY-error.md) + [Amazon EMR クラスターエラー: HDFS replication factor error](emr-hdfs-insufficient-replication.md) + [Amazon EMR クラスターエラー: HDFS insufficient space error](emr-hdfs-insufficient-space.md) # NO\$1SLAVE\$1LEFT で Amazon EMR クラスターが終了し、FAILED\$1BY\$1MASTER でコアノードが終了する このエラーは通常、削除保護が無効になっており、すべてのコアノードが `yarn-site.xml` ファイルに対応する `yarn-site` 設定分類の最大使用率しきい値で指定したディスクストレージ容量を超過したことが原因で発生します。この値のデフォルト値は 90% です。コアノードのディスク使用率が使用率のしきい値を超えると、YARN NodeManager のヘルスサービスにより、ノードが `UNHEALTHY` として報告されます。この状態になっていると、Amazon EMR はノードを拒否リストに追加し、YARN コンテナを割り当てません。ノードの異常が 45 分間続いた場合、Amazon EMR は関連付けられている Amazon EC2 インスタンスを終了するために `FAILED_BY_MASTER` のマークを付けます。コアノードに関連付けられているすべての Amazon EC2 インスタンスに終了のマークが付けられると、ジョブを実行するリソースがなくなるため、クラスターはステータス `NO_SLAVE_LEFT` で終了します。 1 つのコアノードのディスク使用率がしきい値を超えると、連鎖反応が起きる可能性があります。HDFS が原因で 1 つのノードのディスク使用率がしきい値を超えた場合、他のノードのディスク使用率もしきい値に近づいていると考えられます。最初のノードのディスク使用率がしきい値を超えると、Amazon EMR はそのノードを拒否リストに追加します。これにより、拒否リストに追加されたノードで失った HDFS データを残りのノードがそれぞれの間でレプリケートし始めるため、ノードのディスク使用率が上昇します。その後、各ノードも同じように `UNHEALTHY` の状態になり、最終的にはクラスターが終了します。 ## ベストプラクティスとレコメンデーション ### クラスターハードウェアに十分なストレージを設定する クラスターを作成するときに、十分な数のコアノードがあること、および各ノードに HDFS 用の十分なインスタンスストアと EBS ストレージボリュームがあることを確認します。詳細については、「[クラスターの必要な HDFS 容量の計算](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs)」を参照してください。手動で、または Auto Scaling を使用して既存のインスタンスグループにコアインスタンスを追加することもできます。新しいインスタンスのストレージ設定は、インスタンスグループ内の他のインスタンスと同じになります。詳細については、「[Amazon EMR クラスタースケーリングを使用してワークロードの変化に適応する](emr-scale-on-demand.md)」を参照してください。 ### 終了保護を有効化する 削除保護を有効にします。このようにすると、コアノードが拒否リストに追加された場合に、SSH を使用して関連付けられている Amazon EC2 インスタンスに接続し、トラブルシューティングを行ってデータを復旧できます。終了保護を有効にすると、Amazon EMR が Amazon EC2 インスタンスを新しいインスタンスに置き換えなくなる点に注意してください。詳細については、「[Amazon EMR クラスターを誤ったシャットダウンから保護するための終了保護の使用](UsingEMR_TerminationProtection.md)」を参照してください。 ### MRUnhealthyNodes CloudWatch メトリクスのアラームを作成する このメトリクスは、ステータスが `UNHEALTHY` のノードの数を報告します。これは、YARN メトリクス `mapred.resourcemanager.NoOfUnhealthyNodes` と同等です。このアラームの通知を設定すれば、45 分のタイムアウトに達する前に異常が発生したノードに関する警告を受け取ることができます。詳細については、「[CloudWatch で Amazon EMR のメトリクスをモニタリングする](UsingEMR_ViewingMetrics.md)」を参照してください。 ### yarn-site を使用して設定を微調整する 以下の設定は、アプリケーションの要件に合わせて調整できます。たとえば、`yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` の値を増やすことにより、ノードが `UNHEALTHY` と報告するディスク使用率のしきい値を上げることができます。 これらの値は、`yarn-site` 設定分類を使用してクラスターを作成するときに設定できます。詳細については、「*Amazon EMR リリースガイド*の」「[アプリケーションの設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)」を参照してください。SSH を使用してコアノードに関連付けられている Amazon EC2 インスタンスに接続し、テキストエディターを使用して `/etc/hadoop/conf.empty/yarn-site.xml` に値を追加することもできます。変更を加えたら、以下のように hadoop-yarn-nodemanager を再起動する必要があります。 **重要** クラスターの作成時に `yarn-site` 設定分類を使用して `yarn.nodemanager.recovery.enabled` を `true` に設定していなければ、NodeManager サービスを再起動するときにアクティブな YARN コンテナが強制終了されます。そのため、`yarn.nodemanager.recovery.dir` プロパティを使用して、コンテナの状態を保存するディレクトリも指定する必要があります。 ``` sudo /sbin/stop hadoop-yarn-nodemanager sudo /sbin/start hadoop-yarn-nodemanager ``` 最新の `yarn-site` プロパティとデフォルト値の詳細については、Apache Hadoop ドキュメントの「[YARN のデフォルト設定](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml)」を参照してください。 | プロパティ | デフォルトの値 | 説明 | | --- | --- | --- | | yarn.nodemanager.disk-health-checker.interval-ms | 120000 | ディスクのヘルスチェッカーを実行する頻度 (秒)。 | | yarn.nodemanager.disk-health-checker.min-healthy-disks | 0.25 | NodeManager で新しいコンテナを起動するために正常でなければならないディスク数の最小比率。これは、yarn.nodemanager.local-dirs (デフォルトでは、Amazon EMR の `/mnt/yarn`) と yarn.nodemanager.log-dirs (デフォルトでは `/var/log/hadoop-yarn/containers` で、Amazon EMR の `mnt/var/log/hadoop-yarn/containers` に対してシンボリックリンクされています) の両方に対応しています。 | | `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | ディスクが異常であるとマークされてから許容されるディス容量使用率の最大パーセンテージ。値の範囲は 0.0～100.0 です。この値が 100 以上になると、NodeManager によってディスク全体のチェックが行われます。これは、`yarn-nodemanager.local-dirs` と `yarn.nodemanager.log-dirs` に適用されます。 | | `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | 使用するために最低限確保しておく必要があるディスク容量。これは、`yarn-nodemanager.local-dirs` と `yarn.nodemanager.log-dirs` に適用されます。 | # Amazon EMR クラスターエラー: Cannot replicate block, only managed to replicate to zero nodes. 「Cannot replicate block, only managed to replicate to zero nodes.」というエラーは、通常、クラスターに十分な HDFS ストレージがない場合に発生します。このエラーは、HDFS の容量を超えるデータが含まれるクラスターを作成したときに発生します。このエラーはクラスターの実行中にのみ発生します。これは、ジョブが終了するとき、使用していた HDFS 容量を解放するためです。 クラスターが使用できる HDFS 容量は、コアノードとして使用される Amazon EC2 インスタンスの数とタイプによって異なります。タスクノードは HDFS ストレージに使用されません。アタッチされている EBS ストレージボリュームを含め、各 Amazon EC2 インスタンスのすべてのディスク容量を HDFS に使用できます。各 EC2 インスタンスタイプのローカルストレージの容量については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスタイプとファミリー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。 」の「インスタンスのファミリーとタイプ」を参照してください。レプリケーション係数が、使用できる HDFS 容量に影響を及ぼすこともあります。レプリケーション係数は、冗長性を確保するために HDFS に格納された各データブロックのコピー数です。レプリケーション係数は、クラスター内のノード数に応じて大きくなります。これは、クラスターに 10 個以上のノードがある場合は、データブロックごとに 3 つのコピー、4～9 個のノードがある場合は各ブロックの 2 つのコピー、ノードが 3 つ以下のクラスターの場合は 1 つのコピー（冗長性なし）が格納されているからです。ジョブフローが使用できる容量を算出するには、使用できる HDFS 容量の合計をレプリケーション係数で割ります。ノードの数が 9 個から 10 個に増えた場合など、レプリケーション係数が増加することで、使用できる HDFS 容量が実質的には減ることがあります。 たとえば、10 個のコアノードを持つタイプ m1.large のクラスターでは、2833 GB の容量を HDFS で使用できます（10 ノード X ノードあたりの容量 850 GB）÷レプリケーション係数 3）。 HDFS で使用できる容量をクラスターが超えた場合は、コアノードをクラスターに追加するか、データを圧縮すると、HDFS 容量を生成できます。クラスターを停止して再起動できる場合は、さらに大きな Amazon EC2 インスタンスタイプのコアノードの使用を検討してください。また、レプリケーション係数を調整して対応することもできます。ただし、レプリケーション係数を小さくすると、HDFS データの冗長性と、紛失または破損した HDFS ブロックからクラスターを回復する機能が低下します。 # Amazon EMR クラスターエラー: EC2 QUOTA EXCEEDED `EC2 QUOTA EXCEEDED` メッセージが表示される場合は、いくつかの原因が考えられます。設定によっては、1 つのクラスターが完全に終了して、割り当てられたリソースを解放するまでに 5～20 分かかることがあります。クラスターを起動しようとして `EC2 QUOTA EXCEEDED` エラーが発生する場合、そのエラーの原因として、最近終了したクラスターのリソースがまだ解放されていないことが考えられます。このメッセージは、インスタンスグループまたはインスタンスフリートを、そのアカウントの現在のインスタンスクォータよりも大きいターゲットサイズに変更した場合にも表示されることがあります。この変更は手動で、または Auto Scaling により自動的に行われる可能性があります。 この問題を解決するには、以下のオプションを検討してください。 + サービス制限の引き上げをリクエストするには、「*Amazon Web Services 全般のリファレンス*」の「[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」の手順に従ってください。一部の API では、CloudWatch イベントをセットアップする方が制限を引き上げるよりも良好な結果になる場合があります。詳細については、[CloudWatch で EMR イベントを設定するとき](emr-service-limits-cloudwatch-events.md)を参照してください。 + 実行中の 1 つ以上のクラスターの容量が不足している場合は、インスタンスグループのサイズを変更するか、実行中のクラスターのインスタンスフリートのターゲット容量を減らします。 + EC2 インスタンス数またはターゲット容量を減らしたクラスターを作成します。 # Amazon EMR クラスターエラー: Too many fetch-failures ステップまたはタスク試行ログに [**Too many fetch-failures**] または [**Error reading task output**] というエラーメッセージが表示されている場合、実行中のタスクは別のタスクの出力に依存するということを示しています。これは多くの場合、リデューサータスクが実行のために列に並んでおり、1 つまたは複数のマップタスクの出力を必要としているとき、その出力がまだ利用できないときに発生します。 出力が利用できない場合、次のような理由が考えられます。 + 前提条件となるタスクが処理中です。これは多くの場合、マップタスクです。 + データが別のインスタンスに置かれている場合、ネットワークの接続状態が悪いためにデータが利用できないことがあります。 + 出力の取得に HDFS が利用される場合、HDFS の問題も考えられます。 このエラーの最も一般的な原因は、前のタスクが実行中であることです。これは特に、リデューサータスクが最初に実行を試みるときにエラーが発生する場合に該当します。これに該当するかどうかは、エラーを返したクラスターステップの syslog ログを調べることで確認できます。マップタスクとリデューサータスクの両方が進行していることが syslog から判明した場合、マップタスクが完了していないうちにリデューサーフェーズが開始されたことを示します。 ログで確認するべきことの 1 つは、100% に到達し、それから値を落とすマッパーの進捗パーセンテージです。マップのパーセンテージが 100% のとき、それはすべてのマップタスクが完了していることを意味しません。それが意味することは、Hadoop がすべてのマップタスクを実行していることだけです。この値が 100% より下に落ちる場合、それはマップタスクが失敗し、設定によっては、Hadoop がタスクの再スケジュールを試行する場合があることを意味します。ログのマップのパーセンテージが 100% のままになっている場合、CloudWatch メトリクス、特に `RunningMapTasks` を調べて、マップタスクが処理中かどうかを確認します。この情報は、マスターノードで Hadoop Web インターフェイスを利用し、確認することもできます。 この問題が発生する場合、次のような操作を試すことができます。 + リデューサーフェーズが開始までに待ち時間を長くします。この場合、Hadoop 設定の mapred.reduce.slowstart.completed.maps を変更し、時間を長くします。詳細については、「[Amazon EMR クラスターで追加のソフトウェアをインストールするブートストラップアクションを作成する](emr-plan-bootstrap.md)」を参照してください。 + リデューサーのカウントをクラスターのリデューサー能力の合計に合わせます。この場合、ジョブの Hadoop 設定の mapred.reduce.tasks を調整します。 + コンバイナクラスコードを使用して、フェッチする必要がある出力の数を最小限に抑えます。 + Amazon EC2 サービスに、クラスターのネットワークパフォーマンスに影響を与えるような問題がないことを確認します。これは、[サービスヘルスダッシュボード](https://status.aws.amazon.com/)を利用して確認できます。 + クラスターのインスタンスの CPU とメモリリソースをチェックし、データ処理がノードのリソースに過度の負担を与えていないことを確認します。詳細については、「[Amazon EMR クラスターハードウェアとネットワークを設定する](emr-plan-instances.md)」を参照してください。 + Amazon EMR クラスターで使用する Amazon マシンイメージ (AMI) のバージョンを確認します。バージョンが 2.3.0～2.4.4 の場合は、より新しいバージョンに更新してください。このバージョンの範囲に該当する AMI で使用される Jetty のバージョンでは、マップフェーズからの出力の配信に失敗する可能性があります。リデューサーがマップフェーズからの出力を取得できない場合は、フェッチエラーが発生します。 Jetty はオープンソースの HTTP サーバーで、Hadoop クラスター内でのマシン間の通信に使用されます。 # Amazon EMR クラスターエラー: File could only be replicated to 0 nodes instead of 1 ファイルが HDFS に書き込まれるとき、複数のコアノードに複製されます。このエラーが表示されるとき、HDFS にデータを書き込むための DataNode インスタンスが NameNode デーモンにないことを意味します。言い換えれば、ブロックレプリケーションが行われていません。このエラーは次のようなさまざまな問題から発生する場合があります。 + HDFS ファイルシステムに容量不足が発生している可能性があります。これが最も一般的な原因です。 + ジョブの実行時に DataNode インスタンスを利用できなかった可能性があります。 + DataNode インスタンスとマスターノードとの通信がブロックされた可能性があります。 + コアインスタンスグループのインスタンスが利用できない可能性があります。 + 権限が不足している可能性があります。たとえば、JobTracker デーモンにジョブトラッカー情報を作成する権限がなかった可能性があります。 + DataNode インスタンスの予約容量設定が十分でない可能性があります。これに該当するかどうかは、dfs.datanode.du.reserved 設定で確認します。 この問題が HDFS のディスク容量不足により引き起こされているかどうかを確認するには、CloudWatch の `HDFSUtilization` メトリクスを調べます。この値が高すぎる場合、クラスターにコアノードを追加できます。HDFS ディスク容量が不足していると考えられるクラスターがある場合、`HDFSUtilization` の値が一定のレベルを超えたときにアラートを通知するように CloudWatch にアラームを設定できます。詳細については、「[実行中の Amazon EMR クラスターのサイズを手動で変更する](emr-manage-resize.md)」および「[CloudWatch で Amazon EMR のメトリクスをモニタリングする](UsingEMR_ViewingMetrics.md)」を参照してください。 HDFS の容量不足が原因ではない場合、DataNode ログ、NameNode ログ、ネットワーク接続をチェックし、HDFS のデータ複製を阻害している問題が他にないか確認します。詳細については、「[Amazon EMR ログファイルを表示する](emr-manage-view-web-log-files.md)」を参照してください。 # Amazon EMR クラスターエラー: Deny-listed nodes NodeManager デーモンは、コアとタスクノードでコンテナの起動や管理を行います。マスターノードで実行する ResourceManager デーモンが NodeManager デーモンにコンテナを割り当てます。ResourceManager はハートビートを利用して NodeManager ノードを監視します。 ResourceManager デーモンが NodeManager を拒否リストに登録して、タスク処理に利用できるノードのプールから削除する状況は、次のようにいくつかあります。 + NodeManager が過去 10 分間 (600,000 ミリ秒間) ResourceManager デーモンにハートビートを送信していません。この時間は `yarn.nm.liveness-monitor.expiry-interval-ms` 設定で設定できます。Yarn 設定の変更の詳細については「*Amazon EMR リリースガイド*」の「[アプリケーションの設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)」を参照してください。 + NodeManager は `yarn.nodemanager.local-dirs` と `yarn.nodemanager.log-dirs` が決定するディスクの正常性をチェックします。このチェックにはアクセス権限と空きディスク容量 (< 90%) が含まれます。ディスクのチェックで障害が発生した場合、NodeManager はその特定のディスクの使用を停止しますが、ノードのステータスは正常であるとレポートされます。いくつものディスクのチェックで障害が発生すると、ResourceManager にノードに異常性があるとレポートされます。その場合、新しいコンテナはノードに割り当てられません。 アプリケーションマスターも、NodeManager ノードの失敗したタスクが 3 つを超える場合に、ノードを拒否リストに登録する可能性があります。`mapreduce.job.maxtaskfailures.per.tracker` 設定パラメータを利用し、この値を増やすことができます。他には、タスクを失敗と判定するまでに試行する回数を制御する設定を変更できます。マップタスクの場合は `mapreduce.map.max.attempts` を、リデュースタスクの場合は `mapreduce.reduce.maxattempts` を変更します。設定の変更の詳細については「*Amazon EMR リリースガイド*」の「[アプリケーションの設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)」を参照してください。 # Amazon EMR クラスターでのスロットリングエラー エラー「Throttled from *Amazon EC2* while launching cluster」と「Failed to provision instances due to throttling from *Amazon EC2*」は、別のサービスがアクティビティをスロットリングしたために、Amazon EMR がリクエストを完了できないときに発生します。スロットリングエラーの最も一般的な原因は Amazon EC2 ですが、他のサービスがスロットリングエラーの原因である可能性もあります。パフォーマンスを向上させるためにリージョンごとに [AWS サービスの制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)が適用されていて、スロットリングエラーは、そのリージョンでアカウントのサービス制限を超えたことを示します。 ## 考えられる原因 Amazon EC2 スロットリングエラーの最も一般的な原因は、多数のクラスターインスタンスが起動されているために、EC2 インスタンスのサービス制限を超えたことです。クラスターインスタンスは以下の理由で作成される可能性があります。 + 新しいクラスターが作成された。 + クラスターのサイズが手動で変更された。詳細については、「[実行中の Amazon EMR クラスターのサイズを手動で変更する](emr-manage-resize.md)」を参照してください。 + クラスター内のインスタンスグループで Auto Scaling ルールの結果としてインスタンスが追加された (スケールアウトされた)。詳細については、「[自動スケーリングルールについて](emr-automatic-scaling.md#emr-scaling-rules)」を参照してください。 + クラスター内のインスタンスフリートで増加したターゲット容量を満たすためにインスタンスが追加された。詳細については、「[Amazon EMR クラスターのインスタンスフリートの計画と設定](emr-instance-fleet.md)」を参照してください。 Amazon EC2 に対して発行された API リクエストの頻度またはタイプにより、スロットリングエラーが発生することもあります。Amazon EC2 が API リクエストをスロットリングする方法の詳細については、「*Amazon EC2 API リファレンス*」の「[クエリ API リクエスト率](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate)」を参照してください。 ## ソリューション 以下の解決方法を検討してください。 + サービス制限の引き上げをリクエストするには、「*Amazon Web Services 全般のリファレンス*」の「[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」の手順に従ってください。一部の API では、CloudWatch イベントをセットアップする方が制限を引き上げるよりも良好な結果になる場合があります。詳細については、[CloudWatch で EMR イベントを設定するとき](emr-service-limits-cloudwatch-events.md)を参照してください。 + 同じスケジュールで起動するクラスターがある場合 (特定時間の 0 分など)、開始時間をずらすことを検討してください。 + インスタンス容量のピーク需要に合わせたサイズのクラスターがあり、インスタンス容量の需要が定期的に変動する場合は、インスタンスをオンデマンドで追加および削除するように Auto Scaling を指定することを検討してください。この方法では、インスタンスがより効率的に使用され、需要プロファイルに応じて、アカウント全体で同時にリクエストされるインスタンスが少なくなります。詳細については、「[カスタムポリシーによる自動スケーリングを Amazon EMR のインスタンスグループに使用する](emr-automatic-scaling.md)」を参照してください。 # Amazon EMR クラスターエラー: インスタンスタイプはサポートされていません クラスターを作成し、「The requested instance type *InstanceType* is not supported in the requested Availability Zone」というエラーメッセージが表示されて失敗した場合、クラスターを作成した際に、クラスターを作成したリージョンとアベイラビリティーゾーンで、Amazon EMR でサポートされていない 1 つ以上のインスタンスグループのインスタンスタイプを指定したことを意味します。Amazon EMR は、リージョン内のあるアベイラビリティーゾーンではインスタンスタイプをサポートし、別のアベイラビリティーゾーンではサポートしないことがあります。クラスターに選択したサブネットによって、リージョン内のアベイラビリティーゾーンが決まります。 ## ソリューション **を使用してアベイラビリティーゾーンで使用可能なインスタンスタイプを特定する AWS CLI** + `--dry-run` オプションで `ec2 run-instances` コマンドを使用します。以下の例で、*m5.xlarge* を使用するインスタンスタイプに置き換え、*ami-035be7bafff33b6b6* をそのインスタンスタイプに関連付けられている AMI に置き換え、*subnet-12ab3c45* をクエリ対象のアベイラビリティーゾーン内のサブネットに置き換えてください。 ``` aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45 ``` AMI ID の検索手順については、「[Linux AMI の検索](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html)」を参照してください。サブネット ID を見つけるには、[describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html) コマンドを使用できます。 利用可能なインスタンスタイプを確認にする方法については、「[Amazon EC2 インスタンスタイプの検索](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)」を参照してください。 使用可能なインスタンスタイプを決定したら、以下のいずれかを実行できます。 + 同じリージョンと EC2 サブネットにクラスターを作成し、最初に選択したものと同様の機能を持つ別のインスタンスタイプを選択します。サポートされているインスタンスタイプについては[Amazon EMR でサポートされているインスタンスタイプ](emr-supported-instance-types.md)を参照してください。EC2 インスタンスタイプの機能を比較するには、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。 + インスタンスタイプが使用可能かつ Amazon EMR によってサポートされているアベイラビリティーゾーン内のクラスターのサブネットを選択します。 **Amazon EMR でサポートされていないプライマリインスタンスタイプによるインスタンスフリートクラスターの起動失敗の軽減** プライマリノードは Amazon EMR クラスターで不可欠です。プライマリインスタンスタイプがサポートされていない場合、Amazon EMR がアベイラビリティーゾーンでクラスターの起動を試みるときに EMR クラスターの起動は `instance type not supported` エラーで失敗する可能性があります。Amazon EMR のインスタンスフリートクラスターの拡張アベイラビリティーゾーンの選択により、クラスター設定で指定したプライマリインスタンスタイプでサポートされていない AZ が自動的に除外されます。つまり、Amazon EMR は、設定されたプライマリインスタンスタイプがサポートされていないアベイラビリティーゾーンを選択しないため、サポートされていないインスタンスタイプによるクラスター起動の失敗を防ぎます。 この改善を有効にするには、クラスターのサービスロールまたはポリシーに必要なアクセス許可を追加します。`AmazonEMRServicePolicy_v2` の最新バージョンにはこのアクセス許可が含まれているため、このポリシーを使用すると、改善は既に利用できます。カスタムサービスロールまたはポリシーを使用する場合は、クラスターの起動時にアクセス許可 `ec2:DescribeInstanceTypeOfferings` を追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstanceTypeOfferings" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "AllowEC2Describeinstancetypeofferings" } ] } ``` ------ # Amazon EMR クラスターエラー: EC2 is out of capacity *EC2 is out of capacity for *InstanceType** エラーは、指定された EC2 インスタンスタイプがこれ以上ないアベイラビリティーゾーンで、クラスターを作成するか、クラスターにインスタンスを追加しようとしたときに発生します。クラスターに選択したサブネットによって、アベイラビリティーゾーンが決まります。 クラスターを作成するには、以下のいずれかの操作を実行します。 + 類似の機能を持つ別のインスタンスタイプを指定する。 + クラスターを別のリージョンに作成する。 + 必要なインスタンスタイプが使用可能なアベイラビリティーゾーン内のサブネットを選択する。 実行中のクラスターにインスタンスを追加するには、次のいずれかを実行します。 + インスタンスグループ設定またはインスタンスフリート設定を変更して、類似の機能を持つ使用可能なインスタンスタイプを追加する。サポートされているインスタンスタイプについては[Amazon EMR でサポートされているインスタンスタイプ](emr-supported-instance-types.md)を参照してください。EC2 インスタンスタイプの機能を比較するには、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。 + インスタンスタイプが使用可能なリージョンとアベイラビリティーゾーンでクラスターを終了して再作成する。 # Amazon EMR クラスターエラー: HDFS replication factor error コア[インスタンスグループ](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html)または[インスタンスフリート](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html)からコアノードを削除すると、Amazon EMR で HDFS レプリケーションエラーが発生する可能性があります。このエラーは、コアノードを削除し、コアノード数が Hadoop 分散ファイルシステム (HDFS) の設定済み [dfs.replication 係数](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html)を下回ると発生します。そのため、Amazon EMR はオペレーションを安全に実行できません。`dfs.replication` 設定のデフォルト値を決定するには、「[HDFS configuration](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html)」を参照してください。 ## 考えられる原因 HDFS レプリケーションファクタエラーの考えられる原因については、以下を参照してください。 + コアインスタンスグループまたはインスタンスフリートのサイズを設定した `dfs.replication` 係数より低く[手動で変更](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html)した場合。 + [マネージドスケーリング](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html)または[自動スケーリング](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html)のポリシーで、コアノードの数を `dfs.replication` のしきい値未満に減らすためのスケーリングが許可されている場合。 + このエラーは、クラスターに []() で定義されているコアノードの数が最小限の場合に、Amazon EMR が異常なコアノードを[置き換え](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html)ようとする場合にも発生する可能性があります。 ## ソリューションとベストプラクティス ソリューションとベストプラクティスについては、以下を参照してください。 + Amazon EMR でサイズ変更を安全に完了できないため、Amazon EMR クラスターのサイズを手動で変更する場合は、`dfs.replication` より小さくスケールダウンしないでください。 + マネージドスケーリングまたは自動スケーリングを使用する場合は、クラスターの最小容量が `dfs.replication` 係数を下回っていないことを確認してください。 + コアインスタンスの数は、少なくとも `dfs.replication` に 1 を足した数にする必要があります。これにより、異常なコア置き換えを有効にした場合、Amazon EMR は異常なコアノードを正常に置き換えることができます。 **重要** 1 つのコアノードに障害が発生すると、`dfs.replication` を 1 に設定すると HDFS データが失われる可能性があります。クラスターに HDFS ストレージがある場合は、データ損失を避けるため、本番稼働ワークロード用に少なくとも 4 つのコアノードでクラスターを構成することをお勧めします。また、少なくとも 2 の `dfs.replication` 係数を設定してください。 # Amazon EMR クラスターエラー: HDFS insufficient space error コアノードを削除しようとすると、Hadoop 分散ファイルシステム (HDFS) のスペース不足エラーが発生する可能性がありますが、HDFS にスペースが不足しているため、Amazon EMR は安全にオペレーションを完了できません。Amazon EMR がコアノードを削除する前に、ノード上のすべての HDFS データを他のコアノードに転送して、データの冗長性を確保する必要があります。ただし、他のコアノードにレプリケーション用の十分なスペースがない場合、Amazon EMR はノードを正常に廃止できません。 ## 考えられる原因 HDFS スペース不足エラーの考えられる原因のリストについては、以下を参照してください。 + スケールダウン前に残りのノードにデータレプリケーション用の十分な HDFS スペースがない場合に、コアインスタンスグループまたはインスタンスフリートを手動でスケールダウンする場合。 + マネージドスケーリングまたは自動スケーリングは、データレプリケーションに十分な HDFS スペースがない場合に、コアインスタンスグループまたはインスタンスフリートをスケールダウンした場合。 + Amazon EMR が異常なコアノードを置き換えようとしますが、HDFS スペースが不足しているため、ノードを安全に置き換えることができない場合。 ## ソリューションとベストプラクティス ソリューションとベストプラクティスについては、以下を参照してください。 + Amazon EMR クラスター内のコアノードの数をスケールアップします。マネージドスケーリングまたは自動スケーリングを使用する場合は、コアノードの最小容量を増やします。 + EMR クラスターを作成するときは、コアノードにより大きな EBS ボリュームを使用します。 + EMR クラスター内の不要な HDFS データを削除します。EMR クラスターの容量が少ないかどうかを確認するために、クラスター内の `HDFSUtilization` メトリクスをモニタリングするように CloudWatch アラームを設定することをお勧めします。