Amazon EMR クラスターが「application provisioning failed」というエラーで終了したのはなぜですか?

解決方法

Amazon EMR が EMR クラスターを起動しているときに、指定されたソフトウェアをインストール、設定、または起動できない場合、「アapplication provisioning failed」というエラーが表示されることがあります。次のセクションでは、プロビジョニングログを検索して確認する方法を示します。また、さまざまな種類のエラーと、そのエラーを解決するための手順もご紹介します。

Amazon S3 に保存されている Amazon EMR プロビジョニングログを確認する

Amazon EMR のプロビジョニングログは、クラスターの起動時に指定された Amazon Simple Storage Service (Amazon S3) バケットに保存されます。ログの保存場所には、次の Amazon S3 URI 構文を使用します。

s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/puppet.log.gz

注: example-log-location、example-cluster-ID、example-Primary-Node-ID、example-UUID は、使用しているシステムの名前に置き換えます。

1. Amazon EMR コンソールを開きます。ナビゲーションペインで [クラスター] を選択します。次に、障害が発生した EMR クラスターを選択して、クラスターの詳細を確認します。
2. [概要] セクションで [Terminated with errors] を選択し、エラーメッセージに含まれるプライマリノード ID を書き留めます。
3. [クラスターログ] セクションで、Amazon S3 コンソールのクラスターログにリダイレクトする Amazon S3 ロケーション URL を選択します。
4. node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/ というパスに従って UUID フォルダーに移動します。
   注: example-primary-node-ID とexample-UUID は、使用しているシステムの名前に置き換えます。
5. 表示されるリストで puppet.log.gz を選択し、[開く] を選択すると、新しいブラウザータブにプロビジョニングが表示されます。

プロビジョニングログが失敗した理由を特定する

サポートされていない構成パラメータはエラーの原因となります。エラーは、ホスト名の誤り、パスワードの誤り、または一般的なオペレーティングシステムの問題によっても発生する可能性があります。「error」や「fail」など、関連するキーワードをログで検索します。

以下は、一般的なエラータイプです。

• Amazon Relational Database Service (Amazon RDS) インスタンスを使用して外部メタストアに接続する際に問題が発生。
• 外部キー配布センター (KDC) への接続に関する問題。
• YARN リソースマネージャーや Hadoop NameNode などのサービスを開始する際の問題。
• アプリケーションをダウンロードまたはインストールする際に発生する問題。
• S3 ログが利用できない。

Amazon RDS インスタンスを使用して外部メタストアに接続する際の問題

Hive、Hue、Oozie などの一部の Amazon EMR アプリケーションでは、Amazon RDS などの外部データベースにデータを保存するように設定できます。接続に問題があると、メッセージが表示されます。

Hive からのエラーメッセージの例を次に示します。

2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema version.
2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): Underlying cause: java.sql.SQLNonTransientConnectionException : Could not connect to address=(host=hostname)(port=3306)(type=master) : Socket fail to connect to host:hostname, port:3306. hostname
2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): SQL Error code: -1

このタイプのエラーを解決するには、以下を実行します。

• RDS インスタンスのホスト名、ユーザー、パスワード、およびデータベースが正しいことを確認します。
• RDS インスタンスのセキュリティグループのインバウンドルールが Amazon EMR プライマリノードセキュリティグループからの接続を許可していることを確認します。

外部 KDC への接続に関する問題

Amazon EMR では、外部 KDC を設定してセキュリティをさらに強化できます。また、Active Directory サーバーとの信頼関係を構築することもできます。KDC への接続やドメインへの参加に問題があると、メッセージが表示されます。

Puppet からのエラーメッセージの例を次に示します。

2022-11-26 03:02:01 +0000 Puppet (err): 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]
2022-11-26 03:02:01 +0000 /Stage[main]/Kerberos::Ad_joiner/Exec[realm_join]/returns (err): change from 'notrun' to ['0'] failed: 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]

このタイプのエラーを解決するには、以下を実行します。

• Kerberos レルムのスペルが正しいことを確認します。
• KDC 管理者パスワードの入力が正しいことを確認します。
• Active Directory の参加ユーザーとパスワードの入力が正しいことを確認します。
• Active Directory 参加ユーザーが Active Directory に存在し、正しい権限を持っていることを確認します。
• KDC サーバーと Active Directory サーバーが Amazon EC2 上にあることを確認します。次に、KDC と Active Directory セキュリティグループのインバウンドルールが Amazon EMR プライマリノードセキュリティグループからの接続を許可していることを確認します。
• KDC とアクティブディレクトリが Amazon EC2 にないことを確認します。次に、KDC と Active Directory が EMR クラスターの仮想プライベートクラウド (VPC) とサブネットからの接続を許可していることを確認します。

YARN リソースマネージャー、Hadoop NameNode、Spark ヒストリーサーバーなどのサービスを開始する際の問題

Amazon EMR では、EMR クラスターの起動時にすべてのアプリケーションをカスタム構成できます。ただし、これらの構成によってサービスが開始されない場合があります。サービスの開始を妨げる問題が発生すると、メッセージが表示されます。

Spark ヒストリサーバーからのエラーメッセージの例を次に示します。

2022-11-26 03:34:13 +0000 Puppet (err): Systemd start for spark-history-server failed!
journalctl log for spark-history-server:
-- Logs begin at Sat 2022-11-26 03:27:57 UTC, end at Sat 2022-11-26 03:34:13 UTC. --
Nov 26 03:34:10 ip-192-168-1-32 systemd[1]: Starting Spark history-server...
Nov 26 03:34:10 ip-192-168-1-32 spark-history-server[1076]: Starting Spark history-server (spark-history-server):[OK]
Nov 26 03:34:10 ip-192-168-1-32 su[1112]: (to spark) root on none
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service: control process exited, code=exited status=1
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Failed to start Spark history-server.
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Unit spark-history-server.service entered failed state.
Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service failed.
2022-11-26 03:34:13 +0000 /Stage[main]/Spark::History_server/Service[spark-history-server]/ensure (err): change from 'stopped' to 'running' failed: Systemd start for spark-history-server failed!
journalctl log for spark-history-server:

このタイプのエラーを解決するには、以下を実行します。

• 開始できなかったサービスを確認します。提供された設定の入力が正しいかどうかを確認します。
• 次のパスに移動して S3 ログを確認し、失敗の原因を調査します。s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz
  **注:**example-log-location、 example-cluster-ID、 example-primary y-node-ID、 example-failed-application、 example-failed-service は、使用しているシステムの名前に置き換えます。

アプリケーションをダウンロードまたはインストールする際に発生する問題

Amazon EMR では多くのアプリケーションをインストールできます。ただし、1 つのアプリケーションをダウンロードまたはインストールできないという問題が発生することがあります。これにより EMR クラスターに障害が発生する可能性があります。この障害が発生すると、プロビジョニングログは完成しません。代わりに stderr.gz ログを確認して、yum のインストールに失敗したことによる同様のメッセージを見つける必要があります。

stderr.gz からのエラーメッセージの例を次に示します。

stderr.gz
Error Summary
-------------
Disk Requirements:
  At least 2176MB more space needed on the / filesystem.
  
2022-11-26 03:18:44,662 ERROR Program: Encountered a problem while provisioning
java.lang.RuntimeException: Amazon-linux-extras topics enabling or yum packages installation failed.

この種のエラーを解決するには、EMR クラスターの起動時に Amazon Elastic Block Store (Amazon EBS) のルートボリュームを増やします。

S3 ログが利用できない

Amazon EMR でアプリケーションのプロビジョニングに失敗し、Amazon S3 でログが生成されない。このシナリオでは、ネットワークエラーが原因で S3 ログ記録が失敗した可能性があります。

このタイプのエラーを解決するには、以下を実行します。

• EMR クラスターの起動時にログ記録オプションがオンになっていることを確認します。詳細については、「クラスターロギングとデバッグの設定」を参照してください。
• カスタム AMI を使用するときは、必要な Amazon EMR ネットワーク設定を妨げるファイアウォールルールがないことを確認します。詳細については、「Amazon EMR マネージドセキュリティグループの使用」を参照してください。
• カスタム AMI を使用するときは、障害が発生したプライマリノードがないかどうかを確認します。Amazon EMR コンソールを開き、ナビゲーションペインで [Hardware] を選択して、クラスターがプライマリノードを起動できなかったかどうかを確認します。
• カスタム AMI を使用するときは、ベストプラクティスに従っていることを確認します。詳細については、「カスタム AMI の使用」を参照してください。

---

関連情報

EMR クラスターがプロビジョニングに失敗