Amazon EMR によるビッグデータ処理 - Spark と Hive の実行環境
EMR クラスターで Spark ジョブと Hive クエリを実行し、EMR Serverless との使い分けとマネージドスケーリングによるコスト最適化を紹介します。
EMR クラスターの構成
EMR クラスターは最大数百ノードで構成され、マスターノード (クラスター管理と YARN リソースマネージャー)、コアノード (HDFS データ保持と計算処理)、タスクノード (計算処理のみ) で構成されます。コアノードは HDFS のデータを保持するため縮小時にデータ損失のリスクがありますが、タスクノードはデータを持たないため自由にスケールできます。S3 をプライマリストレージとして使用する場合、コアノードの HDFS は中間データの一時保存に限定し、タスクノードのスポットインスタンス活用でコストを削減します。EC2 インスタンスフリートを使うと、複数のインスタンスタイプを指定してスポットの可用性を高められます。
Spark と Hive の実行
Spark on EMR では spark-submit コマンドまたは EMR Steps API でジョブを投入します。EMRFS は S3 への読み書きを最適化するファイルシステムで、S3 の結果整合性を回避する一貫性ビューを提供します。Spark の動的リソース割り当て (Dynamic Resource Allocation) を有効にすると、ジョブの負荷に応じてエグゼキューターの数を自動調整します。Hive on EMR では Glue データカタログを外部メタストアとして設定でき、テーブル定義を Athena や Redshift Spectrum と共有できます。EMR Serverless はクラスターのプロビジョニングが不要で、アプリケーション単位でリソースを指定してジョブを実行します。
EMR on EKS とマネージドスケーリング
EMR on EKS は既存の EKS クラスターで Spark ジョブを実行し、 Kubernetes のリソース管理とスケジューリングを活用します。仮想クラスターを作成して EKS の名前空間にマッピングし、 StartJobRun API でジョブを投入します。 EMR on EC2 のマネージドスケーリングは、ジョブの負荷に応じてコアノードとタスクノードを自動的に追加・削除します。スケーリングの最小・最大ノード数を設定し、 YARN のメモリ使用率に基づいてスケーリング判断が行われます。 EMR Studio はブラウザベースの IDE で、 Jupyter ノートブックから EMR クラスターに接続してインタラクティブな分析を実行できます。 Spark の設計パターンを網羅的に学ぶなら、技術書 (Amazon)を参照してください。
EMR のコスト最適化
EMR のコストはインスタンス料金と EMR 料金 (EC2 料金の約 25%) で構成されます。タスクノードにスポットインスタンスを使用し、コアノードはオンデマンドで HDFS データの安全性を確保する構成が推奨されます。S3 をプライマリストレージとする EMRFS アーキテクチャでは、コアノードの HDFS を最小限にしてスポットの中断リスクを軽減できます。一時的なクラスターをジョブ実行時のみ起動し、完了後に自動終了する設計で、アイドル時間のコストを排除します。Graviton インスタンス (m6g、r6g) は同等の x86 インスタンスより約 20% 安価で、Spark ジョブの実行に適しています。
まとめ
EMR は Spark や Hive などのビッグデータフレームワークのマネージド実行環境を提供します。S3 をプライマリストレージとした EMRFS アーキテクチャでスポットインスタンスの中断リスクを軽減し、マネージドスケーリングでジョブ負荷に応じたノード数の自動調整を実現します。EMR on EKS で既存の Kubernetes 環境との統合も可能です。