Amazon EMR クラスター上でストレージを動的にスケールアップする

Amazon EMR クラスター上でストレージを動的にスケールアップする:

Amazon EMR クラスターのような管理された Apache Hadoop 環境では、クラスター上のストレージ容量がいっぱいになると、それに対処する便利なソリューションはありません。この状況は、クラスター起動時に、Amazon Elastic Block Store (Amazon EBS) ボリュームを設定し、マウントポイントを設定するために発生します。そのため、クラスタの実行後にストレージ容量を変更することは困難になります。これに適したソリューションとしては、通常 、クラスターにさらにノードを追加し、データレイクにデータをバックアップしてから、より大きな記憶容量を持つ新しいクラスターを起動する方法があります。または、ストレージを占有するデータを消去してもよい場合は、通常、余分なデータを削除するという方法があります。

Amazon EMR で管理可能な方法により、この問題に対処する際の役に立つ、Amazon EBS のElastic Volumes 機能を使用してストレージを動的にスケールアップする方法を説明します。この機能で、ボリュームの使用中に、ボリュームサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプを変更することができます。変更が有効になっている間も、EMR クラスターを継続使用して、大きなデータアプリケーションを実行できます。

Amazon EMR クラスター上で、HDFS と YARNがディスクスペースを使用する仕組み

Amazon EMR クラスターを作成すると、デフォルトでは、HDFS（Hadoop Distributed File System）および YARN（Yet Another Resource Negotiator）は、すべてのコア/タスクノードで使用可能なローカルディスクストレージを使用するように設定されます。これは yarn-site.xml および hdfs-site.xml 設定ファイル内で設定します。

厳密に言えば、HDFS では、dfs.datanode.data.dir パラメータは、ローカルストレージを使用するように設定されます。ローカルストレージは、NameNode デーモンが管理するファイルのデータブロックを格納します。また、YARN では、yarn.nodemanager.local-dirs パラメータは、YARN コンテナを実行するために、NodeManager デーモンに必要な中間ファイルを格納するように設定されます。

たとえば、クラスターで、MapReduce ジョブが実行されている場合、マップタスクは、出力ファイルを、yarn.nodemanager.local-dirs で定義されたディレクトリに格納します。さらに、yarn.nodemanager.log-dirs パラメータは、YARN アプリケーションの終了後に、コアおよびタスクノードに、コンテナログを格納するように設定されます。

ストレージの問題回避のための、一般的なベストプラクティス

Amazon EMR クラスターで業務を実行する予定がある場合に、クラスターで使用可能なストレージ容量を超えないようにするための、役に立つヒントを次に示します。

将来のストレージニーズを見積もる

業務のストレージニーズについて事前に計画してくださいデフォルトのストレージ構成を使用してクラスタを起動すると、作業負荷には不十分な場合があり、業務の実行中に問題が発生する可能性があります。業務に必要な中間ストレージ容量を見積るようお勧めします。それに基づいて、新しいクラスターを起動するときに、ストレージ構成をカスタマイズできます。

データレイクにパッシブデータを格納する

すべてのパッシブデータが Amazon Simple Storage Service (Amazon S3) のようなデータレイクに格納されるように作業負荷を設計してください。この方法では、クラスタをデータ処理のためにのみ使用し、その他の計算タスクを実行し、固定ストレージに対応するデータレイクに戻す結果を格納します。このアプローチは、実行中のクラスター上のストレージ要件を最小限に抑えます。

より多くの容量を計画する

入力データまたは出力データをクラスター（HDFS またはローカルストレージ）にローカルに格納するようユースケースで指示されている場合は、それに応じてクラスタのサイズを計画する必要があります。たとえば、HDFS を使用している場合は、データを格納するのに十分な数のコアノードを持つクラスターを作成できます。または、コアインスタンスグループをカスタマイズして、既定の設定よりも多くの EBS ストレージ容量を持たせることができます。

ストレージが最大容量に達した場合に発生する可能性のある問題

EMR クラスターが、異なるデータ処理アプリケーション実行に使用されているため、ある時点でクラスター上のストレージ容量が使い果たされる可能性があります。この場合、クラスターに影響を与える可能性のある問題は、次のとおりです。

