re:Invent 2025: Amazon RedshiftマルチウェアハウスアーキテクチャとVanguard事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Scaling Amazon Redshift with a multi-warehouse architecture (ANT318)
この動画では、Amazon Redshiftのマルチウェアハウスアーキテクチャによるスケーリングのベストプラクティスが解説されています。モノリシックなコンピュートクラスタで発生するワークロード干渉の課題に対し、hub and spokeパターンとdata meshパターンという2つの設計パターンが紹介されます。Vanguardの事例では、データレイクからの移行、集中型データウェアハウスの構築、そしてマルチウェアハウスアーキテクチャへの進化が語られ、SLA改善やアナリストエクスペリエンス向上などの成果が示されます。デモでは、Zero ETL integrationによるOracleデータの取り込み、SageMaker Catalogでの権限管理、Bedrock Knowledge Baseを活用した自然言語クエリの実装が実演され、ワークロード分離を実現しながらデータの単一コピーを維持する方法が具体的に示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション導入：ダッシュボード障害から見えたマルチウェアハウスアーキテクチャの必要性
こんなシーンを想像してみてください。月曜日の朝、今日みたいな良い天気の日に、CEOから電話がかかってきます。ダッシュボードが読み込まれていないことに満足していません。調べてみると、データサイエンスチームが週末に同じコンピュートで大規模なトレーニングジョブを開始していることに気づきます。そこからは状況を把握しようと奮闘することになります。このような問題に心当たりはありませんか？もしそうなら、あなたは正しいセッションにいます。今日は Redshift のマルチウェアハウスアーキテクチャでのスケーリングについてお話しします。私の名前は Naresh Chainani で、Redshift のエンジニアリングディレクターです。本当に嬉しいことに、Vanguard のデータエンジニアリング部門のディレクターである Alex Rabinovich と、AWS のシニアスペシャリストアーキテクトである Anusha Challa をお迎えしています。一緒に、マルチウェアハウスアーキテクチャに関するベストプラクティスをご紹介していきます。
今日のお話しの流れをご紹介します。まず、マルチウェアハウスアーキテクチャの設計パターンの概要から始めます。問題ステートメントと、世界中の私たちの大規模なフリートで見られている新しいパターンからです。その後、Redshift のマルチウェアハウスアーキテクチャを支えるものについて、舞台裏を少し覗いてみます。その時点で、Alex にバトンタッチして、Vanguard がここ数年でマルチウェアハウスアーキテクチャでどのようにスケールしてきたかについて説明してもらいます。最後に、Anusha が今日のために特別に用意したデモで、このアーキテクチャをいかに素早く始められるか、そしていくつかのベストプラクティスをお見せします。質問の時間も少し残しておきたいのですが、もし質問があってもその時間に答えられなくても心配しないでください。セッション後も私たちはここにいますので、喜んでお話しして、皆さんの経験から学ばせていただきたいと思います。
手を挙げてもらいたいのですが、この部屋にいる方の中で、すでに Redshift でマルチウェアハウスアーキテクチャを使用している方はいますか？何人かの専門家がこの部屋にいますね。素晴らしい。これは素晴らしい会話になるはずです。
モノリシックアーキテクチャの課題とHub and Spokeパターンによる解決
設計パターンについて深く掘り下げる前に、問題ステートメントを見てみましょう。この画像に見えるのは、モノリシックなコンピュート、つまり単一のコンピュートクラスタに似た大きな六角形です。これの上で実行されているのは、ストリーミングとバッチインジェスション、リアルタイムインジェスションとバッチインジェスション用のライターアプリケーション、そしてサイエンスチームやダッシュボードのような消費チームです。このクラスタとアーキテクチャはスケールしますが、ある時点を超えると、私が最初に説明したようなワークロード干渉に関する課題に直面します。何が起こるかというと、バッチインジェスションに大量のデータがある場合、それがインジェスション SLA に干渉し始める可能性があります。サイエンスチームとダッシュボードチームも同じ場所で作業しようとしている場合です。このリソース競合とワークロード干渉は、今日ご紹介する最初のパターンで完全に解決できます。これを hub and spoke と呼んでいます。
あの大きなコンピュートクラスタ、大きな六角形を見てください。今それはより小さな部分に分割されています。ここにはいくつかの利点があります。まず、誰もが自分のエンドポイントまたはコンピュートを持っています。ストリーミングインジェスションとバッチインジェスションは、それぞれのコンピュートニーズに基づいてサイズ設定されています。素晴らしいのは、課金制度も導入できるということです。例えば、サイエンスチームが一定の予算を持っている場合、独立してスケールできます。何より、完全なワークロード分離があります。すべてのワークロードは、他のワークロードと調整したり干渉したりすることなく、独立して進行します。設計の良いテストは、それが今日うまく機能するだけでなく、明日のニーズに対応できるかどうかです。このパターンでは、追加のエンドポイントをスピンアップできます。例えば、四半期末の処理があり、SEC のレポーティングガイドラインを満たすために非常に大きなコンピュートが必要な場合、数分以内にスピンアップして、別のコンピュートを接続できます。中央には、Redshift Managed Storage と呼ばれるものがあります。これが Redshift のデータです。このテクノロジーを使用する場合、あなたが持つかもしれない質問の一つは、データのコピーを作成しているのかということです。
答えはノーです。もしあなたのビジネスの中でコピーを作成する理由が見当たるなら、ぜひその理由を見直してみることをお勧めします。なぜなら、コピーを作成することは問題になるからです。特にデータ量が増えるにつれてそうです。コピーの管理は悪夢になります。ですから、データに対して単一の情報源となるソリューションを持つことが重要です。このアーキテクチャでは、ストリーミング取り込みとバッチ取り込みの両方がそのデータの1つのコピーに書き込みを行い、すべてのコンシューマーはスナップショット分離を使用してそれを消費しています。つまり、データウェアハウスで慣れているトランザクションのすべてのメリットが得られるわけです。
これはこのアーキテクチャの一つのバリエーションです。AWS では、お客様がどのようにクリエイティブなことをしているのかを聞いたり見たりするのが大好きです。特に複数テナント型の ISP プロバイダーなど、複数のお客様で見られたことの一つは、このマルチウェアハウスアーキテクチャと、コンピュートクラスタが異なるリージョンに配置できるという機能を活用したことです。その考え方は、世界中の異なる場所にテナントを配置できるということで、実際にテナントアプリケーションがある場所に近いコンピュートを配置できるということです。ここで、ネットワークレイテンシーの物理的な特性が全体的なエクスペリエンスに役立つわけです。
マルチリージョンのユースケースでも、やはりデータの1つのコピーがプライマリリージョンに保存されています。素晴らしいことは、今度は異なるプロバイダーに対して異なるサービス品質と異なるティアを提供することもできるということです。非常に大規模な顧客の中には、より大きなコンピュートから恩恵を受ける可能性のある顧客もいますし、複数の小規模な顧客を1つのエンドポイントにグループ化することもできます。そこには多くの柔軟性があります。
エンタープライズ組織におけるData Meshアーキテクチャの活用
別の問題とデザインパターンを見てみましょう。これは非常に似ていますが、今度は再びモノリシッククラスタがあるのですが、今回は異なるアプリケーションではなく異なるチームがあります。これは通常、大規模なエンタープライズで見られるものです。財務、マーケティング、HR など、異なるチーム、時には組織内のサイロがリソースを共有しています。これは複雑な調整につながります。例えば、財務が月次決算を進めようとしていて、マーケティングが今後のキャンペーンを検討しようとしている場合、ニーズが予測不可能であれば調整する必要があります。データで最近ますます見られていることの一つは、多くの新しいユースケースがあるということです。なぜなら、事前に決められたユースケースで自分たちを制限したくないからです。特にデータと AI が一緒になるにつれて、どのような価値を引き出せるかを探索したいのです。
ですから、再び同じパターンを使用することで、そのモノリシックを複数の部分に分割することができます。この場合、すべてのチームが独自のエンドポイントを持つようになり、HR と財務のこのエンドポイントは基本的に非常にクリーンなチャージバックモデルを持っており、エンタープライズ内のビジネスユニットにそれをチャージバックします。このアーキテクチャを思い出してください。前のものは Hub and Spoke でしたが、そこには集中型のチームがライトをキュレーションし、多くのコンシューマーに公開していました。この場合、すべてのユニット、すべてのエンタープライズユニットが自分たちのデータとデータの一部を所有しています。財務データは、例えば R&D データとは異なります。ですから、このアーキテクチャは data mesh と呼ばれています。
このアーキテクチャでは、データオーナーが誰とデータを共有するか、そしてどのデータを共有するかを決定します。この共有はデータベースレベル、スキーマレベル、テーブルレベルで行うことができますし、さらに細かい粒度で行レベルまたは列レベルで行うこともできます。では、マルチウェアハウスアーキテクチャの背後にある仕組みを見てみましょう。
Redshift Managed Storageとサーバーレス・プロビジョニング型のハイブリッド構成
ストレージレイヤーでは、Redshift Managed Storage があります。これは高性能な列指向ストレージで、キャッシュ効率的な処理と CPU フレンドリーなパイプラインを目指した、最も高度で独自のエンコーディングを使用しています。実は、ハードウェア命令を活用してデータを処理できるラインレートを最適化しています。これが、例えば 2 秒の SLA ダッシュボードを実現する際に Redshift から得られるパフォーマンス上の利点です。コンピュート側では、Redshift のプロビジョニング型とサーバーレス型の組み合わせがあり、お客様の間で見られている新しいパターンとしてハイブリッドアーキテクチャがあります。このアーキテクチャでは、定常的で予測可能な常時稼働ワークロード用にプロビジョニング型キャパシティを使用し、散発的またはスパイク状のアクセスを扱うビジネスユニット用にサーバーレス型を使用します。
スケールアップとオートスケーリングなどのサーバーレスの特性は、こうしたシナリオで有益です。使用したコンピュートに対してのみ料金を支払い、このアーキテクチャの良いところは、ハブアンドスポークパターンまたはデータメッシュパターンのいずれかで組み合わせることができるという点です。どのような組み合わせでも可能です。すべてプロビジョニング型にすることもできますし、すべてサーバーレス型にすることもできますし、混合することもできます。サーバーレス型を検討することを強くお勧めします。お客様はそれがもたらす使いやすさを気に入っていますし、データレイヤーに関しては同じ単一の情報源をクエリできます。
これらのコンピュートクラスタは同じ AWS アカウント内にある必要はありません。複数のアカウント間に分散させることもできますし、リージョン間にすることもできます。この最後のポイントは、特にデータソブリンティに対処する必要がある同僚にとって重要になる可能性があります。EU は、EU の境界外に出ることができるデータについて、という点で非常に先を行っています。パーミッショニングに関する素晴らしい機能がいくつかあり、それについては数分後に説明します。
これは先週ローンチした新しい機能です。これはマルチウェアハウスアーキテクチャのガバナンスを統一します。これまでの私の説明を通じて、データの単一コピーがあることについて述べてきました。お客様から聞いた課題の 1 つは、それでもパーミッションをレプリケートする必要があるということです。標準的な慣行として、これらは追加のコンピュートクラスタであり、そこに細かい粒度のアクセス制御とパーミッションを再度配置する必要があり、それが一定のポイントを超えてスケールするのが難しくなっていました。パーミッションを一貫して管理するという行為だけでも、彼らにとって課題でした。
Federated permissions では、こういったことが起こります。 例を見てみましょう。Finance チームは細粒度のアクセス制御を実現したいので、低レベルのセキュリティポリシーを作成します。この場合、ポリシーはデータソブリンティに関連付けられており、ログインするユーザーは、アクセスしようとしている顧客データの地域から来ている必要があります。このポリシーは顧客テーブルにアタッチされます。その後、ポリシーは Identity Center の sales ロールなどのロールに割り当てられます。Sales analyst が自分のコンピュートクラスタを使ってログインすると、 通常通りこの顧客テーブルをクエリし、その時点で、ポリシーが許可するデータのみが表示されます。自分が属している地域の顧客データのみが表示されます。
この機能が federated permissions です。ぜひこれを確認してみることをお勧めします。先週ローンチされたばかりで、現在も世界中にロールアウト中です。基本的な考え方は、データのコピーが 1 つあるのと同じように、権限のコピーも 1 つあるということです。 Redshift の managed storage についてはたくさん話してきました。これはあなたの Redshift に保存された、分析用に高度に最適化されたデータです。もう 1 つのトレンドとして、私たちの最大規模の顧客の半分以上が、Redshift に加えて、lake データも使用しているということです。Iceberg は AWS 全体で見られる新興トレンドです。Iceberg のようなオープンテーブルフォーマットは、トランザクション性の利点を提供するため、非常に重要です。これは多くのアプリケーションにとって重要です。また、Iceberg データを読み取ることができる任意のコンシューマー、任意のエンジンが、オープンスタンダードであるため相互運用性を提供します。
Redshift では、Redshift に存在するデータと Iceberg データまたは Parquet データを組み合わせることができます。実際、同じクエリで、これら 2 つのテーブル間のデータをジョインすることもできます。例えば、lake にあるランディングゾーンデータと、高度にキュレーションされたデータがある場合、アプリケーションを構築する際に、同じ単位の作業内でそれらをジョインしています。 年初から今日まで、Amazon Redshift Serverless を使用して Iceberg クエリ処理のパフォーマンスを 2 倍以上改善しました。
これはカスタムに対応し続けているだけです。データについて収集する高度な統計情報や、Redshift が持つ高性能クエリ処理技術など、Iceberg に拡張している多くのことがあります。まだ終わっていません。このジャーニーは続きます。また、Iceberg への書き込みも導入しました。これまで読み取りについて話してきましたが、追記専用ワークロードへの書き込みが開始され、数週間前にローンチされました。
SageMaker Unified Studioによるデータと生成AIの統合エコシステム
Redshift についてはたくさん話してきました。しかし、分析の世界は Redshift だけではありません。データウェアハウスがあり、その周りにエコシステムがあります。では、Redshift はそこにどのようにフィットし、どのようにそのエコシステム全体を拡張して活用するのでしょうか。昨年、私たちは SageMaker Unified Studio をローンチしました。これはデータと AI に関するすべてのことのランディングプレイスでした。では、SageMaker Unified Studio とは何でしょうか。基本的には、ワンストップショップであることを想定しています。SQL ノートブック、Jupyter ノートブック、そして自然言語クエリ機能があります。基本的な考え方は、1 つの場所でデータと AI アプリケーションを構築できるようにすることです。
SageMaker プラットフォームのストレージレイヤーには、すべてのデータがあります。これには Redshift のデータが含まれ、Iceberg も含まれています。この Iceberg は、通常の S3 バケットで自己管理することもできますし、AWS が S3 Tables で管理することもできます。S3 Tables を検討したい理由の 1 つは、実際にはパフォーマンスが向上するということです。なぜなら S3 が compaction のような重い処理を引き受けてくれるからです。小さなデータファイルは lake オブジェクトにアクセスする際に問題になる傾向がありますが、S3 が compaction することでその重い処理を取り除き、これは engine と S3 Tables の間のコラボレーションでますます進んでいきます。皆さんにはこれをぜひ確認してみることをお勧めします。
このすべてのデータは SageMaker Catalog に表示されるため、データを発見し、ガバナンスすることができます。ここまでは、Redshift Serverless とプロビジョニング型の組み合わせをどのように使用できるかについて話してきました。すべてのデータウェアハウジングのユースケースが満たされます。 さらに一歩進めると、Amazon Athena のような他の engine があるかもしれませんし、データ処理や変換を行う Spark ジョブがあるかもしれません。これらすべては、例えば Spark からこのデータのいずれかを使用できるという同じ体験の一部です。
これを可能にする重要なポイントは、すべてのインターフェースが Iceberg の IRC、つまり Iceberg REST Catalog API を使用しているということです。これはオープン API です。その後、BI とオーケストレーションツール、Amazon QuickSight とジョブをオーケストレートする Airflow があります。最後になりますが、Gen AI アプリケーションがあり、今年は顧客との会話がますます増えています。「Redshift のデータを agentic アプリケーションで簡単に使用するにはどうすればいいのか」という内容です。これについては少し後で話します。データと AI は本当に同じコインの両面だと考えています。適切なコンテキストは、agentic AI アプリケーションの有効性に大きな違いをもたらすことができます。IRC、つまり Iceberg REST Catalog API を通じたすべてのアクセスが重要だということを思い出してください。
つまり、このエコシステム全体へのアクセスが AWS ツールと engine に限定されていないという力を与えてくれるということです。実際には、その API を話す任意のサードパーティ engine を持ち込むことができます。 約束通り、Redshift で顧客が今日行っている Gen AI のユースケースをいくつか紹介して締めくくります。まず第一に、SageMaker Unified Studio またはクエリエディタを通じて、アナリストはデータとチャットすることができます。これは非常に簡単なソリューションです。生産性の向上に役立ちます。もはやアナリストが最初に開発チームに話しかけて、探索を始める前に SQL ダッシュボードを構築してもらう必要はありません。
これが最初のことで、皆さんにはぜひ試してみることをお勧めします。クエリエディタでは、Amazon Q Generative SQL です。すべての Gen AI アプリケーションの周りでこの Q というブランディングが見られます。次に、データが推論の信頼性と精度にとってどれほど重要であるかについて話したことを思い出してください。実際には、Amazon Redshift のデータを Bedrock アプリケーションのナレッジベースとして使用することができます。以前は、データをアンロードして利用可能にする必要があった時代がありました。すべてが大幅に簡素化されました。さらに一歩進めました。Redshift の SQL コマンドラインから、Bedrock を直接呼び出すことができます。この例では、Anthropic Claude を指す外部モデルを作成し、reviews テーブルを取得して、Redshift SQL エディタから Claude を使用してセンチメント分析を実行します。
最後に、多くの AWS サービスについて、MCP サーバーがあります。MCP は Model Context Protocol の略です。基本的な考え方は、オーケストレーター エージェントが広範なエージェンティック AI アプリケーションを構築するために調整している際に、MCP 標準の一部になることを簡単にしようということです。これは約3ヶ月前にローンチしたものです。ここで、Vanguard のマルチウェアハウス アーキテクチャへの取り組みと、マルチウェアハウス アーキテクチャを構築するためのさまざまな設計パターンについて説明していただくために、Alex をお迎えしたいと思います。Vanguard のお客様の方は手を挙げてください。わかりました、何人か手を挙げていますね。Vanguard のお客様として信頼いただき、本当にありがとうございます。
Vanguardの事例：Client 360システムの進化とスケーリングの課題
私は Alex Rabinovich で、Data Engineering のディレクターです。 Vanguard は世界有数の投資会社で、 ミューチュアルファンド、ETF、アドバイスなどの低コスト商品を提供しています。私は Financial Advisory Services 部門をサポートしています。私たちを B2B ビジネスと考えてください。銀行、保険会社、登録投資会社などの仲介業者に対して、さまざまな商品とサービスを提供しています。本日は、ビジネスニーズを満たすためにアーキテクチャをどのように進化させたかについてお話しします。
私たちは Client 360 システムの構築から始めました。 Client 360 は、仲介業者企業に関する内部および外部データの集約です。内部の運用システムからデータを取得し、外部のデータ集約業者から購入できるデータも取得しています。さまざまなユースケースにデータを使用しています。分析とビジネスインテリジェンスのユースケースが主なものです。データを使用して営業目標、営業報酬、年間目標を設定し、それらの目標をダッシュボードで追跡しています。さらに、顧客セグメンテーション、通話トランスクリプション、センチメント分析などの予測インテリジェンスのユースケースもあります。
また、リアルタイムカスタマーエクスペリエンスのためにデータを使用しています。例えば、ハイパーパーソナライゼーションです。外部の仲介業者のアドバイザーが advisor.vanguard.com にログインすると、彼らが見ている商品に基づいて彼らのエクスペリエンスをカスタマイズします。そのインテリジェンスは営業チームに入り、営業チームは適切なアドバイザーと連絡を取り、適切なタイミングで適切な情報を提供できるようになります。数年前、私たちはアーキテクチャを見直し、すべてのデータソースが S3 上のさまざまなフォルダにあるデータレイクに保存されていることに気づきました。Parquet 形式で S3 にデータを保存していました。
データアナリストがデータに基づいてインサイトを構築することは非常に困難でした。彼らは異なるツールを使用してさまざまなデータ形式から手動でデータを事前集約する必要がありました。その結果、1 人のアナリストが別のアナリストと簡単にインサイトを共有できないため、複数のバージョンの真実が生まれました。努力の重複があり、パフォーマンスが低下していました。CSV ファイルと Parquet ファイルを結合してインサイトを導き出すことは実際に非常に困難でした。
また、レポーティングの一貫性に問題がありました。データアナリストがビジネスルールを複製して、別のデータアナリストに引き継ぐことがありました。統一されたゴールデンレコードがなかったため、その上にビジネスインテリジェンスを構築することができず、スケーリングが課題でした。つまり、データ沼の状態だったんです。そこで、最初の近代化の波に乗り出すことにしました。 Redshift プロビジョニングプラットフォーム上に Client 360 という集中型エンタープライズデータウェアハウスを構築することにしました。データレイクからすべてのデータを取得し、Amazon AWS Glue サービスを通じて変換し、Amazon Redshift プロビジョニングサーバーにデータをロードしました。
ビジネスインテリジェンス、アナリティクス、データサイエンスなど、複数のユースケースを実現することができました。最初の近代化の波の後、多くのメリットが得られました。 データが一箇所に集約されたゴールデンソースを手に入れることができたんです。集中型データウェアハウスの上にビジネスインテリジェンスを構築するのが非常に簡単になりました。データが事前集約されていたため、パフォーマンスが大幅に向上しました。クエリを実行するたびに、Redshift の高性能なコンピュートとストレージを活用することができるようになったんです。
また、ビジネス側からの信頼も向上しました。異なるビジネスインテリジェンスのユースケース全体で、データが一貫して表示されるようになったからです。新しいユースケースを実現することもできました。私のお気に入りは comparative product analysis で、データアナリストが Client 360 のデータを見て、Vanguard が提供している商品と競合他社が提供している商品を比較することができるようになったんです。その深い洞察と調査の結果、アナリストは Vanguard が提供すべき新しい商品を推奨し、Vanguard はそれを実際に提供することになりました。
ここに、私たちが保存しているデータの量があります。 Redshift マネージドストレージに 20 テラバイト以上のデータを保存し、S3 データレイクに 150 テラバイト以上のデータを保存しています。600 以上のテーブルと 400 のビューがあります。アナリスト、データエンジニア、データサイエンティストで構成される約 100 人のアクティブユーザーがいて、月に 50 万件以上のクエリを実行しています。これらすべてが数千のバッチジョブによって支えられています。
最初の集中化の波の後、 データベースオブジェクト、ストレージ、ユースケースの数が指数関数的に増加しました。データベースオブジェクトの数は年々倍増しました。自分たちの成功の犠牲になってしまったんです。 リソース競合の問題が発生し始め、スケーリングの課題も出てきました。例えば、ETL ジョブを実行するときに、ビジネスインテリジェンスやアドホッククエリなどの競合する分析ワークロードが安定ロックをかけると、ETL ジョブが遅延し、SLA を満たすことができなくなってしまったんです。
ピークタイムのパフォーマンスにも問題がありました。ETL ジョブがビジネスアワー中に実行されると、データアナリストたちが同じコンピュートリソースを共有していたため、ユーザーエクスペリエンスに悪影響が出ていました。ワークロード管理の複雑さも課題でした。ジョブを高い優先度で実行する一方で、アナリストが実行する分析ワークロードは低い優先度に設定していたため、アナリストのユーザーエクスペリエンスが低下していました。
さらに、特定のデータベースオブジェクトの再作成に長時間かかるという問題も発生していました。例えば、マテリアライズドビューの再構築に非常に長い時間がかかっていました。実際のところ、特定の種類のデータベース操作については、マテリアライズドビューの再構築に時間がかかりすぎるため、週末に再構築を行わなければならない状況でした。これにより、データエンジニアリング部門に大きな負担がかかっていたため、週末を取り戻すことを決めました。
Vanguardのマルチウェアハウスアーキテクチャへの移行とData Meshへの展開
集中型のモノリシックアーキテクチャ から、分散型のマルチウェアハウスアーキテクチャ、つまりハブアンドスポークモデルに移行しました。右側に複数の Redshift インスタンスをプロビジョニングしているのが見えます。ワークロードタイプ別に複数のインスタンスがプロビジョニングされています。analytics、business intelligence、data science ワークロード用です。左側のアーキテクチャは同じままです。相変わらず AWS Glue を経由して S3 から Redshift プロビジョニングサーバーにデータを取り込んでいます。データは Redshift マネージドサービスに保存され、その後 Datashares を機構として使用して、さまざまなワークロードにデータを公開しています。
モダナイゼーションの第二段階以降、多くのメリットが得られました。 SLA が改善されました。競合が減少したからです。これで ETL ジョブが分析ワークロードと競合する必要がなくなりました。また、アナリストのエクスペリエンスも大幅に向上しました。専用の Redshift コンピュートインスタンスにアナリストを配置できるようになったからです。アナリストがバッチジョブと同じコンピュートリソースを争う必要がなくなりました。以前は、アナリストワークロードは低い優先度で実行されていました。新しいアーキテクチャでは、analytics ワークロードが最高優先度で実行されます。
新しいコンピュート環境でサンドボックスの概念を実現することもできました。アナリストが永続テーブルを構築して、より複雑な分析とインサイトを得ることができるようになりました。これを self-service analytics と呼んでいます。新たな課題も浮かび上がってきました。 最大の課題は、集中型のデータ所有権です。集中型データウェアハウスで 1000 個のデータベースオブジェクトを管理することは、データガバナンスなどの複雑さをもたらします。また、書き込みの単一エンドポイントという課題も見られました。ETL ジョブ同士がまだ競合しており、あるジョブがロックをかけると、別のジョブの完了が妨げられることがあります。右側ではリソース競合の問題も見られました。また、マテリアライズドビューなどのクロスドメイン依存性の課題も見られ、これが俊敏性を低下させていました。
これは私たちの将来のアーキテクチャで、進行中の data mesh です。 左側では、データを S3 バケットにロードしています。AWS Glue を使用してデータを Iceberg というオープンファイル形式に変換します。ここでの重要な違いは、データのドメインを別々の Iceberg テーブルに分離することで、ETL ジョブを並列で実行できるようにしたことです。高いパフォーマンスのために増分マテリアライズドビューを使用し、Iceberg から Redshift インスタンスにデータをロードします。中央に見える Redshift マネージドストレージ内のすべてのデータは、ワークロードで分割されている私たちのコンシューマー全体で共有されます。ビジネスインテリジェンス、アナリティクス、データサイエンスのワークロードがあります。
まとめると、右側でワークロードをファンアウトできるようになりました。すべてのデータプロデューサーは独自のコンピュートを持ち、すべてのデータコンシューマーも独自のコンピュートを持っています。学んだ教訓：シンプルに始めましょう。 プロビジョニングされたアーキテクチャまたはサーバーレスアーキテクチャのいずれかで、単一のサーバーから始めて、アーキテクチャに成長させていきます。
アーキテクチャの限界に達したら、再アーキテクチャする準備をしておきましょう。私たちはアーキテクチャの限界に達するたびに AWS ソリューションパートナーと協力し、彼らと手を取り合って作業します。新しい機能の採用に柔軟で開放的でいましょう。数年間にわたって、Redshift チームは data share や Redshift Serverless などの主要な機能をリリースしてきました。新しい機能を見るたびに、私たちはそれを立ち止まって、その新しい機能をアーキテクチャでどのように活用できるかを理解する必要がありました。成功を測定するためにメトリクスを追跡しましょう。私たちはアクティブユーザー数、テーブル数、ストレージコスト、クエリ数、およびクエリタイムアウト数を追跡しています。
まとめると、私たちは data swamp から始まりました。集中型ウェアハウスアーキテクチャに移行し、その後ハブアンドスポークモデルに移行し、今は data mesh の世界にいます。これが私たちの進化の旅です。そこで、Anusha にステージを譲りたいと思います。彼は demo を通じて私たちを案内してくれます。Alex、あなたの旅を共有してくれてありがとうございました。Vanguard と協力できて AWS チームにとって喜びでした。次のパートでは、マルチウェアハウスアーキテクチャを構築する方法についてのデモをお見せします。
Any Companyのデモ：Zero ETL統合からBedrock Knowledge Baseまでの実装
では、グラフを見てみましょう。このスライドに表示されているグラフは、モノリスの例です。AlexとNareshはモノリスアーキテクチャで直面する課題について話しましたが、このグラフはそれらの課題を数字で表しています。赤で表示されているのはキューに入ったクエリの数です。つまり、クエリを送信したけれど、クエリが実行されず、実行順番を待っている状態です。キューイングは競合の兆候の1つであり、ご覧の通り、このグラフには赤がたくさんあります。
これをマルチウェアハウスアーキテクチャとして再設計し、各部門が独自のエンドポイントを持つようにすると、更新されたグラフでは、赤がほとんど見られません。これは、再設計された世界ではコンテンションが大幅に減少したことを意味します。これがマルチウェアハウスアーキテクチャがワークロードにもたらすことができるポジティブな違いです。
では、デモに移りましょう。デモでは、エンドツーエンドのマルチウェアハウスアーキテクチャを構築する方法をお見せします。このユースケースは、Any Companyという架空の企業に属しています。Any Companyには2つの主要なソースがあります。1つはAny Companyの売上データを含むOracleデータベースです。もう1つは彼らのウェブサイトから来るクリックストリームソースです。
Any Companyには3つの主要なユースケースがあります。まず、すべてのこのデータを取り込み、データを変換し、特定のビジネスロジックを適用することで、そこから洞察を抽出したいと考えています。次に、抽出されたメトリクスの上でレポーティングを実行したいと考えており、ビジネス上の意思決定者がそれを使用してビジネス上の意思決定を行うことができます。3番目に、データの民主化を行いたいと考えています。SQLの書き方を知っているかどうかに関係なく、洞察を求める誰もがこのデータを利用できるようにしたいのです。そのため、生成AIの力を使用してユーザーがこのデータをクエリできるようにするための自然言語インターフェースを提供したいと考えています。
これらが3つの主要なユースケースです。彼らが確認したいことの1つは、これらのユースケースが互いに干渉しないようにすることです。特に、生成AIアプリケーションを通じて来るアドホッククエリです。これらがビジネスクリティカルなETLやビジネスクリティカルなレポーティングに影響を与えるべきではありません。レポーティングはETLに干渉すべきではなく、ETLはレポーティングに干渉すべきではありません。これらは完全に分離されるべきです。これを実現する最良の方法は、マルチウェアハウスアーキテクチャを通じてです。
では、Any Company がマルチウェアハウスアーキテクチャを通じてこれをどのように実現したかを、ステップバイステップで見ていきましょう。まず、彼らは実行したい各ワークロードに対して、3つの別々のエンドポイントを作成しました 。左側には、データロードと変換エンドポイントがあります。右側には、レポーティングが完全に分離された状態で行われるレポーティングウェアハウスがあります。3つ目は、生成 AI ウェアハウスです。
このウェアハウスでは、自然言語クエリを使用してデータにアクセスします。最初のエンドポイント、つまりデータロードと変換を使用して、Any Company は Sales の Oracle データベースから Zero ETL インテグレーションを使用してデータを取り込みます。Zero ETL インテグレーションは、ご存知の方もいるかもしれませんが、ソースがサポートされている場合、最も簡単な方法で Redshift にデータを取り込むことができます。今日、Zero ETL インテグレーションを使用している人はいますか？何人か手を挙げているのが見えます。ソースが Zero ETL インテグレーションでサポートされている場合、それは Redshift にデータを取り込む最も簡単な方法です。データは継続的に Redshift にレプリケートされます。必要なのは一度セットアップするだけで、リアルタイムでデータがレプリケートされます。
今年、数ヶ月前に Oracle 用の Zero ETL インテグレーションをリリースしました。ですから、Oracle ソースをお持ちでしたら、これから恩恵を受けることができます。データロードと変換エンドポイントを使用して、Any Company は Oracle RDS データベースからのデータを Redshift にカラムナー形式でレプリケートしているため、トランザクショナルデータはわずか数秒以内に分析用として利用可能になります。2つ目のソースである Clickstream は Firehose から来ています。Firehose データは Apache Iceberg 形式で S3 の完全マネージド Iceberg テーブルに書き込むことができます。Clickstream データを S3 テーブルに Apache Iceberg 形式でロードする別のパイプラインがあります。これはデータウェアハウスとデータレイクの両方を形成します。
彼らはそれを SageMaker Catalog を使用してカタログ化しており、そこでパーミッション管理を行っています 。カタログを使用して、誰が何を見ることができるかを制御しています。その後、レポーティングはレポーティングウェアハウスを使用して行われます 。そして、生成 AI アプリは生成 AI ウェアハウスを使用します。これでアーキテクチャが完成します。取り込みが行われ、カタログ化が行われ、パーミッション管理が行われ、右側ではレポーティングと生成 AI および自然言語クエリのユースケースのためのデータ消費が行われています。次の数分間で、これを詳しく見ていき、これらのそれぞれがどのように機能するかを確認します。
最初のステップは、各ワークロード用に別々のウェアハウスを作成することです 。生成 AI 用に1つ、ETL 用に1つ、レポーティング用に1つです。3つの別々の Redshift Serverless ウェアハウスが作成されました。この最初の部分では、最初のウェアハウス、つまりデータロードと 変換ウェアハウスを使用して、Oracle Sales データベースからのデータがデータウェアハウスに継続的にレプリケートされる方法を見ていきます 。これのビデオデモを見てみましょう。ソースは Oracle 19C Sales Oracle データベースです。それを素早く検査してみましょう。Sales スキーマと呼ばれるスキーマがあり 、そのスキーマ内に24個のテーブルがあります。では、これを Redshift にほぼリアルタイムでレプリケートする方法を見てみましょう。そのために、 Zero ETL インテグレーションに移動して、下に移動して Zero ETL インテグレーションを作成すると言います。このインテグレーションに名前を付けます。その後、ソースを選択できます 。
ソースについては、Oracle の sales データベースを選択します。選択したら、expression を提供して sales のみをレプリケートするように指定します。ORCL.SALES.* をレプリケートするということですね。次にターゲットを選択します。選択するターゲットは、先ほど作成した ETL データウェアハウスで、このエンドポイントがインジェストに使用されます。すべてを確認したら、zero ETL integration を作成できます。この integration はアクティブです。integration に入ると、この integration に関連するさまざまなメトリクスを確認できます。テーブルレベルの統計情報、レプリケートされたテーブルの数、行数、変更内容、サイズなどが表示されます。これでこのデータに対してクエリを実行する準備ができました。zero ETL integration のターゲットとして使用される ETL workgroup に接続しています。Oracle から利用可能な 24 個のテーブルがあり、データが更新されるとほぼリアルタイムで更新されます。この時点でクエリを書くことができます。このクエリは、Oracle データベース内のさまざまなテーブルを結合してアイテムレベルのメトリクスを生成し、変換してアイテムレベルのメトリクスを生成するもので、item_sales_metrics というテーブルが作成されています。このように、わずかなステップで、Oracle sales データベースからデータを Redshift にロードし、データを常に更新し続ける継続的なパイプラインを作成し、データを変換してアイテム sales メトリクスを作成することができました。
同様に、Firehose から Apache Iceberg S3 テーブルにデータをポンプしている別のパイプラインがあります。この時点で、2 番目のステップに進みます。このデータをインジェストすると、自動的に SageMaker Catalog にカタログ化されます。追加のステップを実行する必要はありません。データはカタログ化され、利用可能な状態になります。カタログ内では、権限管理を行うことができます。権限管理には 2 つの方法があります。IAM ロールに権限を付与することもできますし、より良い方法があります。IAM Identity Center のグループまたはユーザーに権限を付与することができます。カタログは IAM Identity Center とネイティブに統合されています。IAM Identity Center は、Azure AD、Okta、Ping などのほとんどの標準的な業界の ID プロバイダーと同期できます。これらを IAM Identity Center と同期させることで、IAM Identity Center のユーザーとグループに権限を付与し始めることができます。
例を挙げてみましょう。ある企業に 3 つの異なるグループがあると仮定します。データサイエンティスト、アナリスト、データエンジニアで、すべて ID プロバイダーの Okta を使用して管理されています。次のパートでは、この企業がどのようにして作成した新しいテーブルに対してアナリストユーザーに権限を付与し、その上でレポートを実行できるようにするかを見てみましょう。そのために、AWS Lake Formation に移動します。Lake Formation で下に移動すると、IAM Identity Center integration があります。Lake Formation が IAM Identity Center と統合されていることが確認できます。これは、Okta と統合されており、Okta には先ほど話した 3 つのグループ、アナリスト、データエンジニア、データサイエンティストがあり、これらは IAM Identity Center と同期されています。この時点で、これらに対して権限管理を行うことができます。
カタログに移動しましょう。カタログには、Redshift からのデータ、Redshift ウェアハウスが表示されます。また、データレイクからのデータ、S3 カタログも表示されます。次にテーブルを見てみましょう。Redshift カタログには、Oracle からのデータを変換して作成した item_sales_metrics テーブルが表示されています。これがそのテーブルのスキーマです。これで IAM Identity Center プリンシパルに対してこのテーブルの権限を付与できます。開始すると、ID プロバイダーから反映されたアナリストグループを確認でき、それに対して権限を付与し始めることができます。はい、これが正しいカタログ、正しいデータベース、正しいテーブルであることを確認できます。select と describe の権限を付与しています。このように、カタログを使用して、データウェアハウスとデータレイクの両方のオブジェクトに対して、ID プロバイダーエンティティに対して一元的に権限を付与することができます。
権限管理を行いました。オブジェクトがあり、権限管理を行いました。アナリストが item_sales_metrics テーブルにアクセスできるようになったと言いました。彼らは任意のエンドポイントにログインして、アクセスを開始できます。次のパートでは、レポーティングに進みます。アナリストはレポーティングエンドポイントにログインしてデータへのアクセスを開始します。アナリストは同じデータセットを使用します。データのコピーは作成されません。前に使用していたエンドポイントから完全に分離された別のエンドポイントを使用して、同じデータのコピーにアクセスされます。レポーティングがどのように行われるかを見に行きましょう。Query Editor v2 に移動します。2 番目のエンドポイントを使用していて、ID プロバイダーの権限を使用してログインしていることに注意してください。アナリストグループに属するアナリストとしてログインしています。ログインしました。この時点で、アナリストは自分がアクセスできるすべてのオブジェクト、item_sales_metrics テーブルと S3 テーブルを確認できます。現在のユーザーが誰であるかを簡単に確認してみましょう。現在のユーザーは ID プロバイダーからのアナリストです。このアナリストユーザーは、データウェアハウスとデータレイクの Apache Iceberg 形式のデータを組み合わせてレポーティングクエリを実行できます。イベントデータと顧客データを組み合わせて取得し、顧客の総数、クリック数などのメトリクスを取得する簡単なクエリです。同様に、このレポーティングエンドポイントで数百のレポーティングクエリを実行でき、他のエンドポイントで発生している ETL に影響を与えません。このように、これら両方の重要なワークロードの SLA が満たされます。
では、最後のステップは生成AIを使った自然言語クエリです。そのために Bedrock に行きましょう。 ここで Bedrock を使っている人はいますか？ 何人か手を挙げていますね。Bedrock Knowledge Base について知っていますか？素晴らしい。多くの人が知っているんですね。
Bedrock knowledge bases では、S3 のオブジェクトを使用できます。また、Redshift のデータを Bedrock の knowledge base として使用することもできます。それがどのように行われるのか見てみましょう。knowledge bases に行って下に行くと、構造化データに基づいて knowledge base を作成するオプションが選べます。そこで Redshift をクエリエンジンとして見ることができます。 この knowledge base がどの特定の Redshift エンドポイントを使用すべきかを選択できます。私は generative AI workgroup を使用します。これは私たちが使用している他の2つの workgroup とは異なります。この knowledge base がアクセスできるデータセットを選別できます。さらに、テーブルの説明とカラムの説明を追加して、エージェントのパフォーマンスを向上させることができます。これだけです。knowledge base を作成できます。
では knowledge base に入って、テストしてみましょう。3つのオプションがあり、それぞれを見ていきます。knowledge base では、モデルを選択できます。Bedrock がサポートしているどのモデルでも選べます。 私は Amazon Nova モデルの Nova Pro を選択しています。では質問をしてみましょう。「総売上金額はいくらですか？」エージェントがクエリを作成して、Redshift で実行し、結果をシンプルな平易な英語で返してくれます。総売上金額はいくらいくらです。今度はSQL クエリだけを生成することもできます。同じ質問をします。「総売上金額はいくらですか？」レスポンスとして SQL クエリが返ってきます。また、英語ではなく、表形式でデータを取得することもできます。「retrieve only」と言えば、表形式でデータが返ってきます。
generative AI workgroup を使用することで、どの企業でも、その workgroup をいくつでもユーザーに公開でき、レポーティングに影響を与えず、ETL に影響を与えず、自然言語クエリを使ってデータを民主化できます。すべてをまとめると、これが私たちが見たアーキテクチャです。 様々なソースからデータを中央の lake house に取り込み、アイデンティティグループとユーザーを通じて権限管理を行い、レポーティングと自然言語クエリのための消費を行いました。Alex は舞台裏で、昨年彼のチームがこのセッションに参加して、これらの学習を持ち帰り、マルチウェアハウスアーキテクチャを構築したと言っていました。同じことをすることを強くお勧めします。
皆さんのユースケースのために、マルチウェアハウスアーキテクチャを試してみてください。新規で始める場合はマルチウェアハウスで始めるか、既に Redshift ユーザーの場合は、それをマルチウェアハウスアーキテクチャに変換してみてください。マルチウェアハウスアーキテクチャについてさらに詳しく学ぶために、これらのリソースを参照できます。 2秒間一時停止するので、写真を撮って後で参照してください。これでセッションは終了です。ご参加ありがとうございました。ぜひアンケートとフィードバックに記入する時間を取ってください。それは私たちが自分たちを改善するのに大いに役立ちます。彼の話を共有してくれた Alex に特別な感謝を申し上げます。これで質問があればお受けします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion