re:Invent 2024: AWS・Amazonが語るGenerative AI時代のData Foundation

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

📖 AWS re:Invent 2024 - Data foundation in the age of generative AI (ANT302)

この動画では、Generative AIの時代におけるData Foundationの重要性と進化について解説しています。AWS Analytics Tech LeaderのImtiaz Sayedを司会に、Amazon Finance AutomationのNitin AroraとAWS Vice PresidentのIppokriatis Pandisが登壇し、具体的な取り組みを紹介しています。特に、AmazonのFinanceチームによるData Meshの活用事例や、AWS SageMaker LakehouseによるWarehouseとLakeの統合、Zero-ETL技術による8-9秒でのデータ移行など、最新の技術革新が詳しく語られています。また、Apache Iceberg REST APIを活用した新しいManaged S3 Tablesの導入や、SageMaker Unified Studioによる統合開発環境の実現など、AWSのデータ基盤の進化についても具体的に解説されています。
https://www.youtube.com/watch?v=80ImA4-zycw
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！

本編

Generative AIの時代におけるData Foundationの重要性

みなさん、こんにちは。AWS Analyticsのテックリーダーを務めるImtiaz (Taz) Sayedです。本日は、Amazon Finance AutomationのNitin Aroraさんと、AmazonのVice President兼Distinguished EngineerのIppokriatis Pandisさんをお迎えしています。「Data Foundation in the age of generative AI」のブレイクアウトセッションへようこそ。さて、手始めに。この会場にいらっしゃる方の人数を当ててみたい方はいらっしゃいますか？はい、どなたかご予想を。300人？270人？もう一人どなたか？正解しても賞品はありませんが、ここはVegasですからね。実際には約400人です。ご参加ありがとうございました。

この30年間で、データの世界は数々の進化を遂げ、重要な転換点を迎えてきました。ここにいらっしゃる400人の皆さんの中で、Data Warehousing、Big Data、NoSQL、Machine Learningなど、これらのマイルストーンの誕生を目の当たりにしてきた方も多いのではないでしょうか。そして、もし最近のテクノロジートレンドから完全に隔離されていない限り、Generative AIについても耳にされているはずです。これらのテクノロジーの原動力となってきたのはデータであり、それはGen AIにおいても同様です。しかし、正直なところ、Gen AIと聞いて最初に思い浮かぶのはデータではないですよね？

本日は、Gen AIがデータエンジニアリングにどのような影響を与えているのか、そしてAWSがGen AIアプリケーションの構築ニーズに応えるため、どのようにData Foundation機能をスケールさせ、進化させているのかについてお話しします。これから60分のアジェンダとして、まずData Foundationの概念とAWSによる実現方法について簡単に説明します。 次に、Gen AIアプリケーションの構築ニーズに対応するためにAWSがスケールしているData Foundation機能について説明します。 その後、AmazonのFinanceチームのNitinから、AWSでのData Foundation構築が、Data Meshの展開とGen AI機能の迅速な強化にどのように貢献したかについて、実例を交えてご紹介します。 最後に、AWSがどのように将来のニーズに向けてData Foundation機能を進化させているかについて、詳しく掘り下げていきます。

Data Foundationの概念と利点

私はデータビジネスに約25年携わってきましたが、Data Foundationという言葉は一見シンプルに見えても、実際に説明するのは非常に難しいものの一つです。例えば、こんな状況を想像してみてください。新しいチームメンバーが加わり、「私たちのData Foundation戦略について少し教えていただけますか？」と質問されたとします。皆さんならどのように答えますか？ 理解を深める良い方法は、What（何）、How（どのように）、Why（なぜ）、Who（誰のため）という質問に分解することです。 Whatとは？それは、データの取り込み、統合、処理、変換、ガバナンスを中心とした、組織の裏方としての戦略です。 Whoについては？もちろん従業員のためですが、組織と協力する外部パートナーのためでもあり、多くの場合、そのデータを扱う顧客にまで及びます。

Whyについては？これは簡単です - データ駆動型の意思決定のためです。そして重要な問題であるHow - どのように実現するのか？これは主に、広範で相互に連携された一連のデータサービスとソリューションを通じて実現されます。 AWSは、AWS内外のデータに対する直接的かつネイティブな統合機能と、セルフサービス分析のための包括的なデータガバナンスを備えた、総合的なデータ、Machine Learning、AIサービスを通じてこれを実現しています。

AWS Data Foundationはテクノロジーの枠を超えて、組織における人材とプロセスの重要な役割を理解し、これらの要素を取り入れることで、Data Flywheelと呼ばれる効果を加速させます。これは、データを製品として扱い、豊かな顧客体験を提供することを目的としており、 フィードバックに基づいて改善できる余地を持たせ、そのフィードバックをデータに還元していきます。 その利点は、ビジネス面とテクノロジー面の2つに大きく分類できます。 ビジネス面での利点には、質の高いデータを効率的に整理し、信頼性を高め、それによってデータの収益化を容易にするといった実践的な成果が含まれます。これらの利点により、Data Meshのような新しいフレームワークを迅速に採用したり、新しい方法に柔軟に移行したりできるという戦略的な優位性がもたらされます。

テクノロジー面での利点には、効果的な発見とアクセス制御を実現するためのデータの検索性とアクセス性、異なるデータタイプと処理アプリケーション間の相互運用性の向上、そして明確に定義された利用契約による再利用性の向上が含まれます。これらの利点は、複雑なData Meshを構築する場合でも、このような単純なデータパイプライン - 典型的な取り込み、処理、ガバナンスのコンポーネントを持つ従来型のデータパイプラインを構築する場合でも、あらゆる種類のデータアーキテクチャパターンに当てはまります。

Generative AIがData Foundationに与える影響とAWSの対応

では、Generative AIの時代において、Data Foundationの機能とデータパイプラインはどのように変化するのでしょうか？ これについて、AWSがこの変化に対応してData Foundation機能をどのようにスケールさせているかという観点から見ていきましょう。 その前に、Generative AIとは何かを簡単に確認しておきましょう。端的に言えば、大量のデータで学習させたAIモデルを使用して、 新しいコンテンツを生成するAIの活用です。AWSでは、一般的なアプリケーション構築パターンのトレンドが見られます。独自のモデルを一から学習させるアプローチでは、顧客が大量のデータを使って独自のモデルを構築します。継続的な事前学習プロセスでは、新しく利用可能になったラベルなしの入力データに対応するようにモデルのパラメータを調整します。これに続いて、事前学習済みモデルの微調整アプローチでは、事前学習済みモデルを取得し、より小規模なラベル付きデータセットでさらに学習させます。使いやすさから人気の高いRetrieval Augmented Generation（RAG）は、モデルのパラメータを変更したり特定のデータセットで学習させたりせず、代わりに状況的または意味的な追加のコンテキストを渡してモデルの動作を導くin-context learningの一例です。

これらの構築パターンはData Foundationの機能に影響を与えますが、すべてが同じように扱えるわけではありません。 データが差別化要因となるだけでなく、Generative AIアプリケーションの構築には、Data Foundationの機能をスケールさせる必要がある側面が複数存在します。 では、Generative AIアプリケーションを構築する際に、シンプルなデータパイプラインのスコープがどのように影響を受けるか見ていきましょう。 Generative AIがデータパイプラインにもたらす最初の変化の1つは、主に非構造化データの形で追加のデータソースが必要になることです。非構造化データは新しい概念ではありませんが、Generative AIパイプラインでは主要な部分を占めており、世界のデータの80%以上が非構造化形式であることから、現在では中心的な位置を占めています。非構造化データは事前に定義されたフォーマットに従わず、既定のデータモデルに従って整理されていないため、非構造化データのメタデータ発見は課題となります。

非構造化データのメタデータを処理するためにAWS上で構築できるソリューションのハイレベルなアーキテクチャを見ていきましょう。 まず、生の入力データをAmazon S3のようなオブジェクトストアに取り込みます。そして、データの種類に応じて、 この非構造化データからメタデータを抽出するように設計された複数のAWS AIサービスを使用できます。最も一般的なサービスは、Amazon Comprehend、Amazon Transcribe、Amazon Textract、Amazon SageMakerです。メタデータはS3バケットに抽出され、必要に応じてAWS Glue ETLジョブで データセットをエンリッチメントおよび精製するための追加の変換を適用できます。次に、 このデータの発見を支援する抽出されたメタデータ属性を格納するメタデータカタログを構築します。カタログ自体の発見とアクセスには、AWS Glue Data Catalogを使用し、 クエリエンジンとしてAmazon Athenaを適用し、AWS Lake FormationとAmazon DataZoneでガバナンスを展開することができます。

パイプラインの話に戻りますが、Generative AIアプリケーションの構築アプローチによって、データ処理フェーズも異なってきます。Data WarehouseやData Lakeからの情報抽出のためのFeature Engineeringを行うこともあれば、継続的な事前学習アプローチのための推論を実行したり、RAGベースのアプリケーションのためのベクトルデータを管理したりすることもあります。

リアルタイムで意味のあるコンテキストを得るには、高度なデータ統合とデータストアが必要です。ベクトルデータ管理の例を見てみましょう。RAGアプリケーションでは、まずAmazon Bedrockサービスを使用して、非構造化データソースからベクトル埋め込みを生成し、これらの埋め込みをベクトル化されたデータベースインデックスに保存します。

その後、クライアントがLambdaのクエリとエンコーダー関数に質問を送信し、それがBedrockのAPIを呼び出します。この例では、Retrieve and Generate APIを使用しています。APIがナレッジベースに問い合わせを行い、レスポンスを生成し、それを別のナレッジベースLambda関数にコンテキストとして返します。クライアントからの元の質問と共に、これらがLarge Language Modelへのプロンプトとして送信され、より事実に基づいた正確な回答が生成されます。

先ほど述べたように、ベクトルデータを使用したRAGは人気のあるアプローチです。ベクトルデータ管理では、ドメインデータを取り、トークン化と呼ばれるプロセスでチャンクに分割します。これらのチャンクをLarge Language Modelに通して、数値ベクトルまたは数値配列を生成します。これらはベクトルデータベースに保存され、関連する意味を持つ要素が多次元ベクトル空間内で互いに近くに配置されます。そして、意味的に関連するデータの検索と、それをプロンプトに返すことは、単にこれらのベクトル間の最小距離を見つけるという数学的な関数に還元されます。

先ほどのRAGの例では、ベクトルストレージとベクトル検索の機能はAmazon OpenSearch Serviceによって提供されていました。これは、検索分析やログ分析で既に広く使用されているElasticsearchベースのオープンソースソリューションです。馴染みのあるベクトルストアを選択することは大きなメリットとなります。新たなライセンスコストが発生しないためです。また、ベクトルとビジネスデータが同じ場所に保存されているため、アプリケーションはデータの移動をほとんど必要とせず、高いパフォーマンスを発揮できます。

AWSは、使い慣れたツール、ライセンスコストの削減、そしてより高速な体験という同じ精神のもと、Amazon AuroraやAmazon RDSなどのSQLデータベース、Amazon DocumentDBのようなNoSQLデータベース、そしてグラフデータベースのAmazon Neptuneなど、多くのフルマネージドデータベースサービスにわたってベクトル機能を提供しています。 データパイプラインの話に戻りますが、一部のGenerative AIアプリケーションでは、高度にパーソナライズされた正確なレスポンスを実現するための機械学習手法である人間のフィードバックからの強化学習（RLHF）などの先進的な学習技術も取り入れています。このような情報を適切なデータストアと効率的なパイプラインで取り込むことで、レイテンシーと精度の向上に役立ちます。

