垣見です。
AWS re:Invent 2024で発表されたAmazon S3 Metadataについて、概要をつかめるようになることを目的としたブログです。
後半では設定・クエリ・削除も実画面で触っています。
なお、このブログはサーバーワークスで参加しているQiitaアドベントカレンダー2024の記事の一つとしてアップしておりますのでよければ他のブログもご覧ください。
※本発表はプレビュー版です。
Keynoteで発表のあった内容と2024年12月23日(UTC+0900)時点での動作となります。
以降のプレビュー期間、および GA 時には動作が変更となっている可能性がある点にご留意ください。
- 結論：Amazon S3 Metadataとは
- 発表の背景
- メタデータとは？
- 仕組み
- 対応リージョン
- 料金
- 使ってみよう
- テーブルバケットの削除
- 結論（再）：Amazon S3 Metadataとは
- まとめ
結論：Amazon S3 Metadataとは
- S3オブジェクトのメタデータを取得・クエリできる機能（※プレビュー版）
- 裏ではAmazon S3 Tablesが動いている
- メタデータはAWS側で自動更新される
- データの検索や分析に有効
発表の背景
Amazon S3 Metadataは、re:Invent2日目のMatt Garmanのキーノートで発表されました。(45:45あたりです）
S3はデータレイクによく使われるようになり、長期間使い続けるほどに必然的にデータは増えます。
そしてデータが増えれば増えるほど、データの検索は困難になります。
そんな時は、例えば写真なら「Las Vegasで取った写真」、「2021の写真」のように、データ自身の情報すなわちメタデータを使えると検索に便利です。
ただ、メタデータを検索可能にするには、S3汎用バケットから全オブジェクトを取得して、メタデータ情報を取得・付与し、メタデータとデータそれぞれで更新があったら同期するパイプラインを用意し……と、なかなか難しい開発が伴います。
そこで発表されたのが、Amazon S3側で自動的にメタデータを管理して分析や検索を容易化してくれる、Amzon S3 Metadataであるという訳です。
S3 Metadata is an event-processing pipeline that is designed to keep the metadata table eventually consistent with what changes have occurred in your general purpose bucket.
（S3 メタデータは、汎用バケットで発生した変更とメタデータテーブルを最終的に一致させるように設計されたイベント処理パイプラインです。）
S3 Metadata tables schema - Amazon Simple Storage Service
まとめ：何が良いのか？
- メタデータを使うことで簡単にS3のオブジェクトを検索、保存、クエリができるようになります。
- メタデータ取得に複雑な開発が不要です。
- ビジネス分析、人工知能と機械学習 (AI/ML) モデルのトレーニングなどで使用するデータをすばやく準備できます。
メタデータとは？
システム定義とユーザー定義
メタデータにはいくつかの種類があります。
| メタデータの種類 | カテゴリ | 備考 |
|---|---|---|
| システムメタデータ | システム制御 | オブジェクトの作成日など、S3側で自動管理される値 |
| システムメタデータ | ユーザー制御 | 暗号化設定やストレージクラス等、ユーザーが変更できるシステムの値 |
| ユーザー定義の オブジェクトメタデータ |
ユーザー制御 | アップロード時にユーザーが割り当て可能な値 |
オブジェクトメタデータの使用 - Amazon Simple Storage Service
APIを使うとユーザーが自由なメタデータを付けることも可能なようです。
メタデータ例
以下は一部抜粋したものです。必須のメタデータとそうでないものが存在します。例えばサイズとかタイムスタンプなどが身近でしょうか。
詳細なテーブルのスキーマは以下ページに記載がありました。
S3 Metadata tables schema - Amazon Simple Storage Service
リンク先のメタデータテーブルの例では、user_metadataとして{count -> Asia, customs -> false, family -> true, location -> Mary, name -> football, user -> United States}のような情報も設定されていますね。
管理できないメタデータ
全てのメタデータが管理できるわけではないようです。
以下はできないとされているものの例です。
- S3 ライフサイクルの有効期限または移行ステータス
- オブジェクトロックの保持期間またはガバナンスモード
- オブジェクト アクセス制御リスト (ACL) 情報
- レプリケーションステータス
Metadata table limitations and restrictions - Amazon Simple Storage Service
仕組み
Amazon S3 Metadataの後ろでは、同日に発表のあったAmazon S3 Tablesが動いています。
詳細は以下のブログをご覧いただければと思いますが、S3 Tablesとは簡単に言うと「Apache Iceberg テーブル対応で自動管理機能のあるS3バケットタイプ」です。表（Table）形式のS3バケットとして、汎用バケットとは違うものとして覚えてください。
Amazon S3 Metadataを使う際は、事前にAmazon S3 Tables のテーブルバケットを用意しておきます。
メタデータ取得設定をONにした汎用バケットのオブジェクトは、自動的に連携させた Amazon S3 Tables のテーブルバケットにキャプチャされます。
この読み取り専用テーブルは、メタデータテーブルと呼ばれます。
S3 TablesはTableをいくつも入れられるので、下の図のようにひとつのS3テーブルバケットに複数の汎用バケットのメタデータを格納することも可能です。
テーブルバケットを AWS Glue データカタログと統合すると、Amazon Athena、Amazon EMR、Amazon Redshift、Apache Spark、Apache Trino……などのクエリエンジンを使用してメタデータテーブルを直接クエリできます。
QuickSightなどと連携すれば、メタデータ情報をダッシュボードとして可視化することも可能になってきます。
対応リージョン
裏でAmazon S3 Tablesが動いているため、その対応リージョンと同じようです。
- 米国東部 (バージニア北部) リージョン
- 米国西部 (オレゴン) リージョン
- 米国東部 (オハイオ) リージョン
徐々に増えていくかとは思いますので、現時点での情報のご確認は以下リンクからお願いします。 Metadata table limitations and restrictions - Amazon Simple Storage Service
料金
考え方
結論としてはメタデータ自身も課金対象であり、その分のPUTリクエスト料金などはAmazon S3 Tablesと同じようにかかるようです。
料金確認ページの記載
Amazon S3 Metadataとしての特定の料金ページはありませんでした。
Amazon S3 Tablesの料金は、リンク先 で言語設定を英語にし、タブで [Tables] をご選択してご確認いただけます。（対応リージョンにご注意ください。）
2024/12/23時点では、S3 Standardとほぼ同じか少しだけ高価かといった料金となっています。
さらに同ページをスクロールしていただくと、「S3 Tables pricing example:」という部分にAWSメタデータを取得してAmazon S3 Tablesを運用する場合の価格例が記載されております。
これによるとメタデータ自身もメタデータファイルとして課金対象としてとして捉えるようで、その分のPUTリクエスト料金がAmazon S3 Tablesと同じようにかかっています。
特に注意点として、メタデータをテーブルバケットに登録する際の料金が考えられます。
空のテーブルバケットをメタデータ格納先に指定した時点で、メタデータ取り込みが発生してS3へのPUTリクエスト料金が発生します。
この時場合によってはメタデータが特に一度に大量に取得されると思われますので、データ量にはご注意ください。
（実際にCost Explorerで見てみようと思ったのですが、他のS3バケットと混ざってしまうかつ検証レベルでは大変小さい値しか用意できず、取得難易度が高かったです。実運用している方のデータがあれば参照したいと思っているので皆さま是非ブログを！！！！プレビュー版なので難しいかもしれませんが……）
料金削減のヒント
以下のような記載がありました。
S3 Metadata is designed to continuously append to the metadata table as you make changes to your general purpose bucket. Each update creates a snapshot—a new version of the metadata table. Because of the read-only nature of the metadata table, you can't delete records in the metadata table. You also can't use the snapshot expiration capability of S3 Tables to expire old snapshots of your metadata table.
To help minimize your costs, you can periodically delete your metadata table configuration and your metadata tables, and then recreate them. For more information, see Deleting metadata table configurations and Deleting metadata tables.
S3 メタデータは、汎用バケットに変更を加えると、メタデータ テーブルに継続的に追加されるように設計されています。更新ごとに、メタデータ テーブルの新しいバージョンであるスナップショットが作成されます。メタデータ テーブルは読み取り専用であるため、メタデータ テーブル内のレコードを削除することはできません。また、S3 テーブルのスナップショット有効期限機能を使用して、メタデータテーブルの古いスナップショットを期限切れにすることもできません。
コストを最小限に抑えるために、メタデータテーブル構成とメタデータテーブルを定期的に削除して再作成することができます。詳細については、 「メタデータ テーブル構成の削除」および「メタデータ テーブルの削除」を参照してください。
Metadata table limitations and restrictions - Amazon Simple Storage Service
書いてあるまんまですが、読み取り専用であるメタデータテーブルには古い変更ログなどが溜まっていってしまう（！）ため、定期削除・再作成がコストを抑えるために推奨されているようです。
ただし再作成時にPUTリクエスト料金がかかるのではないかと思うため、そこはデータ量や普段どの程度スキャンが行われているかなどを比べる必要がありそうです。
結構制限が多いので、上記リンク先はきちんと読んだほうが良さそうですね。
使ってみよう
ある汎用バケット（test-metadata-20241211）に対してコンソール上でメタデータの取得設定をして、Athenaでクエリを叩いてみましょう。
（AWS CLIでの操作はこちらのブログが良さそうです）
aws.amazon.com
仕様を確認しながらなので特にLake Formation周辺で脱線多めです。すみません。
対応リージョンであるバージニア北部（us-east-1）で作業していきます。
汎用バケットtest-metadata-20241211にはデータを既にいくつか入れてあります。
Amazon S3 Tablesの準備
あらかじめ、メタデータ格納先のテーブルバケットを作成しておく必要があります。
S3コンソールに移動します。
対応リージョンでは「テーブルバケット 新規」が出るようになっているので移動して、「テーブルバケットの作成」を押します。
名前を入れて作成します。
作成したテーブルバケットのARNをコピーしておきます。
汎用バケットのメタデータ設定を作成
Amazon S3 tables 対応リージョンで汎用バケットの詳細を見ると、メタデータ -プレビュー の項目が出るようになっています。
「メタデータ設定を作成」を押します。
先ほどの送信先テーブルバケットのARNを設定し、メタデータテーブル名を入れて「メタデータ設定を作成」をクリックします。
5秒くらいでステータスがアクティブになりました。「Athenaクエリエディタに移動」の表記もあります。
AWS Lake Formationでの許可設定
このままではAthenaでクエリしたときにエラー（Insufficient permissions to execute the query. Principal does not have any privilege on specified resource）が出てしまうため、AWS Lake Formationで権限を付けていきます。
Controlling access to metadata tables - Amazon Simple Storage Service
AWS Lake Formation コンソールに移動します。
初めてそのアカウント・そのリージョンでLake Formationを使う際は以下のような画面が出ますが、[Add myself] > [Get started]で問題ありません。
（気になるようなら後から[Administration] > [Administrative roles and tasks] > [Data lake administrators] から変更可能です。）
[Data Catalog] 配下に今までは無かった [Catalogs] が追加されています。
こちら読まなくてもよい検証なので折りたたんでおきます。主にDatabaseやTables周りの小ネタです。
既にふたつのCatalogsがあります。
NameがアカウントIDのものはデフォルトのようで、[s3tablecatalog] の配下にはそのリージョンでのAmazon S3 Tables テーブルバケット名がObjectsとして自動で入るようです。
また [s3tablecatalog] > [先ほど作ったS3メタデータテーブル名] を選択すると、「aws_s3_metadata」というDatabasesがあることがわかります。さらにそのDatabase [aws_s3_metadata]をクリックして右上[View] > [Tables]を選択すると、「s3metadata_test_metadata_20241211」というTablesができていることがわかりました。
これらは、メタデータテーブルの名前空間とメタデータテーブル名に準拠しているようです。（他のバケットにもS3メタデータを設定してみたところ、名前空間は共通の様でした）
しかも、Tablesのロケーションはこの場所に存在しない汎用バケットになっていました。AWS側でよしなにどこかに作ってくれているみたいですね。
ということでCatalogに権限を付与したいのですが、これはLF-tagは使えないようで、個別に指定してGrantしていく必要があるようです。
CatalogsにはそもそもLF-tagアクション項目が無く、Databases、Tablesに対しては（環境にLF-tagがあるのに）「付けられるLF-tagがない」と出てきました。
アクセスの権限を付けていきます。（最小権限を目指してみました）
[Permissions] > [Data permissions]に移動し、オレンジの [Grant] を選択します。
[Principals]
- [IAM users and roles] を選択し、[IAM users and roles]下の選択欄からAthenaを見る（大抵は自分の現在の）IAMユーザー/ロールを選択する
[LF-Tags or catalog resources] > [Named Data Catalog resources] を選択
- [Catalogs] : [<自分のアカウントID>:s3tablescatalog/<S3メタデータ用テーブルバケット名>]を選択
- [Databases] : [aws_s3_metadata]を選択
- [Tables] : [<メタデータ取得開始時に設定したメタデータテーブル名>]を選択
[Table permissions]
- [Table permissions] : [Select]を選択
[Grant]をクリックします。
Athenaでのクエリ
Amazon Athenaコンソールに移動します。
左メニューに今までは無かった「カタログ」が登場しています。
カタログで [s3tablescatalog/<S3メタデータ用テーブルバケット名>]、データベースで [aws_s3_metadata] を選択します。
その下に「テーブル」で[<メタデータ取得開始時に設定したメタデータテーブル名>]のものがあるはずです。その右の三点マークをクリックし、「テーブルをプレビュー」をクリックすると自動でクエリが生成され、自動で実行されます。
下にクエリの実行結果が出ました。
データサイズや暗号化などがあるのがわかります。 jpg, mp4, txtのデータを入れましたがそれら拡張子は出てこず、またtest.txtはなぜか表示されていませんでした。
新たなオブジェクトを追加してみる
新たに二つオブジェクトを入れてみました。
しばらく待ってからAthenaでクエリを叩くと新たなオブジェクトが更新されていました。
一回目に反映しなかったものと同じ中身の.txtファイルも追加できました。（一回目のtest.txtが反映されないのはなぜ…？ちなみに中身は[test]とだけ書いてあります）
タグを付けてオブジェクトを更新してみる
試しにオブジェクトの一つ（ooishi-san.jpg）にタグを付けてみます。
しばらく*待ってからAthenaを見てみると、object_tagsの項目にこんな感じで追加されていました。タグで簡単に任意の情報が付与・検索できるのは良いですね。
*：10分くらい。その間ずっとクエリしていたわけではないですが、反映までに5分以上はかかりました
またテーブルデータが変更されるのではなく、以下の表のようにメタデータが更新されたという新たな項目が追加されるという仕組みの様です。
長期間運用しているメタデータテーブルやダッシュボード表示する場合は、重複排除かrecord_typeなどを使ってとりたい情報のみを取得する必要がありそうですね。
| # | bucket | key | sequence_number | record_type | record_timestamp | version_id | is_delete_marker | size | last_modified_date | e_tag | storage_class | is_multipart | encryption_status | is_bucket_key_enabled | kms_key_arn | checksum_algorithm | object_tags | user_metadata | requester | source_ip_address | request_id |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | test-metadata-20241211 | ooishi-san.jpg | 1a2b3c4d5effffffffffffffff12345abcde67890fghijk0000000000000000000000000000000072 | UPDATE_METADATA | 2024-12-24 08:48:32.345000 | false | false | 548109 | 2024-12-11 13:14:00.000000 | 12345678abcdefgh | STANDARD | false | SSE-S3 | false | {extension=.jpg, metadata=test, detail=photo of ooishi-san} | {} | 123456789012 | 123.456.789.012 | ABCD1234 | ||
| 6 | test-metadata-20241211 | ooishi-san.jpg | 1a2b3c4d5effffffffffffffff1a2b3c4d5e00000000000000000000000000000000000000000000000072 | CREATE | 2024-12-11 13:14:00.074000 | false | false | 548109 | 2024-12-11 13:14:00.000000 | 12345678abcdefgh | STANDARD | false | SSE-S3 | false | {} | {} | 123456789012 | 123.456.789.012 | 9876DBCA |
テーブルバケットの削除
汎用バケット側はコンソールで普通に削除出来ますが、メタデータ保管先のテーブルバケットはまた別に消す必要があります。
テーブルバケットはAmazon AthenaやS3 コンソールからは消去することが出来ません。
メタデータテーブル構成（取得設定）をコンソール上などから削除した後、メタデータテーブルをAWS CLIなどで削除し、テーブルバケットを削除します。（中身のテーブルを消してからバケットそのものを削除する、という汎用バケットと同じ考え方です）
メタデータ構成（取得設定）の削除
この工程を踏まなくてもメタデータテーブルは削除できましたが、実際はテーブルがないのに汎用バケットのメタデータ設定欄に設定が残っているような表記になっていました。
メタデータの取得を止めて問題がないことを確認する期間を作ってからメタデータテーブルを削除する方が安心かと思います。
メタデータテーブル削除
AWS Lake Formationで対象テーブルへのSuper権限を付けて実施しました。
この時以下のCLI構文を使ったのですが、--table-bucket-arnはメタデータテーブルのARNではなくそのテーブルが格納されたテーブルバケットのARNなのでご注意ください。間違えると写真青枠のようなエラーになります。
aws s3tables delete-table \ --table-bucket-arn arn:aws:s3tables:us-east-2:111122223333:bucket/amzn-s3-demo-bucket \ --namespace aws_s3_metadata \ --name test_metadata_table \ --region us-east-2
エラーメッセージ：when calling the DeleteTable operation: User: arn:aws:iam::XXXXXXXXXXXX:user/administrator is not authorized to perform: s3tables:DeleteTable on resource: arn:aws:s3tables:us-east-1:XXXXXXXXXXXX:bucket/test-tablebucket-20241223/table/abcd1234abcd1234/table/s3metadata_20241223 (Table bucket name length should be within 3and 63 characters)
テーブルバケット削除
以下のようなAWS CLIコマンドで削除可能です。バケットが空でないとエラーになるので注意してください。
aws s3tables delete-table-bucket \
--region us-east-2 \
--table-bucket-arn arn:aws:s3tables:us-east-1:111122223333:bucket/amzn-s3-demo-bucket1
結論（再）：Amazon S3 Metadataとは
- S3オブジェクトのメタデータを取得・クエリできる機能（※プレビュー版）
- 裏ではAmazon S3 Tablesが動いている
- メタデータはAWS側で自動更新される
- データの検索や分析に有効
まとめ
プレビュー版ですが、GAや東京リージョン対応が待ち遠しいですね。
少しでも皆様のお役に立てましたら幸いです。
