この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、小澤です。
今回は、EMRを利用する際にちょっと気をつけておいたほうがいい小ネタを紹介します。
EMRでのディスクサイズ
EMRを利用するときは多くの場合、S3などを入出力先として利用するかと思います。 そのため、主にHDFSとして利用されるインスタンスのディスクサイズってそれほど関係ないんじゃないの？と思われる方も多いかと思います。
しかし、実はHadoopでは、必ずしも入力と出力意外に何も生成しないかというとその限りではありません。 いくつか例を挙げると
- Hadoopのログ出力
- Mapperの中間出力
- Hiveのscratchdir
- Sparkのキャッシュ
などが考えられます。 これらはHDFSや各ノードのローカルディスクに保存されることになります。
平均的なディスク使用率としてみたときはたいしたことないけど、 ジョブ実行中などで一時的に上がるという状態は考慮しておいたほうがいいでしょう。 そのため、基本的にHDFSは利用しないという前提であってもある程度のサイズは考慮しておいたほうがいいということになります。
ストレージがEBSのみのインスタンス
さて、ここのとき注意が必要なのはストレージタイプがEBSのみのインスタンスを使う場合です。 インスタンスストレージを利用する場合は他のスペック比較してディスクサイズのみが極端に小さいという状況はなかなか起こらないため、処理すべきデータ量と相談した上で適切なインスタンスタイプを選択している限りはディスクのみが問題になるということはあまりないかと思います。
一方でEBSを利用する場合、そのサイズも指定可能になっています。 2017/04/03現在、デフォルト値では32GBとなっています。
EMRを利用する場合、処理能力の高いインスタンスを選択し非常に多くのデータを扱う場面も多いかと思いますが、 ついうっかりのEBSを32GBのままにしてしまうと処理途中でディスクフルとなってしまう可能性があります。
処理途中でディスクフルとなってしまうと、それまで順調に進んでいたのに突然失敗し始めた！など、 処理内容やパラメータは問題ないはずなのにうまくいかないといった状況が発生しうる可能性があります。
終わりに
今回は小ネタとして、特にストレージがEBSのみのインスタンスを使う時などに注意が必要なディスクサイズの話をしました。 ディスクフルでの処理が失敗は、知っていないと原因の特定がなかなか難しく、 またフルになるまで処理を進めないと再現できなかったりするので地味に厄介です。