データアナリティクス事業本部の鈴木です。
ちょっと時間が経ちましたが、AWS re:Invent 2022の、セッション番号ANT302の『What’s new with Amazon EMR』を聴講したのでレポートです。re:Invent 2022時点での、Amazon EMRの機能紹介セッションです。
最近は、例えば以下の記事のように、Amazon Athena for Apache Sparkについていろいろ調べてまとめています。
従来のサービスで大規模なデータに対する、インタラクティブな分析の選択肢として比較に挙げられるのはAmazon EMRです。
このセッションを通じて、改めてAmazon EMRの機能を学んだのでご紹介します。
セッション内容
セッションについて
Session type
Breakout Session
動画
スライドPDF
AWS Events Contentより確認しました。
- https://d1.awsstatic.com/events/Summits/reinvent2022/ANT302_Whats-new-with-Amazon-EMR.pdf
セッション概要
Amazon EMRは、オープンソースフレームワークを使用して構築されたビッグデータアプリケーションの実行とスケーリングを実現しやすくします。ETLやペタバイトスケールでの低レイテンシSQLの高速化を支援します。Amazon EMR Serverless、Amazon EMR Studioなど、最新のAmazon EMRを利用した開発についても学びます。
私のまとめ
簡単にですが、セッションにてポイントと感じた点と、関連して調べた内容についてご紹介します。かなりみっちりAmazon EMRの紹介をしているセッションなので、かいつまんでいるところも多いですが、ご興味がありましたらぜひセッションをご覧ください。
コスト最適化について
- Amazon EMRを使うことで、オンプレミスでHadoopクラスタを構築するよりも遥かに大きいコストメリットを受けることができる。
- Amazon EMRの中では3種のコスト最適化オプションがある。
- クラスターが必要なときに正確に起動しワークロードが終わると終了するTransient clustersの機能は、永続的なクラスタの平均利用率が40％しかないことから、大きなコスト削減に繋がる。
- スポットインスタンスを利用すると、オンデマンドインスタンスに比べて最大90％の割引を受けることができる。EMRはスポットインスタンス停止前の警告を受けて、より健全なインスタンスにジョブを割り当てる仕組みのため、中断されるワークロードは5%未満に抑えられる。
- インスタンスフリートを使えば、EC2インスタンスの種類に多様性を持たせ、マルチAZ構成を実現することができる。
- 上記のコスト最適化オプション以外にも、様々なコスト最適化の方法がある。
- インスタンス種別はGraviton2に移行しているユーザーが多い。AWSのベンチマークによれば、Graviton2はM5インスタンスタイプに対して12～16％の性能向上を実現した。対応するx86バージョンよりも20％低い価格となっており、正味で30％の価格改善となる。ただし、ハードウェアのアーキテクチャがARM64であるため、特定のライブラリは再コンパイルが必要になる可能性があることは考慮が必要になる。
- マネージドスケーリングにより、よりリアルタイムにEMRクラスタをスケールすることができ、最大20～60％のコスト改善を達成できる。
- インスタンスを一時的に起動・終了するようなケースでは、起動時間もとても重要な要素となる。AWSはプライベートサブネットのEC2クラスタ上でEMRの起動時間を最大30％短縮した。加えて、マスターノード・コアグループ・タスクノードを並列に起動するようにも対応した。
- Managed Scalingでは、Sparkのシャッフルデータを効率よく利用できるようなスケーリング方式を実現し、処理のパフォーマンス改善をした。
- GP3ボリュームを利用することでEBSの改善のメリットを受けることも可能となった。
Transient clustersは、開発者ガイドの『Configuring a cluster to continue or terminate after step execution』にて紹介されていました。
Managed ScalingのSparkシャッフルデータ対応については、以下のアナウンスが該当すると思われます。
Amazon EMR on Amazon EKSについて
- EMR on EC2とは異なり、数秒でジョブを開始できる。マルチAZクラスタの構成もできることに加え、複数のワークロードが共存することができる。
- Amazon EMR on Amazon EKSの新しい機能としては4点ある。
- データエンジニアがジョブをクラスタに投入する際に必要な引数やパラメータを最小限に抑えることができるジョブテンプレート
- パイプライン全体をSQLスクリプトとして指定することができるSpark SQL Runner
- DynamoDBコネクタ
- ジョブのエラーメッセージの強化
Amazon EMR on Amazon EKSについては、『Run Apache Spark on Kubernetes with Amazon EMR on Amazon EKS』の資料がありましたので、URLをご紹介します。
- https://d1.awsstatic.com/events/Summits/reinvent2022/ANT330-R_Run-Apache-Spark-on-Kubernetes-with-Amazon-EMR-on-Amazon-EKS.pdf
パフォーマンス最適化ランタイムについて
- EMRはSpark、Presto、Trino、Hiveは100％オープンソースと互換性があるが、これに加えてランタイムを最適化している。
-
EMR6.5とEMR6.9を比較すると、同一ベンチマークで1.3倍速くなっているため、EMRを最新バージョンに保つのは意味がある。
-
OSSのバージョンと比較すると以下のような差がある。
- EMR 6.9.0（最適化したSpark） vs. OSS Spark： EMR6.9.0が3.9倍速い
- EMR6.9.0（最適化したSpark） vs. EMR6.5.0（最適化したSpark）: EMR6.9.0が1.3倍速い
- EMR 6.9.0（最適化したTrino） vs. OSS Trino： EMR6.9.0が4.2倍速い
- EMR 6.9.0（最適化したHive zero-rename機能版） vs. OSS Hive： EMR6.9.0が15倍速い
測定条件の詳細については、資料スライドのP.17 - 20を参照してください。
zero-rename機能については以下のAWS Big Data Blog記事にも記載があります。
エンジンの改良について
PrestoおよびTrinoの改良
- Spot loss handling機能の追加・Lake Formationとの連携により、きめ細かなアクセスコントロールへの対応など、5点の追加をした。
- 特に、1点目のSpot loss handlingについては、Presto、Trino向けにはスポット的な中断に弱いため、スポット障害処理のロジックを追加した。具体的にはスポットインスタンス終了警告を見て2分以内に終了するなら続行、しないなら別のインスタンスで再投入するようにした。
この機能については、リリースガイドのHandling Spot Instance loss in Presto - Amazon EMRにも説明がありました。
Hiveの改良
- zero-rename機能、MSCKの改良（S3のListObjectsのAPI呼び出し回数を減らした）など6点の追加をした。
MSCKの改良については、Athenaで実行した際にS3のListObjectsのAPI呼び出し回数が非常に多くなってしまう課題がシステム設計によっては発生します。EMRではこの点に改良が入っているのは非常に素晴らしいですね。
Transactionalデータレイクに向けての機能について
EMRでのユースケース
- GDPRのようなコンプライアンスプログラムを遵守するような場合に、データの削除やそれ以外のトランザクション処理を実現するパイプラインが必要な例として、ストリーミング取り込みパイプラインおよびCDC取り込みパイプラインが挙げられる。
- 特にストリーミングの場合は、作成されるファイルが小さくなってしまうため、一定の周期で大きなファイルにコンパクト化する必要がある。
Transactionalデータレイクを実現するためにサポートするフレームワーク
- セッション発表時で、以下のフレームワークをサポートしている。
- Apache Hudi 0.12
- Apache Iceverg 0.14.1
- OSS Delta Lake 2.1.0
EMRサーバーレスについて
- EMRサーバーレスは、EMRサーバーレスアプリケーションを立ち上げる際にEMRのバージョンとエンジンを選ぶだけでよい非常にシンプルなもの。
- ジョブおよびステージがワーカーを必要とするときに自動的にスケールする。需要が落ち着くとワーカーが削除される。この自動的できめ細かなスケーリングによって、コストを最適化することができる
- Apache Airflowとネイティブに統合している。もちろん既存のGlueカタログをメタストアとして活用することができる。
- EMRサーバーレスの背後にある主な構成は以下スライド記載の3つの要素がある。
- ワーカーについては、適切なサイズに調整することができる。またジョブを高速に起動させたいユースケースで、Pre-initialized workersが利用できる。
- Amazon EMR ServerlessではマルチAZ構成にすることができる。使用するコンピューティングリソースの上限を設定できる。
- ユーザーはAmazon EMRアプリケーションを共有することができ、ジョブごとの実行ロールにより、同じアプリケーションでも異なるリソースにアクセスをする制御が実現できる。
- SparkのグラフィカルUIやCloudWatchにより、クラスタの状態をリアルタイムにモニタすることができる。
- EMR ServerlessもGraviton2を選択することができ、コストおよびパフォーマンスにメリットがある。
EMR Studioについて
- フルマネージドな統合開発環境 (IDE)。JupyterノートブックやSpark UIなどを使い、デバッグを簡素化できるほか、パラメータ化したノートブックをApache AirflowのDAGの一部に組み込むなどもできる。
ここで紹介されている機能については、製品ページでも動画とあわせて確認できるため、ぜひご覧ください。
セキュリティについて
- Job runtime rolesにより共有のクラスタであっても、EMRのジョブごとにアクセスできるリソースを設定することができる。
- LakeFormationと連携することで、きめ細かなアクセスコントロールを実現できるようにもなった。例えば以下のように SageMakerからのアクセス時にEMRとLakeFormationを通して、S3バケットにあるデータへのアクセス制御を実現できる。
感想
『What’s new with Amazon EMR』のセッションの内容は、単にAmazon EMRの機能紹介にとどまらず、普遍的なデータ分析基盤の課題とそのアプローチ例の紹介でした。特にAmazon EMRにおける分散処理システムのパフェーマンス改善の工夫に関する説明がふんだんに盛り込まれており、非常に面白く勉強になるセッションでした。
セッションを見るまでは、EMRはオンプレミスのHadoopのリフトアンドシフトが主な用途なのかなと考えていましたが、以下のような特徴があるように理解しました。
- 非常に大規模なデータに対する分散処理を行いたい場合に、コストやパフォーマンスを最適化することができる。
- 複数バージョンの分散処理システムのライブラリを利用したい。
- ほかのデータ分析系サービスにない最適化された機能を利用したい。
一方で、事例でも挙げられていたようにAmazon EMRが特に強い場面は非常に多くの数のインスタンスを利用する大規模なクラスタが必要な場合で、そこまでのチューニングが求められないような場合はAthenaやGlueジョブを第一の候補とするので問題ないようにも思いました。
ただし、AthenaやGlueを使ったシステムを運用している場合でも、EMRの機能の進化やその活用事例を学ぶことは、自分たちのシステムがより大きなデータ規模や厳しい要件を求められるように成長した場合の参考になり、データ分析基盤の設計を考える上でとても重要な内容だと思いました。
最後に
AWS re:Invent 2022の、セッション番号ANT302の『What’s new with Amazon EMR』のレポートでした。
非常に詳しくAmazon EMRの機能について紹介されているセッションだったので、動画をみるだけでも結構な体力が必要でしたが、その分、Amazon EMRの強みがとてもよく分かり、本当に勉強になる素晴らしいセッションだと思いました。
EMR ServerlessとEMR Studioあたりは気軽に始められそうなので一度触ってみたいと思います。
0
