Vanguard が Amazon Redshift マルチウェアハウスアーキテクチャで分析基盤を刷新

本記事は 2026 年 3 月 18 日に公開された「How Vanguard transformed analytics with Amazon Redshift multi-warehouse architecture」を翻訳したものです。

この記事は、Vanguard の Financial Advisor Services 部門の Alex Rabinovich、Anindya Dasgupta、Vijesh Chandran と AWS の共同執筆によるゲスト投稿です。

Vanguard は世界有数の投資会社であり、全世界で 5,000 万人以上の投資家にサービスを提供しています。450 以上の低コストなミューチュアルファンドと ETF を幅広く取り揃え、投資アドバイスや関連する金融サービスを提供しています。約 20,000 人のクルーメンバーを擁し、投資家の長期的な資産形成を支援する低コスト・高品質な投資ソリューションで高い評価を得ています。

Vanguard の Financial Advisor Services (FAS) 部門は、金融サービス業界で最も著名な B2B 事業の一つです。FAS は仲介チャネルを通じて幅広く多様な資産を管理し、全米のアドバイザリーファームやファイナンシャルアドバイザーの広範なネットワークを支援しています。投資商品、モデルポートフォリオ、リサーチ機能、テクノロジーを活用したサポートサービスを一通り提供し、ファイナンシャルアドバイザーがクライアントにより効果的にサービスを提供できるよう支援しています。

ビジネスユースケースと初期アーキテクチャ

FAS の事業規模と複雑さは膨大なデータを生み出し、ビジネスインサイト、規制遵守、業務効率化のための高度な分析機能が求められます。Vanguard はこの課題に対応するため FAS 360 イニシアチブを立ち上げました。FAS 360 は、内部・外部のデータソースを統合したクラウドデータウェアハウスを構築し、FAS を強化することを目指しています。

主なビジネスユースケース:

業務オペレーション – 営業目標の設定、進捗管理、報酬管理を通じて業務効率を高めます。ファイナンシャルアドバイザーのクライアントにおける商品利用パターンのインサイトも提供します。
データサイエンス – 顧客セグメンテーションモデルや通話文字起こし分析で戦略的インサイトを導出します。マーケティングキャンペーンの準備や、営業電話に向けた顧客インサイトの提供も支援します。
探索的分析 – 経営層からのアドホックな質問、What-if シナリオ分析、チャネルマネージャー向けの販売トレンド分析や競合比較分析に対応します。

上記のユースケースを一元化されたシステムに統合し、FAS 360 は Vanguard の FAS 部門全体で一貫したレポーティングとデータドリブンな意思決定を実現しています。

集中型データウェアハウス FAS 360:

Vanguard のモダナイゼーション第 1 弾では、Amazon Simple Storage Service (Amazon S3) 上の Parquet ファイルが散在する「データスワンプ（データの沼地）」から、構造化された統合システムへの移行を行い、FAS 360 を集中型エンタープライズデータウェアハウスとして確立しました。

以下のアーキテクチャ図は、生データの保存に Amazon S3 を活用し、コア処理エンジンとして Amazon Redshift を使用する構成です。BI ツール、アナリストの探索、データサイエンスワークロードへの統合的なアクセスを提供しています。

アーキテクチャで得られた主な成果:

信頼できる唯一の情報源 – 分散していたデータソースを統合システムに集約し、データの不整合を解消して、組織全体で一貫したレポーティングを確立しました
クエリパフォーマンス 10 倍向上 – 以前のソリューションと比較してクエリ応答時間が大幅に改善され、アナリストの生産性向上とより複雑な分析ワークロードの実行が可能になりました
シームレスなデータレイク統合 – より広範なデータレイク環境との接続性を維持しつつ、構造化されたウェアハウス機能を提供しました
ビジネスの俊敏性向上 – メトリクスへの信頼性が高まり、以前は実現困難だった新しいユースケースが可能になり、FAS360 システムへの移行の推進力となりました

集中型アーキテクチャにより、データが個人に分散しガバナンスが限定的だった従来の課題を解決し、その後のアーキテクチャ進化の基盤を確立しました。

急速な成長と拡大するユースケース

Vanguard FAS のデータ分析要件は 2 年間で著しい成長を遂げ、現代のデータニーズの急速な進化を示しています。

初期状態:

日次データロードを処理する AWS Glue ETL ジョブ 20 本
データウェアハウス内のテーブル数約 100
ビジネスユーザー向け Tableau ダッシュボード 20 個
システムにアクセスするアナリスト約 60 名

2 年後:

Amazon Redshift に 20 TB、S3 データレイクに 150 TB のデータ量
複雑なデータ変換を処理する AWS Glue ETL ジョブ 600 本以上 (30 倍増)
多様なビジネスデータを格納するテーブル 300 以上 (3 倍増)
クエリパフォーマンスを最適化する Amazon Redshift マテリアライズドビュー 250 以上
さまざまなビジネス機能に対応する Tableau ダッシュボード 500 以上 (25 倍増)
月間 500,000 以上のユーザークエリ

急激な成長の背景には、リスク管理やコンプライアンスからクライアントサービスの最適化、業務効率改善に至るまで、ビジネス機能全体でデータドリブンな意思決定への依存度が FAS 部門で高まっていることがあります。

リソース競合とパフォーマンスのボトルネック

Vanguard FAS のデータ環境が拡大するにつれ、初期アーキテクチャである 2 ノード (ra3.4xlarge) の単一 Amazon Redshift プロビジョンドクラスターで深刻なパフォーマンス課題が発生し、ビジネスオペレーションに支障をきたすようになりました。

ETL パフォーマンスの問題:

ETL の SLA 違反が頻発し、重要なビジネスプロセスに影響
Tableau データ抽出の失敗によるダッシュボードデータの陳腐化
データ取り込みと変換ワークロード間のリソース競合

エンドユーザー体験の劣化:

ピーク時のクエリパフォーマンス低下
テーブルやオブジェクトのロック問題による同時アクセスの阻害
深い分析探索ができずフラストレーションを抱えるアナリスト
長時間実行の分析クエリが実行困難

運用上の課題:

ETL ワークロードとインタラクティブ分析間のリソース競合
ワークロードタイプごとにコンピューティングリソースを独立してスケールできない
データオペレーション全体に影響する単一障害点
ワークロードの優先順位付けとリソース配分の困難さ

パフォーマンスの課題は、日常の業務レポーティングから戦略的なビジネス分析に至るまで、FAS がデータ資産を効果的に活用する能力を根本的に制限していました。

ソリューション概要

上記の課題に対処するため、Vanguard FAS は Amazon Redshift のデータ共有機能を活用し、ワークロードの分離と独立したスケーリングを実現するマルチウェアハウスアーキテクチャを実装しました。

プロデューサー – Amazon Redshift プロビジョンドクラスター

中央ハブは RA3 ノードを搭載した元の Amazon Redshift プロビジョンドクラスターで構成され、安定した予測可能なワークロード向けに最適化されています。

専用 ETL 処理: データの取り込み、変換、ロード処理を担当
書き込みワークロードの最適化: 干渉なくデータの書き込みと更新を管理
コスト最適化: 予測可能な定常ワークロードにリザーブドインスタンスを活用
データガバナンス: エンタープライズデータの信頼できる唯一の情報源として機能

コンシューマー – Amazon Redshift Serverless ワークグループ

複数の Amazon Redshift Serverless インスタンスが、需要に応じてコンピューティングリソースを自動スケールする専用のコンシューマーエンドポイントとして機能します。

アナリスト探索: アナリストのデータ探索と実験のための専用環境
BI ツール: Tableau ダッシュボードと可視化ワークロードに特化して最適化されたインスタンス
データサイエンス: 完全に分離された環境での複雑かつ長時間実行の機械学習ワークロード向け

