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 の効率的な使い方の基本は、コンピュートとストレージを分離することです。データは S3 に置き、処理が必要なときだけクラスターを立ち上げて読み込む構成にすれば、クラスターを常時稼働させずに済み、コストを抑えられます。クラスターを終了してもデータは S3 に残るため、複数の処理から同じデータを再利用できます。データカタログにテーブル定義を登録しておけば、EMR だけでなく他の分析サービスからも同じデータを参照でき、データレイク全体を一貫して扱えます。ストレージを永続的な S3 に集約する設計が、柔軟でコスト効率の高いビッグデータ基盤の土台になります。
クラスターの実行形態
EMR のクラスターは、用途に応じて使い分けます。決まった処理を実行して終わったらクラスターを破棄する一時的な使い方は、バッチ処理に向き、無駄な稼働を避けられます。対話的な分析や継続的な処理には、常時稼働のクラスターを使います。処理をステップとして定義し、順番に実行させることもできます。サーバーレスの実行形態を選べば、クラスターの管理自体が不要になり、ジョブの投入だけに集中できます。ノートブック環境を使えば、データサイエンティストが対話的に分析を進められます。処理の性質と頻度に応じて、最適な実行形態を選ぶことが効率化の鍵です。
パフォーマンスとコストの最適化
EMR のコストと性能は、インスタンスの選び方で大きく変わります。複数のインスタンスタイプを柔軟に組み合わせる構成にすれば、可用性を保ちつつ、割安なスポットインスタンスを活用できます。中断されても問題ない処理にスポットを使うことで、コストを大幅に削減できます。負荷に応じてクラスターの規模を自動調整する仕組みを使えば、処理量の波に合わせてリソースを増減でき、無駄を抑えられます。データの分割の仕方や、処理に必要なリソースの見積もりを適切に行うことで、処理時間を短縮しつつ費用も抑える、バランスの取れた運用が実現します。
セキュリティとガバナンス
ビッグデータ基盤では、扱うデータの保護とアクセス管理が重要です。保存データと処理中の通信を暗号化し、機微な情報を守ります。データへのアクセスは、きめ細かな権限管理の仕組みと組み合わせ、利用者ごとに参照できる範囲を制御します。列や行のレベルでアクセスを制限すれば、同じデータセットでも部門ごとに見せる範囲を変えられます。誰がどのデータを処理したかを記録し、監査できるようにします。大量のデータを多くの利用者が扱う環境だからこそ、暗号化・アクセス制御・監査を組み合わせたガバナンスを整えることが、安全な分析基盤の前提になります。
まとめ
EMR は Spark や Hive などのビッグデータフレームワークのマネージド実行環境を提供します。S3 をプライマリストレージとした EMRFS アーキテクチャでスポットインスタンスの中断リスクを軽減し、マネージドスケーリングでジョブ負荷に応じたノード数の自動調整を実現します。EMR on EKS で既存の Kubernetes 環境との統合も可能です。