re:Invent 2025: FINRAがAWS EMR上でNVIDIA GPUを活用し大規模データ処理を高速化した事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - FINRA: Accelerate Massive Data Processing with NVIDIA on AWS EMR (AIM279)
この動画では、NVIDIAのFelixがApache Spark向けRAPIDSアクセラレーターを紹介し、FINRAのAlain Menguyが実際の導入事例を解説しています。FINRAは1日1.5兆件の市場イベントを処理する組織で、GPU活用により不正検出ワークロードで14倍の高速化と90%のコスト削減を実現しました。TPCDS 9テラバイトベンチマークでは処理時間が1時間45分から53分に短縮され、11テラバイトの本番ワークロードでも50%の時間削減と45%のコスト削減を達成しています。ただし、GPU メモリの制限やCPUへのフォールバック、設定の複雑さなど課題も存在し、NVIDIAチームとの密な協力が成功の鍵となりました。すべてのワークロードが恩恵を受けるわけではないものの、FINRAはGPUを戦略的なパフォーマンスレベルへ進化させることを期待しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
NVIDIA RAPIDS Accelerator for Apache Spark の紹介とGPUアクセラレーションの価値
このセッションへようこそ。私の名前は Felix です。Apache Spark 向け Accelerator のプロダクトマネージャーをしています。本日は盛りだくさんのアジェンダをご用意しています。まず NVIDIA RAPIDS Accelerator for Apache Spark をご紹介して、その後、FINRA の同僚がこのテクノロジーを活用してワークロードを加速させた事例をお話しします。
Apache Spark は今日最も人気のあるデータ処理フレームワークの一つです。ほぼすべてのエンタープライズ企業や組織で、分析、レポーティング、機械学習など、様々なニーズに使用されています。さらに重要なことに、特に AI の台頭に伴い、ここ数年でデータが異常なペースで増加しています。このような例外的な成長に対応するため、エンタープライズ企業や組織は GPU アクセラレーションを導入する必要があります。
右側に見えるのが 私たちのスタックです。Apache Spark のワークロードと Spark アプリケーションがそのまま実行されます。ここにプラグインを導入することができます。コード変更なしでワークフローにインストールでき、クラウドまたはオンプレミスで実行される GPU アクセラレーションレイヤーを活用します。これにより、コスト削減と高速な結果が得られます。GPU にはもちろんコストが伴いますが、アクセラレーションの効果は十分に大きく、全体的にはデータをより高速かつ低コストで処理できます。
導入状況をお示しするために、このテクノロジーの使用を公開で発表している企業やエンタープライズ組織をご紹介します。ここ 2 年間でさらに多くの企業がありますが、オンラインサービス、小売、金融サービスにわたってパターンが見られます。特に今日は金融サービスが関連しています。不正検出の例をお話しします。不正検出では、多くの場合、数十億件のレコードを処理する必要があり、5 年、10 年、または 15 年前まで遡ってパターンを探します。このパターン分析は時系列ウィンドウ操作と分析を使用しており、これは GPU が得意とするものです。その結果、この特定のワークロードで 14 倍のスピードアップを達成でき、90 パーセントのコスト削減が実現できます。詳しく知りたい場合は、実は昨年 AWS FSI チームと提携してブログ記事を公開しました。QR コードを使ってウェブページを開いて、ご自身で確認していただけます。また、ぜひご連絡ください。
FINRA の組織概要と1日1.5兆件の市場イベント処理における課題
それでは早速、FINRA の同僚にこのテクノロジーを使った経験についてお話しいただきたいと思います。これについて本当に興奮しています。というのも、昨年の私たちのプレゼンテーションが彼らの関心を引き、そこから協力が始まったからです。ありがとうございます。Felix、Apache Spark RAPIDS と NVIDIA GPU チップセットについての素晴らしい紹介をありがとうございました。私は Alain Menguy で、FINRA のシニアディレクター、ビッグデータおよびパフォーマンスエンジニアリング部門を担当しています。FINRA で 20 年以上働いており、多くの変革的で革新的なプロジェクトに携わってきましたが、この Spark RAPIDS on GPU は、その中でも本当に素晴らしいプロジェクトの一つです。
まず、FINRA がどのような組織なのかをお話しします。 FINRA は長い歴史を持っています。昨年は創立 85 周年を迎えました。私たちのミッションは 2 つあります。市場の完全性と投資家保護です。すべての参加者が自信を持って取引でき、市場が市場操作と詐欺から自由であることを確保しています。基本的には、投資家の皆さんを保護し、皆さんのお金が安全で健全であることを確保しているのです。私たちのビジネスの性質 から、私たちは AI とビッグデータの企業です。AWS クラウド上で 1,000 ペタバイト以上のストレージを運用しています。
今年の 3 月には、1 日で 1.5 兆件の市場イベントを処理しました。はい、繰り返しますが、1 日で 1.5 兆件の市場イベントです。このボリュームを処理するには、膨大なテクノロジーインフラストラクチャと高度なシステムが必要です。
私たちのビジネスフローは次のように機能します。市場が東部時間の午後 4 時に閉場した後、メンバーファームは翌日午前 8 時までに取引活動を報告する義務があります。そこから、市場活動を再構築するまでに数時間しかありません。その後、市場操作と詐欺を探すために数百のパターンモデルを実行します。異常が見つかった場合はアラートが生成され、そのアラートは調査チームに送られます。調査チームはシステムに対話的にクエリを実行して、これらのアラートをより深く理解することができます。
市場ボリュームは増え続けています。 長年にわたって劇的に増加しており、今後数年間もその傾向は上昇し続けるでしょう。最新の電子取引プラットフォームと高頻度取引システムは、以前よりもはるかに多くのトランザクションを生成しています。ボリュームが増加するにつれて、そのボリュームを処理するための計算ニーズも増加します。私たちの課題はビジネスロジックだけではなく、スケーラビリティとコスト効率性であり、それが GPU アクセラレーションオプションの評価につながりました。
FINRA は常に新しいテクノロジーを採用する必要があります。立ち止まることはできません。コストを削減し、パフォーマンスと並行性を向上させ、レジリエンシーとセキュリティを強化する新しい機能を開発する方法を常に探しています。私たちが採用するものは何であれ、パフォーマンスと経済的な意味を持つ必要があります。
ご存知の通り、AWS とオープンソースコミュニティは常に新しいハードウェア、新しいサービス、そして新しい実行モデルをリリースしています。私たちにとって、このイノベーションを評価することは、年に一度行うものではありません。それは私たちの DNA の一部です。これは常に行っていることです。流行りのものを追いかけることではなく、どの EMR バージョン、Java、または Spark を使用するかを決めることなのです。この継続的なベンチマーキングが、私たちのアーキテクチャ、ロードマップ、そしてプラットフォームの決定を導いています。
GPU アクセラレーションの実証実験：ベンチマークから本番ワークロードまでの実践と成果
FINRA では、業界標準と実際の FINRA 本番環境のワークロードをブレンドしたベンチマーク スイートに依存しています。大規模な I/O をストレステストするために TeraSort を使用し、SQL プランニング、結合、集約を評価するために TPCDS を使用しています。また、非常に大規模なデータセット、大量のシャッフル、複雑な結合パターンを持つ 66 の規制ワークロードもベンチマークしています。
時間の都合上、そのスライドはスキップしますが、実行間で公正な比較を行っていることをご理解ください。実行間で同じ入力データセット、同じ Spark 設定、同じクラスタ設定を使用しています。もちろん、出力も検証しています。実行間で結果が変わらないことを確認しています。
これは本当に Moore の法則が実際に機能している例です。EMR、Spark、Java、そして基盤となるハードウェアの自然な進化だけから、これまでのパフォーマンス改善を見てください。これは、私たちが長年にわたって実行してきた TPCDS 9 テラバイト ベンチマークの結果です。コード変更なし、同じデータ、同じロジック、ただ新しい Spark バージョン、新しいエンジン、新しいインスタンス ファミリーです。
6 年前に EMR 5.24 を使用していた時は 9 時間 5 分から、数週間前にリリースされたばかりの最新の EMR 7.10 では 1 時間 45 分まで短縮されました。これは 5 倍のパフォーマンス改善であり、これらの新しいテクノロジーと新しいインスタンス ファミリーに乗り換えることによるコスト削減を想像できるでしょう。これは本当に Moore の法則が実際に機能している例です。ここで Spark GPU がストーリーに登場しました。
数ヶ月前に NVIDIA チームのプレゼンテーションからあるスライドを見たんですが 、それが本当に目に留まったんです。私たちはクラウドの早期採用者で、クラウド上での最初のワークロードは 2013 年、Hadoop の時代で、Apache Hive を使って SQL クエリを実行していました。その後 Apache Spark が登場して、インメモリ処理でゲームを変えてしまい、スピードと効率の面で大きな飛躍をもたらしました。そのスライドを見たとき、これは本当に私たちに語りかけてくるなと思ったんです。そこで疑問が生まれました。GPU アクセラレーション Spark は新しい技術的な飛躍なのか？それが私たちが試してみたいと思ったことです。
では TPCDS で 9 テラバイトを使ってみましょう。 1 時間の壁を破ります。 EMR 7.10 の最新 GPU インスタンスタイプで 1 時間 45 分かかっていた全く同じワークロードを実行したところ、正確に 53 分で完了しました。これは処理時間でおよそ 50% の削減で、クラスタが実行している時間が短くなるため、コスト削減もおよそ 50% です。より速く、より安く、コード変更なしです。
その時点で、よし、本番ワークロードでやってみようということになりました。 これは合成データではなく、実際の本番ワークロードです。このデータセットの総入力は 11 テラバイトで、このパイプラインは本当に結合が多く、シャッフルが集約的です。私たちは 50 億レコードを持つ 2 つの非常に大きなテーブルを結合しています。一方は 125 列で、もう一方は 25 列です。処理日付と生の ID で結合しており、これは私たちのアプリケーションのビジネスロジックの 1 つです。データは取引日でパーティション分割されています。
コードは変更しませんでした。このアプリケーションは Scala で書かれており、CPU と GPU の両方で実行しました。 ここでも 50% のパフォーマンス削減と約 45% のコスト削減が見られました。コード変更なし、そしてこれが本当に私たちが自分たちを納得させ始めたポイントです。これは本当に探求する必要があることがあります。なぜなら、これはパフォーマンスとコスト削減の機会という点で本当に驚異的だからです。
覚えておいてほしい重要なポイントの 1 つは、その大規模なパフォーマンス向上を実現するために、単にスイッチを入れたわけではないということです。最初の試行では、GPU の実行に 5 時間かかりました。私たちは NVIDIA チームに連絡し、ボトルネックが何かを特定するために、2 つのエンジニアリングチーム間で非常に良い協力関係がありました。プランを調査し、時々 GPU が CPU にフォールバックしていることに気づき、多くのボトルネックを特定し、NVIDIA チームはそれらの発見に基づいてこの特別なワークロード用の新しいプラグインを開発しました。重要なポイントは、はい、コード変更はありませんが、プラグアンドプレイではなく、常にそうとは限らないということです。
では、別のワークロードです。これが重要なデータ抽出処理です。メンバー企業がファイルを我々に提出しているとお伝えしてきましたが、彼らは CSV BZ2 ファイルを送信しています。
これらを解凍して、読み込んで、型付きカラムに渡して、その後 Snappy 圧縮プロトコルを使用して Parquet フォーマットに変換する必要があります。企業が毎日数十万のファイルを送信しているため、このアプリケーションは1日の間に何度も実行され、反復的なプロセスになっています。
最初は CPU と GPU のパフォーマンスが同等でした。NVIDIA チームと協力してボトルネックを特定したところ、元のアプリケーションが Dataset API を使用していたことが分かりました。これは GPU の使用ケースとしては適切ではありませんでした。DataFrame API に変更し、複数の反復を通じて、処理時間を 2 倍削減でき、最終的には 10 倍削減することができました。これは大きな改善です。NVIDIA チームとのこの強力な協力がこれらの成果を達成するために不可欠でした。
業界ベンチマークと FINRA の本番ワークロードを見ると、テストしたワークロードの一部で 2 倍高速な結合と低いコストを実現できることが分かりました。RAPIDS は Spark と DataFrame パイプラインと非常に良く統合されます。特定のパイプラインではコード変更が全く不要な場合もあり、設定をチューニングすれば実行時間とコスト削減は一貫していました。しかし、GPU メモリにはいくつかの制限があり、ディスクへのスピルを非常に慎重に管理する必要がありました。一部のオペレータが CPU にフォールバックし、混合実行プランが作成され、RAPIDS の設定は簡単ではありません。オープンソースは気まぐれで扱いにくいため、パラメータの1つの変更でも劇的なパフォーマンス改善またはパフォーマンス低下を引き起こす可能性があります。さらに、GPU インスタンスの可用性は常に容易に入手できるわけではなく、特に複数のインスタンスが必要な場合はそうです。そのため、このタイプのワークロード用に容量を確保するために NVIDIA との関係を構築する必要がありました。
これで、GPU と Apache Spark RAPIDS で実施した最初の概念実証の終了を示します。すべてのワークロードが利点を得るわけではなく、ボトルネックを特定するのにかなりの時間を費やす必要があるかもしれません。現在、CPU と GPU の実行時間を検証できるプロセスがあるため、より多くのワークロードをテストするプロセスがあります。パフォーマンス上の利点とコスト削減から、GPU が実験から戦略的なパフォーマンスレベルへと進化することを期待しています。これは我々にとって進化であり、GPU と Spark RAPIDS をビッグデータワークスタックに追加していきます。しかし、今日のところ CPU が我々のデフォルトのままですが、GPU は確実に我々の将来のアクセラレータパスになるでしょう。
ありがとうございます。ご質問をお受けします。ぜひお試しください。提供されている URL にアクセスしていただくことができますし、表示されているメールアドレスでお気軽にお問い合わせください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion