Amazon EMR
Apache Spark、Hive、Presto などのオープンソースフレームワークをマネージドで実行し、ペタバイト規模のデータ処理・分析を行うビッグデータプラットフォーム
概要
Amazon EMR (Elastic MapReduce) は、Apache Spark、Hadoop、Hive、Presto、HBase などのオープンソースフレームワークをフルマネージドで実行するビッグデータ処理サービスです。EC2 インスタンス上にクラスターを構築する従来型に加え、EKS 上で実行する EMR on EKS、サーバーレスで実行する EMR Serverless の 3 つのデプロイオプションがあります。S3 をデータレイクとして活用し、コンピュートとストレージを分離するアーキテクチャにより、処理が終わればクラスターを終了してコストを最小化できます。
3 つのデプロイモデルと選定基準
EMR on EC2 は最も柔軟なオプションで、インスタンスタイプ、クラスター構成、ブートストラップアクションを細かく制御できます。Spark や Hive のバージョン指定、カスタム AMI の利用、HDFS によるローカルストレージの活用が必要なケースに適しています。EMR on EKS は既存の EKS クラスター上で Spark ジョブを実行する方式で、Kubernetes のリソース管理やマルチテナント機能を活かせます。複数チームが同一クラスターを共有しつつ、名前空間でジョブを分離する運用に向いています。EMR Serverless は 2022 年に GA となった最新オプションで、クラスターの構築・管理が一切不要です。ジョブを投入するだけで必要なリソースが自動的にプロビジョニングされ、処理完了後に解放されます。バッチ ETL やアドホック分析など、常時稼働が不要なワークロードではコスト効率が最も高くなります。選定の目安として、細かいチューニングが必要なら EC2、Kubernetes 統合が必要なら EKS、運用負荷を最小化したいなら Serverless を選択します。
Spark ジョブの最適化とコスト制御
EMR で Spark を実行する際、パフォーマンスとコストに最も影響するのはインスタンス構成とパーティション設計です。ドライバーノードにはメモリ重視の r 系インスタンス、ワーカーノードにはコスト重視の m 系インスタンスを割り当てるのが基本です。スポットインスタンスをワーカーノードに活用すれば、オンデマンドの 60-90% のコスト削減が可能ですが、中断リスクに備えてインスタンスフリートで複数のインスタンスタイプを指定しておく必要があります。Spark のシャッフルパーティション数 (spark.sql.shuffle.partitions) はデフォルトの 200 から、データ量に応じて調整します。目安としてパーティションあたり 128-256 MB になるよう設定すると、メモリ効率とタスク並列度のバランスが取れます。S3 からの読み込みでは、Parquet や ORC などの列指向フォーマットを使い、パーティションプルーニングが効くようにデータを日付やカテゴリでパーティショニングしておくことが重要です。EMR Runtime for Apache Spark は OSS 版 Spark に対して最大 3.5 倍の高速化を実現しており、追加料金なしで利用できます。
データレイクアーキテクチャと Glue との使い分け
EMR と Glue はどちらも Spark ベースの ETL 処理を実行できますが、位置づけが異なります。Glue はサーバーレスで運用負荷が低く、Glue Data Catalog によるメタデータ管理やクローラーによるスキーマ自動検出が統合されています。定型的な ETL パイプラインや、データカタログとの連携が重要なケースでは Glue が適しています。一方、EMR は Spark 以外にも Hive、Presto、HBase、Flink など多様なフレームワークを実行でき、クラスター構成の自由度が高いため、複雑な分析処理やインタラクティブクエリに向いています。実務では、日次の定型 ETL は Glue で処理し、アドホックな大規模分析や機械学習の前処理は EMR で実行するという使い分けが一般的です。データレイクの構築では、S3 に生データを格納し、Glue クローラーでスキーマを検出して Data Catalog に登録し、EMR や Athena からクエリする構成が標準パターンです。Apache Iceberg や Delta Lake などのテーブルフォーマットを EMR 上で利用すれば、ACID トランザクションやタイムトラベルクエリも実現できます。