Amazon Redshift のネイティブなデータ共有機能により、プロデューサーとコンシューマーインスタンス間をセキュアに接続しています。コンシューマークラスターはデータ移動なしにプロデューサーのライブデータにアクセスでき、常に最新の情報を参照できます。ゼロコピー共有アプローチにより、データの複製や複雑な同期プロセスが不要になり、ストレージコストと運用の複雑さの両方を削減できます。

成果

マルチウェアハウスアーキテクチャの実装により、主要なパフォーマンス指標全体で大幅な改善が実現しました。

安定したパフォーマンス

夜間の ETL サイクルが午前 9 時の SLA 前に安定して完了するようになり、ビジネスオペレーションを妨げていた SLA 違反が解消されました。朝のビジネス活動に向けて最新のデータが確実に利用可能になっています。ダッシュボードやレポートに最新のデータが反映され、チームは意思決定に必要なインサイトを得られるようになりました。

アナリストの生産性と体験の向上

新しいアーキテクチャにより、深いアドホック探索クエリを妨げていた 10 分間のクエリタイムアウト制限が撤廃されました。アナリストは完全に分離された環境で、他のユーザーや ETL プロセスに影響を与えることなく、30 分を超える複雑な分析ワークロードを実行できるようになりました。クエリ応答時間の大幅な短縮と合わせて、チーム全体でアナリストの満足度と生産性が向上しました。

新しい分析機能

マルチウェアハウスアーキテクチャにより、アナリストが CREATE TABLE AS SELECT (CTAS) コマンドでデータを実験できる書き込みアクセス権を持つ専用の「Data Lab」環境が導入されました。各ワークロードタイプが需要に応じて独立してスケールでき、異なるコンシューマークラスターが特定のユースケースに最適化されているため、より高度な分析アプローチが可能になりました。

オペレーショナルエクセレンス

ワークロードの分離により、異なるパターン間でコンピューティングリソースを効率的に活用できるようになり、適切なサイジング、Serverless の従量課金、リザーブドインスタンスの活用によるコスト管理が改善されました。ETL と分析ワークロードの明確な分離により、データプラットフォーム全体の管理が簡素化されました。

継続的なモダナイゼーション: データメッシュアーキテクチャへの進化

Vanguard のデータ環境が成熟し、マルチウェアハウスアーキテクチャの成功が組織全体での幅広い採用を可能にしたことで、組織の成長に合わせたアーキテクチャ進化の機会を認識しました。データプロダクトのポートフォリオ拡大とシステムを活用するチーム数の増加が、新たな改善の機会を生み出しました。

Vanguard のデータ環境が成長するにつれ、3 つの主要な課題が浮上しました。

集中型オーナーシップのボトルネック – 単一チームによるデータオーナーシップでは、増加するデータプロダクトに対応しきれない
書き込みワークロードの競合 – 共有エンドポイントでの書き込み操作にリソース競合が残存
クロスドメインの依存関係 – ビジネスドメイン間のデータオブジェクトの相互依存がデータプロダクト開発を遅延させる

データメッシュ採用の理由

Vanguard がデータメッシュを採用した背景には、以下のニーズがありました。

データオーナーシップの分散化 – 専任のスチュワードを配置したデータドメインを確立
書き込み競合の解消 – 各ドメインのデータロードを個別のエンドポイントに分離
自律的な開発の実現 – スチュワードがデータプロダクトのライフサイクルとガバナンス全体をオーナーシップを持って管理
最新のデータレイク機能の活用 – AWS Glue と Apache Iceberg フォーマットによるデータプロダクトのキュレーション

データメッシュへの進化は、マルチウェアハウスアーキテクチャで達成した技術基盤とオペレーショナルエクセレンスを土台に、Vanguard が組織的にスケールする能力を支えるものです。Amazon Redshift マルチウェアハウス実装の成功を基盤として、Vanguard FAS はデータアーキテクチャ進化の次のフェーズとして、以下のデータメッシュアプローチの検討を進めています。

データメッシュアーキテクチャには、スケーラブルでドメイン指向のデータ管理を実現するために連携する複数の主要コンポーネントがあります。

ドメイン指向のデータオーナーシップ

