カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

【AWS re:Invent 2024】Amazon S3 Metadata と Amazon S3 Table Bucket は名前だけ見ると誤解しそうなので整理しました

はじめに

こんにちは、「カミナシ 従業員」開発チームの a2 (@Atsuhiro_tim) です。5日間の AWS re:Invent を終え、帰国しました。 今年の re:Invent は Amazon S3 Table Bucket, Amazon S3 Metadata という新機能が発表されましたね。

Amazon S3 Table Bucket というサービス名を聞いた時、「Relational Database インターフェースのプロビジョニング不要の DB(主に OLTP 用)で、個人開発サービスに使える?」や、「S3 の csv ファイルに対して Athena を経由せずに S3 上でクエリを書けるようになったのか?」 などと思ったのですが、実際は全く違いました。

現地で関連セッションに参加して話を聞き、document も読み、一緒に re:Invent に参加したメンバーと話しての解釈を踏まえ、これらのサービスについてレポートをまとめました。

参加したセッション:

  • STG366-NEW | [NEW LAUNCH] Unlock the power of your data with Amazon S3 Metadata
  • STG367-NEW | [NEW LAUNCH] Store tabular data at scale with Amazon S3 Tables

大量のデータを抱える企業の課題

Amazon S3 Table Bucket, Amazon S3 Metadata の二つの新機能の背景にある文脈は、データ活用の価値と幅が広がり、データの量と種類が増えていることです。 莫大なデータを抱える企業は、それらを効率よく、低コストで分析できるデータレイクソリューションを求めています。

様々なデータが存在する今

顧客の課題

S3 には既に大量 tabular データの分析が可能な Parquet という列指向ストレージ機能があります。しかし Parquet の問題点として、

  • 小さい Parquet が大量にあるとパフォーマンスが低下する
  • path prefix による権限制御しかできない

などがあります。

AI/ML の学習にもObject Storage (S3) は利用され、大量のデータが保存されます。この際、目的に応じて学習に使うデータを選択したいことがありますが、S3 は Prefix でしかデータを区切れないため、データセットを属性ごとに分割したり抽出するためには S3 の外にメタデータ管理の専用データベースを用意するしかありませんでした。

S3 の外にデータベースを作ると、データを最新に同期したり、整合性を担保するための仕組みが必要になり、運用の負荷にもなります。

新機能ができること

これらの課題を解決するため、 Amazon S3 Table Bucket, Amazon S3 Metadata が発表されました。それぞれ見ていきますが、参加したセッションの中では、どちらのサービスもコスト最適化とパフォーマンス最適化を強調していました。

Amazon S3 Table Bucket

Amazon S3 Table Bucket は Bucket 内にテーブルを作り、そこに Amazon EMR などを通して Apache Iceberg format のデータを保存することができます。保存されたデータは Amazon Athena 等のデータ分析サービスからクエリできます。

Tabular データに特化することで、パフォーマンスが最適化されており、通常の S3 と比べて 10 倍のトランザクションスループットを実現しています。

通常の S3 と比較した性能メリット

内部的には、先ほど触れた Parquet に自動でメンテナンスタスクを実行しているようです。

Parquet が使われていると書かれている

また、Lake Formation と連携することで、テーブルごと、カラムごとの権限制御も可能です。

LakeFormation と連携したフロー

Amazon S3 Metadata

Amazon S3 Metadata は、S3 object のメタデータを設定できるサービスです。メタデータには system-defined と user-defined の 2種類あり、system-defined なメタデータは自動で S3 object と同期され、 user-defined な custom metadata はイミュータブルです。 メタデータは S3 Table に保存されており、Table は read-only です。

Amazon 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

https://docs.aws.amazon.com/AmazonS3/latest/userguide/metadata-tables-schema.html

超訳すると、「S3 object のメタデータを結果整合で保持するイベント処理パイプライン」です。

メタデータが保存された S3 Table bucket のテーブルをクエリすることで、ビジネスインサイトの分析の幅が広がり、機械学習も適切なデータを選択しやすくなります。

また、マネージドに結果整合性を提供し、ユーザーのカスタムデータについては immutable にすることで、これまで整合性を担保するためにかかっていた運用負荷もかからないようになっています。

Amazon S3 Metadata のセッションでは面白いユースケースが紹介されていました。

Amazon Recognition で物体を検出して、タグ付けするフロー

一つ目は、画像をS3 にアップロードすると、画像に写っている物体を検出して、タグ付けするフローです。例えば “プロジェクト”: “アフリカ”, “象”: true, “人”: true といったメタデータを付与しておけば、後から SELECT * FROM images where tag.象 is true and tag.人 is false とクエリしてアフリカの象だけが映る画像を絞り込めます。

近日中に Blog を公開予定とのことだったので、公開されたら試してみよう思います。

Bedrock による AI 生成かそうでないかをメタデータとして保持している例

二つ目は、S3 に保存するデータが、Bedrock による AI 生成かそうでないかをメタデータとして保持している例です。AI 生成とそうでないテキストで、結果にどういう違いがあるかを分析したい場合など、S3 object に直接メタデータが紐づいていると便利です。

データ基盤は素人なので迂闊なことを言うと、データのメタデータを整合性ある形で付与するワークフローがあるなら、そのデータレイクはデータウェアハウスに近いように感じました。

おわりに

セッションを聞いている時はパフォーマンスの課題など、ピンとこなかったのですが、既存サービスを調べたり、世の中の流れを踏まえて反芻すると、強く望まれたサービスだったことが分かりました。

カミナシはノンデスクワーカーにWebアプリケーションを提供するsaasスタートアップです。大量データを分析して顧客に価値を提供していくのはまだ先のフェーズになりそうですが、Amazon S3 Metadata は活用したいケースが浮かんでおり、GA するのが楽しみです。

カミナシはソフトウェアエンジニアを募集しています。すぐに仕事に役立つ技術じゃなくても気になって調べてブログにしてOK!そんな弊社で一緒に働きませんか?ご応募お待ちしております!

herp.careers