はじめに
こんにちは、「カミナシ 従業員」開発チームの 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 倍のトランザクションスループットを実現しています。
内部的には、先ほど触れた Parquet に自動でメンテナンスタスクを実行しているようです。
また、Lake Formation と連携することで、テーブルごと、カラムごとの権限制御も可能です。
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 のセッションでは面白いユースケースが紹介されていました。
一つ目は、画像をS3 にアップロードすると、画像に写っている物体を検出して、タグ付けするフローです。例えば “プロジェクト”: “アフリカ”, “象”: true, “人”: true
といったメタデータを付与しておけば、後から SELECT * FROM images where tag.象 is true and tag.人 is false
とクエリしてアフリカの象だけが映る画像を絞り込めます。
近日中に Blog を公開予定とのことだったので、公開されたら試してみよう思います。
二つ目は、S3 に保存するデータが、Bedrock による AI 生成かそうでないかをメタデータとして保持している例です。AI 生成とそうでないテキストで、結果にどういう違いがあるかを分析したい場合など、S3 object に直接メタデータが紐づいていると便利です。
データ基盤は素人なので迂闊なことを言うと、データのメタデータを整合性ある形で付与するワークフローがあるなら、そのデータレイクはデータウェアハウスに近いように感じました。
おわりに
セッションを聞いている時はパフォーマンスの課題など、ピンとこなかったのですが、既存サービスを調べたり、世の中の流れを踏まえて反芻すると、強く望まれたサービスだったことが分かりました。
カミナシはノンデスクワーカーにWebアプリケーションを提供するsaasスタートアップです。大量データを分析して顧客に価値を提供していくのはまだ先のフェーズになりそうですが、Amazon S3 Metadata は活用したいケースが浮かんでおり、GA するのが楽しみです。
カミナシはソフトウェアエンジニアを募集しています。すぐに仕事に役立つ技術じゃなくても気になって調べてブログにしてOK!そんな弊社で一緒に働きませんか?ご応募お待ちしております!