RAGアプリケーションの例に戻って、ユーザーのパーソナライゼーションコンテキストを組み込むためにデータパイプラインをどのように調整できるか見てみましょう。クライアントの質問をエンコーダーに送信する前に、アプリケーションは、より適切で意味のあるユーザーコンテキストを提供するために、追加の情報を参照することができます。Amazon Redshiftのカスタマー360データウェアハウスにクエリを実行して追加のユニークな顧客属性を取得したり、Amazon DynamoDBでデータベースを維持して会話の状態と履歴を保存したりすることができます。

次に進みましょう。Customer 360は、ビジネス上の意思決定を導くための完全で統合された顧客プロファイルビューを提供します。例えば、特定の顧客層により効果的に響くマーケティングキャンペーンを作成するために、Generative AIアプリケーションでCustomer 360を活用することができます。しかし、Customer 360ソリューションの構築は簡単ではありません。異なる種類のデータベースやデータストアに分散されたデータへのアクセスが必要で、時間とともに新しいデータセットを追加できる必要があり、適切なChange Data Capture技術が確実に実装されている必要があります。SQLデータベースやNoSQLデータベースは通常、ユーザープロファイル、会話スレッド、取引履歴などのユーザー操作データを保存します。このデータをCustomer 360に取り込むには、通常、ソースデータベースに接続し、変更点を特定し、それをシステムにロードする複雑なデータ統合パイプラインを構築する必要があります。このプロセスは課題となる可能性がありますが、それを簡素化するソリューションが用意されています。

AWSのZero-ETLデータ統合機能は、CDCテクニックを使用してAWS上のSQLおよびNoSQLデータベースからAmazon Redshiftデータウェアハウスにデータを複製することで、インフラストラクチャのプロビジョニングを必要とせずに、この重労働を解消します。Generative AIアプリケーションでは、より完全な顧客ビューを得るために、最新のユーザー取引に関するリアルタイムの最新情報が必要になることがよくあります。 Amazon MSKやAmazon Kinesis Data Streamsなどのサービスとのストリーミング取り込み、そしてAmazon S3データレイクとAmazon Redshift間のAuto Copy機能により、Generative AIアプリケーションは、ダウンストリーム処理のための最新のコンテキストを得ることができます。

Generative AIアプリケーションは、より幅広いデータソースとデータペルソナに対応するため、データガバナンスはエンドツーエンドのデータパイプライン全体の機能となります。舞台裏では、データ共有、データプライバシー、データ品質、データカタログ化が、Generative AIアプリケーションの包括的なデータガバナンスを提供する上で重要な役割を果たしています。AWS上のデータ共有により、データを移動したりコピーを作成したりすることなく、データを利用可能にすることができます。データウェアハウス、データレイク、またはデータマーケットプレイスからのデータを安全に共有したい場合、Amazon Redshift、AWS Lake Formation、AWS Data Exchange、Amazon DataZoneなどのサービスを使用することで、ポイントツーポイントまたは集中型のデータ共有を簡単に実現できます。

データが適切に整理され、カタログ化されていれば、データ共有がより容易になります。Amazon DataZoneとAWS Glue Data Catalogを使用して、様々なデータタイプに対応したテクニカルカタログとビジネスカタログを構築し、多くのAWSサービスとネイティブに連携することで、データ共有のためのガバナンスのベストプラクティスを迅速に展開できます。ユーザーのプライバシーとデータ品質が管理されていない限り、Generative AIアプリケーションは信頼性を得ることはできません。AWSはAWS Glueサービスをスケールさせ、PIIデータなどの機密データを検出・処理してコンプライアンスを向上させ、さらにAWS Glueサービスに機械学習アルゴリズムとルールベースの自動化機能を搭載し、品質の問題を監視、検出、軽減できるようにしました。

AmazonのFinance AutomationチームによるData Foundationの活用事例

要約すると、私たちは、AWSがGenerative AIの体験を向上させるためにデータ基盤の機能をどのようにスケールしているかについて、いくつかの側面から説明しました。Large Language Modelのトレーニングなど、Generative AIの機能を向上させるための構造化データと非構造化データの処理機能について説明しました。次に、ユーザー体験を向上させるZero-ETL、Auto Copy、ストリーミングインジェストなどのデータ統合機能について説明し、続いてRAGアプローチに重要なコンテキストを追加するベクトル化構造のサポートを含むように最適化されたデータベースについて説明しました。最後に、安全で信頼性の高い体験を提供するデータガバナンス機能について説明しました。私たちはデータ基盤の機能を進化させ続けており、Ippokriatisがこの後、その詳細について説明します。その前に、Amazon FinanceのNitinから、強固なデータ基盤がData Meshの構築にどのように役立ち、さらにGenerative AI機能で迅速に強化できたかについてお話を伺います。

ご清聴ありがとうございました。それでは、Nitinにバトンタッチします。皆さん、こんにちは。私はNitin Aroraです。Finance Automationと呼ばれるチームのSenior Engineering Managerを務めています。データサービス、コミュニケーション、Finance Operations向けの業務管理ソフトウェアの構築・運用を行うチームを率いています。AmazonのFinance Operationsとは具体的に何かというと、主に3つの重要な責務があります。第一に、ベンダーと従業員に対して正確かつタイムリーな支払いを確実に行うこと。第二に、お客様からAmazonへの支払いが適切に行われることを確認すること。そして第三に、すべての金融取引を最高レベルのコントローラーシップとセキュリティで処理することです。

Finance AutomationはFinance Operationsの技術チームです。私たちの技術は、生産性の向上、自動化、セルフサービスを通じて、AmazonのFinance Operationsの成長をサポートしています。AWS、小売、広告などのAmazonのすべてのビジネスラインをサポートしています。Finance Operationsは数千人の従業員で構成されています。Finance Operationsチームの一員であるアナリストたちは、複数のビジネスラインにわたって、様々な言語でグローバルにベンダーをサポートする責任を担っています。彼らはベンダーからの一般的な質問に対応します。

また、世界最大のサプライヤーエコシステムとの強力なパートナーシップを構築することを目標に、様々な紛争や意見の相違にも対応しています。

まず、簡単なアンケートから始めさせていただきます。Amazonで何か購入したことがある方は手を挙げていただけますか？ほぼ全員ですね。まず初めに、私たちのお客様になっていただき、心より感謝申し上げます。私たちの業務規模について、少し説明させていただきます。お客様が Amazonで様々な商品を注文され、その需要に応えるため、Amazonはベンダーから大量の商品を一括で仕入れています。これらの商品をFulfillment Centerに配送し、受け取った商品に対してベンダーへ支払いを行います。基本的にはシンプルなプロセスですが、Amazonの規模になると複雑になってきます。

不良品、返品、配送時の破損など、様々な複雑なシナリオに対応する必要があり、これによってベンダーへの支払いプロセスはより複雑になります。在庫の発注や返品の管理など、複雑なサプライチェーン機能を担当する何百ものチームと分散システムがAmazon全体に存在し、Financeは数十億件のトランザクションにわたるイベントを追跡し、財務状況の全体像を把握する責任を負っています。 これはFinance Operationsがサポートするビジネスラインの1つであるAmazon Retailの話だけです。Amazonの巨大な規模により、特定のビジネス機能を管理する専門チームと分散システムが必要となりました。この構造によってAmazonは急速な成長を遂げることができましたが、トレードオフとして、財務取引の全体像を把握するためのデータサイロが生まれることになりました。Financeは、これら何百ものシステム間でイベントを結び付ける必要があります。

これは毎月数兆件のイベントとペタバイト規模のデータ処理が必要となることを意味します。当然ながら、財務部門のユーザーは、企業全体の運用モニタリング、Machine Learning、データ分析のユースケースをサポートするため、このデータをほぼリアルタイムで必要としています。私たちは毎日数億ドル規模のベンダー支払いを行っています。リアルタイムデータを使用して、これらの支払いが正確かつタイムリーに行われているかを監視しています。Machine Learningを使用して、不正取引を検出・防止するために支払いパターンを継続的に監視しています。データ分析を使用して、Amazonのキャッシュフローを改善するために、現金と回収の実践状況を分析しています。このようなデータは、Amazonが重要な意思決定を行い、日々の財務運営を効果的に行うための大きな部分を占めています。

私たちが最新のData Foundationを構築する journey を開始した時、3つの重要な目標を特定しました。第一に、断片化したデータ、複数のチーム、複数のコピー、複数の場所という状況に直面し、これが非効率と無駄を生んでいました。私たちの目標は、データの冗長なコピーを最小限に抑えることで、ビジネス分析とMachine Learningのための単一の信頼できる情報源を作ることでした。 第二に、データの重複を本当に最小限に抑えるために、データをより簡単にアクセスでき、発見可能にする必要がありました。ユーザーが必要なデータセットを見つけられる中央データカタログが必要でした。中央データカタログに存在するすべてのデータセットが、一連のデータ品質チェックを通じて照合され、検証されることを確実にしたいと考えました。

第三に、何百ものシステムからのデータを扱うため、堅牢な権限管理、厳格なデータセキュリティ、より強力なガバナンスが必要でした。適切な人が常に適切なデータにアクセスできることを確実にするための包括的な監査証跡が必要でした。 先ほど、Amazonの分散型のランドスケープとそのトレードオフについて触れましたが、これは複数のデータ生産者にわたる組織全体のデータサイロを生み出しました。この現実に対処するために、ドメインやシステム間でデータを簡単かつ安全に接続できる方法を特定する必要がありました。私たちは、データ管理の分散型アプローチを提唱するData Meshを基本戦略として選択しました。

このアプローチでは、ビジネスユニットが必要なデータを見つけてリクエストを行うことができるセルフサービス型のデータ共有を推進しています。そのリクエストはデータ提供者に送られ、適切なアクセスレベルが付与されます。Central Data Catalogつまり中央カタログは、データの発見、データガバナンス、そしてデータセットの包括的なドキュメントを保管する場所となっています。

これにより、ユーザーはデータの品質、コンテキスト、利用ガイドラインを理解することができ、データセットをデータプロダクトとして扱うことが可能になります。このスライドでは、 Data Meshの基盤となる2つの側面を示しています：データ提供者とデータ消費者です。データ提供者は、PayablesやReceivablesなど、さまざまなドメインにわたる何百ものアップストリームシステムからData Meshにデータを取り込む責任を持ちます。彼らは、高品質なデータセットとデータプロダクトをData Meshに提供するために必要な、データストレージ、品質、その他すべての要件を管理します。

右側にいるのがデータ消費者で、分析、高度な分析、機械学習のユースケースを実施するチームです。私たちの目標はシンプルです：一度統合して、無期限に利用する。私たちは、高品質なデータセットを信頼できる方法でData Meshに統合し、ビジネス分析や機械学習チームができるだけ早くデータを簡単に利用して、ビジネス上の課題解決を始められるようにしたいと考えています。スライドに表示されている Central Data Catalogは、権限の実装、一貫したメタデータ管理のためのガードレールの適用、ガバナンスポリシーの定義、実装全体での利用状況の監査を行う場所です。AWS Lake FormationやAmazon Redshift Data ShareなどのAWSのデータ統合機能を使用して、データを実際に移動やコピーすることなく共有しています。

AWSのデータアーキテクチャを活用することで、 絶えず変化するビジネスや技術の要求に応じてデータインフラストラクチャを進化させる、驚くべきビジネスの俊敏性を実現しました。データを価値のある利用可能な状態にするまでの時間が、数ヶ月から数日に短縮されました。コンピューティングとストレージのフットプリントを削減することで、 数百万ドルのコスト削減を実現しました。AWSのデータ統合パターンのおかげで、以前は何時間もかかっていたETLジョブが現在では15分未満で完了するようになり、データの鮮度が向上し、ビジネスがより迅速な意思決定を行えるようになりました。

私たちの分散型アーキテクチャは、大規模な一枚岩的なチーム構造から脱却し、データに関する専門知識を持つビジネスやドメイン固有の組織内にデータチームを配置することで、より迅速なイノベーションを可能にしました。一方で、中央集権的な横断的データサービスチームが、Data Meshのデータガバナンスと組織全体での一貫したガードレールの適用を担当しています。 このデータ基盤により、Generative AIをより簡単かつ迅速に活用できるようになりました。強固なデータ基盤、包括的なカタログ、そして整合性のとれたデータを持つことで、これらのデータプロダクトをビジネスプロセスに統合する態勢が整いました。

Generative AIはAmazon Financeにとって大きな機会であり、多くのビジネスワークフローを改善し、より迅速でスマートな意思決定を可能にし、より良い顧客体験で生産性を向上させる可能性を秘めています。私たちは財務業務を検討する中で、複数の顧客やベンダーからの要求に対応するアナリストの生産性向上を最優先課題としました。大まかに言えば、私たちのデータ基盤とGenerative AIは、顧客要求の意図を理解し、ビジネスポリシー文書に沿ったソリューションを特定し、複数のソースにまたがる財務データを組み合わせて提示し、最終的にレビュー用の次のステップを実行または作成する優れた機能を提供します。

私たちの目標は、定型的な人間の作業を自動化し、人間を最終的な意思決定者として位置づけることです。この最終状態を実現するために、ポリシー文書からビジネスコンテキストを理解し、データを統合し、そして人間のレビューと実行のためのアクションを推奨する方法を特定する必要があります。では、どのように始めたのでしょうか？Data Meshは設定済みでしたが、欠けていたのはポリシー文書からのビジネスルールの適切な理解でした。ポリシー文書のデータは非常に非構造化されていますが、Finance Operationsで行われているすべての人間の作業を理解するための優れた参照源となっています。Finance Operationsでは、最終状態に向けて2段階のアプローチを取りました。

ステップ1では、ポリシー文書からビジネスコンテキストを理解すると同時に、アナリストが何百ページもの文書を閲覧する代わりに、ソリューションを検索して取得できる対話型の体験を可能にすることを目標としました。ステップ2では、財務データとビジネスコンテキストを統合して、顧客の問題を解決するためにアナリストが取るべき正確なアクションを提案します。

ここで少し寄り道して、これらのポリシー文書の背後にあるコンテキストをどのように理解し、データを統合したのかについて説明しましょう。包括的な理解を構築するために、AWSのVector Data Storeの機能を活用しました。スライドからわかるように、S3に保存された非構造化文書からデータを抽出し、チャンク化し、ベクトル埋め込みに変換して、ナレッジデータベースにロードしました。パフォーマンス、精度、コストのベンチマーキングに基づいて、Titan Embedding Modelを選択しました。Financeはすでに、先ほどTazが言及していたように、リアルタイム分析と高スループットのトランザクション検索にOpenSearchを使用していました。OpenSearchにVector Database機能が追加されたことで、追加のデータインフラを構築することなく、迅速に適応することができました。

私たちは、多様な文書タイプにわたる検索能力と、ユースケースに特有の大規模データ量の処理能力に基づいて、OpenSearchを選択しました。ビジネスの進化に伴い、ポリシー文書は時間とともに変化し、静的なものではありません。そこで、アナリストが対話型インターフェースを使用してユーザープロンプトに基づいてポリシー情報を検索・取得できるRAGパイプラインを構築しました。ステップ2では、既存のRAG基盤の上に構築を行います。スライドでご覧いただけるように、財務データを解析する機能を追加し、アナリストが顧客の要求を解決するための具体的な推奨事項をデータとともに提供できるようになりました。

このアプローチは、Policy文書からのビジネスコンテキストの理解と正確な財務データ、そしてData Meshからの高品質なデータを組み合わせることで、的確な問題解決を可能にします。以前にData Meshのアーキテクチャについてお話ししましたが、今回はVector Data StoreとLLMを追加し、Data Meshの重要な部分である中央のData Catalogに接続しました。これは、強固なデータ基盤があったからこそ、Generative AIを素早く容易に適用できた例です。Generative AIとデータを組み合わせることで、もはやデータの統合は人間が行う必要がなく、私たちのユースケースではLLMがデータを統合しています。

私たちはまだ journey の初期段階ですが、初期の結果は有望で励みになるものです。顧客の問題の文脈を理解するまでの時間、回答を得るまでの時間、そして次のアクションを決定するまでの時間が短縮されていることが示されています。Policy文書に関するQ&A用のAI Chatbotを導入したところ、サイクルタイムが80%以上改善され、主要なビジネスチャネルにおける数百人のアナリストの生産性が向上しました。より多くのチャネルをChatbotに組み込み、Finance Operationsの全従業員にVirtual Assistantを提供するというビジョンの実現に向けて、人間の生産性は継続的に向上しています。データを統合することで、アナリストに明確に定義された要約と推奨される次のステップを提供できるようになり、数千件のメールにわたる顧客からの問い合わせに対して、生産性の向上と顧客体験の向上を実現できるようになりました。

もちろん、これで終わりではなく、まだやるべきことがあります。Data Meshに組み込むべきドメイン、データセット、ビジネスポリシー文書がまだ多く残っています。LLMには、さまざまな種類の問題、ポリシー、そして幅広いプロンプトに対して、高品質なデータで回答する能力が必要です。より多くのソースとドメインを追加するにつれて、発見の能力を向上させる必要があります。より強力なガバナンスが必要です。Data Mesh内のデータを適切なメタデータで意味的にソースする能力が必要です。現在では自然言語処理を使用してクエリを生成し実行することができます。コスト最適化の機会もまだ残っています。パイプラインの約60%がZero-ETLの恩恵を受けられる範囲にあり、さらなるコスト最適化が可能です。

私はTazの意見に賛同し、優れたデータ基盤が不可欠であることを改めて強調したいと思います。AWSにおける優れたデータ基盤はGenerative AIには必須であることを繰り返し申し上げます。Generative AIの時代におけるデータ基盤の進化への投資は、アナリストの生産性向上とFinance Operationsにおける顧客体験の基準を再定義する変革をもたらすと強く信じています。お役に立てれば幸いです。ありがとうございました。では、AWSのFoundationと今後のAWS Foundationsについてお話しいただくIppoにバトンタッチいたします。

次世代Amazon SageMakerとSageMaker Lakehouseの紹介

皆さん、こんにちは。ありがとうございます。私はIppoです。AWSのDistinguished Engineerで、AWSの分析サービスの技術的進化を担当しています。Mattiasは自分の立場では好みの子供を持つべきではないと言っていましたが、私はRedshiftの出身なので、これが私のお気に入りの子供だと言えます。Nitinが言ったように、Amazon.comのカウンターパートとともに、データは分析とAIエクスペリエンスサービスの燃料となります。特に、お客様のデータこそが、ビジネスを推進するための特殊な、カスタマイズされたデータアプリケーションや分析AIアプリケーションを構築することを可能にします。

長年にわたり、10年以上もの間、皆様はこれらのアプリケーションを開発するために、私たちの包括的なサービスを選んでいただいています。多数の当社サービスをご利用いただき、特に他のベンダーとは一線を画す価格設定、パフォーマンス、セキュリティの姿勢など、私たちのサービスの深さをご評価いただいています。しかしながら、ここ数年、お客様から繰り返しお聞きしてきたことの1つは、サービスと機能の深さを高く評価しつつも、より統合されたエクスペリエンスを通じて同じサービスセットを活用したいということでした。この統合は2つの層に分類できます。まず、統合されたデータ管理層が必要であり、その上に、アプリケーションをより迅速に開発できる統合された開発エクスペリエンスが必要だということでした。

今朝、Mattが発表した SageMaker サービスの進化、次世代の Amazon SageMaker が AWS 上のデータ分析とAIの中心となることを、私たちは大変嬉しく思っています。私たちは SageMaker にいくつかの機能を追加しており、本日は3つの基本的なコンポーネントについてお話ししたいと思います。1つ目のコンポーネントは SageMaker Unified Studio です。これは統合されたIDE、つまり統合開発エクスペリエンスで、データ処理アプリケーションの開発、効率的なSQLアナリティクスの実行、モデル開発、そして生成AIアプリケーションの開発を可能にします。今朝Mattが述べたように、ストリーミング、検索、ビジネスインテリジェンスを取り入れることで、この統合開発エクスペリエンスに機能を追加し続けていきます。その下の層では、DataZone サービスの機能を進化させ、使いやすく強力な方法で SageMaker のデータとAIのガバナンス機能を提供しています。中核となるのは、SageMaker Lakehouse の導入です。これは既存の Lake Formation とデータカタログの進化形で、リレーショナルな管理ストレージ、オープンファイルフォーマット、そして今朝議論した新しく発表された3つのテーブルからのデータを管理およびアクセスできるようになりました。また、これからお話しする他の機能と共に、このLakehouseへのデータ移行を非常に簡単にします。

これらの機能強化により、統合されたデータとAIの開発環境で、より迅速なコラボレーションと構築を実現できるようになります。生成AIアプリケーションを構築するための幅広いツールセットを提供しています。Apache Iceberg REST API などのオープンAPIでアクセス可能な統合データアクセスと管理層を提供することで、WarehouseとLake間のデータサイロを解消しています。この統合データ管理層で細かなアクセス制御などの機能を提供することで、エンタープライズセキュリティとガバナンスの設定を可能にしています。

私はエンジニアですが、今週は次世代 Amazon SageMaker に関する多くの講演があります。そのほとんどは Unified Studio エクスペリエンスに焦点を当てると思います。なぜなら、それがデモンストレーションしやすいからです。私もそれを愛用していますし、非常に印象的です。しかし、エンジニアである私は、実際には逆の順序で、統合データ管理層から始めたいと思います。

皆様はユースケースに対応するために、私たちのサービスから多くのツールを使用してきました。高性能、高スループット、マルチステートトランザクションを実行する能力、そしてもちろんメインメモリからデータにアクセスすることで低レイテンシーを提供する必要があるケースに対応してきました。そのために Data Warehouse を使用してきました。しかし同時に、Data Lake も重宝されています。今朝Mattが言ったように、S3上に Data Lake を構築している何十万ものお客様がいます。ストレージの柔軟性、S3の柔軟性、そしてオープンファイルフォーマットの柔軟性を気に入っていただいています。

15年前、私が以前の職場にいた時、私たちはApache Parquetの開発に携わっていました。それは初期の段階で、私たちはParquetについて革新的な取り組みを行っていました。当時は、これが業界に与える影響を想像することができませんでした - 現在ではほとんどすべてのものがParquetファイルフォーマットを使用しています。これが長年にわたってどのように進化してきたかを見るのは印象的です。また、このデータにアクセスするための異なる専門的なツールを持つ能力も素晴らしいものです。しかし、このような分断された考え方をする必要はありません。WarehouseとLakeについて考え、異なる場所にCatalogを持ち、2つの異なる場所でガバナンスを設定する必要はないのです。

私たちに求められていたのは、統合されたソリューションです。WarehouseとLakeの機能を統合してほしいという要望がありました。この機能を過去1年以上開発している間、私はWarehouseとData Lakeを組み合わせた「WeLake」という名前を提案していましたが、採用されませんでした。そこで私たちはLakehouseという名前に決めました。Lakehouseは、WarehouseとLakeの機能を統合し、このデータの上で任意のサービスを運用し、一貫したガバナンスとアクセス制御を設定することを可能にします。

SageMaker Lakehouseは統合されたデータ管理レイヤーです。これはオープンで、AWSのアナリティクスサービス上のすべてのデータにオープンAPIを通じてアクセスできます。Iceberg REST APIを提供しているので、私たち自身のサービスだけでなく、Iceberg REST APIを使用できるサードパーティのサービスからもこれらを利用することができ、セキュアです。いくつかの機能について詳しく見ていきましょう。AWSでは、柔軟性が必要だと考えています - お客様にはそれぞれ異なるニーズがあり、ストレージにおいても選択肢が必要です。私たちは分析データ用に3つの異なるタイプのストレージを提供しています。

1つ目は非常に一般的に使用されているもので、汎用的なAmazon S3バケットでデータを保存できます。ほとんどの方は、どこかにData Lakeを持っているでしょう。データにアクセスすることができ、Apache Icebergは最近ますます人気が高まっているファイルフォーマットの1つです。Iceberg REST APIなどのIcebergプロトコルを使用してデータにアクセスできます。

AWSでは、Icebergデータレイクに対する最適化を提供しています。例えば、Data Catalogで自動テーブル最適化を有効にして、データが常にコンパクトな状態を保つようにすることができます。また、自動統計情報収集を有効にして、Amazon Redshiftなどのクエリエンジンがコストベースのクエリ最適化で使用する統計情報をテクニカルカタログに格納し、効率的なクエリ実行プランを生成して良好なパフォーマンスを維持します。データへのアクセスは、EMR、Spark、AWS Glue、SageMaker、Redshiftなどのファーストパーティサービスだけでなく、Apache Iceberg RESTなどのサードパーティサービスからも可能です。

本日の朝、私たちはAmazon S3を基盤とした管理型Apache Icebergサービスである、Managed S3 Tablesの提供を発表しました。これは、Apache Icebergデータレイク向けの新しいストレージクラスで、書き込み操作とRPSにおいて高いスループットを実現し、開始時から優れたパフォーマンスを発揮します。また、Icebergテーブルの完全な管理機能も提供します。S3 TablesはSageMaker Lake Houseの一部として提供され、 これらのS3テーブルの自動管理機能を提供します。例えば、開始時からデータのコンパクト化が可能です。また、もう一つの要望の多かった機能として、スナップショットの保持期間を指定し、Icebergデータの古いバージョンから参照されていないデータをクリーンアップできるスナップショット保持機能があります。

また、Redshift Managed Storage もLake Houseに導入しています。Amazon Redshiftでは、分析に最適化された独自フォーマットで10年以上の経験があり、これをSageMaker Lake Houseで利用できるようにしました。既存のRedshiftデータがある場合、そのデータベースをLake Houseの名前空間に公開できるようになりました。これにより、他のどのコンピュートサービスからもこれらのデータベースに接続して読み書きを開始できます。さらに、同じIceberg REST APIを通じてアクセス可能な、Redshift管理フォーマットを使用した新しいデータベースを作成することもできます。私たちは、データベースの物理的な設計を変更して最適なパフォーマンスを確保するなど、システムを継続的に監視・最適化する機械学習ベースの基盤技術で豊富な経験を持っています。

Redshift Managed Storageは、ニアリアルタイムの運用分析アプリケーションに適した分析最適化フォーマットです。例えば、分析ストアに少量のデータを継続的に挿入するストリーミングアプリケーションがある場合、Redshift Managed Storageで実行すると非常に効率的で、小規模なデータを挿入し続けても高いパフォーマンスを維持できます。このフォーマットの実装は、マルチステートのトランザクション一貫性を提供します。私たちの観測では、SparkからRedshift Managed Storageへの書き込みは、Icebergへの書き込みと比較して最大3.5倍のパフォーマンスを達成できます。また、多くの同時ユーザーが迅速な回答を必要とするビジネスインテリジェンスアプリケーションなどの低レイテンシークエリでは、Redshift Managed Storageは他のオプションと比較して最大7倍高いスループットを実現します。

SageMaker Lake Houseは、Redshift Managed Storage、オープンファイルフォーマット、S3テーブルのデータを配置できる統合された技術カタログであり、AWSの独自分析サービスを利用するあらゆるサービスからアクセスできます。

SageMaker LakehouseのZero-ETL機能とデータガバナンス

また、Apache Iceberg REST APIに対応したサードパーティのサービスからもアクセス可能で、オープンかつセキュアな環境を提供しています。 さらに、私たちは、SageMaker Lakehouseへのデータ取り込みを非常に簡単にできるよう、多くのエネルギーを注いでいます。特に、 過去2年間、Zero-ETL技術に関して革新を続けてきました。DynamoDB、Aurora MySQL、Aurora PostgreSQL、RDS for MySQLからLakehouseへの公開メカニズムを通じて、Zero-ETLを使用してRedshiftにデータを取り込む機能を備えています。

