re:Invent 2024: VanguardがAWSでトレーディングプラットフォームを再構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Vanguard rebuilt its mission-critical trading application on AWS (FSI322)
この動画では、世界最大級の投資会社Vanguardが、ミッションクリティカルなトレーディングプラットフォームをAWSで再構築した事例を紹介しています。レガシーのモノリシックなシステムから、Amazon ECS、AWS Fargate、Amazon Aurora PostgreSQL、DynamoDB、Kafkaなどを活用したモダンなアーキテクチャへの移行により、重大インシデントを70%削減しながら、ソフトウェアデプロイメントを5倍に改善しました。9.9兆ドルの運用資産を持つVanguardが、スケーラビリティ、レジリエンシー、アジリティ、顧客満足度の向上を実現した具体的な技術選定の理由と、段階的なモダナイゼーションの進め方について詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Vanguardのクラウド導入とミッションクリティカルな取り組み
みなさん、こんにちは。本日はご参加いただき、ありがとうございます。世界最大級の投資会社であるVanguardが、ミッションクリティカルなトレーディングプラットフォームの再構築と最新化にAWSをどのように活用したかについて、お話しできることを大変嬉しく思います。私はAWSのSenior Solutions ArchitectのJohn Osborneです。このセッションでは、VanguardのAndrew ClemensとMike Del Rossiをお迎えして、現在も進行中のこの取り組みについてお話しします。この journey では、皆様のIT ポートフォリオにおけるミッションクリティカルなアプリケーションに関連する可能性の高い、技術的な判断とトレードオフが含まれています。
多くの方が、今日Vanguardが話すような状況に直面したことがあるのではないでしょうか。レガシーインフラ上で動作しているビジネスアプリケーションが、年々古くなっていく。メンテナンス費用やライセンス費用が増加し、システムを維持するための重要なスキルを持つスタッフの確保が難しくなる。お客様のために改善を行うことはさらに困難です。そして最も重要なのは、お客様のために日々確実に動作し続けなければならないということです。金融サービス以外の分野からご参加の方々にとっても、Vanguardが検討した教訓や重要なトレードオフは参考になるはずです。もちろん、皆様のビジネスの具体的な文脈によって、異なる道を選択することになるかもしれませんが。
re:Inventに参加されている方々の多くは、私が「常連さん」と呼ぶような方々です。2回目、3回目、4回目と繰り返し参加されている方々ですね。常連の方々は、2019年のre:Inventで、VanguardのJeff Dowdsが登壇し、Vanguardのクラウド導入初期の取り組みについて基調講演で語ったことを覚えているかもしれません。Jeffのプレゼンテーションでは、Vanguardのクラウドへの最初のステップが紹介されました。EMRやSageMakerなどのクラウドベースの分析・MLサービスの採用や、オンプレミスのPlatform as a ServiceソリューションのAWSへの移行、さらにはセキュリティ機能の強化とコスト最適化を図るためのECS Fargateへの標準化について語りました。
Jeffは、Vanguardが主力製品全体でアジリティを向上させ、コストを削減し、顧客満足度を向上させた点を強調しました。私はVenetianでJeffの基調講演をライブで聴講しました。AWSの社員になる前でしたが、会場には2012年から定期的に参加している金融サービス以外の分野で働くAWSマニアの方々が多くいました。大スクリーンに映し出されたVanguardのロゴとJeffの基調講演は、金融サービス業界がクラウドで安全にサービスを提供できるのなら、当時の私の業界でも確実にできるはずだという気づきを与えてくれました。
まだご覧になっていない方は、今日YouTubeでJeffの8分間のプレゼンテーションをチェックすることをお勧めします。しかし、基調講演以上に重要なのは、Vanguardの物語が2019年で終わっていないということです。これまでの成果は確かに実現されましたが、それはAWSにおけるVanguardの継続的な最新化への取り組みの始まりに過ぎませんでした。Vanguardは当時から、最新化は目的地ではなく継続的な旅路であることを理解していました。最終的に100%の最新化という野心的な目標が設定され、今やVanguardは、AndrewとMikeが今日お話しするアプリケーションのような、最もミッションクリティカルで顧客にとって最も重要なコアアプリケーションにクラウドを導入するという課題に取り組んでいます。
トレーディングプラットフォームの現代化：課題と目標
Jeff氏は、2020年にVanguardのPersonal Advisor部門で新規アプリケーション開発のためのコンテナプラットフォームとして、ECS Fargateを採用したことについて言及しました。この時点で、Vanguardはクラウドの真価を実現し、レガシーシステムへの依存度を低減するという課題に直面していました。これらのシステム自体を分解し、境界づけられたコンテキストに分割し、クラウド環境で現代化する必要がありました。Vanguardは、小売投資部門を支えるトレーディングプラットフォームを含め、数十年にわたってビジネスを牽引してきた最も重要なアプリケーションの現代化を継続的に進めてきました。
ここで、Vanguardが直面していたアーキテクチャ上の課題が見えてきます。密結合のモノリシックなメインフレームアプリケーションが、2つのレガシーデータベースに依存しており、Order Management System Database（ここではOMS DBと表示）とEnterprise DB間の夜間バッチ処理は限界に達していました。このトレーディングプラットフォームに求められる規模が拡大するにつれ、月末、四半期末、年末のイベントはすべてスケーラビリティに負荷をかけていました。
このアーキテクチャは、Vanguardのスケーラビリティ、障害に対する回復力、そしてピーク時のトレード実行における高いパフォーマンスの実現を困難にしていました。さらに、このシステムは四半期ごとの本番環境へのリリーススケジュールを持っていました。リリースされる変更の単位が大きく、デプロイメントのリスクを高めると同時に、新しい顧客体験を迅速に提供する能力や、フロントエンドでの実験能力を制限していました。
スライドに表示されているコンポーネントの名前は皆さんのシステムとは異なるかもしれませんが、私が説明した基本的な課題は、皆さんのIT portfolioにある1つ以上のシステムと似ているのではないでしょうか。このスライドでも、複雑ではありますが、Order Managementや Order Validationのマイクロサービス部分など、コンポーネントベースの現代化戦略の切り離しポイントとなりうるシステム境界が見られます。AmazonがAPI-firstの方針で行ったように、Vanguardはその部分から現代化を始めることになるのでしょうか？
現代化を導くため、Vanguardは5つの目標と成果に焦点を当てました。第一に、クラウドベースの現代化されたシステムは、より多くの取引量を受け入れ、突発的なピークをシームレスに処理するVanguardの能力を向上させることでした。次のMeme株取引イベントが発生した際、既存のモノリシックシステムの固有の制限を超えてスケールできるクラウドの弾力性を活用することが重要でした。第二に、取引量が増加し、Vanguardのトレーディングプラットフォームの重要性が高まる中、システムの可用性を向上させることが最重要課題となりました。既存のプラットフォームよりも高いシステム可用性を実現するために、設計の回復力の側面に焦点を当てる必要がありました。
第三に、投資家体験の向上に焦点を当てることで、Vanguardはレジリエンシーを損なうことなく、より多くの機能をより短期間で市場に投入する必要がありました。これは第四の成果である、Vanguardの顧客満足度の向上につながります。Vanguardの投資家に新しく、より良い体験を提供することは、Vanguardにおけるこの現代化の取り組み全体の核心です。投資家は、Vanguardのあらゆる活動の中心であり、焦点となっています。多くの人々がAmazonの顧客obsessionへの注力を理解しているように、投資家に投資成功への最高のチャンスを提供するというVanguardのミッションには、この現代化によって投資家がVanguardのプラットフォームをより簡単に使えるようにすることが求められていました。
最後に、コストを削減して投資家のリターンを向上させることは、創業以来のVanguardの基本方針であり、この取り組みも継続的な総所有コストの削減という点で例外ではありませんでした。スライドでこれらの成果に1から5までの番号を付けましたが、これは単にプレゼンテーションを作成する際のスタイルの選択でした。これら5つの成果はすべて重要で期待されていたものであり、どれも他より重要度が高いわけでも低いわけでもありませんでした。
AWSサービスを活用したアーキテクチャの設計
Mikeがまもなく加わり、Vanguardがこれらの成果をどのように達成したかを説明します。AndrewとMikeはまた、AWSプラットフォームにおけるデザインと意思決定の選択についても説明します。しかし、その前に、彼らのアーキテクチャの中心となるいくつかのポイントを強調しておきたいと思います。 まず、VanguardはAWSのワークロードに適したデータストアを選択するという決定指針を理解していました。メインフレームのBounded Contextを分離する際、Vanguardは複雑なクエリ機能を必要とし、リレーショナルデータベースが必要となるワークロードを特定しました。Vanguardは Amazon Aurora PostgreSQLを選択しました。これは、レジリエンシーの目標を達成するために、複数のAWSリージョンにまたがって読み取りを分散し、災害やシステム劣化の際に迅速なフェイルオーバーを可能にするリレーショナルデータベースソリューションが必要だったためです。
また、NoSQLのキーバリュー検索として表現および移行可能なデータアーキテクチャの部分については、Amazon DynamoDBへの移行が特定されました。ここでチームは、Auroraと比較して、パッチ適用やメンテナンス作業を管理する必要のないDynamoDBのマネージドNoSQLエクスペリエンスによる運用オーバーヘッドの削減の恩恵を受けることができました。
VanguardはAmazon ECSとサーバーレスコンテナランタイムのAWS Fargateを中心にコンテナプラットフォームを標準化していました。Jeff Dowdsが2019年のre:Inventの聴衆に語ったように、クラウド採用後、このアプリケーションはAmazon EKSのような異なるコンピューティングテクノロジーを必要とする可能性のある新たなニーズをもたらすことになりました。しかし最終的に、Amazon ECSとAWS Fargateは、チームがコンテナオーケストレーションと管理のパッチ適用を心配することなく、現代化の目標達成に集中できる、Vanguard内で実証済みのプラットフォームでした。
特にデータレイヤーにおいて、レジリエンス目標は最重要課題でした。Vanguardは複数のAWSリージョンにまたがるアクセスをサポートする重要なニーズを特定し、それを実現するためのAWSサービスの改善に向けて技術的な判断を行いました。 リレーショナルデータベース環境における目標を達成するため、Vanguardはリージョン障害時に備えてAurora Global Databaseが必要でした。Aurora Global Databaseのフェイルオーバー機能により、他のVanguard運用リージョンへの移行が可能な耐障害性システムを実現できます。
当初、これは困難な課題でした。フェイルオーバーを実行すると、Vanguardの運用チームとアプリケーションチームは、グローバルデータベースのトポロジーを再構築し、DR機能を回復するために、フェイルオーバー後に複数のステップを実行する必要があったからです。フェイルオーバー後の再構築に要する時間を考慮すると、そもそもフェイルオーバーを実行するかどうかの判断が曖昧になってしまいます。つまり、再構築に必要な労力と時間を考えると、リージョン内の障害がどの程度深刻でなければフェイルオーバーを実行する価値がないのか、という問題です。これらの懸念を解消するため、VanguardはAmazon Auroraチームと緊密に協力し、Auroraの改良されたフェイルオーバーおよびスイッチオーバー機能の早期採用者となりました。Amazon Aurora Global Databaseのこれらの機能は、現在すべてのAWSカスタマーが利用可能です。
高可用性と高信頼性、そして低RTOおよび低RPOが必要な方々にとって、これらの機能は非常に重要になります。しかし、必要な改善はさらに続きました。Vanguardがスイッチオーバーまたはフェイルオーバーを選択した場合、アプリケーションはAuroraのWriterエンドポイントの変更を認識する必要がありました。設定を注入してエンドポイントを更新することは可能でしたが、VanguardはAmazon Auroraチームに働きかけ、最近グローバルWriterエンドポイント機能の提供を実現しました。現在、スイッチオーバーやフェイルオーバーの際に、Amazon Auroraのお客様はこの機能を活用して、グローバルアプリケーションのエンドポイントを変更する必要がなくなりました。これらの取り組みは、VanguardとAWSの継続的なコラボレーションの例であり、Vanguardのニーズだけでなく、すべてのAWSカスタマーのニーズを満たすサービス改善につながっています。
Amazon DynamoDBのグローバルテーブルも必要でした。アプリケーションチームは、書き込み時のマルチリージョン整合性を維持しながら、DynamoDBのオンデマンドモードを活用することで、必要に応じて追加の読み取りおよび書き込み容量を確保し、スケーラビリティを向上させることができました。また、レジリエンシーを犠牲にすることなく、Vanguardがサポートする任意のリージョンから書き込みを行うことができ、グローバルなミッションクリティカルなトレーディングアプリケーションのために世界中からの取引を処理できます。一見するとリレーショナルデータベースの選択が予想されるかもしれませんが、Mikeがまもなく説明するように、VanguardはDynamoDBの極めて高いスケーラビリティと運用負荷の軽減を活用できる立場にあることを認識していました。
現在のアーキテクチャでは、Vanguardはまずマルチリージョンのアクティブ-パッシブアプローチを採用していますが、さらにレジリエンスと可用性を向上させ、マルチリージョンのアクティブ-アクティブを実現するビジョンと継続的な道筋を持っています。DynamoDBにおけるグローバルな整合性は極めて重要で、VanguardはAWSと協力して、本日発表されたDynamoDB RPO zeroによって部分的に実現可能となるアクティブ-アクティブでグローバルに整合性のあるアーキテクチャを構築し続けています。これらの主要なサービスにより、Vanguardはトレーディングプラットフォームのモダナイゼーションの旅を開始しました。
Vanguardの成長と変革の背景
それでは、この取り組みがどのように行われたのかをお話しするために、Andrew Clemensをステージにお招きしたいと思います。最初の3つの聴衆参加のうちの1つ目ですが - 私の声は聞こえていますか？はい、1回目は成功です。 モダナイゼーションの旅についてお話しする前に、まずVanguardの数字についてご紹介したいと思います。
Vanguardは、世界中の5,000万人以上のクライアントから9.9兆ドルもの大切な資産を託されているグローバルな資産運用・資産管理会社です。毎日10億から20億ドルの資金が当社に流入しており、市場が少し上向けば運用資産残高は10兆ドルを超えることになります。Vanguardは実店舗型の金融機関ではありません - 全国各地に支店があるわけではないのです。私たちは技術に大きく依存しており、クライアントとのやり取りの99%以上がデジタルチャネルを通じて行われています。私たちは事業の拡大において、本当に技術に頼ってきました。
最初の質問です：会場の中で、投資ポートフォリオにVanguardのミューチュアルファンドやETFを保有しているVanguardの投資家の方はいらっしゃいますか？素晴らしい、たくさんの手が挙がりましたね。皆さんは5,000万人と9.9兆ドルの一部なのです。資産をどこで保有しているかは関係ありません - 当社の商品に投資することで、皆さんはVanguardの投資家なのです。2つ目の質問：直接vanguard.comにアクセスして、ポートフォリオを自己管理したり、アドバイザリーサービスを利用したりしている方はいらっしゃいますか？かなりいらっしゃいますが、予想通り少し少なめですね - この方々は5,000万人と9.9兆ドルのサブセットということになります。
本日は、Vanguardで直接ポートフォリオを管理するクライアントにサービスを提供する証券取引プラットフォームについてお話しします。よく言われるように、「現状維持では将来は成り立たない」のです。私たちは、技術によって事業を拡大できたことを非常に誇りに思っていますが、それだけでは十分ではないことも分かっています。証券業界は進化し続けており、Vanguardも投資家の成功のチャンスを最大限に高めるために新しいサービスを続々と展開しています。
それでは、どのような変化があり、どのような新しいサービスがあるのか見ていきましょう。まず2010年まで遡る必要があります。 この年、Vanguardは今後数十年にわたって事業の形を決定づける重要な決断を下しました。2010年に向けて、私たちには2つの全く異なる口座タイプがありました：1つはVanguardのミューチュアルファンドのみを扱うTransfer Agency（TA）口座、もう1つは従来型の証券口座です。当時、大多数のクライアントはTA口座でVanguardのミューチュアルファンドを保有しており、証券口座の利用は非常に限られていました。将来に向けて、私たちはVanguardのミューチュアルファンド、Vanguard ETF、その他の投資商品を保有し、それらすべてを横断的に取引できるシームレスな口座タイプが必要だと認識していました。
私たちは証券ブローカレッジの方向に進んでいました。ブローカレッジ業務に取り組む必要があることは分かっていましたし、ETFの台頭も予測していました。そして案の定、2013年にETFが急成長を始めました。Vanguardはシームレスな取引を可能にするアカウントタイプを用意して準備万端でした。2019年になると、業界全体で各社が次々と株式取引手数料をゼロにしていきました。2019年以前は業界全体で1日あたり50～60億株程度の取引でしたが、2019年以降は1日100～110億株と、業界全体で取引量が2倍になりました。
2020年は、私たちがEnterprise Technology Strategyにコミットした重要な年でした。これは全事業部門、全部署、社内システム、外部システムに影響を与える全社的な近代化の取り組みでした。Vanguardはシステムをクラウドに移行することで、将来に向けた準備を進めていました。同時に2020年には、アドバイスサービスの拡大を続け、Robo-advisoryサービスを立ち上げ、Tax Loss Harvestingの拡充を開始しました。Tax Loss Harvestingは、市場下落時に一つのポジションを売却して別のポジションを購入する優れた機能で、2つの利点があります：市場から完全に退出することなく、売却による損失を税務上有効活用できるのです。
アドバイスを受けるクライアントが数十万人、運用ポジションが数百万に拡大する中で、市場下落時にはトレーディングプラットフォームに膨大な取引が集中します - これも私たちが備えておくべき状況の一つでした。2021年には、Roaring Kittyとミーム株の熱狂が業界を襲い、何日も、何週間も、何ヶ月も混乱が続きました。ミーム株は取引量が急増する一例に過ぎません - 選挙期間中や選挙後にも同様の現象が見られました。私たちは様々なシナリオで起こりうる取引量の急増に備える必要があります。
Direct Indexingも、規模が拡大すれば私たちのプラットフォームに大量の取引をもたらすサービスです。過去15年間で、私たちのプラットフォームでのブローカレッジ取引量は100倍に増加しました。これから15年先を見据えると、さらに100倍の増加に備える必要があります。
トレーディングプラットフォームの再構築：段階的アプローチ
Vanguardの成長の文脈と変化する環境を踏まえて、私たちの近代化戦略を見ていきましょう。私たちは、ブローカレッジ取引プラットフォーム全体を近代化する変革の旅に乗り出しています。Johnが言及したように、私たちには20年間よく機能してきたレガシーのオンプレミスモノリスがありましたが、より良くする必要があることは分かっていました。このモノリス型アーキテクチャから、フロントエンドのクライアントエクスペリエンス、API、データという3層アーキテクチャへの移行が必要でした。自己管理型のクライアントは、モダンで直感的なフロントエンドを通じて、クラウドAPIとクラウドデータを活用するスタック全体のメリットを享受できます。アドバイザリー型のクライアントも、同じクラウドAPIとクラウドデータの恩恵を受け、すべてのクライアントの取引が完璧に実行される一貫したアプローチを確保できます。
新システムは100以上の分散システムで構成される、堅牢でスケーラブルなものとなります。年間8,000万件の取引を処理し、その数は増加傾向にあります。日々10億ドルの想定元本を扱うことになります。2025年以降の取引量増加に備え、私たちのクラウドプラットフォームは、日々のクライアントのニーズに応えられるよう、スケールアップとその準備が必要となります。このモノリシックなシステムから高度に分散化されたシステムへの移行は、非常に重要な取り組みです。5年間隔離された状態でモダナイゼーションを進め、その後に真新しい取引プラットフォームを披露する、というようなアプローチは現実的ではありませんでした。
私たちは段階的に価値を提供する方法を見出す必要がありました。その複雑さとスケールを考えると、を一晩でモダナイズすることは現実的ではありませんでした。そこで、Vanguardのビジネスとクライアントの双方に対して、年々価値を最大化できるよう、できるだけ早く、そして頻繁に価値を提供する戦略を練りました。異なる速度で運用できるよう、アプリケーション層間を切り離すためのインフラの接合部を見つける必要がありました。最も高いレベルで見ると、取引プラットフォームには3つの機能が必要です：取引の送信、取引のルール実行に必要なデータの取得、そして取引の送信とルーティングです。これら3つの領域とその間の接合部について考えてみてください - これらは抽象化層を導入し、3つの層それぞれが独立してモダナイゼーションを進められるような重要な領域なのです。
私たちの最初のモダナイゼーションの旅は、フロントエンドから始まりました。まず何よりも、クライアントが目にし、触れ、体験するものを変更することからスタートしたのです。株式とETF（Exchange-Traded Fund）の取引チケットから着手しました。クライアントがETF商品への関心を高めている傾向が見られたことから、ETFの需要が増加すると予測し、データに基づいてETFチケットから始めることを決定しました。しかし、チームはフロントエンドの構築中に、まだ利用できないAPIが必要となるという課題に直面しました。フロントエンドチームが構築とモダナイズを進める中、取引検証APIという最初の抽象化層の構築を開始しました - これは、レガシーシステムを呼び出しながらも、フロントエンドが将来性のあるエンドポイントを持てるようにする重要な層でした。
フロントエンドのローンチ後、APIに取り組む時期となり、レガシーシステムから移行して、クラウドで構築する必要のある多くのビジネスプロセスがありました。これには注文、証券、利用可能な資金、キャンセル変更、税務コスト計算基準などが含まれていました。ETFチケットのローンチ後、それに合わせてETFルールの検証も移行しました。さらに20個ほどのエンドポイントを構築した後、レガシーからクラウドAPIへの切り替えを開始できるようになりました。
現在、フロントエンドのピクセルからクラウド上のオンプレミスデータベースへの送信まで、すべてを行えるようになっています。これは私たちのバリューストリームの重要な部分であり、今やクラウドでその恩恵を受けています。その結果はどうだったでしょうか？システムの可用性は向上し、P95レイテンシーは着実に低下し、観測性とテレメトリーの進歩により、ほぼリアルタイムで問題を検知できるようになりました。クライアントは目的に特化して構築されたフロントエンドの恩恵を受けているだけでなく、システムの可用性と健全性の向上からも利益を得ています。
次はデータベースに取り組む時が来ました。この時点で、私たちのクラウドエンジニアリングは大きく成熟していました。レガシーからクラウドへの移行における私たちの実践とテクニックは成熟し、強化されていました。そして、これらすべてが、データベースでCloud-firstの読み書きを開始する上で極めて重要になってきます。私たちはそこでしばらく時間を費やし、Cloud-firstの読み書きへの大きな飛躍を遂げました。CXやAPIについて話してきた価値だけでなく、今やクラウドからの読み書きを行い、オンプレミスのフットプリントを継続的に縮小しています。
私たちは、なぜモダナイゼーションを行ったのか、その変革の理由と、価値の段階的な提供を通じてどのように実現したのかについて説明してきました。では、具体的に何を構築したのかについて詳しく見ていきましょう。最後の観客参加の質問です：Trade Component Platformの195のステップバイステップの詳細な説明を聞きたい方はいますか？これについては後ほど個別に話しましょう - 今はその時間がありません。しかし、Vanguardには、これらすべてを構築した数十のチームがあり、これを正確に説明できる素晴らしい知見と専門性を持っています。エンジニアリングとプロダクトの両方のリーダーたちが、これを実現してきました。これらのチームは、モダナイゼーションに取り組み、クラウドへ移行することに意欲的で、今日は彼らの仕事を代表してご紹介できることを非常に誇りに思います。
まず、ライフサイクルを高レベルで見ていきましょう。注文を受け付け、OMSでルールの検証を行い、保存し、市場にルーティングし、執行し、トレード確認を受け取り、必要に応じてデータベースを更新し、その時点で完了となり、クライアントがアクセスできるようになります。最初は静的なECS Webアプリケーションでカスタマーエクスペリエンスを構築しましたが、すぐにServerlessなUIのメリットに気づきました。S3バケットからアセットを取得するためにCloudFrontを実装しました。これにより、レンダリングが高速化し、エッジに近い体験が可能になり、地理的ルーティングとActive-Activeのマルチリージョン耐障害パターンが実現し、最後に最新の実験が可能になりました。
技術選択の詳細：データベース、コンピュート、メッセージング
これまでは、モダンなシステムをローンチする際には、常にレガシーとモダンを比較し、CSAが向上したか、ジャーニー完了率が向上したかを確認していました。今では、モダン同士の実験が可能になりました。これははるかに高速で、モダンな体験でA/Bテストを行い、私たちのCXが直感的でクライアントのニーズに応えているかどうかを真に確認することができます。次はCloud Trade APIです。これはCX全体を支える重要なコンポーネントです。このAPIは、WebとMobileの両方に対して一貫したコンシューマーAPIレイヤーとして機能するECS Node.jsのバックエンドフォーフロントエンドアプリケーションです。デジタルプラットフォーム全体で、トレードデータの取得や取引の送信が必要な場合は、すべてこの同じエンドポイントにアクセスします。フロントエンドアプリケーションと同じTypeScriptで書かれており、チームがWebアプリケーションとバックエンドのデータニーズの両方に容易に貢献できるようになっています。このAPIは高度にチューニングされており、1日800万件以上のリクエストを処理しています。
ユーザー起動の取引に加えて、いくつかのバッチアプリケーションがあり、その中から2つを詳しく見ていきます。1つ目はアドバイスです - 先ほどポートフォリオのリバランシングに関するアドバイスについて話しました。毎日、私たちのアドバイス事業部門は、アドバイスを受けているクライアントのポートフォリオが投資戦略に沿うように、彼らに代わって実行する必要のある取引のバッチを送ってきます。2つ目は、セルフダイレクトのクライアント向けで、デジタルチャネルを通じて週次、隔週、月次で何かを実行したいと伝えてくる場合です - 現金を送金して、VanguardのミューチュアルファンドやETFを購入したいという場合です。
これらのバッチ処理の重要なコンポーネントには2つの側面があります。1つ目はタイミング制御です。大量の注文を扱うため、実行タイミングを把握し、下流のAPIが適切にスケールされているようにします。2つ目の重要なレジリエンシーパターンはCircuit Breakerです。障害を検知した瞬間にシャットダウンします。バックエンドのビジネスオペレーションに大量の失敗を送信して後処理が必要になるような状況は絶対に避けたいのです。
ここでは、トランザクションを生成するプロデューサーがルールの検証を要求する必要があり、ここで段階的にLegacyからAPIへの移行を行いました。このコンポーネントはAmazon ECSアプリケーションで、下流で発生するすべての処理を制御するトラフィックコントローラーとして機能します。Legacyを呼び出すのか、クラウドを呼び出すのか、あるいはクラウドの異なる組み合わせを呼び出すのかを決定します。Fractional Sharesのような機能をリリースする際には、ルール検証にさまざまな経路が存在する可能性があります。このアプリは当初、APIが準備できていなかったためLegacyデータベースにハードコードされていました。その後、APIエコノミーが発展するにつれて、データオーケストレーションサービスを構築し、下流への呼び出しをマルチスレッド化して、レイテンシーとパフォーマンスを改善することができました。
ルールをクリアして取引を受け付けられるようになったら、それを保存する必要があります。ここでアーキテクチャの複雑な部分が登場します - Amazon Aurora PostgreSQL、Amazon DynamoDB、Kafka、そして市場へのTCP/IP接続です。取引が入ってくると、Auroraで「entered」ステータスで保存されると同時に、Kafkaにメッセージが送信されます。このメッセージのリスナーかつコンシューマーである経路決定サービスは、私たちにとって重要です。ビジネス部門が取引に適切なマーケットセンターを設定できるDynamoDBデータベースを持っています。このサービスは入力された取引を取得し、ルールを実行し、どのマーケットセンターパートナーに送信するかを決定し、送信先を設定して、別のKafkaメッセージをバスに送信します。
バックエンドの実行管理システムは、送信先が設定された取引を見つけ、どのマーケットセンターにルーティングするかを決定するリスナーとなります。Kafkaメッセージを受け取り、業界標準のFIXメッセージに変換し、そのFIXメッセージをDynamoDBデータベースに保存してから、マーケットセンターに送信します。私たちのルーティングサービスは、マーケットセンターごとにシングルトンのTCP/IPソケットを使用しており、これらを一つずつLegacyラインからクラウドラインに移行しています。マーケットセンターは即座にFIXメッセージで応答し、取引の新しいステータス（routed、acknowledged、partially filled、executed、rejected）を示します。インバウンドメッセージを受信してデータベースに保存すると、別のKafkaメッセージをバスに送信します。
OMSとAuroraデータベースはリッスンして、通常2つのアクションを実行する必要があります。ここで、マルチドメインデータベースが重要になります。実行済みメッセージの場合、注文ステータスと実行済みポジションの株数の両方を更新する必要があります。これを単一のコミットで行うことで、ドメイン間で一貫した実行を確保します。この時点で取引のライフサイクルは完了し、データベースに保存され、APIを通じてクライアントがWebやデジタルチャネルで取引の詳細を確認できるようになります。
私たちのTrade EngineのRDMSとしてAurora PostgreSQLデータベースを採用しており、これは取引、口座、ポジション、注文、証券という4つの柱で構成されています。Amazon ECSアプリケーションがこのデータベースの上に配置され、Trade Engine DBのすべての読み書きを処理しています。DynamoDBは私たちのFIXメッセージを保存しており、これはアクセスパターンが限定的であることや、キーバリューペアデータベースとしての特性、そして高いパフォーマンス基準を満たすことから選択されました。KafkaはEMSのこの重要な領域でメッセージングバスとして機能しています。技術面では、メッセージングプロトコルとしてAvro JSONとProtocol Buffersを評価し、最終的にTrade Engineの重要なノンファンクショナル要件である高スループットと低レイテンシーに最適化されているProtocol Buffersを選択しました。
Kafkaの役割は、OMSとMSの間のハートビートだけではありません。より多くのメッセージが利用可能になるにつれて、私たちのデジタルチャネルがこれらのメッセージをリッスンできるようになっています。例えば、クライアントが10日前に指値注文を出し、その注文が今日トリガーされた場合、フロントエンドがそれらのメッセージをリッスンすることができます。クライアントが指値注文が約定したかどうかを何度も確認する必要がなく、私たちから通知を送ることができます。このようにKafkaプラットフォームを通じて、クライアント体験を向上させることが可能になっています。
これらすべてを実現するために、何百回ものホワイトボーディングセッションと数え切れない議論が必要でした。これから、その議論の内容に踏み込んでいきましょう。先ほど申し上げたように、検討すべき選択肢は無数にありました。これからデータベース、コンピュート、メッセージングについて詳しく見ていきます。ここでMike Del Rossiが登壇して、これらの決定と議論について説明します。
技術的決定の背景と理由
大規模な技術変革において、私たちはいくつかの議論を重ねてきました。Trade Engineのデータベースに関する議論ほど、熱い議論や情熱を呼び起こしたトピックはありませんでした。どのデータベースを使用するか、どれだけのデータを含めるか、スケールするか、どのように保護するかといった点です。まず、私たちはポリグロットデータベース環境を採用しています。DynamoDBとPostgreSQLの両方を私たちのポートフォリオ全体で広く使用し、大きな成功を収めています。ユースケースによって、どちらかがより適している場合があります。今回のケースでは、プライマリデータベースとしてAurora PostgreSQLを選択しました。
この決定に至った考え方をお話しします。まず、DynamoDBとPostgreSQLのどちらのデータベース技術を使用するかを決める必要がありました。これは実質的に、NoSQLかリレーショナルデータベースかの選択でした。両プラットフォームとも魅力的な特徴を持っています。DynamoDBはパフォーマンスがスケーラブルでコスト効率が良く、グローバルテーブル機能によってマルチリージョンデプロイメントが比較的容易です。ただし、適切なパフォーマンスを得るためには、データとインデックスを適切にモデル化する必要があります。将来、保存したいデータや、アクセス方法に関するニーズが変化した場合、更新やインデックスの追加は複雑な作業となり、通常は長時間の停止時間と複雑なロールバックが必要になります。
データが変化する可能性があり、さまざまなアクセスパターンが不確実な場合は、リレーショナルデータベースの方が適している可能性があります。私たちにとってミッションクリティカルなアプリケーションであるため、レジリエンシーは非常に重要です。DynamoDBではマルチリージョンのデプロイメントが比較的簡単ですが、Aurora PostgreSQLでも同じことが実現できます - ただし、設計、実装、テストがより複雑になります。次に考慮すべき要因はコストです。 Vanguardでは、PostgreSQLと比較してDynamoDBの方がコスト効率が良いことがわかりました。ただし、どちらも移行元の従来のプラットフォームよりもコストが低かったため、この点は意思決定プロセスにおいて大きな要因とはなりませんでした。
Aurora PostgreSQLを選択した後、その運用方法を決める必要がありました。2022年にAurora version 2が発表された時は大変期待していました。re:Inventから戻った後、すぐに実験を開始しましたが、結果は様々でした - 一部のデータベースではパフォーマンスが向上しましたが、他では低下が見られました。最終的に、3年間のコミットメントとGravitonプロセッサーの使用で同程度のコストポイントを達成できたため、Provisionedインスタンスの運用を選択しました。これにより、市場の急激な変動に対するAuto Scalingの適切な調整も不要になりました。データベースに関する最後の決定は、必要なデータベースの数でした。Andrewが言及したように、私たちには accounts、positions、orders、securitiesという4つの主要なデータドメインがありました。それぞれを独立したデータベースとして実装することもできましたが、そうすると、データベースに任せられる結合処理をAPIレイヤーで行う必要があり、コーディングがかなり複雑になってしまいます。
ポートフォリオのモダナイゼーションを進める中で、私たちはモノリスを分解し、APIと関連データをそれぞれのBounded Contextに分割してきました。今回は例外的に、これらを1つのデータベースにまとめ、その周りに一連のAPIを配置するというミニサービス的なパターンを採用しました。これは、通常採用している従来のマイクロサービスパターンとは異なるアプローチです。
では、データベースの話から、コンピュートティアの話に移りましょう。 こちらの議論はそれほど物議を醸すものではありませんでしたが、コンピュートは常に進化し続ける分野です。私たちは数年前、クラウドに移行する前に、データセンターでPivotal Cloud Foundryを使用することから始めました。クラウドを採用するにあたり、できる限りAWSに重要な作業を任せることで、価値を最大化したいと考えました。この変更に伴い、モダナイズされたマイクロサービスのホスティングにAmazon ECSを採用することにしました。
その過程で、私たちがトレーディングプラットフォームのモダナイゼーションを開始した時期に、VanguardでAmazon EKSが導入されました。Kubernetesが提供する機能には魅力を感じていましたが、運用経験が限られていたため、トレーディングプラットフォームでEKSの先駆者になることは避けたいと考えました。将来的にEKSへの移行を決めた場合でも、ECSからEKSへの移行パスは比較的straightforwardであることもわかりました。この決定は定期的に再評価しており、現時点でEKSに移行すべきかという質問も常に出てきます。まだ移行はしていませんが、将来的な可能性は残されています。また、どの機能をLambdaで実行し、どの機能をECSやDockerコンテナで実行するのが適切かについても検討を重ねています。
EKSとECSの選択に関しては、クラスターを適切にグループ化するための事前設計、Kubernetesクラスターを運用するために必要な追加サポート、そしてマルチテナント環境を実質的に運用する際の複雑さの増加を考慮する必要があります。ECSはシンプルさが魅力的で、シングルテナントという特性により、あるアプリケーションが他に影響を与えるリスクが低減されます。EKSは明らかにより堅牢で、より複雑なシステムには適していますが、追加の複雑さと責任が伴うため、それらの追加機能が本当に必要かどうかをしっかりと見極める必要があります。
ECSを選択した後、次に検討したのは展開方法でした - FargateとEC2インスタンスのどちらを使うか？EC2での運用は、より多くの設定オプションとハードウェアの選択肢が得られます。しかし、私たちの場合、そのようなアクセスや追加のハードウェア機能は必要ありませんでした。Fargateは私たちのニーズを満たし、AWSにできるだけ多くの作業を任せたかったため、現在もFargateでの運用を続けています。
メッセージングプラットフォームの最後の領域に移ると、 私たちの企業全体でKafka、Amazon Kinesis、またはAmazon EventBridgeの選択について議論がありました。私たちの環境では、KinesisとEventBridgeを使用している重要なアプリケーションがあります。しかし、今回の場合はKafkaを選択しました。これはKubernetesの場合とは逆で、Kafkaは私たちにとって新しい技術でしたが、トレーディングプラットフォームに必要な追加のメッセージングプロトコルとパフォーマンスのスケーラビリティを備えていると判断しました。いずれにしても、強力なマネージドサービスのオプションが利用可能で、最終的に私たちはサードパーティのサポートを受けてKafkaインスタンスを運用することにしました。Kafkaはマルチリージョンで展開されており、私たちのマルチリージョンアーキテクチャに沿った形となっています。
モダナイゼーションの成果と今後の展望
技術的な決定についての説明を締めくくり、この変革がもたらした利点についてお話ししたいと思います。 Johnが先ほど、私たちがこの旅を始めた時に期待していた成果について共有しました：スケーラビリティの向上、レジリエンシー、アジリティ、顧客満足度の向上、そしてTCOの削減です。これらの成果が実現されており、モダナイゼーションの取り組みが進むにつれて、さらに成果が拡大していることをお伝えできることを嬉しく思います。それでは、これらの各領域について、顧客満足度から詳しく見ていきましょう。
私たち全員が高まる顧客期待に直面しています。 比較対象は金融サービス企業だけでなく、業界を超えたデジタルネイティブ企業との比較になっています。モダナイゼーションを進める中で、単に既存のアプリケーションを再構築するだけでなく、体験を見直し、既存の機能やルールが本当に必要かどうかを自問する機会としました。最近、アプリケーションポートフォリオの80%以上のモダナイゼーションを達成しました。私たちのブローカレッジプラットフォームは外部からも高い評価を受け、Web Wealth Management Innovation Awardを受賞しました。社内では、顧客満足度を複数の方法で測定していますが、すべての指標において、モダナイゼーションの進捗に相関する意味のある向上が見られています。これらの改善に興奮している一方で、まだやるべきことがあることを認識しており、これは私たちの継続的な注力分野となっています。
もう1つの大きな利点は、価値を迅速に提供できるようになったことです。 Product Team構造への移行、DevOpsプラクティスの活用、そして最新のクラウドテクノロジーの導入による影響は絶大でした。初期の段階では、株式とETF取引のモダナイゼーションで着実な進展を遂げていました。しかし、APIプラットフォームが成熟し、追加機能が実装され、クラウドでの開発スキルが向上するにつれて、さらにペースが加速しました。投資信託取引のモダナイゼーションや、Dollar-based tradingやETFの自動投資といった新機能の追加にかかる時間も大幅に短縮されました。また、Cash Plusのような全く新しいサービスの構築でも同様の効果が見られています。Cash Plusについてご存じない方のために説明すると、FDIC保険対象の高利回り預金口座です。このサービスを市場に投入するまでに12ヶ月もかからず、80以上のチームが様々なレベルで関わりました。このように、新機能を試験的に導入したり、既存の機能を素早く改善したりできる俊敏性を獲得できたことは、本当にエキサイティングです。
次にレジリエンシーと生産性についてお話しします。 この分野では最も大きな成果を上げることができました。これらの指標を意図的に並べて示していますが、従来であれば、この2つは相反する関係にあると考えられていました。DevOpsとクラウド以前、私はプロジェクトマネジメントにおける「コスト・品質・時間」のトリレンマの概念の中で育ちました。つまり、3つのうち2つは確保できても、3つすべてを満たすことは不可能だと考えられていたのです。以前データセンターで働いていた時は、変更作業が増えれば障害も増えるという証拠がたくさんありました。しかし現在では、重大インシデントが70%減少し、同時にソフトウェアデプロイメントは5倍に改善されています。これは最新テクノロジーの活用、レジリエンシーのベストプラクティスの採用、堅牢なCI/CDパイプライン、そしてProduct Teamのオーナーシップマインドによって実現されました。このことは、私のキャリア初期に学んだことを見直すきっかけとなりました。
ここで、私たちのモダナイゼーションの旅を振り返って、いくつかの考察を共有したいと思います。 まず、大きく考えることです。確かに段階的な提供は重要ですが、スタック全体のモダナイゼーションを目指すべきです。私のチームのリーダーの一人が言うように、私たちは「画面からディスクまで」すべてをモダナイズして、その恩恵を最大限に引き出そうとしています。従来のやり方を全面的に見直し、包括的に考える必要があります。単に現在のスタックをクラウドにLift & Shiftしたり、新しいフロントエンドを追加したりするだけでは不十分です。次に、柔軟性を保つことです。クラウドの世界は急速に変化するため、これまでの決定を見直し、必要に応じて方向転換する意思を持つ必要があります。先ほど申し上げたように、私たちはデータセンターでPCFを使用することから始まり、その後ECS、そして現在は場合によってLambdaを活用するまでに至っています。その時点で最善と思われる決定を下して前進することが重要です。特定の決定に固執せず、変更を厭わない姿勢が必要です。最後に、モダナイゼーションはマラソンであってスプリントではありません。これは特にミッションクリティカルなアプリケーションを扱う場合に当てはまります。ただし、道路や橋の工事プロジェクトと比較されて、途中でサポートを失うリスクは常に存在します。そのため、価値を段階的に提供し、リスクを小さく分けて取り組む必要があります。
これを実現するために、Blue/green deploymentやCanary deploymentなどの拡張された本番環境での並行テスト技術を活用できます。プロセスの特定のステップや特定の取引タイプをターゲットにすることと組み合わせることで、段階的に信頼性を構築することができます。大きく考え、柔軟に対応し、慎重に進めることが重要ですが、何よりも「できる」という揺るぎない信念を持つことが最も大切です。
次のステップについて話す前に、私たちのチームに感謝の意を表したいと思います。Pennsylvania、North Carolina、Arizonaのクルーチーム、そしてドイツとインドのパートナーチームが、これを可能にしてくれました。素晴らしい仕事をしていただき、ありがとうございます。今後は、取引プロセスのパーソナライゼーションレベルを高め、Generative AIを活用してクライアント体験を向上させることに注力します。また、キャッシュ関連サービスの拡充や、社内のクルー向けエクスペリエンスの完成も目指します。これらを通じて、Vanguardのミッションに忠実に従い、クライアントのより良い投資成果の実現を支援できると考えています。
最後に、私たちVanguardのミッションについてお話しさせていただきたいと思います。このミッションは、私たちの日々の原動力となっているものです。私たちの目的は、すべての投資家のために立ち上がり、公平に接し、投資の成功に向けて最高の機会を提供することです。John、Andrew、そして私からの本日のプレゼンテーションは以上となります。私たちの経験が皆様のお役に立てば幸いです。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion