[小ネタ]Amazon EMRクラスターで使用するAmazon EC2インスタンスのスペックをケチると、クラスターが動かないことがある

Amazon EC2インスタンスタイプのメモリが小さすぎると、Amazon EMRクラスターのステータスが「実行中」のまま動かなくなることがあります。他の設定が原因であることもあるので、正確にログを確認し、原因を特定することが重要です
2024.01.30

Amazon EMRクラスターが動かない

おのやんです。

みなさん、Amazon EMR(以下、EMR)クラスターが動かなくなったことはありませんか?私は何度かあります。

具体的に言うと、マネジメントコンソール上でEMRクラスターを確認した際に、ステータスがずっと「開始中」のまま進まない現象に遭遇しました。

ということで、今回はこちらの原因の調査と対策を行ってみたいと思います。

原因

今回の現象は、EMRクラスターのAmazon EC2(以下、EC2)インスタンスのインスタンスタイプを、デフォルトのm5.xlargeからc1.mediumに変更したことが原因でした。

EMRクラスターを作成する際には、複数のEC2インスタンスが起動されます。この際の料金を節約するために、EC2インスタンスタイプをm5.xlarge(0.248 USD/時間)からc1.medium(0.158 USD/時間)に変えた経緯がありました(こちらの料金はマネジメントコンソール上の数値です)。

スペックを比較すると次の通りです。

インスタンスタイプ コア数(vCore) メモリ(GiB)
m5.xlarge 4 16
c1.medium 2 1.7

m5.xlargeのメモリが16GiBであるのに対して、c1.mediumのメモリは1.7GiBでした。これにより、デフォルトの設定で動作するはずのEMRクラスターがメモリ不足で実行不可能になったわけです。

実際にEMRクラスターをクローンして、インスタンスタイプをm5.xlargeに戻してみます。すると、EMRクラスターが正常に実行されるようになりました。

調査方法

この原因に辿り着く際に、どこを調べたのかを共有します。

EMRクラスターの起動が上手くいかない場合の対処法は、こちらのAWS re:Postの質問に記載があります。

ブートストラップアクションが失敗した理由を判断するには、ブートストラップアクションの stderr ログを確認します。これらのログは、Amazon EMR クラスターの作成時に設定した Amazon Simple Storage Service (Amazon S3) のパスまたは LogUri にあります。

この情報を元にS3バケットのログを調べると、確かにstderrログが作成されていました。今回の場合は、あるクラスターの配下にあるノード(EC2インスタンス)が記録しているprovision-node/apps-phase/0/id名にありました。

こちらを開くとログが表示されます。ここでCtrl + Fを押して「error」を検索します。するとログの中にエラー文があるのを確認できます。

'HADOOP_OPTS': '"$HADOOP_OPTS -server -XX:+ExitOnOutOfMemoryError -add-exports=jdk.compiler/com.sun. tools.javac.til=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED

ExitOnOutOfMemoryError、つまりメモリ不足によるエラーでしたね。ここからインスタンスタイプを変更したことを思い出し、原因特定に繋がったわけです。

EMRクラスターがうまく動かない時はログを正しく確認しよう

EMRクラスターのエラーに関する情報が意外と少なかったので、今回まとめてみました。

今回はEC2インスタンスのメモリが小さすぎることが原因でしたが、他の設定が原因であることもあります。不具合が起きている際には、正確にログを確認し、原因を特定しましょう。では!