re:Invent 2024: AWSがSageMaker新プラットフォームを発表
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Innovations in AWS analytics: Data processing (ANT346)
この動画では、AWSのデータ処理および開発体験製品のProduct Management部門を統括するWilliam Vambenepeが、新しいSageMakerプラットフォームについて解説しています。SageMaker Lakehouse、統一されたガバナンスフレームワーク、そしてSageMaker Unified Studioという3つの主要コンポーネントの詳細が語られ、特にUnified Studioではデータ処理製品群の統合環境としての機能が紹介されています。また、AWS GlueやTrinoを活用して日々200万回のモデル実行と19ペタバイトのデータを処理するBridgewaterの事例も共有され、実際の大規模データ処理における課題解決方法が具体的に説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
SageMakerプラットフォームの概要と本セッションの紹介
みなさん、こんにちは。本セッションへようこそ。私はWilliam Vambenepeです。AWSのデータ処理および開発体験製品のProduct Management部門を統括しています。本日は、後ほど自己紹介していただくKinshuk PahareとCraigも同席しています。まず、これから何をお話しするかについて概要をお伝えしましょう。今朝のKeynoteで発表された内容に基づいてお話しします。Keynoteの最後で、Matt Garmanは最高の発表として新しいSageMakerについて触れました。本日は、その中でもデータ処理に関する部分に焦点を当ててお話しします。
Keynoteを見逃された方もいらっしゃるかもしれません。長時間に及んだため、最後まで見られなかった方もいるでしょう。そこで、SageMakerについて発表された内容をおさらいし、より詳しくご説明します。その後、KinshukがSageMakerプラットフォームの基盤となるデータ処理製品群と、それらの製品に最近追加された改良点や新機能についてお話しします。最後に、Craigが、Bridgewaterが自社のデータプラットフォームでこれらの製品をどのように活用しているかについてご紹介します。
新しいSageMakerプラットフォームの構成要素
今朝の発表に話を戻しますと、私が言及しているのは新しいSageMakerの発表についてです。ご説明させていただきますと、おそらくみなさんの多くは、SageMakerをAWSの機械学習サービスとしてご存知だと思います。しかし、SageMakerは今やそれ以上のものになりました。AWS上のすべてのデータAIとMLサービスを統合したプラットフォームとなったのです。昨日までSageMakerとして知られていたものは、新しいSageMakerプラットフォームの一部として、現在はSageMaker AIと呼ばれています。このプラットフォームははるかに広範で、EMR、Glue、Athena、MWAA、Redshiftといった私たちのデータ処理製品すべてと、Gen AI向けのBedrockを統合し、中核となるデータレイクと統一されたガバナンスを備えています。
図で表すと、新しいSageMakerプラットフォームには3つの主要な部分があります：本セッションで主に説明するUnified Studio、データワーカーがすべてのデータ処理とML機能を1つの統合アプリケーションで利用できる新しい開発環境です。全体像を把握していただくために、SageMakerプラットフォームの他の2つの部分についても簡単に触れておきますが、これらは本日の主題ではありません。ガバナンスの側面とSageMaker Lakehouseについては、他のセッションで詳しく説明されます。
本日一般提供が開始されるSageMaker Lakehouseについて、これはRedshiftのデータウェアハウス機能とAmazon S3上のIcebergを使用したデータレイク機能を統合し、データレイクハウスとして一本化したものです。さらに、分析用ストレージシステムのデータだけでなく、運用データベースやAWS外のサービスのデータも含まれます。Zero-ETLのおかげで、SalesforceやSAPなどのベンダーからのデータをレイクハウスに取り込むことができます。また、BigQuery、Snowflake、その他の場所のデータにアクセスするためのフェデレーテッドデータソースを作成することもできます。
消費の観点からのこれらすべてのデータは、Apache Icebergを使用した標準ベースの統一された消費インターフェースを通じて、Lakehouseの一部として利用可能です。これは、Apache IcebergのRESTの定義に基づいたオープンな標準であり、今日お話しするすべてのサービスがこのデータにアクセスできるだけでなく、Apache Icebergを使用してデータの読み書きができるすべてのサービスやフレームワークでも利用可能です。Apache Icebergの急速な成長と採用により、現時点でほぼすべてのサービスがこれに対応しています。Lakehouseについてはまだまだお話しできることがありますが、今回のメインテーマではないので、 SageMaker Lakehouseに関する他のセッションをご参照ください。
Lakehouseの上に、私たちは統一されたガバナンスフレームワークも構築しました。 多くの方々は現在製品として存在するDataZoneをご存じかもしれません。DataZoneはSageMakerプラットフォームの中核に組み込まれ、そのガバナンス機能やビジネスデータカタログ、ビジネスコンテキストでデータを閲覧・文書化する機能をもたらしています。ビジネスデータカタログを使用すると、Lakehouseカタログの技術的なメタデータの上にビジネスメタデータを追加することができます。
現在SageMaker catalogとして知られるDataZoneは、SageMakerプラットフォーム内で、データ品質、系統、分類を管理する機能を提供しながら、システム全体にガバナンス機能を拡張しています。これは現在、ガードレールを管理する場所でもあり、Amazon SageMaker AIが提供する責任あるAIのための機能がすべて統合される場所となっています。技術的なデータ管理環境としてのLakehouseの上に、ビジネスデータのガバナンスを提供するのです。SageMaker catalogと、以前のDatazoneの機能を基に構築されたガバナンスおよびコラボレーション機能については、複数のセッションが用意されています。
SageMaker Unified Studioの特徴と既存サービスとの関係
SageMaker Unified Studioについてお話ししましょう。ガバナンスやSageMaker catalog、Lakehouseが今日からGAとしてリリースされているのとは異なり、Unified Studioはプレビューとしてリリースされています。GAは間もなく続きますが、現在はパブリックプレビューとして利用可能です。誰でもUnified Studioの使用を開始できます。これは、すべてのデータ処理製品のための単一の体験です。右側に表示されているものの一部には「Coming Soon」とマークされているのがわかります。今日SageMaker Unified Studioを使用しても、ストリーミング、ビジネスインテリジェンス、検索機能は見つかりません - これらは後日追加される予定です。現時点では、左側の最初の4つが利用可能です：AWS Glue、Athena、EMRによるデータ処理、Amazon RedshiftによるSQLアナリティクス、以前SageMakerにあったすべての機能にさらに機能を追加したもの、そして以前Bedrockにあったすべての機能にさらに機能を追加したものです。
本日のセッションでの私の目標の1つは、既存のものと新しいものの関係を明確にすることです。基調講演やブログ投稿では新しい部分について多く語られていますが、Unified Studioは体験とグラフィカルツールを備えたWebアプリケーションとして新しいものの、すでに使用している同じデータ処理AIおよびMLサービスに基づいています。Unified Studioを通じて、EMRのSpark、Trino、Presto、Flinkなど、EMRが提供するすべての機能を、自身のクラスターを使用するか、サーバーレスシステムを使用するかを選択して利用できます。Athena、MWAAのAirflow、AWS Glue、Amazon Redshiftも使用できます。カバーの下では、これらは全く新しい実行環境ではなく、安全で、スケーラブルで、信頼性の高いことが実証済みのサービスです。
既存のアプリケーション、データ、クラスター、パイプラインはすべて、Unified Studioで直接利用できます。一からすべてを作り直す必要のある新しい環境というわけではありません。導入の観点から、スムーズな移行が可能であることは私たちにとって重要でした。Unified Studioの開発中も、チームの他のメンバーは基盤となるサービスの改善を続けていました。Amazon Redshift、SageMaker AI、Bedrockの改善については、他のセッションで取り上げられるので、ここでは触れません。本日は、Kinshukが左側の列について説明しますので、データ処理サービスの改善については彼に任せたいと思います。
SageMaker Unified Studioの実際の使用感とプロジェクト機能
SageMaker Unified Studioは、あらゆるデータ関連の処理作業のための統合環境です。これまでの製品群を見てみると、EMR ConsoleやEMR Studio、RStudio、Athena、Bedrockなどがあり、それぞれが独自のUIを持っていました。これらは各サービスのフロントエンドとしては十分機能していました。しかし、データ処理の多くは複数のサービスが連携して動作する必要があり、従来はこれらの包括的なサービスの統合はユーザーに任されていました。
つまり、同じ人が複数のツールを使い分けたり、異なるスキルや好みを持つ人々が協力したりする場合でも、統合作業は自分たちで行う必要がありました。しかし、Amazon SageMaker Unified Studioによって、それが変わろうとしています。
実際の使用感を見てみましょう。これがログインページですが、一見すると特に目新しくないように見えるかもしれません。しかし実は、とても興味深い点があります。まず気づくのは、これがAWS Consoleの一部ではないということです。これはデータワーカー向けに一から作られた環境で、多くのユーザーはAWS Consoleを使う必要がありません。これはWebアプリケーションで、1つのURLにアクセスするだけで利用を開始できます。次に注目すべき点は、SSOクレデンシャルでログインすることです。これは、企業の認証情報を使用して個人として識別される場所であり、Gitのコミットやアクセス権限を含むすべての操作が、個人ベースで行われます。これはSSOアカウントとグループを使用する、より優れた方法といえます。
次に紹介したいのは、SageMaker Unified Studioの中核的な追加原則の一部である「プロジェクト」という概念です。Datazoneをご利用の方は、このプロジェクトという概念をご存知かもしれません。これはDatazoneからSageMakerプラットフォームへの統合の一部として取り入れられたものです。これは協業の場であり、パイプライン、SQLクエリ、モデル、GenAIアプリケーションなど、作成済みのアーティファクトを持ち込んだり、プロジェクト内で直接作成したりすることができます。EMRクラスター、Redshiftクラスター、AthenaやRedshiftのサーバーレスエンドポイントなどの計算リソースを持ち込むことができます。各プロジェクトはGitリポジトリによってバックアップされており、変更はすべてバージョン管理され、Gitリポジトリを通じてアクセスできます。右上の小さな紫色のボタンからわかるように、Amazon Qはプロジェクト全体で利用可能です。具体的な機能についてはこの後お話ししますが、Amazon Qは環境全体に組み込まれており、あらゆる段階でサポートしてくれます。
SageMaker Unified Studioフレームワークのもう一つの重要な要素がデータブラウザです。これは、先ほどお話したLakehouse、つまりSageMaker Lakehouseを視覚的に表現したものです。ここでご覧いただいているのは、プロジェクトで共有されているすべてのデータに一箇所からアクセスできる機能で、S3上のIcebergテーブルなどLakehouse内のデータや、フェデレーテッドソースを含むすべてのデータを閲覧できます。このデモでは、プロジェクトに取り込まれ、データブラウザ内でカタログとして表示されているフェデレーテッドソースの例や、ゼロインテグレーションを通じて取り込まれたデータをご覧いただけます。これにより、きめ細かなアクセス制御を集中管理し、あらゆるツールでデータを活用できる、豊かな機能を備えたLakehouseの全体像をご確認いただけます。これらのデータを右クリックすることで、ノートブックで開いたり、クエリを実行したり、すぐに作業を開始したりすることができます。
次に、利用可能なツールについてお話しましょう。実際には、ここでお見せする以上に多くのツールがあります。本日は、データ処理に関連するツールに焦点を当てたいと思います。SageMaker AIからのモデルトレーニング機能やGenAIアプリケーション開発など、SageMaker Unified Studioの他の部分についてはご紹介しません。今回は左側に表示されている、データ処理サービスを利用するためのインターフェースとなるツールに焦点を絞ってお話しします。まずはノートブックからです。多くのユーザーにとって、ノートブックは最も中心的なツールと言えるでしょう。SQLだけを使用する方もいますが、多くの方にとってノートブックが本当に重要なツールとなっています。昨日までは、EMRにもノートブックがあり、AWS Glueにもノートブックがあり、Amazon Athenaにもノートブックがあり、SageMakerにもノートブックがありました。つまり、ユーザーとしてはノートブックを簡単に入手できるものの、複数の選択肢から選ばなければならなかったのです。
現在、Amazon SageMaker Unified Studioには、すべてのサービスで使用できる統合ノートブックが用意されています。このノートブックはポリグロットで、セルごとにSQL、Java、Python、Scalaを使用でき、それぞれに対応するランタイムをアタッチすることができます。このノートブックから、データエンジニアリング、特徴量抽出、データサイエンスなど、あらゆるツールを使用して、基盤となるサービスを組み合わせて活用することができます。
ノートブックを通じてワークフローを作成することもできます。そのサービスの1つが、マネージド型Apache Airflowサービスであるmwaaです。Airflow DAGを作成してワークフローをオーケストレーションすることができます。Sparkのログにアクセスしたり、他のツールでできることはすべて実行できる上に、新機能も追加されています。さらに、Amazon Q統合も追加され、事実上あらゆるタスクでQを使用できるようになりました。Qを使用してコードを生成したり、他の人が書いたコードを説明したり、コードのリファクタリングを支援したりすることができます。基本的に、ノートブック内のすべてのタスクがQによってアシストされます。
データ処理サービスの改善とGen AIを活用した新機能
もう1つのツールは、AWS Glueから提供されているものです。データ統合にGlueを使用している方々は、コードインターフェースに加えて、Glueがビジュアルインターフェースを提供していることをご存知でしょう。これを使用すると、ソースを選択し、ドラッグアンドドロップでデータを変換したり、フィルタリングしたり、その他の変換を適用してから目的の場所に取り込んだりすることができます。これが現在SageMaker Unified Studioで利用可能になり、Glueと同様に、ビジュアル表現から直接実行することも、より詳細な制御が必要な場合はコードに変換することもできます。ここでもAmazon Qが利用可能で、自然言語リクエストに基づいてビジュアルワークフローを生成することができ、必要に応じてフィルターやその他の変換を追加することができます。
SQLクエリについてお話ししましょう。 Amazon RedshiftにはQuery Editorがあり、Amazon AthenaにもQuery Editorがありましたが、現在はRedshiftとAthenaの両方で使える統合されたQuery Editorが登場しました。これには結果の可視化、Glueとの連携、そしてAmazon Qによるアシスタンス機能が含まれています。自然言語で説明するだけで、カタログの内容を理解したAmazon QがSQLを作成してくれます。例えば、「特定の国の顧客で、一定額以上の支出がある人を探したい」というように、ビジネス用語でテーブルを参照すると、Amazon Qが実際のテーブル名を使用して実行可能なクエリを生成します。
さらにいくつかポイントがあります。 Data Zoneのガバナンス機能が、新しいSageMakerプラットフォームの一部として組み込まれました。これらの機能は現在、SageMaker Unified Studioを通じて利用できます。ここでビジネスデータカタログによるガバナンス機能の例をお見せします。画面は少し見づらいかもしれませんが、これはデータセットに関するビジネスメタデータを示しており、スキーマ情報などの技術的なメタデータだけでなく、ビジネス的な説明も含まれています。ビジネスの説明を追加してデータをキュレーションできます。その際、Amazon Qが説明文を生成してくれるので、それをレビューして編集できます。その後、このデータをビジネスデータカタログに公開すれば、同じドメイン内の他のユーザーがそのデータを見つけることができます。
ユーザーが有用なデータを見つけた場合、 そのデータセットに対してサブスクリプションリクエストを送信する機能があります。これにより自動的にデータオーナーにリクエストが送られ、オーナーはそのリクエストを承認、拒否、またはフィルターを付けて承認することができます。例えば、誰かが顧客テーブルへのアクセスを要求した場合、オーナーはアクセスを許可しつつ、特定のカラムに限定するフィルターを追加することができます。
このワークフローの一部として、きめ細かなアクセス制御を適用できるというのがポイントです。 その他にも、データの系統管理、データ品質、責任範囲、Amazon Bedrockのガードレールなど、多くのガバナンス機能があり、これらがすべて統合されています。これは開発者、SQLアナリスト、データキュレーター、そして実際にはすべてのデータワーカーが協力して作業するための適切な場所となっています。
以上が統合スタジオの概要です。これらの実行は、私たちの強力なデータ処理製品に基づいており、Kinshukが基盤となるデータ処理サービスについて詳しく説明します。 Williamが説明したように、SageMaker Unified Studioをブラウズすると、シングルサインオンで自分の名前が表示され、 そこで利用可能なすべてのツール - Query Editor、Notebook - はすべて基盤となるデータ処理エンジン（AWS Glue、Amazon EMR、Amazon Athena）によって動作しています。既存のEC2クラスターにNotebookを接続したり、ノーコードジョブを作成してGlueエンジンで実行したり、SQLクエリを作成してAthenaやAmazon Redshiftで実行したりすることができます。
プロセッシング層におけるイノベーションのテーマを続けて、私たちは3つの特定の分野に注力しています：パフォーマンスとコストへの継続的な投資、運用の卓越性とセキュリティ、そしてこれまでご覧いただいたコード作成の枠を超えて、データエンジニアの作業を容易にする新しいGen AIベースの機能を提供しています。 まずは、最高のパフォーマンスを最低のコストで実現する点からお話ししましょう。 お客様がAWS上でSparkワークロードの実行を好む最大の理由は、より簡単で高速だからです。最新のアナウンスによると、AWS管理のSparkは、EMRエンジン上で実行した場合、オープンソースのSparkと比較して3.9倍高速です。
ここでの重要な利点は、課金の大部分がコンピュート時間に基づいているため、基盤となるエンジンが高速であれば、データ処理に必要なコンピュート時間が少なくなり、結果としてコストが低くなるということです。私たちは、AthenaのSQLサービスを支えるTrinoエンジンでも同様のイノベーションを実現しています。 Athenaのクエリエンジンは、オープンソース版と比較して2.7倍のパフォーマンスを発揮します。 また、コンピュートレベルでも同様の改善を進めています。Graviton3は、大規模ジョブのコスト削減につながる20%のパフォーマンス向上を標準で提供します。 これらすべては、エンジンとの100%のオープンソース互換性を維持しながら利用可能です。つまり、既存のワークロードをEMRやAthenaに移行する際も、予期せぬ問題は発生しません。
今年提供した2つ目の側面は、マネージドスケーリングに関するものです。EMRをご存知の方なら、すでにオートスケーリングをサポートしていることはご存知でしょう。マネージドスケーリングの特徴は何でしょうか？まず、大幅に改善されました。ワーカーのシャットダウンを決定してから実際に実行するまでの時間差を縮小しました。より迅速なスケールダウンが可能になり、コンピュートコストがさらに削減されます。改善されたオートスケーリングアルゴリズムにより、最大60%のコスト削減を実現しているお客様もいます。Apache AirflowサービスであるMWAAでも同様の改善を行いました。 左のグラフで見られるように、タスク数が減少すると、 ワーカー数も即座に減少します。以前は、この2つの間にタイムラグがありました。
AWS Glueにおける主要な要望の1つは、新入社員のアクセス管理に関するものでした。 例えば、新入社員やインターンが200ノードのSparkジョブを起動できないようにしたい場合があります。今年、Usage Profilesを導入し、インターンプロファイル、新入社員プロファイル、QAプロファイルなどを作成して、コンピュート使用量、使用時間、セッション数をコントロールできるペルソナを割り当てることができるようになりました。これは事後的なコスト管理ではなく、予防的なコスト管理です。Usage Profilesを通じてこのペルソナを割り当てると、より大きなクラスターや長時間のジョブを起動することができなくなります。
運用の卓越性とセキュリティについてお話ししましょう。 データ処理における主要な課題の1つは、Fine Grained Access Control（FGAC）に関するものです。FGACは、管理者が行と列の組み合わせであるセルレベルでのアクセスを強制するポリシーを作成できるようにすることです。 大規模なFGACの実現は困難で、Apache Sparkを例に説明させていただきます。主な課題は、Sparkが非常に開発者フレンドリーであることです - 命令型と宣言型のコードを混在させることができ、ユーザーはデータ操作により多くの制御を持つことができます。これがSparkを非常に人気のあるものにしている理由です。データ操作が非常に簡単だからです。 クエリプランにユーザー定義関数（UDF）を組み込むことができ、それらのUDFはメモリ空間にアクセスできます。
私たちが実装したのは、SparkネイティブのFGACです。これは今年実現した重要なイノベーションで、クラスターをユーザースペースとシステムスペースに分割しました。これにより、ポリシーの実施はシステムレベルでのみ許可される一方で、ユーザーは引き続き関数の定義と記述が可能です。そしてそれらのポリシーの実施はシステムスペースで実行され、ペタバイト規模のデータでもFGACを実現できるようになりました。 この詳細については、Amazon Scienceのページで公開している論文をご覧いただけます。そこではSparkベースのデータ処理システムとFGACの実現に際して直面した課題について詳しく説明しています。
同時実行とキュー管理に関して、AWS Glueなどの各種サービスになぜ制限があるのかとよく質問を受けます。その理由の1つは、暴走したジョブが過剰にコンピュートリソースを消費し、大きな請求額を生むことを防ぐためです。AWS GlueとEMR Serverlessの両方で、設定ミスのジョブや実行中のマシンの放置による大きなエラーから顧客を保護するための制限を設けています。両サービスでは、ジョブに十分なコンピュートリソースやメモリリソースがない場合、リソースが利用可能になるまでキューイングされる仕組みを導入しています。
最後に、Amazon EMRの柔軟なデプロイメントオプションについてお話ししたいと思います。チームとのSLAやジョブのコストプロファイル（SLA重視のものもあれば、コスト重視のものもある）に応じてデータ処理のニーズは様々ですが、EMRは多様なコンピュートオプションを提供しています。ServerlessからAmazon EKS、Spotインスタンス、Graviton3の利用、目的に応じたインスタンスタイプの選択が可能です。例えば、バッチジョブは汎用インスタンスで実行し、大量のデータを扱う大規模な結合のようなメモリ集約型のジョブはメモリ集約型インスタンスを活用できます。あらゆる種類のワークロードに対して、ジョブプロファイルやコンピュートプロファイル、システムプロファイルを選択できます。
今年初めに、SparkとSQLの両方で生成AIを活用したオーサリング機能をリリースしました。Sparkの場合、「S3からDynamoDBにデータを移動し、マッピング変換を適用するETLパイプラインを作成して」といった自然言語のプロンプトを使用することで、設定可能な実行可能なETLパイプラインを生成します。SQLの場合は、「このテーブルから売上トップ10を表示して」といった要求を入力すると、SQLクエリに変換されます。
コード生成は素晴らしい機能ですが、私たちは2つの重要な問題に対処することでさらに改善しました。1つ目は、ジョブが失敗した場合の対処と根本原因分析の方法です。2つ目は、Icebergなどの最新の安定フォーマットをサポートし、パフォーマンスが向上した最新のSparkバージョンへのアップグレードをどのように行うかという問題です。先週、生成AIを使用してこれらの問題を解決する機能をリリースしました。 Sparkの障害を分析するには、これまでは数週間から数ヶ月かかることもありました。Sparkのような分散プログラミング構造の課題の1つは、たった1行のコードエラーが100ページものエラーメッセージを生成し、経験豊富な開発者でも解析が困難だということです。私たちは生成AIを使用して、自動的に根本原因分析を実行できるようにしました。
標準的なSparkコードを使用してS3ソースからデータを取り込み、ジョブが失敗したケースのデモをご紹介します。AIによるトラブルシュートボタンをクリックすると、リソースが見つからないエラーが発生した根本原因を特定しました。この場合、18行目にタイプミスがあることを正確に指摘しています。根本原因分析では、エラーの発生箇所とエラーの種類について詳細な情報を提供し、包括的なレポートを生成します。変更を適用してジョブを再実行すると、ジョブが正常に完了したことが確認できます。
私たちが実装した2つ目のイノベーションは、Sparkバージョンのアップグレードに関するものです。Sparkの各バージョンアップグレードでは、関数呼び出しやデータ型の扱い方（整数値か浮動小数点値を受け付けるかなど）において、APIに根本的な変更が加えられることがあります。通常、データエンジニアは最新バージョンにアップデートしてジョブを実行し、エラーを見つけて修正し、このプロセスを何度も繰り返してSparkをアップグレードします。ジョブが失敗するたびに、エラーを分析し、エラーコードを確認し、コードを変更して再試行する必要があります。
私たちはGen AIを活用してこのプロセスを自動化しました。ジョブがある場合、「AIによるアップグレード分析を実行」を選択し、アップグレードされたコードの保存先を指定できます。興味深いのは、結果のスクリプトを提供するだけでなく、すべての失敗したインスタンスも表示することです。システムはジョブを実行し、失敗の種類を理解し、コードを変更して再実行し、新しい失敗の種類を特定し、ジョブが正常に実行されるまでこのプロセスを継続します。
この機能は現在プレビュー版として利用可能で、AWS Glueインターフェースで確認できます。失敗したジョブがすべて表示され、これらはシステムが試行して失敗したすべての試みを示しており、失敗するたびに原因を学習してコードを修正していきました。最後に、コードの詳細を確認したい方のために、結果画面があり、そこで実際に変更前と変更後のバージョンの差分をダウンロードして結果を比較することができます。
Bridgewaterの概要とデータ処理の課題
ここで、Bridgewaterについて話をするCraigにバトンタッチします。私はBridgewaterのアーキテクトのCraig Sahaniです。これらのデータ処理ツールを使って私たちの課題をどのように解決しているかについてお話しします。多くの方がBridgewaterについてご存じないと思いますので、簡単に私たちの概要をご説明させていただきます。私たちはSystematic Global Macro Asset Managerですが、これは多くの専門用語が含まれているので、分解して説明しましょう。Asset Managerとして、私たちはクライアントの資金を運用し、投資目標を達成するために資産の売買を行います。Systematicとは、その方法を指しています - 世界経済を理解するためのモデルを構築し、そのモデルに基づいて資産の売買を決定しています。
グローバルマクロの側面は、私たちが購入する資産の種類を指しており、例を挙げると最も分かりやすいでしょう。例えば、米ドルがユーロに対して下がるか、米国株式市場が上がるか、あるいは日本の債券市場が下がるかといった予測に基づいて投資を行います。多くの資産運用会社では個人がこれらの判断を行っているのとは異なり、私たちはモデルを使用したシステムでこれらの判断を行っています。つまり、システムが複合的に意思決定を行っているのです。
モデルについて説明する際、2つの観点からお話しできます。 このシステムはAIを使用しているわけではありません。これは私たちの10年にわたる専門知識、そして40年にわたるビジネス構築と経済の仕組みの理解に基づいて構築されたシステムです。基本的には、因果関係、経済の動向、資産価格の変動要因を理解し、それに基づいて意思決定を行うことを目指しています。このシステムは専門家システムとして構築されており、時間的にも次元的にも普遍的です。現在の資産価格や経済状況だけでなく、歴史全体を振り返り、あらゆる経済状況でモデルが機能するように努めています。なぜなら、次にどのような状況が訪れるか分からないからです。
モデルの具体例として、インフレーションを見てみましょう。 ニュースでよく耳にするインフレーション - インフレ率が上昇している、Fedが特定のインフレ率を目標にしているといった話題です。多くの場合、インフレーションについて語られる際に実際に言及されているのは、Consumer Price Index（CPI）、つまり消費者物価指数です。これは米国政府が毎月発表している数値です。私たちは独自のCPIモデルを持ちたいと考えています。なぜなら、政府が発表する月次の数値だけに頼りたくないからです。どの国においても、インフレーションとは何かを包括的に見るモデルを持ちたいと考えています。インフレーションをさまざまなカテゴリーに分類し、総合的なヘッドラインインフレ、そしてコアとノンコアに分けています。コアには食品やエネルギーなど、人々が必需的に支出するものが含まれ、ノンコアにはより裁量的な項目が含まれます。これをさらに細分化し、あらゆるタイプのデータプロバイダーからのデータを活用して、人々がスーパーマーケットや給油所、電気料金などに支払う金額を集計しています。
そのデータを集約し、変換して、人々が実際に経験しているインフレーションが彼らの家計に与える実質的な影響についての見解を形成します。このようなモデルを多数継続的に実行しています。 実際、1,000以上のモデルを運用しており、これは年間約200万回のモデル実行に相当します。これにより膨大な量のデータが生成され、年間で3億のテーブルと19ペタバイトのデータを扱っています。システムがより多くのデータを分析できるようになるにつれて、成長は驚異的なものとなっています。過去6ヶ月間で、新しいモデルは約5%増加し、作成するテーブル数は30%増加、データ量は80%増加しており、この成長は鈍化する気配がありません。この成長はAWS上に構築したシステムによって実現されています。
これらのモデルは独立しているわけではなく、相互に接続されています。これは非常に重要です。なぜなら、これらのモデルが私たちの資産の売買を決定しているからです。モデルが正しいデータを生成していることを確認し、データが間違っている場合や異常が発生した場合を理解する必要があります。問題が発生した場合、その状況を詳しく調査して対応を決定する必要があります。例えば、米国のインフレ率が突然100%にジャンプした場合、データをロールバックするか、最新のデータではなく前日のデータを使用して取引を行うか、モデルのバグを修正するか、あるいはデータプロバイダーからの入力に関する問題に対処するかを判断する必要があります。
自動化できる部分もある程度ありますが、重要なのは人間が介在することです。つまり、毎日正確な最新情報を確実にタイムリーに提供することを担保するオペレーターの存在です。ポジションを適切なタイミングで取れないと市場での流動性を失いますし、米国のインフレ率が100%といった誤ったデータに基づいて取引を行えば、悪い取引になってしまいます。これらのオペレーターは単にボタンを押すだけの存在ではありません。彼らはモデルの仕組み、市場、経済データについて深い文脈を理解しています。オランダのGDPのような指標で異常な数値が出た場合、それが正当なものなのかエラーなのかを見分ける必要があります。
これらのオペレーターは各分野のエキスパートであり、彼らの時間は貴重です。そのため、効率的に作業できるようにツールを開発しています。データ間の関係性を理解するために、これらのテクノロジーの上に可視化ツールを構築しています。オペレーターは何か問題がありそうだという直感に従う必要があるため、それらの関係性を深く掘り下げてデータと対話できる必要があります。つまり、データをピボットしたり、掘り下げたり、根本原因を見つけて適切な判断を下すために、できる限り関係性を追跡できなければなりません。
インフレモデルに話を戻しましょう。これらのモデルが何を生成しているのか見ていきましょう。先ほど述べたように、私たちはデータテーブルを生成しており、このビューからモデルがトップレベルで何を生成するかがわかります。ただし、私たちは行う計算すべてについてこれを生成しています。これらのセル（すべての詳細やカラムを埋めていませんが）は単一の値ではなく、処理が必要な豊富な時系列データです。これらのテーブルは非常に大きくなります。特に、個々のセルに大量のデータがある場合はそうです。
このデータを処理して、ユーザーに適切な情報を届ける必要があります。行の間に関係性があることがわかります。この例では国によって次元が分かれていますが、ユーザーが望む任意の次元で分けることができます。モデルをより深く掘り下げると、その中にはおそらくさらに多くの次元性が隠されています。
Trinoを中心としたBridgewaterのデータ処理アーキテクチャ
また、Total CPIがCore CPIとNon-core CPIの集計であるという関係性も見て取れます。しかし、これは単なるデータテーブルになっているため、テーブル上では明示されていません。関係性を理解しようとしているオペレーターは、この場合のように明白とは限らない関係性を掘り下げて理解する必要があります。私たちのツールは、S3に保存されているORCファイルのこれらのデータテーブルを、時には自身と、時には他のテーブルと結合して、関係性を示す必要があります。これによってオペレーターはグリッドの診断方法を理解できるのです。
私たちは、日々生成しているデータテーブルに関する課題を抱えています。これらのテーブルはイミュータブルなので、毎日新しいテーブルのコピーが作成され、そのため大量のテーブルが存在することになります。このデータを分析し、ユーザーが素早く分析できるようにする必要があります。この問題を解決するには3つの基本的な要件があります：まず、コストの観点から、スケーラブルなインフラストラクチャが必要です。市場が開いていて経済活動が活発な営業時間中は負荷が急増し、経済イベント時にはさらにスパイクが発生します。
市場が大きく動く際には、データをできるだけ早く更新するためにより多くの処理を実行する必要があります。また、私たちが日々処理するデータ量は80%の割合で増加しており、そのデータは継続的に増え続けているため、スケールに対応できるインフラストラクチャが必要です。さらに、すべてのデータを詳細に処理することは不可能なので、データ処理を効率的に行う必要があります。
ユーザーの行動を予測して事前計算を行う必要があります。なぜなら、私たちが行っている処理の物理的な制約により、ユーザーが望む時間枠内で情報を返すことが不可能なケースがあるためです。これらのオペレーターは、モデルで何が起きているかを理解しようとする各分野のエキスパートであることを忘れないでください。彼らが情報を掘り下げようとしているときに処理が途切れることは許されません - クリックして1分待たなければならないような状況では、彼らの思考は別の方向に向かってしまいます。私たちは素早く反応する必要がありますが、無制限のコンピューティングリソースがあったとしても十分な速さで解決できない処理の問題があるのです。
これらの課題に対処するために使用しているテクノロジーの中で、Trinoは私たちの活動の中核となっています。多くの機能を実現する上で、本当に重要な役割を果たしています。SQLインターフェースを通じたリレーショナル代数は、ユーザー向けの可視化を生成するために使用しています。このデータを処理し、その上に機能を構築していくために、リレーショナル代数を使用していない世界から使用する世界へと移行することが私たちにとって重要でした。独自の制約を持つカスタムデータベースエンジンを構築するのではなく、Trinoのような基盤の上に構築できることは、非常に価値があります。
もう一つの重要な要素は、TrinoでのUDFの動作方式です。システムを構築する際、Athenaをそのまま使用するか、Trinoを使用するかなど、さまざまなシステムを検討しました。Trino内のUDF機能は重要なコンポーネントです。なぜなら、処理をデータにより近づけることができるからです。AthenaにもUDF機能はありますが、Lambdaを通じて実行する必要があります。そのため、大量のデータシリーズをLambda処理のためにネットワーク経由で転送する必要がありますが、UDFを使用すれば、必要なデータだけを選択できます。
処理を行うノードにデータを取り込み、効率的に操作を実行します。また、Trinoはスケーリングが可能です。Map-Reduceのパラダイムに従って、Map-Reduceジョブに基づいてスケーリングを設定できます。ワーカーノードとマスターノードをワークロードに応じてスケールできるほか、異なるタイプのワークロード向けにクラスターを設定することもできます。また、Predicateプッシュダウンなどの機能により、S3バケットから読み込む必要のないデータは選択しないなど、非常に効率的に動作します。この効率性がTrinoの重要な特徴の一つとなっています。
私たちはすでに、共通のエンジンを使って複数の可視化ツールを構築しています。これはデータにSQLインターフェースを持っているからこそ可能なことです。Amazon EMRと組み合わせてTrinoを使用していますが、EMRは私たちに柔軟性を提供してくれます。 私たちには様々なタイプのワークロードがあるため、異なる方法で設定された複数のクラスターを持っており、その設定は非常に簡単です。私たちは特定の技術のスペシャリストではなく、ジェネラリストが多い小規模なチームです。基本的な概念と設定に慣れている人なら誰でも、簡単にサービスの設定や構築、必要に応じたスケーリングを行うことができます。
見逃してはいけない重要な点として、アップグレードの容易さがあります。多くの組織と同様に、私たちも技術のアップグレードや最新ライブラリの維持に苦労していますが、TrinoとEMRのアップグレードは、私が経験した中で最も苦労の少ないものでした。あるTrinoのバージョンにバグがあり、アップグレードが必要になった時のことを覚えています。数スプリントかかり、問題が発生すると予想していましたが、チームにアップグレードの話を持ちかけたところ、次のスプリントで完了してしまいました。EMRが提供してくれるアップグレードの容易さと移行のスムーズさは、私たちにとって大きなメリットです。
AWS Glueは、これら全てを結びつける接着剤です - このダジャレは意図的です。私たちは複数のクラスターを実行し、多くの事前作業を行っているため、データカタログとしてGlueを使用しています。一度登録するだけで、これらのテーブルをカタログに登録でき、異なるワークロードで簡単に使用できるようになります。6ヶ月前にこの話をしていたら、おそらくGlueについては触れなかったでしょう。当時は、アーキテクチャの弱点だと考えていたからです。パフォーマンスの問題が発生しており、スケールの問題でGlueは機能しないと考え、カスタムソリューションに置き換える必要があると思っていました。当時はGlueに対して非常に悲観的でしたが、今では非常に楽観的です。
この6ヶ月間で、いくつかの重要な発見がありました。まず、私たちはGlueを間違った方法で使用していました。これは誰もが学ぶべき教訓です - 常に、技術自体の問題なのか、それとも使い方の問題なのかを自問する必要があります。私たちはAPIを意図されていない方法で使用しており、それがパフォーマンスの問題につながっていました。私たちは他のユーザーとは異なる使い方をしており、毎日何百万ものテーブルを追加し、削除しています。特に削除プロセスでGlueの限界に直面していました。自分たちの問題が分かってからは、アーキテクチャのこの部分についてあまり心配する必要がなくなりました。以前は、HiveメタデータカタログにはクロスAZの耐障害性がなかったため、独自のデータカタログソリューションを構築する必要があると考えていました。大規模なプロジェクトと、相当なエンジニアリングと管理の労力が必要になると思っていましたが、今ではそれを心配する必要がなくなりました - これは、特に差別化要因とならない技術について言える最高の評価です。
Bridgewaterのデータ処理システムの詳細と AWSの貢献
これまでの課題について説明してきましたが、ここでこのシステムのアーキテクチャがどのように組み合わさっているかについてお話ししたいと思います。 モデルが実行されると、データテーブルがORCファイルとしてAmazon S3バケットに書き込まれます。その後、モデルはWarming Serviceを呼び出して、可視化のために準備が必要な新しいテーブルが作成されたことを通知します。Warming ServiceはこれらのテーブルをAWS Glueに登録し、Trinoに実行を要求します。
考慮すべき重要なポイントの1つは、豊富なデータを含むセルを持つテーブルがあり、それらが非常に大きくなる可能性があることです。しかし、オペレーターは通常、可視化において今日の値と昨日の値を比較するなど、最新のデータポイントに注目します。そのため、私たちはテーブルを単一のスカラー値にスライスするクエリを実行することが多く、これによりユーザーが可視化にアクセスする際の効率が向上します。また、Warming Serviceはモデルによって検出される可能性のある異常を予測し、バックグラウンドクラスターで利用可能な計算能力を使用してそのデータを事前に処理し、Amazon ElastiCache for Redis OSSに保存します。
ユーザーが診断のためにこれらの可視化サービスにアクセスする際、Query Serviceと対話し、Trinoを通じて生のクエリを実行する代わりに、事前に計算された情報をRedisから素早く取得することができます。新しい予期せぬクエリについては、Query Serviceがその情報をビューに統合します。また、このサービスはユーザーが次に行う可能性の高い操作（ピボットやデータの変更など）を予測します。たとえ正確なビューがキャッシュされていなくても、すでにデータを効率的に操作できる形でスライスしているため、すぐに利用できる状態になっています。
また、私たちは大量のデータを生成し、年間何億ものテーブルを作成するため、AWS Glueカタログに保持し続けることが現実的ではなくなってきています。データは初期の比較期間を過ぎると即時的な有用性が急速に失われます。ユーザーが先月や昨年の履歴情報にアクセスする必要がある場合、テーブルの再登録やデータの再スライスが必要になるというトレードオフを受け入れています。なぜなら、これらのシナリオはアクティブな処理と同じような時間的制約がないからです。メタデータメンテナンスジョブは、AWS Glueカタログをクリーンに保ち、必要なデータのみを維持しながら、Amazon S3バケットもクリーンアップします。
最後に、AWSは私たちの成功に不可欠でした。小規模なチームで運営しており、多くの技術を自前で構築する必要がなかったからです。ビジネスの拡大と情報処理の効率化において、AWSは革新的な役割を果たしてきました。AWSは優れたパートナーとして、技術的な決定を導き、試すべきソリューションを提案し、彼らの技術を効果的に使用する方法を理解する手助けをしてくれました。特に、AWS Glueの制限への対応や、それらの制約の中でシステムを設計する際に大きな支援をしてくれました。本当に貴重なパートナーであり、彼らのサポートに感謝の意を表したいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion