Amazon EMR

解決する課題

Spark や Hadoop のクラスタを自前で構築しようとすると、サーバーの調達、分散フレームワークのインストールと設定、バージョン整合、スケーリング、障害対応に多くの工数がかかります。Amazon EMR はこれらを肩代わりします。

• ビッグデータ基盤のクラスタを数分で起動し、不要になれば破棄できる
• フレームワーク（Spark/Hive/Presto/HBase など）の導入・設定をマネージド化
• データ量や処理量に応じてノードを自動で増減できる
• ストレージを S3 に分離し、コンピュートを使う分だけに抑えられる

主要概念と用語

• クラスタ: 処理を担う EC2 インスタンス（ノード）の集合。1回の起動単位
• ノードタイプ: クラスタ全体を統括するマスター（プライマリ）、計算と保存を担うコア、計算のみを担うタスクの3種
• アプリケーション: クラスタに導入するフレームワーク。Spark、Hadoop（MapReduce/YARN）、Hive、Presto/Trino、HBase、Flink など
• ステップ: クラスタに投入する処理ジョブの単位
• EMRFS: EMR から S3 をファイルシステムのように扱う仕組み。HDFS の代わりに S3 を永続ストレージにできる
• インスタンスフリート / インスタンスグループ: ノードの台数やインスタンスタイプ、購入オプションをまとめて管理する方式
• デプロイ形態: EC2 上で動かす標準形態のほか、Kubernetes で動かす EMR on EKS、クラスタ管理不要の EMR Serverless がある

仕様・制限・クォータ

• リージョン内の VPC・サブネットにクラスタを配置する。1クラスタは原則として単一の AZ に展開される
• マスターノードは通常1台で、可用性を高める構成も選べる。コア/タスクノードは複数台にスケール可能
• 起動するインスタンス数は EC2 の vCPU クォータに従い、上限引き上げを申請できる
• 利用できるアプリケーションのバージョンは EMR リリースラベルごとに束ねられている。具体的なバージョン番号はリリースにより変動するため、利用時に最新の対応表を確認する
• クラスタは**長時間稼働（常設）にも、処理が終わると自動終了する一時クラスタ（トランジェント）**にもできる

内部の仕組み

EMR はクラスタを EC2 インスタンス上に構築し、各ノードに選択したアプリケーションを配置します。マスターノードが YARN などのリソース管理を通じてジョブを各ノードに割り当て、コア/タスクノードが分散処理を実行します。

• コアノードは HDFS のデータ保持を兼ねるため、減らしすぎるとデータ消失のおそれがある。タスクノードは計算専用で、安全に増減できる
• 永続データは EMRFS 経由で S3 に置き、HDFS は一時的な中間データに使うのが一般的。これによりクラスタを破棄してもデータが残る（ストレージとコンピュートの分離）
• EMR on EKS は既存の Kubernetes クラスタ上で Spark ジョブを実行し、EKS のリソースと共存させられる
• EMR Serverless はクラスタのサイジングや起動を意識せず、ジョブ実行に必要な容量を自動で確保する

設計パターン / ベストプラクティス

• ストレージはS3、コンピュートは使い捨て: 永続データを EMRFS で S3 に逃がし、処理ごとに一時クラスタを起動・破棄する
• タスクノードにスポット: 中断を許容できる計算は安価なスポットで賄い、コアノードはオンデマンド/予約で安定させる
• オートスケール / マネージドスケーリング: 負荷に応じてノードを自動増減し、待ち時間と無駄を抑える
• ジョブ特性で形態を選ぶ: 細かい運用制御が要るなら EC2、Kubernetes 基盤に寄せたいなら EMR on EKS、断続的なジョブなら EMR Serverless
• ブートストラップアクションでノード起動時に共通設定やライブラリを投入し、再現性を保つ

運用・監視

• CloudWatch でクラスタやノードのメトリクス（CPU、メモリ、HDFS 使用率、保留中のコンテナ数など）を監視する
• アプリケーションのログは S3 へ自動アーカイブする設定にしておくと、クラスタ破棄後も調査できる
• Spark/YARN の **Web UI（履歴サーバー含む）**でジョブの実行状況やボトルネックを確認する
• 一時クラスタは処理完了後の自動終了を有効にし、消し忘れによる課金を防ぐ

コスト

• 課金は主にEC2 インスタンスの稼働時間に、EMR の利用料が上乗せされる形が基本（EMR on EKS や Serverless は課金体系が異なる）
• コスト最適化の要点は、使う分だけ起動・即破棄、タスクノードのスポット活用、right-sizing と自動スケール
• 変動する具体的な単価は公式の料金ページで確認する

セキュリティ

• IAM ロールでクラスタやノード、EMRFS から S3 などへのアクセスを最小権限に制御する
• データは保存時暗号化（S3/EBS、鍵は KMS）と転送時の TLS で保護する
• クラスタは VPC のプライベートサブネットに置き、セキュリティグループで通信を絞る
• 複数ユーザーでクラスタを共有する場合は、ユーザー単位のアクセス制御（細粒度アクセス制御や Lake Formation 連携など）を検討する

Well-Architected の観点

• パフォーマンス効率: 用途に合うインスタンスタイプ選定、自動スケール、適切なフレームワーク選択
• コスト最適化: 一時クラスタの即破棄、タスクノードのスポット、S3 分離による無駄の削減
• 信頼性: 重要データは S3 に永続化し、クラスタ自体は使い捨てにできる設計にする
• セキュリティ: 最小権限の IAM ロール、暗号化、プライベートサブネット配置

試験で問われるポイント

関連サービス・比較

サーバーレスでクエリやETLを行う Athena/Glue とよく比較されます。クラスタを制御したい大規模・反復的な処理は EMR、運用を最小化したいアドホックな処理はサーバーレス系が向きます。

ハンズオン / CLI例

# Spark 入りの一時クラスタを起動し、処理完了後に自動終了させる例
aws emr create-cluster \
  --name "demo-spark" \
  --release-label emr-7.0.0 \
  --applications Name=Spark \
  --instance-groups \
    InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m5.xlarge \
    InstanceGroupType=CORE,InstanceCount=2,InstanceType=m5.xlarge \
  --use-default-roles \
  --log-uri s3://my-emr-logs/ \
  --auto-terminate

# クラスタの一覧（起動中・待機中のみ）
aws emr list-clusters --active