【report】 Vanguard 重要な取引プラットフォームを AWS に再構築 #FSI322 #AWSreInvent #Vanguard
こんにちは。AWS 事業本部の Yoshi です。
re:Invent 2024 でラスベガスに来ています。
世界最大級の資産運用会社 Vanguard 重要な取引プラットフォームをクラウドネイティブサービスを活用して、メインフレームを再構築した事例に関する session があったので参加してみました。
セッションの概要
タイトル
FSI322 | How Vanguard rebuilt its mission-critical trading application on AWS
説明
Learn how Vanguard rebuilt its retail investor trading platform on AWS to achieve higher resiliency, improve performance, and lower costs by scaling to meet demand. Vanguard adopted AWS Fargate for Amazon ECS to run this mission-critical platform, which uses cloud-native services like Amazon Aurora PostgreSQL-Compatible Edition and Amazon DynamoDB to store and replicate data across Regions, achieving 99.99% availability over the past two years. New features that Vanguard needed months or longer to develop on its legacy mainframe monolith now take only weeks or even days, enabling the company to continuously improve the customer experience and compete effectively.
スピーカー
- Andrew Clemens Director, Vanguard
- Michael Del Rossi Principal, Head of Personal Investor Invest, Architecture & APIs, The Vanguard Group
- John Osborne Senior Solutions Architect, Amazon Web Services
概要
Vanguard は重要な取引プラットフォームを AWS 上で再構築することで、高い回復力、パフォーマンス向上、コスト削減を実現。クラウドネイティブサービスとして AWS Fargate や Amazon Aurora PostgreSQL、DynamoDB などを活用。過去 2 年間で 99.99% の可用性を達成して、従来のメインフレームでは数ヶ月かかっていた新機能開発が、数週間や数日で可能になった。
ポイント
-
- Vanguard とは?
-
- レガシープラットフォームの主な課題
-
- Key Design Goals
-
- Key AWS services
-
- 成果
-
- 教訓
1. Vanguard とは?
世界最大級の資産運用会社
Vanguard の規模
- 世界中に5,000 万人以上の顧客
- 運用資産額 9.9 兆ドル
- 1 日あたり 10-20 億ドルの資金流入
- デジタルチャネルでの取引が 99% 以上
2. レガシープラットフォームの主な課題
Vanguard でも、多くの企業の IT ポートフォリオで見られる一般的な問題を抱えていた。
1. インフラストラクチャの老朽化
- 年々システムが古くなっていく
- メンテナンスコストの増加
- ライセンス費用の増加
2. 人材面の課題
- レガシーシステムの知識を持つスタッフの確保が困難
- 重要な経験を持つ人材の維持が困難
3. アーキテクチャの制約
- 密結合なモノリシックなメインフレームアプリケーション
- 2つのレガシーデータベースへの依存
- オーダー管理システム DB と企業 DB の間の夜間バッチ処理の限界
4. スケーラビリティの問題
- 取引プラットフォームに必要なスケールに対応できない
- 月末、四半期末、年末の負荷に対する制約
- ピーク時の取引実行におけるパフォーマンスの課題
5. デプロイメントの制約
- 四半期ごとのプロダクションリリーススケジュール
- 大規模な変更単位によるデプロイリスク増大
- 新しい顧客体験の迅速な提供が困難
- フロントエンドでの実験が制限される
3. Key Design Goals
5 つの目標があるが全て同等の重要性を持つものとして位置付けられており、優先順位付けはされていない。
1. 取引量の拡大対応
- より多くの取引量に対応可能なシステム構築
- ミーム株取引のような突発的なピークへのシームレスな対応
- クラウドの弾力性を活用した既存モノリシックシステムの制限克服
2. システム可用性の向上
- 取引量増加に伴うシステムの重要性向上
- より高いシステム可用性基準への対応
- 設計における回復力(レジリエンス)の重視
3. 投資家体験の改善
- より迅速な機能提供
- 回復力を損なうことなく市場投入までの時間短縮
- 段階的な体験改善の実現
4. 顧客満足度の向上
- 新しく、より良い体験をVanguardの投資家に提供
- 投資家を中心とした設計思想
- プラットフォームの使いやすさと簡便性の向上
5. コスト削減
- 継続的な総所有コストの削減
- クラウドへの移行に伴う取引量増加への対応
- 投資家へのリターン向上
4. Key AWS services
5 つの目標達成に必要な AWS サービス選定には、運用負荷の軽減を考慮したマネージドサービスを積極的活用。対象障害性・回復力を考慮してマルチリージョン対応を重視した。
データストア
1. Amazon Aurora PostgreSQL
- 複雑なクエリ機能が必要なワークロード向け
- マルチリージョンでのリード処理
- リージョン間の迅速なフェイルオーバー対応
- グローバルデータベース機能の活用
- グローバルライターエンドポイント機能の実装
2. Amazon DynamoDB
- NoSQLキー値ルックアップ向け
- 運用オーバーヘッドの削減
- パッチ適用やメンテナンス作業の軽減
- グローバルテーブル機能の活用
- オンデマンドモードによるスケーラビリティ
- マルチリージョンでの一貫性確保
コンピューティング
1. Amazon ECS (Elastic Container Service)
- コンテナプラットフォームの標準化
- Fargateとの組み合わせによる運用効率化
- パッチ適用やコンテナオーケストレーション管理の簡素化
2. AWS Fargate
- サーバーレスコンテナランタイム
- コンテナインフラストラクチャの管理負荷軽減
- スケーラビリティの向上
フロントエンド
1. Amazon CloudFront
- コンテンツ配信の最適化
- エッジロケーションの活用
- 地理的ルーティング対応
2. Amazon S3
- 静的アセットの保存
- スケーラブルなストレージソリューション
5. 成果
主な成果
- 重大インシデントが 70% 減少
- ソフトウェアデプロイメントが 5 倍に向上
7. 教訓
大規模なモダナイゼーションプロジェクトを成功に導くための重要な指針を説明。
Think Big(大きく考える)
完全なモダナイゼーションを目指す。クラウド移行は単なるインフラ変更ではない、単なるリフト&シフトや表面的な改善では不十分。従来のやり方を根本的に見直す必要性がある。
Remain Flexible(柔軟性を保つ)
スタートした場所がゴールとは限らない、過去の決定の再評価、クラウドの急速な変化へ対応しながら技術選択は状況に応じて見直すことが必要。
Modernization is a Marathon(モダナイゼーションはマラソン)
段階的な価値提供、リスクを小規模に分割して対応。ミッションクリティカルなアプリケーションでは特に重要。
おわりに
Re:invent 参加前に社内にて金融市場でのクラウド利用状況について学ぶ機会があり、重要な取引プラットフォームこそクラウド利用だ!という強いメッセージを感じたのがまだ新しかったので、世界最大級の資産運用会社での大規模なモダナイゼーションプロジェクト成功エピソードはとても勉強になった。
Think Big, Remain Flexible, Modernization is a Marathon !
このブログがどなたかの参考になれば幸いです。
以上、Yoshi でした!