re:Invent 2025: AWS Glue、EMR、AthenaのSpark 4.0とIceberg V3対応
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Innovations in AWS analytics: Data processing (ANT305)
この動画では、AWS の Glue、EMR、Athena、Redshift を含むアナリティクスポートフォリオにおける最新のイノベーションが紹介されています。特に注目すべきは、Spark バージョンアップグレードを自動化する AI エージェントで、従来 6～12 ヶ月かかっていた作業を数分で完了できるようになりました。Iceberg V3 のサポート、Spark 4.0 によるオープンソースの 5.4 倍の性能向上、Iceberg Materialized View の導入も発表されています。SageMaker Notebooks と Athena Spark の統合により、Python から Spark へのシームレスな移行が可能になり、サーバーレス Airflow のワークフローレベルセキュリティも実現しました。Serverless Storage により最大 20% のコスト削減を達成し、Lake Formation による細粒度アクセス制御の書き込みサポートも追加されています。Netflix は EMR on EC2 の概念実証を完了し、PySpark で大幅なパフォーマンス改善を確認した上で、2027 年までに段階的な移行を決定しました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
データ処理における革新：Glue、EMR、Athenaの実績と信頼性
皆さん、こんにちは。本日は、データ分析における革新についてお話しします。私の名前は Kinshuk Pahare で、Glue、EMR、Athena、Redshift を含むアナリティクス ポートフォリオの製品責任者です。本日は Neil Mukerje と、Netflix のシニア エンジニアリング マネージャーである Anjali Norwood が一緒に参加しています。本日のテーマはデータ処理における革新についてですので、さっそく始めましょう。
こちらが本日のアジェンダです。最新の革新についてお話しし、特に私たちが行ったエージェント関連の革新に触れます。次に Iceberg と使いやすさの革新についてお話しします。最後に、Anjali が Netflix がどのように EMR をデータ処理ワークロードに活用しているかについてシェアします。
データ処理サービスの中で、データ統合に使用される Glue ETL についてはご存知かと思います。もちろん EMR についてもご存知でしょう。EMR は 2009 年からある歴史あるサービスで、主にオープンソースのデータ処理に使用されています。お客様は EMR と EMR がサポートする複数のエンジンを使用して、データ ワークロードを処理しています。そして Athena があります。これは主に S3 のデータレイクをクエリするために使用される対話型クエリ サービスです。これらのサービスを合わせて、数百万のお客様がデータ パイプラインを作成し、対話型ワークロード用にデータをクエリしています。
週ベースで、Redshift Serverless では 3 億件以上のクエリが実行されています。その背後には 19 年間の革新があります。Athena では週ベースで 10 億件以上のクエリがデータレイクに対して実行されています。最も急速に成長しているサービスの 1 つである EMR Serverless では、約 3 億個の Spark ジョブが実行されています。これらのサービスを合わせて、週間を通じて S3 から 100 ペタバイト以上のデータをクエリしており、これらのデータ ワークロードは主に S3 をデータレイクとして構築されています。
長年にわたって、S3 はデータレイクを構築するための最適な場所として浮上してきました。データレイクおよびクエリの目的で、S3 に保存されている Parquet データはエクサバイト単位で存在します。ご存知の通り Parquet はカラムナー形式で、通常はデータレイク構築に使用されます。読み取りと書き込みがはるかに効率的だからです。S3 から書き込みと読み取りを行うエンジンは Glue、EMR、Athena の背後にあります。これらのデータレイクに対して、1 秒あたり 2,500 万件以上のリクエストがあります。これらの数字を共有する理由は、これらの数字が素晴らしく、お客様がこれらのデータ処理サービスと S3 をミッションクリティカルなデータ アプリケーション構築のために信頼していることの証だからです。
毎年、私たちはここに集まって、どうやってさらに良くしていくかについて話し合います。これが私の4回目の re:Invent ですが、Athena サービスは9年前にローンチされ、Glue は2017年8月にローンチされました。これらはすべて、データ処理とデータのクエリを目的として、長年にわたるイノベーションが注ぎ込まれたサービスです。私たちにとって最優先事項は価格性能であり、これは毎年繰り返されるテーマです。
価格性能の向上と4つのイノベーションテーマ：Iceberg、AIエージェント、ガバナンス
今年も、私たちのエンジニアリングチームは AWS Spark の性能を実現しました。これはオープンソースの Spark の性能を4.5倍上回っています。書き込みについては2倍優れており、私たちが行った新しいイノベーションである Spark 4.0 を使用する場合は約5.4倍優れています。価格性能が重要になる理由は、Spark エンジンが速いほど、SLA ターゲットをより良く達成できるからです。同時に、コンピュートやデータ処理ジョブが速く完了すれば、実際に支払う金額が少なくなるため、価格とコストの利益を実現することができます。
価格性能はさておき、今年チームが推し進めている4つのイノベーションテーマがあります。Iceberg はデータレイクを構築するための標準として浮上しています。主な利点は、Iceberg でデータレイクを構築して、任意のエンジンを使用してそのデータレイクをクエリできることです。データ処理の文脈における AI エージェントが浮上しており、データエンジニアリングの最も困難な問題のいくつかを解決しています。私はこのセッションでそのいくつかについて話すつもりですし、Neil はデータエージェントをいくつかの使いやすいユースケースにどのように使用しているかについて話すつもりです。そして最後に、ガバナンスです。ガバナンスは常に多くのお客様にとって関心のあるトピックです。データレイクをどのようにガバナンスするのか？きめ細かいアクセス制御をどのように確保するのか？データレイクのクエリと書き込みに関する実行を行う際に、エンドユーザーのアイデンティティがすべてのために前に進められることをどのように確保するのか？
AIエージェントによるSparkアップグレードの自動化：6ヶ月の作業を数分に短縮
それでは、AI エージェントとデータについて始めましょう。 AI エージェントには多くのアプリケーションがあります。これは様々な文脈における AI エージェントの1年でした。このトークでは、データエンジニアが直面する最も難しい問題の1つに焦点を当てます。それは Spark ランタイムをバージョン X.Y からバージョン P.Q にアップグレードすることです。Spark バージョンのアップグレードは常に課題でした。これが悪化している理由は、すべてのデータレイクイノベーションが最新の Spark ランタイムに依存しているからです。明らかに、実務家として、誰もが最新の Spark バージョンを実行して、それから最高のパフォーマンスを得るべきです。また、それからデータレイクの最高のパフォーマンスを得るべきです。そして機能も得るべきです。しかし、通常、簡単なアップグレードではありません。
Spark アップグレードを複雑にする2つの問題があります。1つ目は、コードアップグレード部分があります。しかし、データ一貫性部分もあります。単に Spark コードをアップグレードしてコンパイルがうまくいくだけではありません。実際に前のバージョンがデータに対して行っていたのと同じことを行うことを確認する必要もあります。したがって、考慮すべき3つの要素があります。実際には、データエンジニアはコードをアップグレードしながら反復する必要があります。コードをアップグレードして、新しいエラーメッセージを見て、コードを編集して、繰り返します。そのプロセスは、時間がかかるだけでなく、最新の Spark バージョンで異なる方法で定義されている変換を見落とす可能性があるため、完全に確実なプロセスではありません。
これを解決するために、私たちは Spark アップグレード用の AI エージェントをリリースしました。このエージェントの動作方法は、データエンジニアがどのように仕事をするかに似ています。実は、アップグレードのための計画を立てるんです。計画を立てるために、プロジェクト構造を読み込んで、アップグレード計画を生成します。これが私が達成しようとしている計画だと教えてくれます。計画を見て、編集して、パイプラインの構造に応じて独自のアップグレード計画を提供することができます。次のステージはビルドと実行で、このステージではその計画を実行して、エラーメッセージを確認して、エラーメッセージに基づいてコードを編集します。これはデータエンジニアが行うことが期待されるのと同じことをしますが、自動的に行うんです。
最後に、コードがアップグレードされて、コンパイルが正常に行われ、すべてのテスト計画がパスしたら、データ品質チェックも実行します。データ品質チェックが何を意味するかというと、AI エージェントが実際にアップグレード前後のデータ構造を確認するんです。スキーマが一致しているか、カラムの型が一致しているか、データのサイズが一致しているかをチェックします。これらすべてのチェックを行って、最終的にこのコードはアップグレードされたと言うんです。プロセス全体を通じて、あなたは完全にコントロールしています。設定可能なガードレールがあります。計画内のすべてのステップを手動で実行したいと言うこともできますし、エージェントに進めてほしいと言うこともできます。
エージェントを信頼していて、コードを適切にアップグレードしてくれると信頼しています。プロセス全体を通じたすべての実行とすべてのビルド中に、オブザーバビリティログにアクセスできるので、実際に何が変更されたかを見ることができます。これが実際にどのように機能するかについて説明するデモを見せます。実は、パイプライン全体または複数のパイプラインをアップグレードすることができます。以前は 6 ヶ月、時には 6 ～ 12 ヶ月かかっていたタスクが、今ではこのエージェントが自動的にこれらの非常に見つけにくい Spark の問題を達成して対応できるため、数分で完了できます。
ここで簡単なデモです。バージョン 2.4 から 3.5 へのアップグレードを手伝ってください。わかりました、アップグレードしてほしいということですね。ファイルを読み込んで、プロジェクト構造を読み込みました。実は計画を立てて、この計画はどうですかと言うんです。この計画が気に入ったと言ったら、進めることができます。これから実行しようとしているステップはここにあると言うんです。実行の一部として、計画を保存して進めることができます。最後に、わかりました、前のバージョンと新しいバージョンの間にこの差分が見つかったと言うんです。これが実行しようとしているすべての変更です。承認しますか？はいをクリックすると、すべてのプロセスに対してこれを繰り返し続けるんです。最後に、実際に何が変更されたかを正確に教えてくれて、アップグレードに満足したら、これを本番環境に実行することができます。
Iceberg V3とSpark 4.0：データレイク構築の最新イノベーション
FINRA はこのアップグレードエージェントを複数のデータパイプラインをアップグレードする目的で使用しています。私が話した 2 番目のイノベーションは Iceberg V3 のサポートです。Iceberg V3 は最新のテーブルフォーマットです。Iceberg バージョン 1.10 に基づいており、削除ベクトルとロール系統に関する新しい機能をサポートしています。これらはすべて EMR Spark runtime 7.12 の一部として利用可能です。ご存知ない場合は、EMR Spark runtime は Glue ETL および Athena とも共有されています。これらはすべて EMR 7.12 で提供される同じイノベーションから恩恵を受ける Spark ランタイムなので、Iceberg V3 の一部として同じパフォーマンス特性と同じ機能セットが得られます。
Deletion vectors と role lineage により、データレイクをより効果的に管理できます。これにより、write amplification の問題が軽減され、smart delete の問題が解消され、データレイクの構築と保守が非常に効率的になります。また、EMR Spark バージョン 4.0 も発表しています。これは、先ほど説明した最新の Iceberg バージョンをサポートしています。さらに、オープンソースの Spark よりも 5.4 倍高速です。つまり、Spark ジョブを使用して SLA を達成するか、パイプラインの運用コストを同等の量だけ削減することができます。最後に、今年実施したもう 1 つのローンチが Iceberg Materialized View です。
Materialized view は、ご存知の通り、SQL でビューを定義できるもので、Iceberg materialized views は、その SQL コード実行の結果である Iceberg テーブルです。これにより、Spark エンジンからのクエリが自動的に高速化されます。Iceberg API と互換性があるため、SQL クエリの一部として実行されると、カタログオブジェクトとして表示されます。そのカタログオブジェクトに対して、Athena Spark、EMR Spark、または Glue ETL クエリを実行できます。さらに重要なのは、Iceberg ビューの増分更新を実行できることです。つまり、ETL パイプラインを構成し、すべてのトリガーとスケジューリングを構成する必要がなく、materialized view を定義するだけで、選択した頻度に基づいて、またはデータが利用可能になったときに自動的に更新されます。これは Glue data catalog の一部として利用可能です。
ビュー定義はカタログに保存され、EMR、Spark、Glue ETL Spark、または Athena Spark からアクセスできます。これは昨日発表したものです。では、ease of use についてお話しする Neil にバトンタッチします。
使いやすさの革新：SageMaker Notebooks、サーバーレスAirflow、Serverless Storage
Ease of use を強調する機能に焦点を当てましょう。最も目立つ機能は Amazon SageMaker notebooks です。重要なのは、SageMaker Studio がすべてのデータ処理および AI/ML の新しい UI およびフロントエンドであることです。EMR、Glue、または Athena を使用しているかどうかに関わらず、ユーザーのメイン UI フロントエンドは SageMaker Studio であり、SageMaker Notebooks は SageMaker Studio への最新の追加機能です。これは、目的別に構築された AI エージェントが付属する新しい最新のノートブック体験です。数秒で始めることができ、SQL、Python、または Spark など、タスクに最適な言語を選択できます。
素晴らしいのは、Python で始めて、大規模なデータセットを処理するために Spark ワークロードにシームレスにスケールできることです。バックグラウンドでは、SageMaker Notebook が Athena for Apache Spark にステップインして、Spark 機能を提供します。Athena Apache Spark は、EMR と同じパフォーマンスランタイムエンジンを使用しています。実は EMR 5.12 を使用しており、これはオープンソースの Spark よりも 4.7 倍高速です。サーバーレスであるため、すべての管理オーバーヘッドが排除され、数秒の低いオーダーで起動およびスケーリングします。つまり、ノートブックに入って Spark と入力すると、数秒以内に、データ処理用の大規模な Spark クラスタが準備できます。
このアーキテクチャのユニークな点は、Python と Spark のワークロード全体にわたって、統一されたオーサリング、実行、デバッグの体験を提供することです。SageMaker Notebook は Spark Connect を使用して Athena Spark に接続します。 Spark Connect は Spark の新しいクライアント・サーバー・アーキテクチャで、クライアント・アプリケーションをリモート Spark ドライバーから分離しながら、2つの間でシームレスにデータを交換するためのプロトコルを確立し、リモート実行を可能にします。つまり、ノートブックのセルで Spark と入力すると、Spark がノートブック内でローカルに実行されているように見えますが、実は背後にある大規模なクラスター上で実行されているということです。Python 変数をデバッグするのと同じように Spark 変数をデバッグできます。つまり、小から中規模のデータセットに対しては Python や SQL、または Pandas や DuckDB のような Python パッケージを活用でき、同時に大規模なデータ処理には Spark を活用できるということです。
それでは、このノートブックに付属する AI エージェントをもっと詳しく見てみましょう。AI エージェントの体験はノートブックのインターフェースに組み込まれており、ノートブックの右側に表示されます。これはあなたのデータ・カタログとビジネス・メタデータを理解しています。Athena を使用している場合は Spark SQL または Athena SQL という正しい方言の SQL を生成できます。Python コードと Spark コードも生成でき、データを生成するだけでなく、特定の結果を達成するために、セルが満たされた完全なノートブック全体である、完全なプランを生成することもできます。つまり、本当に会話することができるのです。
データ・エージェントがどのように機能するかの簡単なデモをご紹介します。この例では、データ・エージェント・パネルで、「show me tables in my sample database」という質問をしました。それは私が持っているテーブルを発見しに行きます。ここに3つのテーブルがあります。churn テーブル、LTV テーブル、New York taxi trips テーブルです。自分で SQL を入力してクエリすることもできますし、テーブル・セルに移動して、持っているデータを可視化することもできます。しかし、さらに良いことに、単に会話して「LTV テーブルのデータを可視化するのを手伝ってくれませんか」と言うことができます。そうすると、可視化を構築するための対応する Python コードを生成し、LTV テーブルのデータの包括的な可視化を提供します。
この利便性とパワーを気に入っていただき、ぜひ使用していただきたいと思います。次に、非常にリクエストが多かった機能に移ります。管理された Airflow が完全にサーバーレスなデプロイメントで利用可能になりました。Airflow はデータ・オーケストレーション分野で非常に人気があり、今ではサーバーレス・デプロイメント・モデルで利用できます。このための UI は、やはり SageMaker Unified Studio なので、単一の UI でワークフローを作成・管理することもできます。ワークフローごとに IAM ロールを指定できるという強化されたセキュリティ・モデルが付属しており、これは各ワークフローが一意のパーミッション・プロファイルを持つことができるようになったということです。
そしてもちろん、サーバーレスなので、使用した分だけ支払います。プロビジョニングされた Airflow で既に持っているものと、サーバーレスとの比較をしてみましょう。プロビジョニングされた Airflow では、最初にサイズを決める固定インフラストラクチャがあり、マイクロ・サイズなどを選択できます。ワークフローが実行されているかどうかに関わらず、常にオンになっています。選択したサイズに基づいて特定の容量制限があり、環境を管理する必要があります。しかし、サーバーレス側では、インフラストラクチャはもうありません。使用量に応じた支払い、無制限の容量、そして完全にサービス管理されています。
セキュリティの観点から見ると、プロビジョニングモードにはいくつかの重要な変更があります。Airflow 環境全体が単一のセキュリティモデルを持っているため、すべてのワークフローが同じ権限プロファイルを持っています。これらのワークフローを分離したい場合は、別々の環境を起動する必要があり、つまり認可は共有され、分離は複雑になります。一方、サーバーレス側ではワークフローレベルのセキュリティがあるため、ワークフローごとに細粒度のアクセス制御を定義できます。つまり、各ワークフローに対して最小権限の IAM ロールを持つことができるようになり、これはコンプライアンスを大幅に簡素化します。
これらすべてが SageMaker Unified Studio のワークフロー UI に組み込まれています。これらのアクティビティをドラッグアンドドロップして、Python や Airflow の事前知識がなくても自分で DAG を構築できます。ワークフローを構築したら、これらのワークフローを送信したり、ジョブを監視したりすることができ、すべてが単一の UI から行えます。また利用可能なのは Visual ETL 用のワンクリックスケジューラーです。これにより、SageMaker Unified Studio の同じ UI から ETL フローとクエリを簡単に合理化できます。これらのスケジュールを作成、変更、監視できます。バックグラウンドでは、Amazon EventBridge Scheduler と統合されており、これらのスケジュールを実現します。
顧客からは、特定の依存関係があるため SageMaker Unified Studio へのオンボーディングが簡単ではないと言われています。IAM Identity Center を設定する必要があるなど、です。私たちはこれを聞き、SageMaker Unified Studio へのオンボーディングを Athena コンソール、S3 Tables、Amazon Redshift コンソールなどの既存サービスからワンクリックで行えるようにしました。これらのページから 1 回クリックするだけで、SageMaker Unified Studio に移動できます。デフォルトの SageMaker Unified Studio ワークスペースが自動作成されます。プロセス全体は 1 分で完了します。IAM Identity Center を設定する必要はもうありません。これらのコンソールで既に使用していた IAM ロールを使用し、ノートブック機能、コードエディターなど、同じデータセットで使用できるより高度なインターフェースにアクセスできます。
では、非常にエキサイティングな機能に移りましょう。これは業界初です。Serverless Storage は Spark ワークロード向けのローカルディスクプロビジョニングを完全に排除します。これにより、当社のベンチマークによると最大 20% のコスト削減を実現できます。仕組みはこうです。Spark ワーカーには ローカルディスクがあり、これらのローカルディスクにはシャッフルが含まれています。これらのディスクの容量が不足すると、ジョブが失敗します。ディスクが制約されている場合、ジョブが遅くなります。多くの場合、特定のタスクがストラグラーになり、一部のワーカーが長時間実行され続け、ディスクにシャッフルデータが含まれているため、すべてのワーカーを保持する必要があります。これにより Spark スケーリングは本質的に非効率になります。
Serverless Storage では、これらの問題は完全に排除されます。Serverless Storage はシャッフルを高性能ストレージレイヤーにオフロードします。つまり、ディスク容量が不足することはなく、ジョブの失敗に直面することもなく、ジョブが遅くなることもありません。シャッフルがクラスタの外にあるため、Spark はより弾力的になり、ステージのニーズに応じてスケールアウトおよびスケールインできます。Serverless Storage がもたらすコンピュート効率と、これをプロビジョニングする必要がないという事実の組み合わせは、この分野における絶対的なゲームチェンジャーです。当社のベンチマークによると最大 20% 削減でき、ワークロードの形状によってはさらに削減できる可能性があります。
エンタープライズセキュリティとガバナンス：細粒度アクセス制御と信頼できるアイデンティティの伝播
では、次は セキュリティとガバナンスというテーマに移りたいと思います。これはエンタープライズ顧客にとって非常に重要なテーマです。もちろん、主な懸念事項はデータアクセス制御ですよね。 顧客は、使用したいさまざまなフォーマット全体で一貫したデータアクセス制御を望んでいます。もちろん Apache Iceberg は非常に重要ですが、Delta Lake や Hudi も同様に重要ですし、もちろん Parquet、CSV、JSON といった従来のフォーマットもあります。ほとんどのユースケースでは、粗粒度のアクセス制御が必要です。これは特定の S3 ロケーションをセキュアにしたり、特定のテーブルをセキュアにしたり、ユーザーがそれらにアクセスできるようにしたいというものです。一部のユースケースでは、列、行、セルレベルのセキュリティもある細粒度のアクセス制御も必要になります。
今年は、セキュリティとガバナンスに焦点を当てた多くのローンチを行いました。これらがすべてどのように組み合わさるかを見てみましょう。最初の焦点は S3 ロケーションの粗粒度アクセスです。このために、推奨事項は S3 Access Grants を使用することです。ここでは S3 バケット、プレフィックス、およびオブジェクトに対して SQL のようなシンプルなパーミッションを持つことができます。 ジョブを送信すると、エンジンは単に S3 Access Grants を参照して、スコープダウンされた認証情報を取得し、その認証情報を使用して S3 と通信します。これは EMR ではバージョン 6.15 以降からずっと存在しています。現在は Glue でもバージョン 5.0 で利用可能になり、すべてのテーブルフォーマット全体で一貫して機能します。
では次に、カタログ内のテーブルの粗粒度アクセスを見てみましょう。 これは確実に最も一般的なシナリオで、細粒度のアクセス制御のオーバーヘッドに対処したくないが、特定のテーブルへのアクセスをユーザーに付与したいというものです。これはメタデータのフィルタリングだけなので、パフォーマンスのオーバーヘッドはありません。期待されるのは完全なサポートで、つまりすべてのユースケースに対する読み取りと書き込みのサポートです。実装は比較的簡単です。
最初のステップは、管理者が Lake Formation に移動して、特定のユーザーに対して特定のテーブルのパーミッションを付与することです。ジョブが送信されると、Glue カタログと通信し、Lake Formation にリダイレクトされ、スコープダウンされた認証情報が返されます。これらの認証情報は S3 にアクセスするために使用されます。これは EMR ではバージョン 7.9 以降から、また Glue ではバージョン 5.0 以上から利用可能で、Iceberg、Delta、および Hudi テーブルをサポートしています。
では、列、行、セルレベルのセキュリティが必要な細粒度アクセス制御を見てみましょう。エンタープライズ顧客はコンプライアンスレポーティングのための監査 証跡を求めており、もちろんこれは細粒度のアイデンティティベースのアクセス制御とも連携する必要があります。 管理者は Lake Formation で特定のテーブル、行、列、またはセルに対して細粒度のパーミッションを設定します。エンジンレベルでは、細粒度アクセス制御を有効にする必要があり、ユーザーがジョブを送信すると、Lake Formation と通信してスコープダウンされた認証情報を取得し、S3 とカタログテーブルにアクセスします。
バージョン 7.7 以降の EMR では、すべてのデプロイメントでの読み取りをサポートしています。Glue はバージョン 5.0 以降でサポートされています。そして、書き込みもサポートするようになったことをお知らせできて非常に興奮しています。ほぼ最新のリリースであるバージョン 7.12 では、すべての EMR デプロイメント、および Glue 5.1 で Iceberg、Delta、Hudi での書き込みを一貫してサポートしています。これは非常にユニークなアーキテクチャで、システムドライバーとユーザードライバーを分離しています。システムドライバーはすべてのフィルタリングが行われる場所で、ユーザードライバーは Spark コードが実行される場所です。この分離こそが、Spark コードを実行してコントロールをバイパスできないようにするセキュリティモデルを実現しています。
では、エンタープライズ顧客にとって非常に興味深く、非常に重要なトピックである信頼できるアイデンティティの伝播に移りましょう。 エンタープライズ顧客の期待は、ユーザーが Active Directory や Okta などの確立されたアイデンティティプロバイダーに対して認証し、それらのアイデンティティがさまざまなサービスに伝播されることです。もちろん、すべてのユーザーアクションのエンドツーエンドトレーシングが期待されます。これは IAM Identity Center で実現可能になりました。 IAM Identity Center でシングルサインオンを有効にすると、エンドツーエンドのデータアクセスとトレーサビリティが可能になります。ユーザーのアイデンティティに基づいた細粒度のパーミッションとアクセスが実現できます。これは SageMaker、Unified Studio からのインタラクティブセッションとジョブの両方からサポートされており、バージョン 7.11 以降の特定の EMR バージョンでサポートされています。すべての EMR デプロイメントでサポートされており、Glue 5 でも機能します。
これがどのように機能するかをお見せします。ここに Charlie と Elle という 2 人のユーザーがいます。Charlie は特定の S3 テーブルにアクセスしたいと考えており、Elle は別の S3 テーブルにアクセスしたいと考えています。SageMaker Studio にログインすると、IAM Identity Center で認証され、Active Directory、Okta などからアイデンティティがフェデレーションされます。そのエンティティと認可は、ジョブを送信するか、インタラクティブセッションを開始するときに EMR に伝播され、Lake Formation と通信してアクセス権を付与することができます。信頼できるアイデンティティの伝播と細粒度アクセス制御がエンタープライズセキュリティをどのように実現するかをご理解いただけたなら幸いです。
Netflix事例：EMR on EC2への移行決定とPOCの成功ストーリー
では、Netflix の Anjali Norwood さんに EMR の評価に関する Netflix のストーリーをシェアしていただきたいと思います。ありがとうございます、Neil。EMR 上の Spark に関する Netflix の概念実証のストーリーをシェアするためにここにいます。このストーリーがハッピーエンドで終わるかどうかを知るために、私と一緒にいてください。これはドラマでしたか？ これは協力とチームワークのストーリーでしたか、それとも戦いとアクションがありましたか？最後まで見ていてください。私は Anjali です。Netflix でビッグデータアナリティクスプラットフォームをリードしています。私のチームは S3 ベースのデータウェアハウスのデータ管理、Iceberg テーブルメンテナンス、データにアクセスするエンジンの周りのガバナンスとセキュリティを担当しています。Spark は大きなワークホースの 1 つです。他のエンジンには Trino、Druid、Snowflake 周辺のソリューション、および他のツールの新しいエディション、そして私たちが社内で構築したオーケストレーションテクノロジーが含まれます。
Netflix は何よりもまずエンターテインメント企業です。 しかし、私たちのほぼすべての決定はデータ駆動型です。Netflix のアカウントにテレビや携帯電話でログインすると、コンテンツの行が表示され始めます。このおすすめコンテンツはあなた専用です。その決定は非常にデータ駆動型です。どの行が表示されるか、どの順序で表示されるか、どのカバーアートが表示されるか、これらすべてがパーソナライズされ、データ駆動型です。これらはユーザーに見える決定です。その一方で、EC2 で Spark を実行するときなど、社内で行う決定もあります。どのインスタンスタイプを使用すべきか、R7 は採用の準備ができているのか、それともしばらくの間 R5 に留まるべきか。これらの決定もすべてデータで行われます。
これが私たちのストリーミングビデオオンデマンド、つまりレガシービジネスです。 しかし今、私たちはいくつかの国で広告プランを提供し始めています。ライブコンテンツの配信も始めています。クリスマスの日に NFL を見ている人はいますか？私は見ています。ゲーム、Netflix オリジナル、これらはコンシューマーエクスペリエンスです。また、ポッドキャストの配信も始める予定です。 つまり、これらすべての新しいビジネスイニシアティブにより、ウェアハウスにはより多くのデータが蓄積され、そのデータからインサイトを得る必要性がますます高まっているということです。これは Spark のストーリーでもあります。これは 7 年以上前に始まりました。
Netflix はストレージとコンピュートの分離を決定しました。これは私たちが行った大きな賭けであり、それは成功しました。それ以来、私たちは Hadoop 上で Spark を運用しています。オープンソースの Spark からフォークを切り出し、Netflix のスケール、パフォーマンス、そして出現するさまざまなユースケースに合わせてハイパー最適化し、カスタマイズしました。私たちは複数の Hadoop クラスタを運用しており、スケール感を示すための統計情報があります。以前共有されたものと比べると、それほど多くはないかもしれませんが、私たちは 11,000 個のユニークなワークフロー、250,000 個のジョブ、そしてウェアハウスに 1 エクサバイト以上のデータを持っています。これはかなり大規模なスケールで運用しているということです。私たちは約 8,000 から 8,500 の R7 ノードを持っています。
Spark を何に使用しているのか。それはさまざまなことです。データからインサイトを得ること、ETL、これは ETL の非常に人気のあるエンジンです、大規模分析、レコメンデーション、その他多くのことです。 そうすると、このすばらしいプラットフォームを持っていて、ずっとこれを運用してきたのに、なぜ他のことを考えるのかと質問するでしょう。実は Netflix にとって少し状況が変わっています。
私たちが始めたとき、ウェアハウスはセキュリティなしでデフォルトで開かれていました。誰もがどのデータにもアクセスできました。Netflix は非常に透明性の高い文化であり、今でもそうです。しかし、広告などの新しいビジネスの追加により、一部のデータは機密性が高く、保護する必要があります。私たちの現在のプラットフォームは Hadoop と Yarn で動作しており、必要なレベルのセキュリティと分離を実現することが難しいのです。
新しいテクノロジーの導入は難しいです。なぜなら、私たちが実行しているジョブとワークフローの規模と数が多いからです。Scala のマイグレーションには長い時間がかかります。Python のバージョン変更にも長い時間がかかります。Spark のマイグレーションにも長い時間がかかります。これは私たちのチームにとって大きな運用上のオーバーヘッドとコストを伴う多くの作業です。私たちはこれを「差別化されない重い作業」と呼んでいます。重要な作業ですが、ビジネスの針を動かしていない作業です。私たちはこの作業をオフロードして、チームの負担を減らす方法を見つけたいと考えています。
特殊なハードウェアへのサポートが限定的であることも課題です。AI のユースケースが出現している中で、GPU サポートが必要ですが、現在のセットアップではそれが難しいです。私たちの環境は機能していますが、使用とデバッグが少し難しいです。使いやすさは私たちが望むレベルにはありません。ここで私たちは Amazon EMR について考え始めました。このジャーニーは 2024 年の Q4 から始まりました。EMR を試してみようと言ったのです。
EMR は分離とセキュリティの向上を提供することがわかりました。90 日ごと、つまり四半期ごとに頻繁にリリースされます。それに伴って、新しい Iceberg、新しい Python、Scala、そしてすべての素晴らしいサポートが提供されます。運用上のオーバーヘッドを削減します。スケールアップとスケールダウンが行われます。GPU をサポートし、S3、IAM、その他の AWS サービスとも非常に良く統合されています。
では、私たちは何をテストしたのでしょうか？EMR にはさまざまなフレーバーがあります。私たちは複数の理由で EMR on EC2 のテストから始めました。1 つは、それが私たちが現在のシステムをどのように運用しているかに非常に近いということです。マネージドサービスが欲しいのですが、同時にゆっくりそこに到達したいのです。ノブを調整したり、設定を変更したり、ユーザーのために物事が機能することを確認したいのです。
機能の互換性をテストしました。これは重要でした。なぜなら、私たちは Netflix ユーザー向けに Spark をカスタマイズしているからです。パフォーマンスをテストしました。TPCDS チェックから始めて、その後、ユーザーワークフローを導入することにしました。これらは代表的なユーザーワークフローです。文字通り、私たちは連絡を取って、あなたのチームを最もよく表すワークフローをくれと言いました。それらは SQL、PySpark、Scala、Java などのさまざまなカテゴリに分類されます。
それでは、スケーラビリティについてテストしました。基本的には、EMR上で本番環境の実行をシミュレートして、EMRがどの程度対応できるのか、そしてリソース消費がどうなるのかを確認しました。スケーラビリティテストの第2段階は飽和テストでした。システムに過負荷をかけて、メモリを使い尽くし、メモリ集約的、IO集約的、CPU集約的なワークロードをすべて投入して、システムがどの程度耐えられるかを見ました。また、運用の複雑さについても検討しました。プラットフォームプロバイダーとして、私たちのチームはこのプラットフォームをどのように運用するかを知っておく必要があり、それが彼らにとって簡単である必要があります。そしてもちろん、コストも重要なので、それについても確認しました。
いくつかの数字をお見せします。P90の列を見ると、PySpark が圧倒的に最も大きな改善を見せており、その次が SQL、そして Scala となっています。私たちのプラットフォームは非常に最適化されているということを思い出していただきたいので、このような改善を見ることは素晴らしいことです。こちらはリソース消費についてのスライドです。ここでも PySpark が P90 での vCore の改善で最も優れており、その次が SQL、そして Scala となっています。vCPU の消費はコストと直接相関しているので、使用するリソースが少ないほど良いわけです。
これはちょっとエッフェル塔のようなチャートです。POC と評価について詳しく説明した非常に長いドキュメントがあります。すべてを説明するのは難しいのですが、触れておきたい重要なポイントには、将来への対応があります。私たちは、私たちにとってうまく機能し、ビジネスが成長するにつれて一緒に成長するプラットフォームを探しています。
AWS が強力なロードマップと継続的なイノベーションでこの分野に大きく投資していることが分かります。これは私たちにとって重要でした。セキュリティと分離は EMR で本当に優れています。コスト構造は競争力があり、透明性があることが分かりました。ユーザーエクスペリエンスは良好で、ノートブック統合もサポートされています。
運用の負担は減ります。これはマネージドサービスだからです。パフォーマンスとスケーラビリティはうまくいきました。パフォーマンス結果を共有しましたし、スケーラビリティの結果も現在のプラットフォームと同等かそれ以上でした。このプラットフォームは bootstrap actions を通じてかなり拡張可能です。DIY アプローチほど柔軟ではありませんが、それは予想されることです。それを考慮に入れても、私たちはこのプラットフォームはかなり機敏だと判断しました。
可観測性とデバッグのために、CloudWatch を使うのではなく、独自の可観測性を導入しています。その他の統合とストーリー全体は良さそうです。ここでやることはちょっとありますが、ストーリーはまだ良好です。前に示したスライドに戻ると、4つのボックスのうち3つをチェックして、本当に素晴らしいことがわかりました。価格、パフォーマンス、使いやすさ、セキュリティです。AI acceleration はまだ試していません。これは次に試すことになります。
このストーリーはこのように終わりますが、もしかしたら新しいストーリーが始まるかもしれません。Netflix Spark ワークフローを段階的に EMR に移行することに決めました。2026年の前半は、やることがあります。技術的な負債を返済し、新しいコントロールプレーンやジョブルーティングインフラなどを構築しています。2026年の後半には、独自のプラットフォームワークフローを移行し、dog fooding を行い、物事をチェックアウトします。学習に基づいて微調整を行い、2027年にはユーザーワークフローを移行します。
POC 中に EMR Serverless をテストする予定です。それについて触れて、初期段階での肯定的な結果を見ましたが、深掘りする時間がありませんでした。AI acceleration は、先ほど述べたように、コスト帰属の追加が探索する領域です。EMR アカウントチームの Wedi、Manju、Kartik に感謝したいです。EMR プロダクトチームの June、Geo、Pinhuk、Neil と一緒に、1つのチームでした。Netflix チームの延長のようでした。彼らが部外者のように感じたことはありません。一緒に仕事をしていて、本当に素晴らしい経験でした。
Netflix Spark チームの Anurag とチーム、DSI Security、その他の BA チームに大きな感謝を捧げます。これは3四半期にわたって行われた巨大な努力でした。今年の Q2 の終わりに POC を完了し、その後、カスタムパッチとカスタマイズについて話し合う必要があったため、さらにフォローアップがありました。すべてがまとまってきています。AWS EMR との旅に本当に興奮しています。最高はまだこれからです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion