オンプレミスHadoopからAmazon EMRへの移行とコスト最適化の手法

Posted at 2026-08-10

オンプレミスで複数台のサーバーを用いてHadoopを運用し、大規模なデータ処理基盤を提供しているケースはまだ多くあります。こうした環境をクラウドへ移行しようとする際、最大の壁となるのが 「データの移動コスト」と「ストレージコスト」 です。

クラウド移行における課題：EC2への単純インストールはなぜ危険か

安易にEC2インスタンスを複数台立ててHadoopを構築し、大容量のEBS（Elastic Block Store）を割り当てると、コストが膨大になります。理由は主に2点です。

ストレージの永続性と課金： EC2を停止させてもEBSは課金され続け、データを保持するためには削除できません
HDFSのレプリケーションによる増幅： Hadoop（HDFS）の特性上、データが複数台に複製して保存されるため、実際のデータ量よりもはるかに大きなストレージ費用が発生します

つまり、「計算リソースとストレージをセットで常時保持する」構成は、クラウドでは極めてコスト効率が悪くなります。

この問題を解消するのが Amazon EMR の活用です。
ポイントは、「処理する時だけクラスターを起動し、データはS3に逃がす」という運用形態（エフェメラルクラスター） を採用することです。

EMRでは、S3をHDFSのようなファイルシステムとして扱うことができる EMRFS という仕組みが提供されています。これにより、「S3にデータを置き、処理時だけ計算リソース（EMR）を割り当てる」ことが可能になります。

さらに、私は実装において以下の最適化を行いました。

EMRFSを使えばS3から直接データを読み書きできますが、本件ではあえて 「S3 $\rightarrow$ HDFS（ローカル）$\rightarrow$ 処理 $\rightarrow$ S3」 というフローを採用しました。

理由： S3への直接アクセスよりも、一度HDFSに取り込んだほうがI/Oパフォーマンスが向上するためです
効果： I/Oのボトルネックが解消され、EMRの実行時間が短縮されました。EMRは時間課金であるため、処理時間を短くすることはそのままコスト削減に直結します

エフェメラルクラスターの場合、インスタンスの起動に数分（2〜3分程度）かかります。この待機時間や起動後の処理順序を制御するため、AWS Step Functions を導入してワークフローを管理しました。

これにより、「クラスター起動 $\rightarrow$ データのインポート $\rightarrow$ 本処理実行 $\rightarrow$ 結果のエクスポート $\rightarrow$ クラスター削除」という一連の流れを完全に自動化し、人的ミスやリソースの消し忘れを防止しています。

具体的には、以下のようなシェルスクリプトによるバッチ処理をStep Functionsで制御していました。

この構成を採用したことで、以下のようなメリットを得ることができました。

劇的なコスト削減： 常時起動していたオンプレミス/EC2環境に比べ、計算リソースを「使った分だけ」の支払いに変更でき、ストレージ費用も安価なS3へ集約できたため、大幅なコストダウンを実現しました。
運用の効率化： Step Functionsによる自動化で、バッチ処理の再実行性や管理性が向上しました。

オンプレミスからの移行では、単に環境をコピーするのではなく、「クラウドならではのストレージ特性（S3）」と「サーバーレスなオーケストレーション」を組み合わせることが成功の鍵となります。