毎朝、私が受け取るレポートの1つに、Zero-ETLを利用している全顧客のレイテンシー統計があります。顧客がAuroraにデータを書き込む際、そのデータがLakehouse側で分析可能になるまでにかかる時間を計測しています。レイテンシーはどのくらいだと思いますか？平均して一桁秒台で、今日では8〜9秒程度でデータがAuroraから分析側に移動しています。 そして本日発表された通り、私たちはZero-ETL機能を拡張し、エンタープライズアプリケーションからのZero-ETLを可能にすることを嬉しく思います。最初の対象は8つのアプリケーションです：Salesforce、SAP、ServiceNow、Facebook Ads、Zendesk、Zoho、Instagram Ads、そしてSalesforce Marketing CloudとPardotです。

私たちはLakehouseにフェデレーション接続を導入し、さらにストリーミング機能も導入しています。 RedshiftとLakehouseへのインジェストにおいて、ストリーミングをサポートしています。Kinesis Data StreamsやAmazon MSKのサポートはしばらく前から行っていましたが、先月からApache KafkaとConfluentにも対応を広げました。ストリーミングインジェクションを使用して、毎秒ギガバイト単位のデータをRedshiftとLakehouseに取り込んでいるお客様もいます。

これらの機能はすべて、統合された技術的・ビジネス的カタログの一部となります。Studioでは、Lakehouseによってインデックス化されたすべてのデータをナビゲートして閲覧することができます。 動的なカタログ階層があり、S3バケットやRedshift Managed Storageによってサポートされる管理カタログを持つことができます。また、既存のRedshiftインストール、S3テーブル、フェデレーテッドソースも取り込むことができます。

具体的な仕組みをご説明します。例えばRedshiftで、テラバイト規模のデータがある場合、ボタンを押すだけで、 それが別のカタログとしてLakehouseに移動します。 その後、他の既存のRedshiftコンピュートインスタンスを持つことができます。別のサーバーレスコンピュートをスピンアップして、そのデータの読み書きを開始することができます。データサイエンティストが書いた複雑なジョインを本番環境から分離したい場合は、そこに接続して読み書きを始めることができます。また、Amazon EMR Spark、 AWS Glue、Amazon Athena、さらにはIceberg APIを使用できるサードパーティアプリケーションも利用可能です。

このレイヤーでアクセスコントロールを設定できます。例えば、カラムレベルのセキュリティ、行レベルのセキュリティ、あるいはその両方を 実装する機能を提供しています。SageMaker Lakehouseでインデックス化されたすべてのデータに対して、タグベースのアクセスコントロールを行う機能も提供しています。 さらに、Amazon DataZoneによって実現されるデータとAIのガバナンスがあり、データアセット、モデル、コンピュート、AIアプリケーションを含むプロジェクトを作成することができます。タグベースのコラボレーションにより、その上でアプリケーションを開発・作成することが可能です。

私たちは、Q形式でデータセットを探索できるビジネスカタログを提供するガバナンスを持っています。販売に関する情報を含むデータセットを見つけ、それらを購読し、プロジェクトに組み込んで、チームで協力して開発することができます。これらの操作はすべて、Apache Iceberg REST APIを使用して行われます。Apache Icebergは過去数年間で大きな注目を集めており、これと連携できる多くのファーストパーティおよびサードパーティのサービスが存在します。私たちはその上にREST APIを実装しており、Amazon SageMaker Unified Studio、分析サービス、またはサードパーティのサービスからアクセスすることができます。

Amazon SageMaker Unified Studioによる統合開発環境の実現

実は、共有したいことが多かったので、このセッションには2時間を要求したのですが、残念ながら1時間しか与えられず、今は残り4分しかありません。開発体験について話しましょう。以前は、ユーザーはEMRコンソール、AWS Glueコンソール、Amazon S3コンソール、Amazon Athena、またはAWS Glue Data Catalogなど、異なるコンソール間を行き来する必要がありました。これは特に生成AIアプリケーションを開発する際に課題となっていました。Unified Studioは、これらすべての要素を一つにまとめています。

Unified Studioは、機械学習アプリケーションや生成AIアプリケーションを含むアプリケーションを作成できる、単一のデータとAIの開発環境です。データエンジニアの方であればデータの準備ができ、SQLクエリを実行することもできます。また、データ、コード、モデル、コンピュートを保存したプロジェクトにアクセスすることができます。既存のAmazon EMRクラスター、AWS Glueエンドポイント、またはAmazon Redshiftエンドポイントがある場合は、それらを統合できます。既に作成したセットアップの利用方法を進化させながら、開発したプロセスを継続して使用できます。

Amazon SageMaker AIを使用してAIモデルのトレーニングとデプロイを行い、プレビュー中のBedrock IDEで生成AIアプリケーションを構築し、Amazon EMRやAWS Glueを使用してデータの準備と統合を行い、Amazon Redshiftを使用してSQLクエリを実行することができます。これらの操作はすべて、ソフトウェア開発者向けの最も優れた生成AIアシスタントであるAmazon Q Developerによって加速されます。プラットフォーム全体にこれを統合し、開発のための自然なインターフェースを提供しています。

以上が、私たちがどのように進化しているか、そしてAmazon SageMakerの次世代が何を表しているかについての包括的な概要です。既存のサービスをご利用の方は、何も変更する必要はありません。私たちは既存のサービスをAmazon SageMakerの下に統合しており、皆様からのご意見をお待ちしています。皆様が何を開発されるのかを見るのを楽しみにしており、フィードバックをお待ちしています。今週はAmazon SageMakerとその次世代についての多くのセッションがあります。これらのセッションにご参加いただき、フィードバックを提供し、私たちのプラットフォームを使って開発してください。ありがとうございました。

---

※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。