Vanguard はビジネス機能に沿った個別のデータドメインを確立し、各ドメインに専任のデータスチュワードを配置して明確なオーナーシップとアカウンタビリティを実現しています。集中型のデータ管理から分散型モデルへの移行により、データに近いチームがドメイン固有のニーズについて的確な判断を下せるようになります。

分散型データアーキテクチャ

新しいアーキテクチャでは、ドメイン固有のデータロードを個別のコンピューティングエンドポイントに分離し、各ドメインに独立したデータ処理パイプラインを構築しています。クロスドメインの依存関係や競合が軽減され、チームは組織全体の調整を待つことなく変更の反復とデプロイが可能になります。

データプロダクトアプローチ

Vanguard は Apache Iceberg フォーマットを使用してデータレイク上でデータプロダクトをキュレーションし、メトリクスの計算とデータレイク統合に AWS Glue を活用しています。データをプロダクトとして扱い、定義された SLA と品質メトリクスを設定することで、ダウンストリームのコンシューマーが信頼して利用できる高品質なデータ配信を実現しています。

セルフサービス分析

ドメインチームはエンタープライズガバナンス基準を維持しながら、データプロダクトのライフサイクル全体を独立して管理できます。Vanguard は独立したデータ管理のためのツールとシステムを提供し、データ品質やセキュリティを損なうことなく迅速なイノベーションを可能にし、組織全体でインサイト獲得までの時間を短縮しています。集中型データウェアハウスからマルチウェアハウスアーキテクチャ、そして完全に分散されたドメイン指向のデータメッシュへの進化は、Vanguard の継続的な成長に対応する自然な発展です。

まとめ

Vanguard Financial Advisor Services の取り組みは、分析のスケーリングが単一ウェアハウスの拡大ではなく、ワークロードの分離、独立したスケーリング、組織の成長に対応するアーキテクチャ設計にあることを示しています。

2 ノードの RA3 プロビジョンドクラスターから Amazon Redshift Serverless とプロビジョンドを組み合わせたマルチウェアハウスアーキテクチャへの進化により、Vanguard は本番環境で以下の成果を達成しました。

月間 500,000 以上のクエリを ETL やダッシュボードの競合なしに処理
ETL SLA 遵守率 100% – 夜間パイプラインが午前 9 時前に完了
BI 利用 25 倍増 (Tableau ダッシュボード 20 → 500 以上) をパフォーマンス劣化なしに実現
アナリスト数 8 倍増 (60 → 500 名以上) をワークロード分離で実現
ETL パイプライン 30 倍増 (20 → 600 本以上) を取り込みロジックの再設計なしに実現
Amazon Redshift のゼロコピーデータ共有をプロデューサーとコンシューマーウェアハウス間で実現し、データの複製と同期コストを最小化
10 分間のクエリ制限を撤廃し、高度な探索的分析や長時間実行の分析を実現

注目すべきは、コンピューティングの過剰プロビジョニングではなく、ワークロードごとのコンピューティングの適正化と専門化で成果を達成した点です。需要が予測可能な ETL にはキャパシティを予約し、需要が変動する BI やアドホック分析には Amazon Redshift Serverless の自動スケーリングを活用しています。

Vanguard がドメイン指向のデータメッシュへと進む中、マルチウェアハウスアーキテクチャは組織のスケール、データプロダクトのオーナーシップ、自律的な分析を実現するための基盤であるという教訓が得られました。データ分析要件の成長に直面している組織にとって、Vanguard のアプローチは参考になるでしょう。適切なアーキテクチャと AWS サービスの活用により、パフォーマンスの大幅な改善、コスト削減、ビジネス価値の創出を加速する新しい分析機能を実現できます。

AWS では、AWS アカウントチームにご連絡いただき、AWS アナリティクススペシャリストによるアーキテクチャガイダンスとお客様に合わせた推奨事項をご活用ください。

© 2026 The Vanguard Group, Inc. and Amazon Web Services, Inc. All rights reserved. This material is provided for informational purposes only and is not intended to be investment advice or a recommendation to take any particular investment action.

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

Amazon Web Services ブログ