re:Invent 2025: LSEGの1日274億メッセージ処理基盤のサーバーレス移行とコスト97%削減事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - LSEG: Transforming market intelligence at massive scale (IND3305)
この動画では、London Stock Exchange Group (LSEG)がAWSと協力して実現した市場データ処理の大規模変革について解説しています。LSEGは世界575の取引所から1日274億件のメッセージを処理し、75ペタバイトの履歴データと9000万以上の市場商品を扱っています。従来のオンプレミスインフラからサーバーレスアーキテクチャへ移行し、Matrix Signals Platformを構築しました。このプラットフォームはAmazon S3、AWS Glue、Amazon Athena、Amazon Bedrockを活用し、ゼロデータコピーで数兆のティックデータを数十億の最適化されたデータポイントに変換します。結果として、インフラコストを5分の1に削減し、シグナル検出時間を3日から30-45分に短縮、ストレージコストを97%削減しました。さらにAmazon Bedrockを使用してReutersニュースと市場変動を相関させ、Gen AIによる市場インサイトを提供しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション概要：LSEG の大規模市場インテリジェンス変革への旅
皆さん、こんにちは。私はロヒット・シンです。Financial Services AWS のプリンシパル・ソリューション・アーキテクトをしています。本日は Jason West、Group Director Real Time、そして Ed Johnson、Real-time architect とご一緒できて光栄です。LSEG の変革の旅、彼らがいかに大規模で市場インテリジェンスを進化させているかについてお話しします。大規模というのは、本当に大きな数字を扱っているということです。
アジェンダは、まず資本市場エコシステムの概要から始まります。それが直面している課題、常に稼働しているシステム、そして間もなく 24/7 で稼働する取引所が出てくることで、生成される市場データの量をさらに探っていきます。
その後、Jason がステージに上がり、LSEG と AWS のパートナーシップの旅、主要なビジネス・ドライバー、戦略的な決定、そして AWS と協力して達成した素晴らしい成果についてお話しします。その後、Ed がステージに上がり、Matrix Signals Platform について深く掘り下げます。これは大規模な洗練された市場インテリジェンスを実現する技術的なバックボーンです。最後に、主要な成果と重要なポイント、皆さんの組織内で適用できることをまとめます。これは本当にエキサイティングな大規模イノベーションの旅になります。
このセッションの終わりには、LSEG がいかに大規模に動作するサーバーレス・ソリューションを設計したかを学ぶことができます。本当に大きな数字の話をしています。274 億のメッセージが処理され、グローバルに配信されています。75 テラバイトの履歴ティック・データがあります。そして 9,000 万以上の市場商品があります。このセッションの焦点は Matrix Signals Platform です。Ed は LSEG がいかに極端なスケールで動作するサーバーレス・ソリューションを設計したかを説明します。従来のインフラストラクチャの頭痛の種はもうありません。スケーリングの管理はもう必要ありません。
資本市場エコシステムの複雑性と課題：数兆ドル規模のデータ処理
このソリューションはシームレスにスケールし、インフラストラクチャのコストを最大 5 倍削減しています。市場環境が変わるにつれて、今見ているように、柔軟性も提供するソリューションです。そして Amazon Bedrock を使用した Gen AI を活用して市場インサイトを提供しています。私たちは数百の取引所を扱っており、 それぞれが 24 時間体制で膨大な量のデータを生成しています。そして London Stock Exchange Group のようなアグリゲーターがいます。彼らは、このすべてのデータを取得し、処理し、世界中に配信するという困難なタスクを担っています。
そして、銀行やヘッジファンドなどの消費者がいます。彼らはこのデータを取引の決定を下すために必要とします。
スケールについて考えてみてください。575 の異なるソースがあり、それぞれが独自のフォーマット、プロトコル、タイミング要件を持っています。全体的には、これは毎日数兆ドルの市場取引を表しています。システムがスムーズに稼働すると、グローバル市場は効率的に機能します。データの遅延や問題は、数百万ドル相当の機会喪失につながる可能性があります。ですから、ステークスは本当に高く、 パフォーマンス要件は非常に厳しいものです。各レイヤーは独自の課題セットを表しています。
プロデューサーは、地理的な制約と規制要件、特に地域全体での要件を管理しながら、超低レイテンシーと高スループットが必要です。
それでは、LSEG のようなアグリゲーターについて見てみましょう。彼らはこのような多様なデータをすべて収集し、処理し、正規化し、それを世界中のクライアントに配信する必要があります。クライアントはそれを重要な取引判断を下すために利用しています。 コンシューマーは安全なアクセスと、ペタバイト規模でのデータ処理・分析能力を必要としており、それらすべてをコスト効率的に提供される必要があります。さらに、市場環境は常に変わる可能性があるため、より高い柔軟性が求められています。この課題は、市場データの量が年々増加し、従来のインフラストラクチャがそれに対応できなくなっているため、ますます深刻になっています。
市場データプロデューサーが直面する課題をさらに掘り下げると、複雑性は急速に増加し、課題は指数関数的に増加します。 彼らは市場のボラティリティに対処する必要があり、特に大きな市場イベント時には市場データの量が 10 倍から 50 倍に急増する可能性があります。
すべてのデータは、コスト効率的かつ確実にすべてのクライアントに配信される必要があります。S3 や Private Link といった AWS サービスがこれをサポートできます。S3 はペタバイト規模のストレージを提供し、 他の AWS サービスとの統合により、データが S3 上にある状態でアナリティクスを実行できます。Private Link は、世界中のどこからでもクライアントに対して高性能でセキュアな接続を提供します。資本市場エコシステムの信じられないほどの複雑性について概要を説明したので、ここで Jason に、この変革を促した主要なビジネス課題と、LSEG が AWS をテクノロジーパートナーとして選んだ理由について説明してもらいます。Jason が提供するビジネスコンテキストは非常に重要です。なぜなら、これはテクノロジーの現代化についてではなく、新しいビジネス機能の提供、クライアント体験の向上、そして市場アグリゲーション・配信ビジネスにおける LSEG のリーダーシップの継続的な強化についてだからです。Jason、よろしくお願いします。
London Stock Exchange Group の全体像：300年のイノベーションの歴史
ありがとうございます、Rohit。Jason West です。私は London Stock Exchange Group のリアルタイムビジネスを担当しています。ご存知ない方もいるかもしれませんが、私たちは世界有数のグローバル金融市場インフラストラクチャ企業の一つで、世界中 170 カ国の 440 万クライアントにデータを配信しています。 世界中に 26,000 人の従業員がおり、300 年のイノベーションの歴史があります。私たちの最高のイノベーションは 1850 年で、その時は London Stock Exchange から伝書鳩で最初のメッセージを送りました。今は Gen AI とクールなものに注力しており、クライアントが進化し、テクノロジーパートナーが進化するのと同じように、私たちも進化しています。
これが今日の London Stock Exchange Group の構成です。 複数の部門があります。左上から始めると、LSEG Data & Analytics があり、ここが私の部門で、リアルタイムビジネスが位置しています。その右側には LSEG FX があり、FX マーケットと取引をブローカーに直接提供し、また Workspace プラットフォーム経由で提供しています。その次が Post-trade で、これはクリアリングと取引クリアリングに関するものです。Risk Intelligence は私たちを安全に保ち、クライアントが適切な規制枠組みの中で良質なデータを使って業務を行えるようにしています。FTSE Russell ビジネスはインデックスに関するもので、世界中で非常に大きく、よくサポートされているビジネスで、今日は 44,000 クライアントを抱えています。そして最終的に、私たちは株式取引所でもあり、データ取り込みと執行から取引入力とクリアリングまで、すべてをカバーしています。
リアルタイムビジネスの規模：1日2,740億メッセージと75ペタバイトのデータ
リアルタイムビジネスの数字に掘り下げてみると、私たちは今日170カ国に展開しています。世界中で1日に2,740億件のメッセージを送信しており、世界中の575の会場と取引所から取り込んでいます。クラウドベースのものもあれば、従来の会場や取引所もあります。そのデータを4ミリ秒で取り込んで、正規化してネットワークに乗せることで、ストライク価格、高値、安値、どの会場のものであっても、クライアント向けにまったく同じ場所に配置できるようにしています。1996年以来、私たちはすべての会場からのすべての取引とすべてのティックを保存してきました。それをやっている唯一の企業であり、現在それは75ペタバイトに達しています。数年前、このデータはクラウドでホストされる必要があるという決定を下したので、そのデータは現在AWS上の私たちの敷地外に置かれており、毎日5～10テラバイトのデータを書き込んでいるため、それを成長させるための柔軟性が必要です。
Rohitが言及したように、これらすべての会場からの900万以上の単一商品が毎日世界中で送信されています。私たちはData & Analyticsの一部として、世界中で150～200の新しい会場を導入または更新しています。世界中に34の収集・配信ポイント・オブ・プレゼンスがあり、そこで会場や取引所からデータを収集して、正規化してからネットワークに配信しています。ここ数年、現代の金融市場の前例のない規模に関して、かなり大きなトレンドが見られています。COVIDはその一つで、市場はある程度横ばいになりました。ウクライナとロシアの紛争では、データレートが40パーセント増加し、それは下がらず、今も続いています。
米国の法律と関税戦争を見ると、それは私たちのバックボーン上で1秒あたりほぼ2,000万件のメッセージまで押し上げました。私たちはそれに対する容量を持っており、データを収集・配信する環境内で20～25パーセントのスケールを持っています。しかしこれはますます大きくなっています。私たちは常にTick HistoryストアとPAPストアにアクセスしており、さらにこれらのメッセージを低レイテンシー、高スループット、ジッターなし、そして時間通りに配信して、クライアントの周りの世界に送る必要があります。私たちはこれをやることに頼られています。より多くの会場がオンラインになり、より多くのクライアントがGenAIのデータサイエンティストやデータエンジニアと協力してこのデータを分析・抽出し、アルファを見つけようとしたり、より賢く取引しようとしたり、市場で他の人より先に行こうとしたりするにつれて、これが成長することを予想しています。
そこで私たちはこれに対処するための計画を立てる必要がありました。私たちはコアネットワーク、インフラストラクチャ、バックボーンをスケールしており、さらにこのすべてのデータを保存しています。私たちがそれを保存する理由は、クライアントがそれを望まないからです。今日のインフラストラクチャコストを見ると、このゲームに関わっている人たちは、この問題に対して馬力を投じたくありません。上下両方でスケールで実行する必要があります。
ビジネス上の課題：レガシーインフラからの脱却と変革の必要性
ビジネス上の課題に対処する場合、レガシーなオンプレミスインフラストラクチャはほとんどの人にとって問題です。広告が出ているときに3～5年ごとにそれを交換するか、データセンターにさらに多くを送り込む必要があり、コロケーションがより多くのお金がかかっています。LSEGでは、歴史的データを移動してその環境をシャットダウンするという決定を下しました。これは私たちにとって素晴らしいことです。これにより、私たちはCapExモデルからOpExモデルに移行し、メンテナンスが容易になります。
データの指数関数的な成長は、私たちが毎日目にしているものです。ただ増え続けているだけで、どこまで行くのか分かりません。現在、1秒あたり2000万メッセージに達していると予測していますが、2029年までには1日あたり5000万メッセージになると予想しています。これは対処するのが大変なケースになるでしょう。リアルタイムインサイトに対する顧客需要も別の課題です。前の職では、Tier 1の投資銀行で働いていました。FXデスクのヘッドが私のところに来て、「このベニューに参入したい」と言ったんです。私は「いいですね、9ヶ月で50万ドルくれたら作ります」と答えました。でも今の時代、それでは十分ではありません。クライアント、パートナー、デスクをできるだけ早く市場に投入できる必要があります。
競争市場でのコスト圧力は大きいです。みんなマージンを見ています。正直に言うと、私たちのデータは世界で最高のデータだと思いますが、競争上の課題もあります。ですから、自分たちにとってもクライアントにとってもコスト効率的にする必要があります。また、イノベーションの速度も必要です。私たちの開発者は昼間にコードを書いて実行し、1日に5～10回リリースしています。それらが市場に対して正しいものであることを確認する必要があります。
変革の過程では、まず履歴データの移行から始めました。Tick History PCA は元々、すべてのデータを CSV ファイルとして保存していました。膨大な量のデータです。それを Parquet フォーマットに変更しました。これはデータの問い合わせがしやすく、保存容量も大幅に削減でき、コスト削減につながり、クライアントがそのデータにより早くアクセスできるようになります。リアルタイムプラットフォームの開発は重要です。世界中の34の拠点で、市場が動くときにスケールできる必要があります。そして実際にスケールしています。20～25%のヘッドルームを持つ非常に優れた容量予測チームがあります。しかし、現在リアルタイムを担当している私でも、次世代を見据えて、必要に応じて30%、40%、50%スケールできるようにする方法を考える必要があります。
また、Matrix Signals Platform と大規模 ETL にも取り組んでいます。これについては、Ed がすぐに説明します。
クラウドネイティブデータフィードとビジネス成果：地理的拡大と迅速なオンボーディング
レイテンシスペクトラム全体にわたるクラウドネイティブデータフィードを見ると、LSEG が提供するデータルームフィードはビジネスに対して、超低レイテンシからクアント向けデータソリューション、価格データと参照データセットまで、フロントからバックまで提供しています。このサイドに履歴データがあり、このサイドに低レイテンシがあります。下部に見えるように、これらは私たちが市場に成長していく中で、移行を促進するために今日使用している AWS 製品の一部です。
ビジネスの成果という観点では、地理的な拡大というのは私たちにとって非常に重要です。クライアントは私たちがどこにいても対応してくれることを期待しています。今、私たちが取り組んでいるのは、世界中の様々な国、特に規制が厳しい国でのサービス提供です。そうした国ではデータがその国内に存在し、その国内で運用される必要があります。
私たちは規制当局、中央銀行、クラウドプロバイダーを含む複数のパートナーと協力しています。迅速なオンボーディングは私たちの主な利点の一つです。私たちの製品の中には、クライアントのオンボーディングに数週間かかっていたものもあります。しかし今では、AWS から提供される私たちのリアルタイム最適化製品を使えば、メール一つでクライアントを 2 分で稼働させることができます。このプロダクトは 1 秒間に 3 回のアップデートを行います。Trade Safe はもう一つの機能です。低レイテンシートレーディングを使用している人たちは必ずしもこれを使いませんが、ウェルスファンドやヘッジファンドはこのようなタイプのデータを喜んで使用しています。
オンデマンドの容量スケーリングは私たちにとって重要です。今年 4 月に市場が変動した時、多くのクライアントから電話をもらいました。「このデータを統合してもらえませんか？私たちのアプリケーションが悲鳴を上げています。対応できません」と。そこで、各クライアントの配信 POP 内で、アップデートレートをフルティックから 1 秒間に 4 回、5 回程度に削減しました。市場が安定したら、フルティックに戻しました。これにより、パブリッククラウドとプライベートクラウドの両方でそのような対応ができる能力を得ることができます。
加速されたイノベーションサイクルも同様に不可欠です。私たちは皆、GenAI の流行、より高速なチップ、Nvidia などを目にしています。誰もが市場に素早く参入し、データを使ってより賢いことをしようとしています。私たちも同様に賢くなる必要があります。クライアントが必要なことを実現するのを支援するためです。ですから、私たちは技術チーム、アーキテクト、開発者と一緒に、市場の先を行くために絶え間なく取り組んでいます。
LSEG Real-Time Platform の技術的基盤：9,000万のデータストリーム
では、メインイベントとして、私たちの real-time アーキテクトの一人である Ed Johnson にバトンを渡したいと思います。ありがとうございます、Jason。私は Ed です。Real-time アーキテクトをしています。本日は、アーキテクチャの観点から、そして私たちが直面してきた技術的な教訓から、real-time Matrix Signals Platform について、皆さんに詳しく説明していきたいと思います。これが他の人たちにも教訓を与え、私たちのデータを大規模に活用するのに役立つことを期待しています。
まず最初に、Matrix Signals環境の詳細に入る前に、技術的な観点からLSEGのリアルタイムプラットフォームが何であるかについて、少し理解しておくと役に立ちます。部屋の中には市場データの専門家ではない方もいると思いますが、LSEG Real-Timeは、世界中に分散した、ステートフルな、先入先出のメッセージバスです。
このメッセージバスは、単一のデータストリームだけでなく、世界中で送信するあらゆる市場商品にまたがっています。それは単一のストリームではなく、9000万のストリームです。スライドにはその例が示されています。NvidiaのRIC、つまりReuters Instrument Codeが見えますが、ご存知の通り、これは米国市場で最も流動性が高く、最も取引されている商品の一つです。これが私たちのデータストリームの一つを表しています。しかし私たちは、先入先出の低レイテンシーキューを持っており、それはコレクション施設から私たちのコアインフラストラクチャを通じて、配信拠点を経由して顧客に、可能な限り最速の方法でそのデータを配信しています。
このサービスの一部として、私たちはまた、ストリーム内に付加価値分析データを追加して、そのデータを顧客にネイティブに利用可能にしています。また、そのデータを正規化しているので、世界のどの会場がそのプライスを提供しているかに関わらず、それをLSEG形式に変換し、その後は世界中のどこからそのデータを受け取っているかに関わらず、同じAPIと同じデータ構造になります。今日の私たちの課題であり、深く掘り下げようとしていることは、これら9000万のストリームがどのように重なり合うかを理解し、規模でホットスポットを検出し、インフラストラクチャ内のどこで重なり合うかを把握し、市場でそれに対応することをより速く、より最適化された方法で行うことができるようにすることです。
この変革の一部として、市場でこれらのシグナルを検出する所有コストを5倍以上削減することも実現しました。みんなのための簡単な類似例です。技術的な領域から抜け出すために。LSEG real timeと私たちのフィードをデータの川だと考えると、かなり単純です。各ストリームはその川の中に位置しています。世界中の575の証券取引所、取引会場、その他の貢献者は、ほぼ支流のようにデータの川に流れ込みます。私たちの顧客は銀行のそばに座って、流れてくるストリームを観察しています。
川の下流にあり、Jasonが先ほど言及したように、基本的には私たちのTick Historyプロダクトである湖のようなものがあり、それは1996年までさかのぼるデータストリームのキャプチャ版を提供し、S3に75ペタバイト以上のデータがあります。
このデータは Parquet フォーマットで保存されているんですが、これは皆さんの中には役に立つかもしれませんね。この類似表現については、これからの議論の中でまた戻ってくることになります。LSEG Real-Time は川で、私たちの Tick History プロダクトはその先にある湖というわけです。先ほど述べたように、このインフラストラクチャは世界中に分散しています。
グローバルインフラストラクチャとホットスポット検出の重要性
こちらは私たちのコレクション、コア、そしてディストリビューション インフラストラクチャの概要です。LSEG のプライベート クラウド環境（世界中のデータセンターに配置されています）と、AWS のディストリビューション ロケーションの両方があり、そこからリアルタイム最適化プロダクトを提供しています。私たちのグローバル インフラストラクチャは多くのサイトにまたがっており、すべてが私たちの世界トップクラスのソフトウェア定義ネットワークで接続されています。このコレクションとディストリビューション インフラストラクチャは、ほぼあらゆるソースからほぼあらゆる宛先へコンテンツを提供します。米国からアジアへ、またはその逆でデータを消費することができるんです。
この環境全体でシグナルやホットスポット、インサイトを検出するために使用していたグローバル ハードウェア フットプリントがありました。それにより、市場のボラティリティに対応することができていたんです。キャパシティ管理やその他のホットスポット検出用に設計されたこのシグナル検出インフラストラクチャのコストが膨らんでいて、Jason が先ほど話していた市場のデータレート増加に伴い、増加し続けています。私たちはそのソリューションを将来に対応させ、より最新のツーリングを活用し、その過程でプロダクト オファリングを変革する方法を見つける必要がありました。
このホットスポット検出は、私たちの組織にとって非常に重要です。低レイテンシー、低ジッターで、正確でタイムリーな方法でデータを配信することが私たちのビジネスなんです。それが私たちがやることです。問題になる前にそれを検出することは本当に重要なんです。先ほど説明したデータ ストリームに戻ると、問題ステートメントを少し整理して、その後アーキテクチャについて深掘りするのに役立ちます。
まず、キャパシティ管理のための予測と最適化を行います。つまり、ホットスポットを検出して、このインフラストラクチャのコンポーネント、つまりこの環境のインフラストラクチャがより多くのデータストリームを受け取っている場所でパフォーマンス最適化を実装することです。インフラストラクチャの各部分がそのいくつかを処理しているので、その中でホットスポットがどこにあるのかを把握することは非常に重要です。
Matrix Signals Platform のアーキテクチャ：数兆のティックから数十億のインサイトへ
インフラストラクチャのコストが増加していくのを抑制したいというのが我々の狙いでした。オンプレミスのパケットキャプチャベースの信号検出システムの所有コストを削減することが、その一環として重要な成果物でした。また、運用チームとリーダーシップが意思決定を下すスピードを加速させたいという要望もありました。市場が非常に急速にスケールしていく中で、我々の信号検出環境は信号の応答という点で遅れを取っていたため、それを高速化し、運用チームとリーダーシップチームに対して洞察を提供する方法が必要でした。これにより、市場が極度に変動する局面での対応をより迅速に行えるようになります。
では、そのストリームの一つ、ここでは Nvidia を例に挙げていますが、これは先ほどから続いている例です。ここに、実際のデータがどのような形をしているのか、我々の正規化されたデータフォーマットの例が示されています。ご覧の通り、画面には7つのメッセージが例として表示されていますが、これらは業界用語で「ティック」と呼ぶものです。ここの各ティックには株価の更新が含まれています。これが基本的にデータが示しているものです。ご覧の通り、トレードもあります。つまり、トレード価格とボリュームもこのデータストリームの一部として送信されます。
これはこの銘柄に対して1秒間のデータに過ぎず、これはあくまでモックアップの例です。我々の環境には多くの銘柄があり、1秒間に10,000回以上のティックを送信する可能性があります。これを我々が保有する9,000万の銘柄全体にスケールさせると、スケールの問題がどこにあるのか、そしてこの環境を非常にパフォーマントで最適化された状態に保つために我々がどれだけの作業をしなければならないのかが、すぐに見えてきます。
画面に表示されているデータに加えて、付加価値データと分析も含まれており、これらはフィードと一緒にパッケージ化されます。そして、先ほど述べたように、取引会場がどこであれ、すべて同じフォーマットで格納されています。マーケットデータの観点から注意すべき点は、このデータは順序が正しい場合にのみ意味があるということです。つまり、正しい順序で到着する必要があります。そうでなければ、株価が間違ってしまいます。データが正しい方法で到着することを確認する必要があります。これが FIFO（先入先出）の考え方が出てきた理由です。
アーキテクチャについて詳しく説明させていただきます。ご覧いただいているのは、LSEG Real-Time Collections のコアと 配信インフラストラクチャで、これが完全なティックデータ用の低レイテンシーなオンプレミス環境を構成しています。LSEG Tick History プロダクトは Amazon S3 でホストされており、75 ペタバイトのデータを保有しています。このアーキテクチャの一部として行っている変更は、LSEG リアルタイムフィードで見えるデータを、Tick History で保有しているインサイトに変換し、その後クラウド環境の Tick History 最適化データセットで分析を実行するというものです。その後、そのデータをオンプレミス環境全体とグローバル配信インフラストラクチャに反映させて、ホットスポットに素早く対応します。
このソリューションは Tick History からデータキャプチャを取得し、そのデータを高度に最適化されたタイムシリーズ形式に集約します。その後、環境内のホットスポットを検出するために必要なパラメータとインサイトを抽出します。このプロジェクトは Glue コンポーネントと OpenSearch コンポーネントなしで開始し、このビルドの一部として何を達成できるかを実証しました。Amazon Athena でデータを確認する必要があり、これを最初のベースとして選択しました。なぜなら、Tick History データセット内に存在するデータを Parquet でネイティブに検査でき、完全にゼロコピーで実行できる、非常に低コストで軽量なソリューションだからです。
このアプローチを実行に移し、このデータセット内にインサイトが存在すること、そして信号を環境に素早く反映させることができることを実証することは、非常に価値がありました。インフラストラクチャのデプロイメントなしで、数ヶ月間のプルーフオブコンセプトとしてそれを実現しました。Athena を使用したプルーフオブコンセプトから、その上に Glue レイヤーを追加しました。この Glue ETL レイヤーは、非常に最適化された事前集約ステップで、S3 バケット内のティックバイティック表示の背後にある、導出可能なすべてのタイムシリーズと、その他のパラメータおよび参照情報を生成します。
その後、Amazon OpenSearch パイプラインの一部としてそのデータをインデックス化し、埋め込みます。これにより、内部ユースケースと組織の他の部分で利用可能になります。これらはすべて、Lambda 関数、Event Bridge、およびこの部屋の多くの方々が馴染みのあるその他のコンポーネントの一連で結び付けられています。ここからの信号は環境に戻され、ホットスポットに素早く対応するために使用されます。
ティックバイティックデータは Amazon S3 の LSEG Tick History プロダクトセット内に存在します。Amazon S3 アクセスポイントでネイティブにそのデータをクエリしているため、データをコピーする必要がありません。これは内部でのみ行うものではありません。Tick History の S3 Direct プロダクトを通じて、S3 アクセスポイント経由でゼロコピー方式でこのデータを提供しています。
私たちはティック・バイ・ティックのビューを取得して、その後、最適化されたタイムシリーズ版のデータを生成しています。環境内の各インストルメントは、1秒のタイムシリーズに集約され、すべての市場インストルメント全体で100ミリ秒のバースト検出が行われています。私たちはそのデータセットに事前集約を行っています。そこからは、Amazon Bedrock と Athena を使用した柔軟なモデリングレイヤーを利用できます。これはマルチテナント対応なので、その最適化されたデータセット内の数十億のデータポイントを、エンドクエリレイヤーで非常に柔軟にモデル化できるインサイトとシグナルに変換することができます。
例を挙げると、上部に7つのティックがモックアップされています。これらの7つのティックは、その秒の総メッセージパラメータにフィードされ、その後、例えばアジアのこの地域で消費されている上位のインストルメントを見つけるというモデルの一部として、インストルメントランクを計算する可能性があります。 ここからは、このアーキテクチャの3つの特定の側面を詳しく説明していきます。これらは、いくつかの教訓を提供することを期待しています。最初の側面は、数兆のティック（Tick History データセットのティック・バイ・ティックストアを参照）を数十億の最適化されたデータポイントに変換することです。私たちは S3 アクセスポイントと Glue サービスを使用してこれを行っています。これはゼロコピーであり、Glue を少し後で導入した理由は、ETL フェーズをパフォーマンスチューニングするためのダイヤルがより多くあり、最大の価値を得られるようにするためです。
サーバーレスソリューションの成果：コスト削減とシグナル検出の高速化
AWS Glue で柔軟なスケーリングが可能なので、週末か昼間か、US マーケットオープンのような市場が活発な時間かによって、スケールアップとスケールダウンを行います。これにより、コスト最適化に役立ちます。また、この段階で参照情報や他のパラメータとこの情報を結合しており、これは環境の他の部分に対するサポートと集約を支援するのに役立ちます。この一環として、私たちはゼロストレージコストの所有権を実現しました。なぜなら、ソリューションの一部としてストレージコストを維持する必要がなくなったからです。
2番目の側面は、これらの数十億の最適化されたデータポイントから、私たちがデータに対して質問したい質問に応答する非常に具体的なシグナルを作成することです。私たちは、最初の概念実証の一部として見られた柔軟なバックボーンを保持しました。なぜなら、このデータセットに対して質問したい質問のセットが事前にはわかっていなかったからです。これは、ソリューションを将来に対応させ、今日知っている使用例だけでなく、将来の使用例にも対応できるようにするための素晴らしい方法です。
Athena レイヤーは、新しいデータが利用可能になったときを自動的に検出し、そのすべてのモデルを新しいデータセットに対して実行します。この集約レイヤーを使用して、データに対してあらゆる質問をすることができます。いくつかの例としては、US リージョンのマーケットオープン時のすべての100ミリ秒のホットスポットを特定すること、今日の最も流動性の高いインストルメントを昨日と比較して見つけること、または私たちのティア1銀行顧客の特定のインストルメントウォッチリストのコンピュート要件とパフォーマンス要件を分析することが含まれます。
このアーキテクチャは Athena SQL クエリで構成されていますが、これらはすべてマルチテナント方式で、この容量とホットスポット検出データのエンドユーザーによって所有されています。個々のユースケースごとに非常に特定のパイプラインを構築しているわけではありません。これにより、非常に低いコストを維持でき、この環境に対して料金を支払う必要もありません。
3番目の側面は、Athena に関連付けられているのを見たことがないかもしれません。Athena の出力を Parquet 形式で取得して、それを直ちに OpenSearch に自動インデックスしています。これは2つの非常に具体的な理由で有益です。そのデータへの API ベースのアクセスを提供でき、非常に特定の方法で集約してから、ユースケースに関係なくそのデータをネイティブに API として提供できるということです。データをインデックスして、素早いインサイトを提供し、API 経由でそれを提供できます。
さらに、Amazon Bedrock でそのデータをナレッジベースのユースケースで利用可能にしているため、データの埋め込み結果を取得してホットスポットを検出できるだけでなく、それらのホットスポットを GenAI ネイティブな方法で相関させることができ、Bedrock で利用可能なテクノロジーに対して将来性があります。あらゆるユースケースでこれを利用可能にすることで、組織全体の容量に関するデータセットを改善しました。現在は API ベースの統合または GenAI ベースの統合であり、これらのホットスポットと変動性検出をファーム内のより広い範囲のユーザーに提供できるようになりました。これにより、FinOps を実行したり、他のことも実行したりできるようになります。
最後の説明として、最初のスライドで見た変動性に関することですが、市場の予期しないニュースは私たちにとって変動性を引き起こします。それが見られるとき、その変動性情報を、Reuters から金融サービス顧客に提供する市場をリードするニュースと相関させる素早く簡単な方法があることは非常に価値があります。このソリューションの一部として、ニュース相関レイヤーを追加しました。ホットスポットがあったというだけでなく、ホットスポットがなぜ発生したのかを説明することもできます。これは GenAI タイプの要約と RAG の観点からのみ利用可能なものです。
最後に、マルチテナンシーとこれをスケールで実行できることについてですが、Athena でこれをどのように実行しているのか疑問に思うかもしれません。非常に簡単です。Fargate を通してそれを実行し、認証された API を組織内の異なるユーザーに安全で構造化された方法で利用可能にしています。これは私たちがその部分でも役に立ちます。
シグナル検出をエンドツーエンドで見ていきましょう。ティックバイティックのデータがあり、最終的には AWS Glue のサーバーレス集約ジョブに入ります 。事前に集約されたデータがあり、すべてのマーケット商品に対してそのデータから検出したり、あらゆる質問をしたりできるようになっています。例えば、ある商品では 1 秒間に 5,000 件のメッセージが発生する可能性があります。
そのうち 4,000 件は、その 1 秒間の中で 100 ミリ秒のバースト内に発生します。Glue サーバーからこのジョブは、Amazon Athena SQL アプローチの一部として、ホットスポット検出モデルを自動実行します。データフローの異常なバーストを検出し、この場合は利用可能な総量に対して有意なバーストメッセージの割合がある場所、つまりホットスポットを探しています。
そこから、すべての出力を自動インデックス化します。すべてのホットスポットを見つけて、その後 すべてのホットスポットを自動インデックス化して、API 経由でバーストベースのモニタリングをトリガーします。これは新しいデータに対する非常に迅速な検出モデルであり、その後の自動インデックス化も簡単です。そのインデックス化は API ベースのビューを通じて利用可能になり、その後、インフラストラクチャアクション、特定のモニタリングアクション、またはその環境の一部としてのバースト修復を実行するために使用します。
エンドツーエンドで、ティックバイティックビューからこのデータを集約し、本当に効率的で非常にコスト効果的な方法で、環境内のデータをコピーすることなく実現できます。私たちはこれを、環境内のすべての 9,000 万の商品に対応するスケールで行っており、これは個別に各商品に対してこの質問をしていたら、過去には決してできなかったことです。
エンドツーエンドのアーキテクチャに戻ると、ティックバイティックデータ を取得して、Glue でそのデータを集約および分析する機能があります。そのためのコストはありますが、管理されています。その後、柔軟なクエリレイヤーとして Amazon Athena を通じてそのデータをモデル化し、その後、Amazon Bedrock と Fargate の配信メカニズムの一部としてインデックス化して埋め込みます。
このプロジェクトの目的は、リアルタイムのパターン検出と 異常検知を大規模に実現することです。S3 バケットでデータが利用可能になったらすぐに、これを実行しています。ここで言う規模というのは、数兆件のメッセージから重要な洞察を得るということです。ストレージの観点から、インフラストラクチャコストの観点から、そしてシグナルまでの時間という観点から、これらについて少し詳しく説明していきたいと思います。
これまで、このシグナル環境全体でパケットキャプチャのためにオンプレミスのハードウェアを保守していたのですが、これは保守とサポートに非常にコストがかかっていました。S3 に既に存在するデータを活用することで、ストレージコストを基本的にほぼゼロまで削減することができました。つまり、97% のコスト削減です。インフラストラクチャのコストも削減されており、スケーラブルな Glue ジョブと AWS 環境に存在するエンタープライズ機能を使用することで、インフラストラクチャコストも約 82% 削減することができました。
それに加えて、シグナルまでの時間を、最悪の場合で特定のデータポイントを探している場合の 3 日間から、30 分から 45 分のウィンドウまで短縮することができました。これは、顧客のホットスポットにどれだけ迅速に対応できるかという観点から、完全に革新的です。これはすべてサーバーレスアーキテクチャなので、OS イメージの保守やパッチ適用など、運用上コストがかかるようなことをする必要がありません。
運用コストの観点から、そしてクラウドデータアプローチを活用することで、運用経費も完全に削減することができました。2030 年までに市場のメッセージ数が 1 秒あたり 5,000 万件に近づくにつれて、これがスケールできるという点で、私たちは非常に楽観的です。
変革の成果と今後の展望：Gen AI を活用した次世代金融ソリューション
この AWS テクノロジーにより、キャパシティ管理だけでなく、より広い範囲の組織的な課題に対応することができるようになりました。 既存のアプローチに投資することで、キャパシティ管理に対応することはできたはずです。しかし、この場合に私たちが実際に行ったのは、アーキテクチャを変更し、サーバーレスツールを使用することで、多くの追加的なメリットを得たということです。過去 10 年間のビッグデータ分野で起こった多くのイノベーションを活用することができるようになりました。これらは以前は低レイテンシープラットフォームの観点から私たちがアクセスできなかったものです。
キャパシティ管理は改善されているんですが、他にも色々できるようになったことについて、具体的に触れていきたいと思います。先ほど言及したように、Bedrockを活用してホットスポット検出を強化していて、Reuters のニュースデータから市場ニュースと洞察を取り込んでいます。
データへのオープンな API ベースのアクセスを確保することで、特定のドメインエキスパートがキャパシティとホットスポット検出情報を独占することがないようにしています。組織全体でそれをオープンにして、環境全体のホットスポットに対応するための様々なユースケースを実現しています。初めて一貫性を持ってエンドツーエンドのデータパスをプロット化することができました。これが難しかった理由は、9000万個の異なるデータストリームを扱っているからです。それらがどこから流れてきているのかを把握することは、私たちにとって非常に大きなビッグデータの問題なんです。そのパスをトップからボトムまでプロット化できるようになったことは、本当に役に立っています。そして初めて、すべての市場商品にわたってそれができるようになりました。
FinTechs が市場データを消費者に提供できるようにすることは本当に重要です。最大のインフラを最もボラティリティが高い場所に配置することで環境をより最適化する方法を見つけることは、非常に価値があります。新規顧客のオンボーディング時間を短縮することができました。これは私たちのプロダクト体験の一部として本当に重要です。なぜなら、より正確で、より的を絞った帯域幅、キャパシティ要件、そして最後のマイルの接続性の見積もりを、数分で提供できるようになったからです。以前は古いシグナルシステムからそのデータを取得するのに複数日かかっていました。
良い旅でしたし、たくさん学びました。概念実証インフラと、それを組織に証明することで、Jason を含む他の人たちが、それを本番環境に持っていくための資金を提供する自信を持つことができました。今、私たちは市場データ量が増加していく中で、環境全体にわたってシグナルとホットスポットを検出するためにスケールできる立場にいます。このディープダイブを聞いてくれてありがとうございます。Jason に戻します。Jason は結論を出して、次のステップについて説明してくれます。
ありがとう、Ed。本当に感謝します。Ed が言及したように、POC について、もし彼が私に実際のライブインフラとデータセンターで POC をやるよう頼んでいたら、莫大な費用がかかっていたと思います。20ポンドだったと思うんですが、素晴らしかったですね。冗談ですけど、そんなに安くはなかったです。
では、結論と次のステップについてお話しします。 LSEG の AWS トランスフォーメーション・ジャーニーについてですが、私たちのティック・ヒストリー・データは 75 ペタバイトで、毎日テラバイト単位で増え続けていますが、今ではオンプレミスではなく、スケーラブルな環境に置かれています。CapEx もかかりませんし、必要に応じてスケールすることができます。また、クライアントに対してそのデータへの直接アクセスポイントを提供しています。私たちの環境に来る必要がなく、彼ら自身の S3 を使用して接続することができます。つまり、クライアント全体に対して、基本的にすべてのデータへの単一のアクセスポイントを提供でき、彼らがそれを保存する必要がないということです。
リアルタイム・プラットフォーム開発についてです。Real-Time Optimized は AWS から生まれた私たちの製品の一つです。 これはトレード・セーフで、1 秒間に 3 回の更新があります。現在、約 500 のクライアントがこれを使用しています。なぜなら、彼らはフル・テックを必要としておらず、自分たちのワークロードを実行するか、そのデータを直接自分たちの施設に取り込むことに満足しているからです。私たちのマネージド・サービス・オファリングである RTMDS は、昨年からパブリック・クラウドでもこれをデプロイし始めました。つまり、私たちがインフラストラクチャとサービスを管理し、クライアントはアプリケーションとワークロードに専念することができます。
昨年 AWS がプライベート・リンク・コネクティビティをリリースしたことで、私は世界中の 6 つのリージョンを持っています。これで AWS のバックボーンとインフラストラクチャを使用して、任意の AWS リージョンに相互接続することができます。私のクライアントも私自身も、テレコ・ラインの調達に関わる必要がありません。これにより、市場投入までの時間を大幅に短縮できます。
Matrix Signals Platform は、Ed と私たちの組織の他の優秀な人たちによる素晴らしい発明です。これにより、キャパシティ管理とスケーリングに焦点を当てることができます。ホットスポットがどこにあるのか、どこに投資する必要があるのか、どこでスケールアップする必要があるのかが分かります。ですから、引き続きこれを構築し、生涯にわたって存在し続けることを期待しています。
そして、高度な最適化についてです。先ほど言及したように、私たちはデータ企業であり、テレコ・プロバイダーではありません。私がクライアントにデータを迅速に、かなり安価に、そして簡単に届けることができるなら、そして私がそれをする必要がないなら、私はそのオプションを選びます。昨年、34 の AWS リージョンへの Cross Region Private Link のリリースは、私と AWS 上の私たちのクライアントにとって素晴らしいものです。これは私たちにとって機能し、データをより迅速に、より速く送り出すことを可能にします。みんな満足しています。これが AWS とのパートナーシップで行ってきた変革の一部であり、これからもこのチームと一緒に仕事をして、どのようになるか見ていきたいと思います。では、最後のまとめを行う Rohit にバトンタッチしたいと思います。
ジェイソンとエドに感謝します。本当に素晴らしいジャーニーですね。そしてエドが説明してくれた技術アーキテクチャは本当に印象的です。特にゼロデータコピーで、完全にサーバーレスで、クラウドネイティブ設計という点が素晴らしい。これは、初期段階でチケッティングソリューションのような解決策を構築して、その上に新しいユースケースを構築していく、そういった例の一つです。イノベーションはこれからも続いていくと思います。
Gen AI の側面に関しては、Matrix Signals Platform は金融サービスにおける Gen AI の可能性を実証しています。その一つの例は、市場イベントと Reuters ニュースを相関させることができる AI システムを持つことです。Gen AI が市場の動きをニュースイベントが発生した時点と関連付ける能力、そして私たちが話しているのは大きなイベントについてですが、これはビジネスアナリストがこのペースと、このデータスケールで行うことも、発見することもできないものです。
さらに、9,000万以上のインストルメントを同時に持つときにパターンを認識する能力があります。接続、ホットスポット、トレンドを見つける能力で、これは人間が特定することは不可能なものです。メトリクスプラットフォームはチームに運用可能なアクショナブルインテリジェンスを提供しているので、これらのイベントが発生するときに、より迅速に準備することができます。これは Gen AI によって本当に解決される問題の一つです。非常に大量のデータをアクショナブルインテリジェンスに変換するとき、特にこのスケールとこのスピードで、数年前に別のシステムを使用してこれを行うことは想像もできなかったでしょう。
LSEG チームは Gen AI を使用しており、これは単なるナイスツーハブではありません。彼らは実際に市場インテリジェンスの機能を根本的に変革するために使用しています。これらは私たちの capital markets 顧客に関連する AWS サービスと機能の一部です。LSEG チームが使用しているものの中には、低レイテンシーの Outposts と EC2 上のナノ秒タイムスタンピング機能が含まれており、これらのソリューションは引き続き提供されています。また、本日のセッションで紹介されている LSEG ソリューションへのリンクもいくつか含めました。ここで一度立ち止まって、これらの QR コードの写真を撮りたい場合は、どうぞ。
それでは、このセッションに参加していただき、LSEG の素晴らしいジャーニーと、彼らがこの大規模で達成したことに感謝したいと思います。これは、ビジョナリーリーダーシップ、適切なクラウドプラットフォーム、そして協調的なパートナーシップアプローチの例です。LSEG チームが使用している AWS サービスは利用可能であり、顧客が次世代の金融ソリューションを試して構築する準備ができています。これらのサービスとイノベーションを使用し始める能力を受け入れている組織が、将来の市場リーダーになるでしょう。後ほど質問にお答えしたり、特定の課題や機会について具体的な議論をしたりするために、ここにいます。それでは、お時間をいただきありがとうございました。ぜひこのセッションについてフィードバックをお願いします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion