AWS re:Invent2025セッションレポート「Amazon EKSのSparkパフォーマンス最適化」

はじめに

本記事は、ラスベガスで行われているre:Invent 2025の参加レポートです。
現地の12/04(木) に行われた、EKS上のSparkパフォーマンス最適化に関するChalk Talkセッション（CNS420）に参加したレポートです。

セッションについて

タイトル

Shuffle, Scale, Succeed: Optimizing Spark Performance on Amazon EKS (CNS420)

概要（日本語訳）

Amazon EKSでApache Sparkを実行することはスケーラビリティをもたらしますが、
デフォルト設定のままではコスト増大やパイプラインの遅延を招く可能性があります。
このChalk Talkでは、Sparkのパフォーマンスに関する主要な課題と、実証済みの修正方法に焦点を当てています。
Apache Icebergによるメタデータプルーニングでのクエリ時間短縮、DataFusion CometによるSpark SQLの高速化（約2.4倍）、GlutenとVeloxによる最大3倍のパフォーマンス向上について学びます。
また、CometとGlutenの比較、Apache Celebornを使用したRemote Shuffleによるスケーリングの実演、さらにカスタムバッチスケジューラー、Karpenterによる動的スケーリング、Spark DRA（Dynamic Resource Allocation）を含むEKSの最適化についても共有されます。
データチームにとって、より高速でコスト効率の高いSparkワークロードを実装するための実践的なプレイブックとなります。

スピーカー

• Vara Bonthu, Principal Open Source Specialist SA, Amazon Web Services
• Manabu McCloskey, Senior Open Source Engineer, AWS

セッションタグ

• セッションタイプ: Chalk talk
• レベル: 400 – Expert
• 形式: Interactive
• トピック: Analytics, Serverless & Containers
• 関心領域: Open Data, Kubernetes, Machine Learning
• 対象ロール: Data Engineer, Data Scientist, DevOps Engineer
• 対象サービス: Amazon Elastic Kubernetes Service (Amazon EKS)

スケジュール

• 日時: Thursday, Dec 4 | 2:00 PM - 3:00 PM PST
• 場所: Mandalay Bay | Level 3 South | South Seas A

ポイント

このセッションを受けてみて感じたポイントです。

• EKSでのSpark実行における、Karpenterを利用した動的スケーリングとLocal NVMe SSD (RAID 0) の活用によるI/O最適化の重要性
• Apache Gluten + Veloxを用いたネイティブ実行エンジンによる、コード変更なしでのパフォーマンス向上（JVMオーバーヘッドの削減）
• Apache Celebornを用いたRemote Shuffle Service導入による、Spotインスタンス中断時の再計算コスト削減と耐障害性の向上

Why Spark on EKS?

現在、多くの企業（スタートアップからエンタープライズまで）がHadoopやEMRからEKS上のオープンソースソリューションへ移行しています。
EKSを利用する最大のメリットは、安定したリソースマネージャー（Kubernetes）とコントロールプレーンが提供される点です。
EKS上でSparkを実行する場合、主に「オープンソースのSpark on EKS」と「EMR on EKS」の2つの選択肢がありますが、本セッションではオープンソース版の最適化に焦点を当てています。

Configuration Spark on EKS for Scale and Efficiency

Sparkジョブを実行する際、Driver PodとExecutor Podがデプロイされます。
このスケジューリングとリソース効率化において、AWSでは Karpenter の利用を推奨しています。

従来のCluster Autoscalerと比較して、KarpenterはPodの要求リソースに最適なインスタンスタイプを動的に選択し、高速にノードをプロビジョニングします。

インスタンス選定と信頼性

• Driver Pod: ジョブの管理を行う単一障害点であるため、中断のリスクがない オンデマンドインスタンス の使用が推奨されます。
• Executor Pod: ステートレスな処理を行うため、コスト効率の良い Spotインスタンス を活用できます。
• アーキテクチャ: コストパフォーマンスに優れた Gravitonインスタンス（r7gなど） の利用が増えています。

ストレージ構成の最適化

Sparkのシャッフル処理はI/O負荷が高いため、ストレージのパフォーマンスが全体の処理速度に直結します。

• EBSボリューム: ネットワーク帯域の制限を受ける可能性があります。
• Local NVMe SSD (Instance Store): 「d」が付くインスタンスタイプ（例：r7gd）を利用することで、コンピュートに直結した高速なSSDを利用できます。
• RAID 0構成: Karpenterの NodePool 設定で raid0 を有効にすることで、複数のNVMe SSDを自動的にRAID 0構成し、単一のパス（例：/mnt/raid0）としてマウント可能です。
  • データエンジニアは、Spark設定のシャッフルディレクトリをこのパスに向けるだけで、I/Oパフォーマンスを最大化できます。

Dynamic Scaling with Spark + Karpenter

ストリーミングデータや日次バッチなど、データ量が予測できないワークロード（例：通常10TBだが突発的に20TBになるなど）において、静的なリソース割り当ては非効率です。

Dynamic Resource Allocation

Sparkの Dynamic Resource Allocation を有効にすることで、処理待ちのタスク数（Queue）に応じてExecutor数を動的に増減できます。

