Vertex Macro｜Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 02: AI と AWS を活用した未来の取引プラットフォームの構築
動画: https://www.youtube.com/watch?v=aqDCPW9oBYA
AI と AWS を活用した未来の取引プラットフォームの構築
（LPL Financial 登壇）（Cognizant スポンサー）
セッションの紹介
● 次世代取引プラットフォームのモダナイゼーションと構築
● ウェルスマネジメントにおけるスピード、スケール、耐障害性、インテリジェンスの重要性
● セッションのアジェンダ概要 ウェルスマネジメント業界の概要：
● ウェルスマネジメントの定義と中核的な目的
● 業界規模：運用資産 144 兆ドル、ファイナンシャルアドバイザー 30 万人、顧客 6,800 万人
● 世代間の資産移転：ベビーブーマー世代からテクノロジーに精通した次世代へ 100 兆ドルの資産が移行
LPL Financial の紹介
● Fortune 500 企業であり、全米最大手のブローカーディーラーである LPL の地位
● LPL のビジネスモデルと現在の取引プラットフォーム 独立系ブローカーディーラーの説明：
● ファイナンシャルアドバイザーが自身の事業を運営できるようにしながら、必要な支援（テクノロジー、オペレーション、コンプライアンスなど）を提供する企業 LPL Financial の地位：
● 32,000 人のファイナンシャルアドバイザー
● 運用資産 2.3 兆ドル LPL の顧客中心のアプローチ：
● ミッション：あらゆる段階で顧客の成功を支援する
● ビジョン：最高のウェルスマネジメント企業になる LPL のビジョン達成に必要なテクノロジー：
● 適応性があり、最先端で、将来に対応できるテクノロジー LPL における取引の定義：
● ファイナンシャルアドバイザーと市場をつなぐ結合組織 舞台裏の取引プロセス：
● 数百の高性能システムが一体となって稼働
● 2,000 以上のチェックをサブミリ秒で実行
● 複数のパートナー（マーケットセンター、フィンテック企業）への依存 取引に対するユーザーの期待：
● 安全な取引
● 常時稼働するシステム
● 即時かつほぼリアルタイムの応答
● 費用対効果の高い取引 ビジネス目標を達成するためのテクノロジー目標：
● セキュリティインシデントゼロ
● 100% のコンプライアンス
● 高い耐障害性を備え、常時稼働し、迅速に復旧できるシステム
● ピーク時の取引量を想定した取引システム クラウドへの道のり：
● ビッグバン型の移行ではなく、反復的かつ段階的なプロセス
● たとえ：超高層ビルの建設（基礎、躯体、電気、配管、自動化）
● 2024 年まで：オンプレミスのデータセンターからクラウドへのプロセス移行、EKS 上での重要システムの運用、AI および機械学習アルゴリズムの導入
● 2024 年の重点：スケーラビリティ向上のためのオートスケーリングとプラットフォームの疎結合化
● 今後の計画：プラットフォームの耐障害性向上、複数アベイラビリティーゾーン構成から複数リージョン・複数アベイラビリティーゾーン構成への移行、オンプレミスへの依存軽減
現行アーキテクチャ
● オンプレミスのデータセンターとクラウド上の複数アベイラビリティーゾーン
● オンプレミスとクラウド間でハンドシェイクするよう設計されたワークフロー AWS を利用した現行アーキテクチャの構成要素：
● プレゼンテーションレイヤーとコンテンツレンダリング用の S3 バケット
● サーバーレス設計とオートスケーリング／自己修復アーキテクチャのための
● EKS Kubernetes
● リレーショナル要件と高いトランザクションスループットのための
● Postgres SQL
● ドキュメントデータベース（主に読み取りユースケース）のための
● Dynamo DB
● 低レイテンシーで高負荷なインメモリ処理のための Memory DB
● 依存関係や障害の連鎖を抑えるメッセージブローカーとしての Kafka
● 機械学習アルゴリズムと AI ユースケースのための SageMaker
● 計装とエンドツーエンドのオブザーバビリティのための CloudWatch 次世代アーキテクチャの目標：
● Tier 1 の重要アプリケーションからオンプレミス依存を排除
● クラウドの能力を最大限に活用し、エンドツーエンドの耐障害性と、よりシンプルなフェイルオーバーを実現
● アクティブ／アクティブの複数リージョン環境へ移行
● 課題：リージョン間のデータ整合性の確保と、複数リージョン間でのアクティブ／アクティブ方式によるリクエストのオーケストレーション
● 解決策の候補：ネイティブな複数リージョンサポートを備える Aurora DB の利用 次世代アーキテクチャの導入：
● コアワークフローへの Gen AI と LLM の統合を改善するため、SageMaker と併せて Bedrock を採用
● Bedrock により学習曲線が緩やかになる
ユースケース：Klein Works Rebalancer
● LPL を代表する自社開発の取引プラットフォーム
● モデルベース取引の原則に基づく
● アドバイザーは、投資ニーズ、目標、リスク特性が異なる顧客向けにポートフォリオを作成
● 市場は常に変化するため、ポートフォリオは意図した戦略から乖離する
● モデルベース取引により、顧客目標に合わせてポートフォリオを調整するプロセスを自動化
● モデルから口座への一対多の関係
● 取引は個別口座ではなくモデルに対して実行
● Client Rebalancer は数百万件の乖離チェックを並列実行し、取引を自動執行するとともに、完全なコンプライアンスを実現
● たとえ：Client Rebalancer は交通状況に応じて経路を再計算する GPS のようなもの
● 現在、LPL Financial の 32,000 人のアドバイザーのうち 14,000 人が利用
● 過去 5 年間にわたり段階的に展開
● プラットフォーム上で 7,000 万件を超える取引を執行
● 1 日あたり 100 万件の乖離チェックを実行
ユースケース：Klein Works Rebalancer
● AWS を活用したハイパースケーリング
● プラットフォーム上の各取引で 50 以上のチェック（口座詳細、市場価格、ライセンス、コンプライアンスルールなど）を実行
● 数百の口座とアドバイザーにまたがる数千件の取引により、1 分あたり数十万件の取引量が発生 プラットフォーム設計：
● アドバイザーからのリバランスリクエストをオーケストレーターが受信
● オーケストレーターが大規模なリバランスリクエストを小さなミニバッチに分割
● ミニバッチを Kafka に送信し、Kafka が配信を保証
● リバランスアルゴリズムはオートスケーリング用に設計された EKS クラスター上で稼働
● アルゴリズムは独立しており、CPU、メモリ使用率、Kafka キューの深さに基づいてスケーリング 取引前検証：
● 取引を執行できるか判断するため 200 以上のチェックを実行
● 取引の有効性をミリ秒単位で即座にフィードバックするため、インプロセスキャッシュを使用
● 無効な取引はキューに戻され、それ以上処理されない 並列化と CQRS：
● 60 以上のコードマイクロサービスとデータベース呼び出しを依存関係マップに従ってグループ化し、並列実行
● Command Query Responsibility Segregation (CQRS) パラダイムを適用
● 書き込みは 1 台のサーバー向けに最適化し、バッチ化およびバッファリングによりデータベースアクセスを削減
● 読み取りは、読み取り量が多いため読み取りインスタンス向けに最適化し、AWS Memory DB を使用してインメモリにキャッシュ 読み取りインスタンスの適応型スケーリング：
● 読み取り中心のシステムであるため、読み取りインスタンスに適応型スケーリングを適用
● EKS は自動的にスケーリングし、読み取りも自動的にスケーリングするよう設計 CloudWatch によるエンドツーエンドのオブザーバビリティ：
● 完全な追跡可能性を確保するため、各取引に相関 ID を付与
● モニタリングとログ記録に CloudWatch を使用
● システムは自己アラートおよび自己修復するよう設計 Synthetics：
● アドバイザーの操作を模倣する合成トランザクションを作成
● ユーザーに影響が及ぶ前に潜在的な問題を検出するため、これらのトランザクションをシステム上で反復実行
● システムは毎秒数千件のトランザクションを処理し、ピーク時には 100 万件近いトランザクションを記録 LPL における AI ユースケース：
● Human-in-the-loop アプローチを優先し、AI が提案した結果やスマートな推奨事項をアドバイザーが管理 ユースケース：マーケットセンターの障害検知
● マーケットセンターでは遅延、問題、障害が発生する可能性があり、運用上の問題や注文の重複につながる
● 目標：マーケットセンターの障害を事前に検知
● リアルタイムの取引と約定をアルゴリズムに供給するワークフローを作成
● 使用アルゴリズム：時系列異常検知アルゴリズムである Random
● Cut Forest
● 異常を検知すると運用チームに警告し、チームが対応 第 2 のユースケース：ETF 分類
● ETF は保有銘柄が異なるため、そのメタデータに基づいてカテゴリー（暗号資産、コモディティ、外国ファンドなど）に分類する必要がある
● 規制上の影響により、ライセンス確認、コンプライアンスルール、アドバイザー向け研修が必要
● 従来は手作業で行っていたが、毎晩実行される学習済みモデルを使用して自動化
● 使用モデル：高精度な教師なしモデルである Artificial
● Neural Network (ANN)
● 運用担当者がモデルの提案を確認して承認
AI モデルのアーキテクチャ
● データストレージ：両ユースケースの履歴データを RDS Aurora PostgreSQL データベースに保存
● Lambda 関数：精選・更新されたデータを毎日取得して処理し、学習用の S3 バケットに出力
● SageMaker：モデルを学習してホストし、学習済みモデルをダウンストリームで利用するエンドポイントとして公開 リアルタイム異常検知のワークフロー：
● Lambda 関数がリアルタイム取引データのストリームを取得
● 学習済みモデルのエンドポイント（Random Cut Forest アルゴリズムなど）でデータを処理
● 異常を検知し、担当者に警告
● モデルの判断に基づく今後の学習に使用するため、データを RDS にフィードバック ETF 分類のワークフロー：
● 新しい ETF データを Lambda 関数に送信
● 学習済みモデルのエンドポイントでデータを処理
● オペレーターに結果を提示
● データを RDS インスタンスに保存
取引バックオフィスの自動化
ビジネス上の背景
● 投資の目的：資産を増やす
● ポートフォリオの成長に伴い、キャピタルゲイン税が増加
● 特に超富裕層顧客の大規模口座では、税務上の影響が重大
● 口座には課税基準額が存在 Rebalancer の複雑性
● Rebalancer のプロセスは複雑
● 税務を考慮した最適化を加えることで、複雑性が増大
● アルゴリズムは相互依存性と感応度の高い 50 以上の変数を考慮 マルチエージェント AI フレームワーク
● 問題解決へのエージェント AI 活用を検討
● エージェントは特定の役割とアクションを持つモデル Rebalancer Agent
● 22 のデータセットで学習
● データセットには 50 以上のパラメーターを持つアルゴリズムと、税務取引 Rebalancer の過去の実行結果が含まれる
● 1 日あたり数百件のリクエストを処理
● 結果を後続処理に返送 Validation Agent
● 口座エコシステムにおける依存関係や影響の連鎖を確認
● 良好な結果を承認し、Trading Agent に進める
● 検証に失敗した場合は再処理のためのフィードバックを送信
● Trading Agent
● マーケットメーカーおよびマーケットセンターとの取引を執行
● スループットが 10 倍に拡大した実績を持つエージェントループの一部 業界動向
● モデルベース取引への移行
● 歴史的経緯や運用負荷のため、まだ移行していない口座もある AI ソリューション
● アドバイザーが現在担当する顧客群と口座の保有資産を分析
● モデルベースの業務へ移行するための口座向けモデルを提案
● 運用作業を減らし、顧客との対話時間を増やすことで、アドバイザーの効率向上を目指す