翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 遅い Amazon EMR クラスターのトラブルシューティング
このセクションでは、実行中のままですが、結果が返るのに時間がかかっているクラスターをトラブルシューティングする手順を説明します。クラスターがエラーコードで終了した場合の対処方法については、「[エラーコードで失敗した Amazon EMR クラスターのトラブルシューティング](emr-troubleshoot-failed.md)」を参照してください。
Amazon EMR では、クラスター内のインスタンスの数と種類を指定できます。これを指定することが、データ処理の実行速度に影響を与える主な手段です。クラスターの再実行を検討する可能性があります。今回は、より大きなリソースを持つ EC2 インスタンスを指定するか、より多い数のインスタンスをクラスターに指定します。詳細については、「[Amazon EMR クラスターハードウェアとネットワークを設定する](emr-plan-instances.md)」を参照してください。
次のトピックでは、クラスターを遅くさせる他の要因を特定する手順を説明します。
**Topics**
+ [ステップ 1: Amazon EMR クラスターの問題に関するデータの収集](emr-troubleshoot-slow-1.md)
+ [ステップ 2: EMR クラスター環境の確認](emr-troubleshoot-slow-2.md)
+ [ステップ 3: Amazon EMR クラスターのログファイルの確認](emr-troubleshoot-slow-3.md)
+ [ステップ 4: Amazon EMR クラスターとインスタンスのヘルスの確認](emr-troubleshoot-slow-4.md)
+ [ステップ 5: 中断されたグループの確認](emr-troubleshoot-slow-5.md)
+ [ステップ 6: Amazon EMR クラスターの設定の確認](emr-troubleshoot-slow-6.md)
+ [ステップ 7: Amazon EMR クラスターの入力データの確認](emr-troubleshoot-slow-7.md)
# ステップ 1: Amazon EMR クラスターの問題に関するデータの収集
クラスターのトラブルシューティングの最初の手順は、不具合とクラスターの現在のステータスおよび設定に関する情報を収集することです。この情報は、問題の原因を確認または除外するために、以降の手順で使用されます。
## 問題の定義
まず、問題を明確に定義します。自問するいくつかの質問を次に示します。
+ 何が起こると予想したか 代わりに何が起こったか
+ この問題が最初に発生したのはいつか それ以来どのくらいの頻度で起こっているか
+ クラスターの設定方法や実行方法に変化があったか
## クラスターの詳細
問題を追跡するために、次のクラスターの詳細が役立ちます。この情報の収集方法の詳細については、「[Amazon EMR クラスターステータスと詳細の表示](emr-manage-view-clusters.md)」を参照してください。
+ クラスターの識別子。(ジョブフロー識別子とも呼ばれます)。
+ AWS リージョン およびクラスターが起動されたアベイラビリティーゾーン。
+ クラスターの状態 (最後の状態変更の詳細を含む)。
+ マスター、コア、およびタスクの各ノードに指定されている EC2 インスタンスの種類と数。
# ステップ 2: EMR クラスター環境の確認
環境をチェックして、サービスが停止しているか、 AWS サービスの制限を超えたかどうかを確認します。
**Topics**
+ [サービスの停止の確認](#emr-troubleshoot-slow-2-outages)
+ [使用制限の確認](#emr-troubleshoot-slow-2-limits)
+ [Amazon VPC サブネット設定の確認](#emr-troubleshoot-slow-2-vpc)
+ [クラスターの再起動](#emr-troubleshoot-slow-2-restart)
## サービスの停止の確認
Amazon EMR は、内部で複数のAmazon Web Services を使用します。Amazon EC2 で仮想サーバーを稼働させ、Amazon S3 にデータとスクリプトを保存し、CloudWatch にメトリクスを報告します。これらのサービスを中断するイベントはまれですが、発生すると、Amazon EMR で問題が発生する恐れがあります。
次に進む前に、[サービスヘルスダッシュボード](https://status.aws.amazon.com/)を確認します。クラスターを起動したリージョンで、これらのサービスのいずれかに中断イベントがあるかどうかを確認します。
## 使用制限の確認
大規模なクラスターを起動する場合、多数のクラスターを同時に起動している場合、または他のユーザー AWS アカウント と を共有しているユーザーの場合、 AWS サービスの制限を超えたため、クラスターが失敗した可能性があります。
Amazon EC2 は、1 つの AWS リージョンで実行されている仮想サーバーインスタンスの数を 20 個のオンデマンドインスタンスまたはリザーブドインスタンスに制限します。20 を超えるノードを持つクラスターを起動するか、 でアクティブな EC2 インスタンスの合計数が 20 AWS アカウント を超えるクラスターを起動すると、クラスターは必要なすべての EC2 インスタンスを起動できず、失敗する可能性があります。この場合、Amazon EMR は `EC2 QUOTA EXCEEDED` エラーを返します。Amazon EC2 インスタンス制限 AWS の引き上げリクエストアプリケーションを送信することで、アカウントで実行できる EC2 インスタンスの数を増やすように にリクエストできます。 [ Amazon EC2 ](https://aws.amazon.com/contact-us/ec2-request/)
使用制限を超えるもう 1 つの原因は、クラスターが終了してからすべてのリソースを解放するまでの遅延です。設定によっては、1 つのクラスターが完全に終了して、割り当てられたリソースを解放するまでに 5～20 分かかることがあります。クラスターを起動しようとして `EC2 QUOTA EXCEEDED` エラーが発生する場合、そのエラーの原因として、最近終了したクラスターのリソースがまだ解放されていないことが考えられます。この場合は、[Amazon EC2 クォータ増加リクエスト](https://aws.amazon.com/contact-us/ec2-request/)を送信するか、20 分待ってからクラスターを再起動してください。
Simple Storage Service (Amazon S3) では、アカウントで作成されるバケットの数を 100 までに制限しています。クラスターがこの制限を超える新しいバケットを作成すると、バケットの作成が失敗し、クラスターが失敗する恐れがあります。
## Amazon VPC サブネット設定の確認
クラスターが Amazon VPC サブネットで起動された場合は、「[Amazon EMR 用の VPC でネットワークを設定する](emr-plan-vpc-subnet.md)」の説明に従ってサブネットを設定する必要があります。さらに、クラスターを起動するサブネットに存在する空きの Elastic IP アドレスが、クラスター内の各ノードに 1 つずつ割り当てるのに十分であることを確認します。
## クラスターの再起動
処理速度の低下は、一時的な条件で発生している可能性があります。クラスターの終了および再起動を検討し、パフォーマンスが改善されるか確認します。
# ステップ 3: Amazon EMR クラスターのログファイルの確認
次のステップは、ログファイルを調べて、クラスターで発生した問題のエラーコードまたはその他の兆候を見つけることです。使用可能なログファイル、ファイルの場所、および表示方法の詳細については、「[Amazon EMR ログファイルを表示する](emr-manage-view-web-log-files.md)」を参照してください。
何が起こったのかを調べるには、しばらく調査作業をすることが必要な場合があります。Hadoop は、クラスター内のさまざまなノードでタスクを試行してジョブの作業を実行します。Amazon EMR は、完了しない他のタスク試行をまず終了して、投機的なタスク試行を開始する可能性があります。これは、発生時にコントローラー、stderr、および syslog ログファイルに記録される重大なアクティビティを生成します。さらに、複数のタスク試行が同時に実行されますが、ログファイルは結果を直線的にしか表示できません。
クラスターの起動中のブートストラップアクションログで、エラーや予期しない設定の変更をまず調べてください。次に、ステップログを調べて、エラーのあるステップの一部として起動された Hadoop ジョブを特定します。Hadoop のジョブログを調べて、失敗したタスク試行を特定します。タスク試行ログには、タスク試行が失敗した原因に関する詳細が含まれます。
さまざまなログファイルを使用してクラスターのエラーを識別する方法について以降のセクションで説明します。
## ブートストラップアクションログの確認
ブートストラップアクションは、起動時にクラスター上でスクリプトを実行します。通常、クラスターへの追加ソフトウェアのインストールや、デフォルト値からの設定の変更に使用されます。これらのログを確認すると、クラスターのセットアップ中に発生したエラーや、パフォーマンスに影響する可能性のある設定の変更に関するインサイトが得られる場合があります。
## ステップログの確認
ステップログには 4 種類あります。
+ **コントローラー——**ステップ実行の試行中に発生したエラーから発生する Amazon EMR (Amazon EMR) によって生成されたファイルが含まれます。ロード中にステップが失敗した場合は、このログでスタックトレースを見つけることができます。アプリケーションの読み込みまたはアクセスのエラーは、しばしばここに記載されます。マッパーファイルがないエラーについても同様です。
+ **stderr—**ステップの処理中に発生したエラーメッセージが含まれます。アプリケーションの読み込みエラーは、しばしばここに記載されます。このログには、スタックトレースが含まれている場合があります。
+ **stdout—**マッパーおよびリデューサーの実行可能ファイルによって生成されたステータスが含まれます。アプリケーションの読み込みエラーは、しばしばここに記載されます。このログには、アプリケーションのエラーメッセージが含まれている場合があります。
+ **syslog—**Apache や Hadoop などの、Amazon 以外のソフトウェアからのログが含まれます。ストリーミングエラーは、しばしばここに記載されます。
stderr で明らかなエラーを確認してください。stderr にエラーの短いリストが表示されている場合、ステップはエラーがスローされてからすぐに停止しています。これは、多くの場合、クラスターで実行されていたマッパーおよびリデューサーアプリケーションのエラーが発生の原因です。
コントローラーと syslog の最後の行を調べて、エラーまたは障害の通知を確認します。特に「Job Failed」と表示されている場合、失敗したタスクに関する通知に従ってください。
## タスク試行ログの確認
前のステップログの分析で 1 つ以上の失敗したタスクが見つかった場合は、対応するタスク試行のログを調べて、詳細なエラー情報を入手してください。
## Hadoop デーモンログの確認
まれに、Hadoop 自体が失敗する場合があります。その場合に該当するかどうかを確認するには、Hadoop ログを確認する必要があります。ログは各ノードの `/var/log/hadoop/` にあります。
JobTracker ログを使用して、失敗したタスク試行を、それが実行されたノードにマッピングできます。タスク試行に関連付けられているノードが判明したら、そのノードをホストしている EC2 インスタンスのヘルスを確認して、CPU やメモリ不足などの問題がないかどうかを確認できます。
# ステップ 4: Amazon EMR クラスターとインスタンスのヘルスの確認
Amazon EMR クラスターは、Amazon EC2 インスタンスで実行されているノードで構成されています。これらのインスタンスがリソースにバインドされた場合（CPU またはメモリの不足などにより）、ネットワーク接続の問題が発生したり、ネットワークが切断されたりして、クラスターの処理速度が低下します。
クラスターには最大 3 種類のノードがあります。
+ **マスターノード** — クラスターを管理します。パフォーマンスに問題が発生した場合、クラスター全体に影響があります。
+ **コアノード** — マップリデュースタスクを処理し、Hadoop Distributed Filesystem (HDFS) を保守します。これらのノードの 1 つにパフォーマンスの問題がある場合、HDFS の操作とマップリデュースの処理を行うスピードを下げる可能性があります。さらにコアノードをクラスターに追加し、パフォーマンスを改善できますが、コアノードを削除することはできません。詳細については、「[実行中の Amazon EMR クラスターのサイズを手動で変更する](emr-manage-resize.md)」を参照してください。
+ **タスクノード** — マップリデュースタスクを処理します。専用の演算リソースがあり、データは保存しません。タスクノードをクラスターに追加してパフォーマンスの速度を上げるか、必要のないタスクノードを削除することができます。詳細については、「[実行中の Amazon EMR クラスターのサイズを手動で変更する](emr-manage-resize.md)」を参照してください。
クラスターの状態を確認する場合、クラスター全体のパフォーマンスと、個々の仮想サーバーインスタンスのパフォーマンスの両方を確認する必要があります。次のようなツールを使用できます。
## CloudWatch でのクラスターのヘルスの確認
すべての Amazon EMR クラスターが CloudWatch にメトリクスを報告します。メトリクスでは、合計読み込み、HDFS 使用率、実行中のタスク、残りのタスク、および破損ブロックなどのクラスターに関するパフォーマンス情報の概要を提供します。CloudWatch メトリクスを確認すると、クラスターで進行中の内容に関する概要を把握でき、処理が低速になっている要因についてインサイトが得られる可能性があります。CloudWatch を使用して既存のパフォーマンスの問題を分析するのに加えて、今後パフォーマンスの問題が発生した場合に、CloudWatch がアラートを生成するようにアラームを設定できます。詳細については、「[CloudWatch で Amazon EMR のメトリクスをモニタリングする](UsingEMR_ViewingMetrics.md)」を参照してください。
## ジョブのステータスと HDFS のヘルスの確認
クラスター詳細ページの [**Application user interfaces (アプリケーションユーザーインターフェイス)**] タブを使用して、YARN アプリケーションの詳細を表示できます。特定のアプリケーションでは、さらに詳細やアクセスログに直接アクセスすることができます。これは、Spark アプリケーションで特に有益です。詳細については、「[Amazon EMR アプリケーションの履歴を表示する](emr-cluster-application-history.md)」を参照してください。
Hadoop では、情報の表示に使用できる Web インターフェイスのシリーズを提供します。Web インターフェイスへのアクセス方法については、「[Amazon EMR クラスターでホストされているウェブインターフェイスを表示する](emr-web-interfaces.md)」を参照してください。
+ JobTracker — クラスターで処理されているジョブの進行状況に関する情報を提供します。このインターフェイスを使用して、ジョブが停止したタイミングを特定できます。
+ HDFS NameNode — HDFS の使用率および各ノードの使用可能な容量に関する情報を提供します。このインターフェイスを使用して、HDFS がリソースにバインドされ、追加の容量を必要とするタイミングを特定できます。
+ TaskTracker — クラスターで処理されているジョブのタスクに関する情報を提供します。このインターフェイスを使用して、タスクが停止したタイミングを特定できます。
## Amazon EC2 でのインスタンスヘルスの確認
別の方法でクラスターのインスタンスのステータスに関する情報を確認するには、Amazon EC2 コンソールを使用します。クラスターの各ノードは EC2 インスタンスで実行されるため、Amazon EC2 から提供されるツールを使用してステータスを確認できます。詳細については、「[Amazon EC2 でクラスターインスタンスを表示する](UsingEMR_Tagging.md)」を参照してください。
# ステップ 5: 中断されたグループの確認
ノードの起動を試行中にエラーが多数発生したとき、インスタンスグループは中断されます。例えば、ブートストラップアクションの実行中に新しいノードが繰り返し失敗した場合、インスタンスグループは、しばらくすると、新しいノードのプロビジョニングを引き続き試みることなく、`SUSPENDED` 状態になります。
たとえば、次のような場合に、ノードが表示されないことがあります。
+ Hadoop またはクラスターが何らかの理由で破損し、クラスターへの新しいノードを受け入れない
+ ブートストラップアクションが新しいノードで失敗した
+ ノードが適切に機能していないため、Hadoop でチェックインできない
インスタンスグループが `SUSPENDED` 状態で、クラスターが `WAITING` 状態の場合は、クラスターステップを追加して、必要な数のコアおよびタスクノードをリセットできます。ステップを追加することで、クラスターの処理が再開し、インスタンスグループが `RUNNING` 状態に戻ります。
中断状態のクラスターをリセットする方法については、「[停止状態](emr-manage-resize.md#emr-manage-resizeSuspended)」を参照してください。
# ステップ 6: Amazon EMR クラスターの設定の確認
構成設定では、タスクを再試行する回数およびソートに利用できるメモリ量など、クラスターの実行方法に関する詳細を指定します。Amazon EMR を使用してクラスターを起動すると、標準の Hadoop 設定に加えて、Amazon EMR 固有の設定があります。構成設定はクラスターのマスターノードに保存されます。構成設定を確認し、効率的に実行するのに必要なリソースがクラスターにあるようにできます。
Amazon EMR は、クラスターの起動に使用されるデフォルトの Hadoop 設定を定義します。この値は、クラスターに指定した AMI およびインスタンスに基づいています。ブートストラップアクションを使用したデフォルトの値から、またはジョブ実行パラメータに新しい値を指定することによって、構成設定を変更できます。詳細については、「[Amazon EMR クラスターで追加のソフトウェアをインストールするブートストラップアクションを作成する](emr-plan-bootstrap.md)」を参照してください。ブートストラップアクションで構成設定を変更したかどうかを判定するには、ブートストラップアクションログを確認します。
Amazon EMR は、各ジョブの実行に使用された Hadoop 設定をログに記録します。ログデータは、マスターノードの `/mnt/var/log/hadoop/history/` ディレクトリに `job_job-id_conf.xml` という名前のファイルで存されます。ここで *job-id* はジョブの識別子で置換されます。ログのアーカイブを有効にしている場合、このデータは Simple Storage Service (Amazon S3) の `logs/date/jobflow-id/jobs` フォルダーにコピーされます。ここで *date* はジョブが実行された日付、*jobflow-id* はクラスターの識別子です。
次の Hadoop ジョブ構成設定は、パフォーマンスの問題を調査するのに特に役立ちます。Hadoop の構成設定および Hadoop の動作にどのように影響するかについては、[http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/) を参照してください。
**警告**
ノードが 4 つ未満のクラスターで `dfs.replication` を 1 に設定すると、単一ノードがダウンした場合に HDFS データが失われる可能性があります。本番環境のワークロードには、少なくとも 4 つのコアノードを持つクラスターを使用することをお勧めします。
Amazon EMR では、クラスターはコアノードを `dfs.replication` 未満にスケールすることはできません。例えば、`dfs.replication = 2` の場合、コアノードの最小数は 2 です。
マネージドスケーリングや自動スケーリングを使用する場合や、クラスターのサイズを手動で変更する場合は、`dfs.replication` を 2 以上に設定することをお勧めします。
| 構成設定 | 説明 |
| --- | --- |
| dfs.replication | RAID のような環境を生成するために、単一ブロック（ハードドライブブロックなど）がコピーされる HDFS ノードの数。ブロックのコピーを含んでいる HDFS のノード数を決定します。 |
| io.sort.mb | ソートに利用可能な合計メモリ。この値は io.sort.factor の 10 倍になります。この設定は、io.sort.mb に mapred.tasktracker.ap.tasks.maximum を掛けて計算して、タスクノードが使用する合計メモリを計算するためにも使用できます。 |
| io.sort.spill.percent | 割り当てられたソートメモリがいっぱいであるため、ディスクが使用を開始するポイントでソート中に使用されます。 |
| mapred.child.java.opts | 廃止済み。代わりに、mapred.map.child.java.opts および mapred.reduce.child.java.opts を使用します。TaskTracker が内部で実行するタスク用に JVM を起動する際に使用する Java オプション。共通パラメータは、最大メモリサイズの設定用の "-Xmx" です。 |
| mapred.map.child.java.opts | TaskTracker が内部で実行するマップタスク用に JVM を起動する際に使用する Java オプション。共通パラメータは、最大メモリヒープサイズの設定用の "-Xmx" です。 |
| mapred.map.tasks.speculative.execution | 同じタスクのマップタスク試行を並行して起動できるかどうかを決定します。 |
| mapred.reduce.tasks.speculative.execution | 同じタスクのリデュースタスク試行を並行して起動できるかどうかを決定します。 |
| mapred.map.max.attempts | マップタスクの最大試行回数。すべてが失敗した場合、マップタスクは失敗としてマークされます。 |
| mapred.reduce.child.java.opts | TaskTracker が内部で実行する Reduce タスク用に JVM を起動する際に使用する Java オプション。共通パラメータは、最大メモリヒープサイズの設定用の "-Xmx" です。 |
| mapred.reduce.max.attempts | Reduce タスクの最大試行回数。すべてが失敗した場合、マップタスクは失敗としてマークされます。 |
| mapred.reduce.slowstart.completed.maps | Reduce タスクが試行される前に完了する必要のある Map タスクの量。待機時間が足りないと、試行中に「Too many fetch-failure」エラーが発生する場合があります。 |
| mapred.reuse.jvm.num.tasks | タスクは単一の JVM 内で実行されます。同じ JVM を再利用できるタスク数を指定します。 |
| mapred.tasktracker.map.tasks.maximum | マッピング中のタスクノードごとに並行して実行できる最大タスク数。 |
| mapred.tasktracker.reduce.tasks.maximum | 減らしている間のタスクノードごとに並行して実行できる最大タスク数。 |
クラスタータスクがメモリを大量に使用する場合、コアノードごとに使うタスクの数を減らしてジョブトラッカーのヒープサイズを減らすと、パフォーマンスを向上させることができます。
# ステップ 7: Amazon EMR クラスターの入力データの確認
入力データを確認します。キー値に均等に割り付けられていますか? データが 1 つまたは少数のキー値に偏っている場合、他のノードが待機中であるにもかかわらず、読み込み処理は少数のノードにマップされている可能性があります。この不均等な作業の割り付けは、処理時間を遅くさせる場合があります。
たとえば、不均等なデータセットでは、クラスターを実行して単語をアルファベット順にしていますが、所有しているデータセットには "a" の文字で始まる単語しかありません。作業を綿密に計画した場合、他の文字で始まる単語を処理するノードが待機中であっても、"a" で始まる値を処理しているノードに負担がかかることになります。