• 設定: spark.dynamicAllocation.enabled=true とし、minExecutors と maxExecutors を設定します。
• メリット: スパイク時のみリソースを拡張し、アイドル時は縮退することでコストを最適化できます。
• 注意点:
  • maxExecutors を適切に設定しないと、コストが青天井になるリスクがあります。
  • ExecutorあたりのCPU/メモリを小さくしすぎると、KarpenterのBin Packing（ノードへの詰め込み）効率が悪化し、オーバーヘッドが増加するため、適切なサイジングが必要です。

Accelerating compute with Apache Gluten + Velox

インフラ側の最適化（Karpenter, SSD）だけでなく、
Spark実行エンジン自体の高速化も可能です。
従来のSparkはJVM上で動作するため、オーバーヘッドが発生します。

Apache Gluten + Veloxとは

• Velox: Meta社が開発したC++ベースの高速な実行エンジン（ベクトル化処理、カラムナストレージ）。
• Apache Gluten: Sparkの物理プランをSubstraitプランに変換し、Veloxなどのネイティブエンジンに処理をオフロードするプラグイン。

導入効果と方法

• パフォーマンス: ベンチマーク（TPC-DS）では、クエリの60%以上で2倍〜10倍の高速化が確認されており、全体で最大3倍程度の性能向上が期待できます。
• 導入の容易さ: コードの書き換えは不要。Glutenライブラリを含むDockerイメージを作成し、Spark設定でプラグイン（spark.plugins）を有効にするだけで利用可能。
• リソース設計: Veloxはオフヒープメモリを使用するため、Executorのメモリ設計においてオフヒープ領域を十分に確保（従来の2倍程度必要な場合もある）する必要があります。
• 注意点: 全ての演算子がサポートされているわけではない。サポート外の処理が含まれる場合、Vanilla Sparkへのフォールバック（JVMとのデータ変換）が発生し、逆に遅くなる可能性がある。ジョブごとに適用効果を検証することが推奨される。

Remote Shuffle Service with Apache Celeborn

Spotインスタンスを活用する際の最大の課題は、インスタンスの中断（Interruption）によるシャッフルデータの消失です。
通常、ノードが終了するとローカルディスクのデータも消え、再計算（Fetch Failure）が発生します。

Apache Celebornとは

Apache Celeborn は、シャッフルデータをコンピュートノードから分離して保存・管理するRemote Shuffle Serviceです。

• アーキテクチャ: Master（HA構成、3ノード推奨）とWorker（StatefulSet）で構成されます。
• メリット: Spotインスタンスが中断されても、シャッフルデータはCelebornクラスターに残っているため、新しいExecutorはデータを再取得するだけで処理を継続できます。これにより、長時間実行されるジョブ（例：8時間）の完了確実性が向上します。
• コスト最適化（Single AZ）: データ転送コストを抑えるため、Sparkクラスター（Driver/Executor）とCelebornクラスターは 同一のAvailability Zone (AZ)に配置することが強く推奨されます。クロスAZでのシャッフルは通信コストが高額になり、パフォーマンスも低下します。

Best Practice & Next Steps

ベストプラクティス

セッションで紹介されたベストプラクティスのまとめです。

1. Karpenterの活用: 高速なプロビジョニングと柔軟なインスタンス選択。
2. Local SSD (RAID 0): I/Oボトルネックの解消。
3. Dynamic Resource Allocation: 予測不能なワークロードへの対応。
4. Apache Gluten + Velox: ネイティブ実行によるコンピュートの高速化（まずは一部のジョブでテスト）。
5. Apache Celeborn: Spotインスタンス利用時の耐障害性向上（Single AZ構成を徹底）。

次のステップ

次のステップとして、
GitHubリポジトリ「Data on EKS」にて提供されているブループリントやベンチマークを参照し、
実際の環境で検証を行うことが推奨されました。

Q & A

セッション中に行われた主な質疑応答です。

Q: すべてのジョブでDynamic Allocation（初期2、最大20など）を設定しても良いか？
A: ジョブの特性によります。ストリーミングや予測不能なジョブには有効ですが、処理量が予測可能な定型バッチ処理であれば、固定数のExecutorを割り当てた方が安定する場合もあります。

Q: GlutenはEMR on EKSでも利用可能か？
A: はい、利用可能ですが、カスタムイメージの作成が必要です。今後、より簡単に利用できるようになる可能性があります。

Q: Apache Celebornは同じEKSクラスター内にデプロイできるか？
A: はい、可能です。Data on EKSのブループリントを利用してデプロイできます。ただし、必ずSparkジョブと同じAZで動作するように構成してください。

まとめ

本セッションでは、EKS上でSparkを実行する際の「スケーラビリティ」「パフォーマンス」「コスト効率」を高めるための具体的な手法が紹介されました。
基本となるKarpenterやLocal SSDの活用から始まり、Gluten + Veloxによる実行エンジンの高速化、CelebornによるSpotインスタンス運用の安定化まで、段階的な最適化の道筋が示されました。
特にGlutenやCelebornは、コード変更を最小限に抑えつつ導入できるため、既存のSparkワークロードの改善において強力な選択肢になると感じました。

---

[re:Invent 2025] 参加レポート一覧はこちら (随時更新)