YARN の観点からの問題

yarn.nodemanager.local-dirs または yarn.nodemanager.log-dirs パラメータで定義されているディレクトリが、ボリュームの合計ストレージの少なくとも 90％ まで満たされている場合、NodeManager は、その特定のディスクに不健全とマークします。この操作により、NodeManager は、それらのディスクが不健全であるノードもマークします。したがって、ノードが正常でない場合、ResourceManager はコンテナをノードに割り当てません。

さらに、EMR クラスターで終端保護機能がオフになっている場合、EMR サービスは、最終的にクラスターのノードを終了します。

HDFS の観点からの課題

クラスター上の HDFS 使用率が増加すると、EBS ボリューム上のローカルストレージの使用量も増加します。EMR では、HDFS データディレクトリは、YARN ローカルディレクトリとログディレクトリと同じマウントポイントに設定されます。したがって、マウントポイントの使用量が HDFS のためにストレージのしきい値（90％）を超えた場合、YARN はそのディスクに異常があるとマークし、ResourceManager はノードをブラックリストに登録します。

コアノードとタスクノードのストレージスペースを動的にサイズ変更する

クラスタ上のコアノードとタスクノードのストレージをスケールアップするには、次のブートストラップアクションスクリプトを使用します。

s3://aws-bigdata-blog/artifacts/resize_storage/resize_storage.sh

さらに、ボリュームのサイズを変更できるようにするには、クラスターの EC2 インスタンスプロファイルに、ec2:ModifyVolume 権限が必要です。

このスクリプトは、EMR クラスターのすべてのノードで実行されます。ノード上で cron ジョブを設定し、2分ごとにディスク使用率チェックを実行します。マスターノードでは、ルートボリュームと、さまざまなマスターデーモンのログを格納しているボリュームのチェックを実行します。コアノードとタスクノードでは、YARN と HDFS が使用するボリュームのチェックを実行し、ストレージをスケールアップする必要があるかどうかを判断します。

ボリュームが使用量の90％を超えたと判断した場合、ボリュームのサイズは、「--scaling-factor」パラメータで指定された割合で拡大されますリサイズ処理中、ボリュームのパーティションが拡張され、ファイルシステムが更新されて、更新された容量が反映されます。これはすべて、クラスタで実行されているアプリケーションに影響を与えることなく行われます。

このソリューションを使用する前に、次の点に注意してください。

• クラスタが EBS ボリュームをストレージバックエンドとして使用する場合に限り、EMR クラスタ内のノードのストレージ容量を拡大できます。特定の EC2 インスタンスタイプは、インスタンス格納ボリュームのみ、またはインスタンス格納と EBS ボリュームの両方を使用します。このような EC2 インスタンスタイプを使用するクラスターでは、ストレージ容量のサイズを変更できません。
• スクリプトのスケーリングファクターのオプションを決定する際に、ボリュームを増やして、更新した設定でかなりの時間持続するように計画してください。ストレージのスケールアップをする場合、同じボリュームにさらに変更を加える前に、少なくとも6時間待たなければなりません。

結論

この記事では、HDFS と YARN が Amazon EMRクラスターノードでローカルストレージをどのように使用するかについて説明しました。Amazon EBS の Elastic Volume 機能を使用して、EMR クラスター上のストレージをスケールアップする方法について説明しました。この機能を使用して、ボリュームの使用中に、ボリュームのサイズを増やしたり、パフォーマンスを調整したり、ボリュームの種類を変更することができます。そして、EMR クラスターを継続使用して、変更が適用されている間に、大きなデータアプリケーションを実行することができます。

ご不明な点がございましたら、下記へコメントをお寄せください。

---

今回のブログ投稿者について

Jigar Mistry は、Amazon Web Services の Hadoop システムエンジニアです 。オープンソースのアプリケーションを使用して、クラウド内の大規模なデータセットを処理するためのアーキテクチャーのガイダンスと技術サポートをお客様に提供しています。余暇には、キャンプに行ったり、シアトルのさまざまなレストランを探索して楽しんでいます。