re:Invent 2025: Amazon S3 Metadataによるオブジェクトメタデータ管理とデータ発見の高速化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Accelerate data discovery with object metadata in Amazon S3 (STG357)
この動画では、AWS のRoohi SoodとClaire EdgcumbeがS3 Metadataの機能と活用方法を解説しています。データ量の爆発的増加とGen AI革命により、非構造化データの迅速な発見が競争優位の鍵となる中、S3 Metadataはjournal tableとlive inventory tableという2つのApache Iceberg形式のテーブルを自動生成し、システムメタデータとカスタムメタデータの両方をキャプチャします。デモでは、SageMaker Unified StudioやAthenaを使った実際のクエリ方法、暗号化されていないオブジェクトの特定、削除操作の追跡とロールバック、さらにMCP for S3 Tablesを使った自然言語でのクエリ実行が紹介されました。医療画像処理企業やデジタルコンテンツ企業の実例を通じて、ワークフロー最適化とペタバイト規模のデータ移行における具体的な成果が示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
データディスカバリーの課題：Alice のストーリーとセッションの目標
それでは、皆さんを心より歓迎いたします。本日はお越しいただきありがとうございます。まず、今ますます一般的になってきているシナリオをいくつかお話しすることから始めたいと思います。例えば、美しい水曜日の朝の8時か8時半だとしましょう。皆さんのリード データサイエンティストである Alice が、彼女のバケット内の 2,300 万個のオブジェクトの中からラベル付けされ処理された画像を探しています。一方、皆さんのセキュリティチームは監査リクエストが来たため、機密情報を含むすべてのオブジェクトのリストを取得しようとしています。彼らはすべてのオブジェクトをリストアップして、どのオブジェクトが機密コンテンツを含んでいるかを 1 つずつ把握しようとしています。これに心当たりはありませんか？これはデータの問題ではありません。これはデータディスカバリーの問題です。
こんにちは。Amazon Web Services のシニア プロダクト マネージャー テクニカルの Roohi Sood です。本日は、加速化されたオブジェクトディスカバリーのビジョンを現実にした素晴らしいエンジニアリングチームを率いるソフトウェア開発マネージャーの Claire Edgcumbe と一緒にお話しします。Claire と私の本日の目標は 1 つです。皆さんの組織内でこれらのデータディスカバリーの課題を永遠に克服する方法のロードマップをご説明することです。皆さんのデータサイエンティストは数分以内に必要なものを手に入れることができ、セキュリティチームはシンプルなクエリで質問に答えることができるようになります。
本日のジャーニーはこのようになっています。まず、組織に数百万ドルの損失をもたらしているデータディスカバリーの課題について深く掘り下げます。その後、Claire と私が S3 Metadata がこれらの課題をどのように克服するかをお見せします。デモを通じて、さまざまなユースケースをご紹介します。理論ではなく、皆さんが自分の環境で再現できる実例です。本日お見せするすべてのものは今すぐ利用可能です。ラスベガスを出発する前にこれを有効にすることができます。最後に、皆さんの組織に持ち帰ることができる 3 つの重要なポイントでまとめます。
データ爆発と Gen AI 革命がもたらすメタデータの重要性
では、これらのデータディスカバリーの課題を理解することから始めましょう。これを課題と呼んでいますが、実は、これは機会です。 最大の機会の 1 つであり、すぐにその理由がわかります。このお部屋の誰もが驚かないと思いますが、データは今までにないスピードで増加しています。 5 年前には想像もできなかったペースで増加しています。皆さんが使うあらゆるアプリ、運転するあらゆる車、建物内のセンサー、あらゆるセキュリティカメラ、それらすべてがストレージにデータを流し込んでいます。これを視点に入れるために、Amazon S3 は現在 500 兆個以上のオブジェクトを保存しています。つまり、500 兆個のオブジェクトです。
ここに Gen AI 革命が登場し、データの価値方程式を根本的に変えました。突然、皆さんの S3 バケットに保存されているすべての非構造化データ、 すべてのビデオ、画像、ログ、それらはもはや単なるストレージではなくなりました。それは数百万ドルの価値がある潜在的なトレーニングデータです。しかし、ここに課題があります。モデルをトレーニングしたり、ファインチューニングしたり、ナレッジベースを使用して RAG ユースケースを構築したりする場合、データセットを迅速に特定、分類、アクセスできる必要があります。皆さんのチームが適切なビデオを探すために何時間も何日も費やしたり、適切なコンテンツを含む、または機密コンテンツを含まないドキュメントを特定するために時間を費やしたりしているのであれば、皆さんはすでに後れを取っています。
これをデータディスカバリーの機会と呼ぶ理由はここにあります。なぜなら、組織のためにこのデータディスカバリーの課題を最初に解決した企業が、圧倒的なAIの優位性を手に入れることになるからです。これが今日の根本的な質問へと繋がります：どうやって大規模でアクション可能なデータセットを見つけたり、アクセスしたりするのか？答えは、皆さんの多くがすでにご存知の通り、メタデータです。それはあなたのデータのDNAなのです。それが何を持っているのか、どこに保存されているのか、そして時には何が潜在的に含まれているのかを教えてくれます。しかし、ここがほとんどの組織が行き詰まる場所です。
従来のメタデータソリューションは通常、ストレージソリューションの外部に存在するため、すでに複雑であり、さらに同期の問題があります。第二に、大規模でそれらを構築、運用、保守することは信じられないほど難しいのです。基本的なメタデータソリューションを正しく機能させるだけで、数週間、時には数ヶ月を費やしている組織を見てきました。そして最も重要なことに、メタデータは現在のものでなければ役に立たないということです。実際のところ、古いメタデータはメタデータがないよりも悪いのです。なぜなら、それはあなたを間違った方向へ導く可能性があるからです。
S3 Metadata の登場：自動的で常に最新のメタデータソリューション
これが私たちが自分たちに問いかけた質問です：もしメタデータが S3 のように機能したらどうだろう？シンプルで、信頼性があり、スケーラブルな。これが私たちが S3 Metadata を作成した理由です。しかし、S3 Metadata が何をするのかを説明する前に、実は何をしないのかを説明しようと思います。S3 の使い方を変える必要はありませんし、複雑なセットアップをする必要もありません。S3 Metadata は、メタデータを正しい方法で行うものです。自動的にです。
簡単に言うと、S3 Metadata は S3 内のオブジェクトから自動的にメタデータを抽出し、シンプルな SQL ステートメントでクエリできます。オブジェクトを追加したり削除したりするたびに、メタデータは自動的に更新されます。包括的で、常に最新の状態です。今日の顧客にとってなぜこれが素晴らしいのかを掘り下げてみましょう。
まず、システムメタデータとカスタムメタデータの両方をキャプチャします。システムメタデータには、オブジェクトサイズ、チェックサムタイプ、暗号化タイプが含まれます。これらの両方について、今日のプレゼンテーションでもう少し詳しく説明します。第二に、Apache Iceberg フォーマットに基づいており、S3 Table バケットに保存されています。つまり、証明済みのオープンソース標準を使用しており、互換性のあるクエリエンジンであれば、今でも将来でも使用できます。第三に、完全に自動です。オブジェクトをアップロード、更新、または削除した瞬間に、メタデータテーブルも更新されます。手動での同期は必要ありません。
では、実際のところどのように機能するのでしょうか？実は非常にシンプルです。やることは、汎用バケットに対して、このバケットのメタデータが必要だということを示す簡単な設定を追加するだけです。この設定を確認すると、AWS S3 Table bucket という管理対象のバケットをセットアップします。このテーブルバケット内で、メタデータテーブルの入力を開始します。これらは journal table と live inventory table と呼ばれています。これらのテーブルが正確に何であり、何を含んでいるのか疑問に思われるかもしれません。これらのメタデータテーブルの違いと、それぞれのユースケースを理解するのを手伝ってもらうために、Claire をステージに招待したいと思います。
Journal テーブルと Live Inventory テーブル：2つのメタデータテーブルの仕組みと特徴
ありがとうございます、Ruhi。Ruhi が述べたように、バケットに対して S3 Metadata を有効にすると、2 つのテーブルが作成されます。1 つ目は journal table です。journal table はバケットの監査ログと考えることができます。すべての put、すべての delete、すべての変更が独自の行として記録されます。これは単なるメタデータではなく、ソースバケットのタイムマシンです。何が起きたのか、いつ起きたのか、誰がそれを行ったのかを正確に確認できます。journal table は数分以内に更新されるため、常に最新の情報を扱っています。今年は、コスト管理をシンプルにするために、古いレコードの自動有効期限を導入しました。
2 つ目のテーブルは live inventory table です。live inventory table は、バケットに何が含まれているかについての詳細なビューを提供します。データ資産全体のスナップショットと考えることができます。オブジェクトバージョンごとに 1 行あります。1 時間ごとに更新され、データの状態に関する質問に答えます。これは分析とレポーティングに最適です。もう高コストの list リクエストを発行してページネーションを行う必要はありませんし、Ruhi が先ほど述べていたような複雑なカスタムソリューションを構築する必要もありません。すべてここにあり、クエリを実行する準備ができています。
これを実際に見てみましょう。共有データセットを操作しているユーザーのセットがあります。彼らはオブジェクトを追加、更新、削除しています。ここで見ることができるのは、S3 Metadata が有効になっているため、彼らがこれらのアクションを実行すると、journal table に新しい行が表示され、それらのアクションと関連するメタデータが記録されるということです。これらの変更を inventory table に反映させるために、大体 1 時間ごとにジョブを実行します。このジョブは journal table に記録された新しい行を読み取り、それを inventory table に適用して、バケットの新しいスナップショットを生成します。ここでメタデータが journal table から inventory table へ流れ込み、クエリを実行するためのスナップショットが作成されるのが見えます。
内部を見てみましょう。スキーマは非常に豊富です。合計で 21 種類のメタデータがテーブルに記録されています。journal table には、record type、request record timestamp、requester、source IP などのリクエストメタデータが含まれています。システムメタデータとカスタムメタデータは両方のテーブルに記録されます。システムメタデータには、bucket、key、object size、object storage class などが含まれていますが、暗号化ステータスに関する情報、オブジェクトがマルチパートアップロードを使用してアップロードされたかどうか、さらには暗号化アルゴリズムに関する情報も含まれています。
カスタムメタデータは、ユーザーメタデータまたはオブジェクトタグの形式で、あなたが定義するメタデータです。では、これらのテーブルはどこに存在し、どのようにクエリするのでしょうか？メタデータテーブルについて知っておくべき3つのことがあります。1つ目は、Apache Iceberg形式であるということです。2つ目は、S3テーブルであり、S3テーブルバケットに存在するということです。そして3つ目は、AWSによって管理されているということです。 それぞれが何を意味するのか、詳しく説明しましょう。Apache Icebergはオープンテーブル形式で、Parquetデータに対するSQLのようなクエリをサポートしています。 これは非常に人気があります。実際のところ、S3内で最も急速に成長しているデータタイプの1つです。顧客がこれを好む理由の1つは、Iceberg自体がただのデータ保存形式であるため、顧客がデータと相互作用する際に使用したいクエリエンジンを選択できるということです。異なるユーザーが、それぞれのニーズに応じて、同じテーブルに同時にアクセスするために異なるクエリエンジンを使用することがあります。
Apache Icebergはまた、大規模な分析をサポートするように設計されています。ペタバイト単位のデータと数十億のファイルを含むテーブルに対するクエリをサポートしています。また、タイムトラベルやスキーマ進化機能などの機能もサポートしています。S3 Tablesは、Apache Icebergのための私たちのマネージドソリューションです。 メタデータにS3 Tablesが適切な場所である理由はいくつかあります。1つ目はパフォーマンスです。S3 Tablesは、汎用バケットに保存されたApache Icebergテーブルと比較して、10倍のトランザクション数をサポートしています。 もう1つの理由は、S3 TablesとAWSの分析ソリューションサービスとの深い統合です。特に、AWS Lake Formationとのシームレスな統合を強調したいのですが、これにより行と列レベルまでの細粒度なアクセス制御が可能になります。これにより、メタデータを複数の異なるチームと共有しながら、機密情報が保護されたままであることを確認できます。
3つ目に述べたことは、テーブルがAWSによって管理されているということです。これが意味するのは、S3だけがメタデータテーブルに書き込むことができるということですが、それでも誰がどのデータを読むことができるかについて完全なアクセス権を保持しています。メタデータテーブルへの書き込みアクセスを制限する理由は、テーブルに含まれているものがバケットに含まれているものの正確な表現であることを確認するためです。AWSによって管理されるということが意味するもう1つのことは、テーブルのメンテナンス操作を設定・制御するということです。ターゲットコンパクションサイズを設定し、コンパクションの実行頻度を設定し、スナップショット管理を設定・構成し、参照されていないファイルのクリーンアップの設定を行います。これにより、あなたがそれを行う必要がなくなり、また、メタデータテーブルのサイズと構造に基づいてこれらの設定を最適化することもできます。
昨日、私たちは3つの新しいタイプのマネージドテーブルを発表しました。AWS CloudWatch logs、SageMaker Unified Studioアセットメタデータ、 およびS3 Lensデータ用のマネージドS3テーブルを作成するための統合を有効にできるようになりました。これは非常に強力です。複数の異なるAWSサービスからのメタデータが1つの場所にあるようになりました。 そして、それらはすべて同じ形式で保存されているため、それらを一緒にクエリできます。では、マネージドテーブルおよびS3メタデータテーブルをクエリするにはどうすればよいでしょうか？ いくつかの異なるオプションがあります。1つ目はAWS分析サービスを使用することです。S3はこれらのサービスと深く統合されているため、Athena、Redshift、SageMaker Unified Studioをすぐに簡単に使用できます。 2つ目は、S3 TablesがIceberg REST Catalogエンドポイントをサポートしているため、DuckDB、Apache Spark、Flink、またはTrinoなど、Icebergをサポートするオープンエコシステムのエンジンを活用できるということです。 最後に、今年私たちはS3 Tables用のMCPをリリースしました。これにより、自然言語を使用してデータとチャットすることが可能になりました。
メタデータで他に何ができるでしょうか？画面には、Amazon QuickSightを活用してメタデータを可視化する方法のいくつかの例があります。 これは、バケット内の異なる使用パターンを追跡・要約するための簡単で効果的な方法です。
3つのメタデータタイプとユースケース：Request、System、Custom メタデータの活用法
理論はもう十分です。では、実際のユースケースについて話しましょう。まず、メタデータテーブルに何が含まれているかを示したスライドに戻ってみましょう。 覚えていると思いますが、メタデータには3つのタイプがあります。request metadata、custom metadata、そして system metadata です。これらそれぞれを見ていって、データを理解し、データに対してアクションを取るためにどのように使えるかを確認していきます。
Request metadata は journal テーブルに存在し、バケットで何が変わっているかを調査するために使うものです。 ここに、共有データセットで操作を行っている別のユーザーセットがあります。 データセットのオーナーとして、過去1日以内に何が変わったかを理解したいとします。その場合、source IP と requester に基づいて結果をグループ化する SQL クエリを書くことで実現できます。Source IP はリクエストのソース IP を示し、requester は AWS アカウントを示します。S3 Lifecycle または他の AWS サービスからのリクエストの場合、アカウント ID の代わりに AWS サービスのサービスプリンシパルが表示されます。
では、特定の操作に絞り込みたいとしましょう。例えば、誰がデータを削除しているかを理解したいかもしれません。 これはバケットでバージョニングが有効になっているかどうかによって、いくつかの異なる方法で実現できます。バージョニングが有効になっていないバケットの場合、record type にフィルタを追加します。バージョニングが有効になっているバケットの場合、delete markers に追加のフィルタを追加します。Delete markers を使うことで、完全削除と、削除リクエストが行われたときにバージョニングされたバケットに追加される delete markers を区別することができます。
では、誰がデータを削除しているかが分かりました。 実際に削除されたデータが何かを知りたいと思うでしょう。その場合、select ステートメントを更新して bucket、key、version ID を含めることで実現できます。バージョニングが有効になっていないバケットの完全削除からは復旧できませんが、バージョニングが有効になっている場合、このクエリの出力を使って delete markers を削除することで削除リクエストをロールバックすることができます。実は、先週 S3 metadata を使ってこれを大規模に実行できるツールを公開しました。 このツールは削除をロールバックするだけでなく、バケットでバージョニングが有効になっている限り、実際にすべての変更をロールバックすることができます。これは S3 metadata をクエリして特定の時点に存在していたバージョンを理解し、その後 S3 Batch Operations を使ってバケットを delete markers を削除し、オブジェクトをコピーすることで、以前の状態に戻すことで実現されます。このツールを見てみることを強くお勧めします。試してみるのもいいでしょう。
では、request metadata についてはここまでです。次は system metadata に移ります。 System metadata は journal テーブルと inventory テーブルの両方に存在し、データランドスケープを理解するために必要な情報を提供します。 例えば、画面に表示されているのは、レガシーバケットの inventory テーブルの一部です。このバケットについて分かっていることは、数年にわたって異なる部門によってアップロードされた数百万のオブジェクトが含まれているということです。昨年、compliance チームはすべてのオブジェクトを SSE-KMS を使って暗号化することを要求するポリシーを更新しました。これに心当たりのある人はいますか？では、1年後、すべてのアプリケーションを SSE-KMS を使うように更新しましたが、ポリシーが施行される前に作成されたオブジェクトについては確信が持てません。平文を使用している残りのオブジェクトをどのように見つけるつもりですか？
ご覧の通り、これは本当に大海の中から一本の針を探すようなものです。ここで S3 メタデータの出番です。S3 メタデータを使うことで、この課題は単純な SQL クエリ一つに簡潔化されます。 さらに素晴らしいのは、ここで止まる必要がないということです。これらのオブジェクトを暗号化するアクションを取ることができます。出力を batch operation に渡して、これらのオブジェクトに対してコピーをインプレースで実行し、コピーリクエストの一部として希望する暗号化タイプを指定するだけです。
system metadata についてもう一つお話ししたいユースケースがあります。実はこれは system metadata と request metadata を組み合わせたものなんです。この例では、誰がどのくらいのデータをどのストレージクラスにアップロードしているかを見ています。これはスクリーン上のクエリで実現できます。このユースケースが興味深い理由は、従来ではアクセスログとストレージデータはおそらく全く異なる場所に保存されていて、アクセス制御も異なり、形式も異なっているということです。そしてこれらにアクセスして、データを一つの場所に統合して分析するには、実は開発者の相当な努力が必要でした。S3 メタデータを使えば、すべてが一箇所にあり、クエリの準備ができています。
第三のメタデータタイプはカスタムメタデータで、これが最も興味深い部分だと思います。 これにより、メタデータを独自のビジネスコンテキストで拡張することができます。これを行う方法はいくつかあります。まず一つ目は user metadata を使う方法です。 User metadata は journal と inventory table の両方に表示されます。オブジェクトに user metadata を付与するには、オブジェクト作成のリクエストの一部としてキーバリューペアで提供します。User metadata は PUT リクエストの一部として指定されるため、イミュータブルです。これにより、オブジェクトのライフサイクル全体を通じて変わるべきではない情報を保存するのに理想的です。例えば、オブジェクトの provenance やソースは変わるべきではないため、顧客がこのタイプの情報を user metadata として保存しているのをよく見かけます。
二番目のオプションは object tags を使う方法です。 Object tagging API を使ってオブジェクトに object tags を付与することができます。そしてオブジェクトに付与されると、自動的に journal と inventory table に表示されます。User metadata と object tags について理解しておくべき重要なことは、オブジェクトに付与されると、そのメタデータはオブジェクトと一緒に存在するということです。オブジェクトがコピーまたはレプリケートされた場合、このカスタムメタデータはそれと一緒に移動します。同様に、オブジェクトが削除された場合、そのメタデータもクリーンアップされます。
最後に、第三のオプションがあります。S3 table bucket 内の自分で管理する S3 table にカスタムメタデータを保存することです。 メタデータがタグとユーザー定義メタデータのサイズ制限を超える場合、顧客がこのアプローチを取るのをよく見かけます。これはサムネイルやテキストドキュメント、ビデオファイルの要約を保存する場合があります。Self-managed S3 tables は非常に柔軟なオプションであり、同じクエリエンジンツールと互換性があるため、管理されたメタデータと簡単に組み合わせることができます。Self-managed tables を使う際のトレードオフは、バケットからの更新が self-managed tables に伝播されるため、メタデータがまだ最新かどうかを理解するために、self-managed table を管理された S3 メタデータテーブルと結合する必要があるかもしれないということです。
カスタムメタデータのユースケースをいくつか見てみましょう。 顧客からよく聞くことは、合成データの爆発的な増加に伴い、AI生成 と非AI生成のメタデータを分離する方法が必要だということです。また、AI データがどのように作成されたかというその系統を追跡したいとも考えています。昨年の re:Invent での Nova ローンチの一環として、Bedrock は S3 にアップロードされたビデオと画像にユーザーメタデータを使用して注釈を付け始めました。これらの注釈は、そのオブジェクトが Bedrock から来たこと、そしてそれを作成するために使用されたモデルを示しています。S3 メタデータが有効になっていれば、AI 生成 と非AI生成の情報を分離する問題は、単一の SQL クエリに縮小されます。
前の例では、AI によって生成されたデータを理解することについて話しました。 しかし、S3 のデータが増加するもう 1 つの原因は、私たちの日常生活で見られるセンサーとモニターの指数関数的な増加です。 いくつかの例としては、セキュリティカメラ、車両センサー、飛行機や船のセンサー、そして地形データ、地理空間データ、月面画像、あるいはゲノム研究からの DNA シーケンスなどの科学研究からの情報があります。これらすべてのユースケースに共通しているのは、データ自体が、特にクラウドに最初にアップロードされるときに、それを分析するために必要なコンテキスト情報が不足しているということです。
例えば、アップロードしているセンサーデータのことを考えると、記録が作成された時間、センサーが存在していた場所、またはその他のセンサー設定など、追加情報を記録する必要があります。 幸いなことに、オブジェクトタグを使用して、これらすべてのコンテキストメタデータをオブジェクトとデータに追加できます。オブジェクトタグがデータに付加されると、それはメタデータテーブルに流れ込み、 オブジェクトに付加した同じコンテキスト情報をクエリして、データを見つけることができます。
実践デモ：メタデータ設定からクエリ、バッチ処理、自然言語による分析まで
では、これらが実際に動作しているのを見る時間だと思います。今日のデモについて、私たちは非常に興奮しています。今日お見せするすべてのことは利用可能で、文字通り今日ここを出る前にこれを試すことができます。今日のデモは 3 つの部分に分かれています。
まず、バケットでメタデータ設定をセットアップする方法を学びます。次に、異なるアナリティクスエンジンでこれらのメタデータテーブルをクエリする方法について説明し、最後に、メタデータクエリの出力に基づいてストレージ管理アクションを実行する方法を見ます。
では始めましょう。最初の部分、つまり汎用バケットにメタデータを設定することから取り組みます。これが最も簡単な部分です。本当に1分以内にバケットに設定できます。やることは、メタデータを設定したい汎用バケットを決めるだけです。
この場合、Starwatcher バケットで作業していきます。話題に上がった2つのテーブルは journal テーブルと live inventory テーブルです。これらを有効にして、暗号化タイプを指定することができます。そして record expiration を使うと、一定期間後にレコードを期限切れにすることができます。例えば、365日以上前のレコードを期限切れにしたい場合、そうすることができます。live inventory テーブルは有効になっています。やはりテーブルの暗号化タイプを選択して、メタデータ設定を作成できます。
ここで言及したいことがいくつかあります。設定を作成すると、最初に起こることはテーブルステータスが creating ステージに入ることです。数秒以内に journal テーブルがアクティブになります。Journal テーブルは forward looking で、put と delete をキャプチャするので、設定を設定するとすぐにアクティブになります。Live inventory テーブルはまず backfilling ステージに入ります。これは live inventory テーブルがバケットについてのすべての情報を持っているためです。既存のすべてのオブジェクトがキャプチャされます。ですから最初に backfill ステージに入ります。ここでは、すべてのオブジェクトのメタデータを取得して、テーブルを準備して整えます。
もう1つ指摘したいことは、ここで table bucket が AWS S3 であることが見えるということです。これは table bucket で、リージョンとアカウントのすべてのメタデータテーブル、すべての journal テーブルと live inventory テーブルがホストされます。この単一のバケット内で、すべてのインベントリと journal テーブルを見ることができます。namespace は再度おなじみに見えるかもしれません。これはメタデータテーブルを設定したバケットの名前と非常に密接に対応しています。通常は B アンダースコアのプレフィックスがあります。
これがメタデータ設定の設定についてのすべてでした。次は、デモの第2部に進みます。これはこれらのメタデータテーブルをクエリする方法についてです。これらのテーブルを設定する方法を学んだので、それらを読んでクエリする方法を探ってみましょう。ここで journal テーブルと live inventory テーブルの両方がアクティブになっています。今日は journal テーブルをクエリすることから始めます。SageMaker Unified Studio と Athena の両方を使ってこれらのテーブルをクエリします。
まず journal テーブルをクエリすることから始めます。ここで使用しているのは SageMaker Unified Studio です。SageMaker Unified Studio と S3 Table buckets の統合は本当にシンプルです。ワンクリックの統合です。最初に見ていただきたいのは、先ほど説明したトポロジー全体です。 ここでバケットを確認してみます。ご覧の通り、AWS S3 table bucket が表示されています。namespace は B アンダースコア バケット名で、journal テーブルと live inventory テーブルという 2 つのテーブルがここに表示されています。
次に見ていただきたいのは、journal テーブルと live inventory テーブルについて説明した時のスキーマです。これは journal なので、requester、request ID、source IP address という 3 つの特別なフィールドが表示されます。 今日 journal テーブルでテストするシナリオは、過去 7 日間に特定のプレフィックスで削除されたすべてのものを表示することです。ここで多くの追加フィルターでフィルタリングできますが、誰かが特定のプレフィックスのオブジェクトを削除したかどうかを確認したいと思っています。
では実行してみます。数秒以内に、削除されたすべてのものと、プレフィックス内でこれらのオブジェクトを削除した requester のリストが表示されます。 これが journal テーブルが非常に強力である理由です。調査クエリ、監査分析、バケットで何が起きたのか、そして誰がそれをしたのかを追跡しようとする場合に活用できます。
このデモの次の部分は live inventory テーブルのクエリです。ここでは Athena を使用して live inventory テーブルをクエリしています。Live inventory テーブルは、バケット全体を見て何が起きているのかを確認したい場合の、ストレージランドスケープ分析に役立ちます。 ここで見たいのは、特定の種類のタグを持ち、特定のストレージクラスにあるすべてのものです。暗号化とチェックサムタイプの追加フィルターを追加できます。特定の種類の weather タグと training カテゴリーのオブジェクトタグを持つすべてのオブジェクトのリストを取得しようとしています。
やはり数秒以内に、オブジェクトをリストしたり get object tagging を実行したりすることなく、特定の条件を満たすすべてのものが表示されます。タグの特定の条件を満たすすべてのもののリストを取得できます。
ここで指摘したいもう一つの興味深い点は、これらのオブジェクトがすべて Glacier ストレージクラスにあるということですが、メタデータはクエリ可能だということです。これは S3 メタデータの強力な側面です。すべてのストレージクラスにわたってすべてのオブジェクトのメタデータを取得でき、それは即座にクエリ可能です。この時点でメタデータにアクセスするために何も復元していません。
デモの2つの部分が完了しました。設定方法を学び、ジャーナルテーブルとライブインベントリテーブルの両方をクエリする方法を探索しました。本日のデモの3番目の部分は、メタデータテーブルの出力に基づいてストレージ管理アクションを実行することです 。これを行うために、別のシナリオを取り上げます 。Alice という、モデルのトレーニング用データを検索しようとしていたデータサイエンティストを覚えていますか。彼女は実際に雨天時の駐車支援システムをトレーニングしています。ここで私がしたいことは、Glacier に保存されているすべての生データを取得して、それをすべて復元し、彼女が使用できるようにすることです。
これを簡単に説明しましょう。このクエリは以前見たことがあります。インベントリテーブルで実行して、Glacier ストレージクラスのこれらの特定のタグ条件に合致するすべてのもののリストを取得しました。バケットとキーだけに限定しました。それはバッチオペレーションジョブに渡す必要があるものだからです。このクエリの出力を渡す最も簡単な方法は、この出力が保存されているバケットに移動することです 。クエリ結果が保存されている実際の S3 バケットに移動し、それをバッチオペレーションジョブに渡します。
結果はこの training query プレフィックスに保存されています。結果を取得しに行きます。このクエリ結果を使用する前に1つ小さなことをする必要があります 。それはバッチオペレーションジョブが読み取れる形式に変換することです。ここで実行できます。2つの値（バケットとキー）を分離して、マニフェストファイルとして保存するだけです。つまり、ここでしていることは、メタデータテーブルからの出力を取得し、それをカンマ区切りリストに変換し、このマニフェストファイルに保存することです。
そのマニフェストファイルの URI を取得しに行きます。これは基本的に最も重要なステップです。データを持っていて、準備ができていて 、バッチ処理の準備ができています。このマニフェストファイルの URI を取得して、バッチオペレーションジョブに渡します。これは本質的にこれで最大のステップです 。次に、さらにいくつかの設定を行う必要があります。最も重要なことは、バッチオペレーションジョブが実行する操作を選択する必要があることです 。Glacier からオブジェクトを復元して準備しているので、restore を選択しました。5日間利用可能にしたいので 、このバッチオペレーションジョブを優先度で実行しようとしているため、準備ができたら実行を選択しています。
通常、completion reports は manifest ファイルと同じ場所に置きたいので、completion reports がどこにあるかの URI を素早く取得しに行きます。これが completion reports の URI です。これを batch operations job に渡すだけです。 restore operation を実行する際に batch operations が使用するロールを選択します。 そして query の出力を使用して batch operations job をセットアップしました。job をセットアップする際に確認したい点がいくつかあります。 job がセットアップされると、manifest 全体を見ることができ、restore する object の数を確認できます。
それでは、ここで設定した batch operations job を見てみましょう。 manifest リストに 88 個の object があることが表示されています。すべてが restore されます。restore が operation です。5 日間 restore されます。これが S3 metadata を使用して batch processing job を実行できることの力です。データの準備に何時間も費やす必要はもうありません。query の出力を取得して、それを処理し、batch operations job 用に準備して、渡すだけです。
最後に、今日のデモの最後の部分として、 natural language を使用した querying についてお話しします。Claire が言及したように、metadata テーブルを 3 つの方法で query できます。Kiro CLI と MCP for S3 Tables を使用して natural language で query してみます。まず Kiro を初期化することから始めます。既に Kiro で MCP for S3 Tables をセットアップしているので、初期化するとすぐに S3 Tables の MCP server がロードされ始めるのが見えます。 これが実際に natural language を使用して metadata テーブルを query できるようにするもので、MCP for S3 Tables です。SQL query を手動で作成する代わりに、基本的にプロンプトを渡して、storage を分析し、すべての object count、storage class distribution、prefixes を確認するよう指示しています。
Quiro が私のリクエストを解釈して自動的に分析を実行するのを見てください。舞台裏では、基本的に S3 metadata テーブルに接続しています。 いくつかのツールを実行するための許可を求めてくるでしょう。具体的には query database というツールです。これが私のテーブルを query するために使用するツールです。 これで SQL query を実行する準備ができました。この時点で S3 テーブルに接続しており、実行している SQL query を最適化しています。
また、Quiro に特定の query を実行している理由を教えてもらうよう指示したので、まず count、size、distribution を確認し始めたのが見えます。 その情報を取得すると、prefixes に進み、最大の prefixes を見つけています。これはすべて、私が単一の SQL query を実行したり、どの SQL を実行したいかを指示したりすることなく起こっています。私がしたのは、見たいものを正確に指示しただけです。ですから、prefix 分析を修正し、prefix ごとの storage distribution を分析し、最後に、これをすべてサマリーで提供することを期待しており、現在それを実行しています。実行可能な出力を含むクリーンな executive summary です。
ストレージの総オブジェクト数、ストレージクラスの分布、プレフィックスの分布が確認できます。また、実行できるアクションについていくつかの推奨事項も提示されています。これが S3 メタデータテーブルと Quiro、MCP for S3 テーブルを組み合わせることの力です。メタデータテーブルと対話でき、ビジネスチームもメタデータテーブルと対話でき、SQL の専門家である必要がありません。 これがメタデータの実際の活用方法です。
実際の顧客事例と3つの重要なポイント：S3 Metadata がもたらす組織への影響
次に皆さんが質問するであろうことは、どこで使用できるのか、そしてどのリージョンで利用可能なのかということです。現在、28 のリージョンで利用可能であり、そのうち 22 は過去 1 週間でローンチされました。引き続きリージョンの拡大を進めており、非常に期待しています。 本日は多くのことをカバーしました。データディスカバリーの課題と機会についてお話ししました。 S3 メタデータがこれらの課題をどのように解決するかについてお話しし、デモをご覧いただきました。ここからは実際の影響についてお話ししたいと思います。メタデータを導入して即座に成果を上げた、実際の顧客シナリオ 2 つをご紹介したいと思います。
最初にご紹介したいのは、CT スキャンから 3D モデルを生成し、毎時間数千のオブジェクトとファイルを処理する医療画像処理企業のストーリーです。 以前、この顧客はイベントを使用し、Lambda で各ファイルを処理していました。このワークフロー全体は非常に脆弱で、タイムアウトが発生し、多くの複雑性が関わっていました。 S3 メタデータテーブルを導入した際、この顧客は S3 メタデータを使用してジョブ処理パイプラインを完全に刷新しました。現在、S3 メタデータジャーナルテーブルを使用し、15 分ごとにクエリを実行してクエリ結果を取得し、オープンソースのオーケストレーションプラットフォームを使用しています。 ジャーナルテーブルの出力を 15 分ごとにオープンソースのオーケストレーションプラットフォームに供給し、それが新しいオブジェクトのバッチ処理を支援しています。現在、毎時間数千のファイルを処理しており、全体的な処理時間が大幅に短縮されました。これはワークフローを意味のある形で大幅に高速化する本当に影響力のある方法です。
2 番目のストーリーは、数千のパブリッシャーから数百万の記事を保有するデジタルコンテンツ企業についてです。彼らの課題は、すべてをオンプレミスからクラウドに移行し、異なるシステム全体でこれらの数百万のファイルを追跡する必要があることです。彼らは古いサーバー、データベース、そして S3 を持っています。 S3 メタデータがなければ、これは手作業の悪夢になっていたでしょう。しかし、S3 メタデータインベントリテーブルを使用して、 彼らはシンプルな SQL クエリを使用してデータベース ID とマイグレーションタグに基づいてデータを検索しています。現在、どのファイルが正常に更新されたのか、どのファイルが重複しているのか、どのファイルを削除できるのかといったシンプルな質問に答えることができます。シンプルな SQL クエリでこれらの質問に答えることができるようになりました。現在、すべてのファイルに完全な可視性を持ちながら、自信を持ってペタバイト単位のデータを移行しており、手作業による追跡や推測は一切ありません。
最後に、本日のセッションをこれらの影響力のあるストーリーで締めくくるために、S3 メタデータがデータディスカバリーでどのように組織を支援するかについて、3 つの重要なポイントをお伝えしたいと思います。まず、常に最新のメタデータを提供するため、 検索を止めて、必要な情報についてテーブルにクエリを実行するだけで済みます。データサイエンティスト、セキュリティチーム、エンジニアは基本的に数分以内に情報を検索できます。
次に、これらの Iceberg 互換テーブル、ジャーナルテーブルとライブインベントリテーブルを使用することで、スマートなワークフローを構築し、これらのストレージインサイトをすべてアクションに変換することができます。大規模なバッチワークフローを構築できます。そして最後に、データレイクを将来に向けて保証することができます。S3 メタデータは、ストレージと知的にやり取りできる AI エージェントの基盤を提供します。メタデータの旅を始めるのに役立つリソースをいくつかご紹介します。本日はみなさんにお越しいただき、本当にありがとうございます。お時間をいただき感謝いたします。また、re:Invent の残りのセッションも頑張ってください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion