技術⾰新統括本部 Cloud & Infrastructure技術部の藤井⼤輝です。アメリカのラスベガスで開催された"AWS re:Invent 2024"に参加したメンバーによる第2回レポートになります。
今回は注⽬のリリースであったS3 Tablesについて解説します。
まず最初に
Amazon S3は⾔わずと知れたストレージのコアサービスの⼀つです。そんなS3から新機能S3 Tablesがリリースされました。(※1) 本稿はre:Inventのセッションと検証を踏まえた考察を展開します。 またre:Inventにおける参考となるセッションを末尾の参考欄に記載します。(※2、※3)
-
(※4)
どのような機能か
S3 Tables
S3上でApache Icebergテーブルをマネージドに利⽤できる機能であり、指定のS3上のデータ更新に対してS3 Tables側でテーブル更新を⾏ってくれます。
また、従来の⽅式と⽐較するとクエリパフォーマンスの改善、データ管理の煩雑化が解消されることが期待されます。(※5)
※Apache Iceberg形式はデータセットからメタデータを⽣成し、メタデータに対してクエリを⾏うため、ユーザは元のデータセットの構造を意識することなくデータを扱うことができます。 近年データ分析、機械学習などを背景にデータセットのスキーマが複雑化し分岐しており、現在AWS Glueか らも利⽤できるためApache Iceberg形式が活⽤される機会が増えています。
またネイティブに連携できるAWS分析系のサービスも拡充しています。(※6)
・Amazon Athena
・Amazon Redshift
・Amazon EMR
・Amazon QuickSight
・Amazon Data Firehose
何がうれしいのか
既存⼿法における課題
既存の⼿法ではS3上でIceberg Tableを利⽤する場合Glue Data CatalogによるApace Iceberg形式のテーブルを指定する必要がありました。この⽅法での課題はセッションで語られていましたが以下の通りです。
#1 パフォーマンス
S3 Tablesでは複数アプリケーションからのアクセス競合によるトラフィックの増加やデータ規模の増加に⽐例して⾼いパフォーマンスを要求されますが、これまでのS3では対応しきれないパターンがありました。
#2 データ管理の煩雑化
Apache Icebergで利⽤するメタデータをS3上の特定のプレフィックスに配置し管理する⽅式であり、データセットに紐づくメタデータを削除やGlacier移⾏を⾏うとテーブルの整合性が保てなくなる仕様がありデータセットとメタデータの管理が煩雑となる要因となっていました。
また、セキュリティガバナンスの観点でもメタデータが存在するプレフィックスに対してバケットポリシーによる制御を分岐するなど同様に煩雑化する要因となっていました。
#3 コスト
Icebergではデータセットを更新の際にコミットを⾏い、コミットがスナップショットとして保存されます。
これらのスナップショットの蓄積がコスト要因になっていました。 またこれらの古いスナップショットやガベージコレクションを⾏うためには、⼿動作業が必要でした。
S3 Tablesを利⽤した際の利点
s3 Tablesでは上記の課題が解決することが⽰唆されています。
#1 パフォーマンス
キーの命名を分散させ最適化することに加え⾃動ファイル圧縮によりTPS最⼤10倍、クエリパフォーマンス最⼤3倍の改善が期待されます。
#2 データ管理の煩雑化
メタデータ管理をS3 Tablesが担ってくれることでS3上でのメタデータファイル管理をマネージドに実施できるようになります。 これによってデータセット・メタデータアクセスの制御を⼀括でバケットポリシーなどで実装する必要がなくなり、メタデータのアクセス制御はS3 Tables側で制御できるようになりセキュリティガバナンスの制御をシンプルに管理できるようになりました。
また同様にライフサイクル管理においてもメタデータを考慮した除外設定などの設計も不要になりシンプルな設計が実現できます。
#3 コスト
S3 Tablesでは不要なスナップショットの有効期限管理や未参照ファイルのクリーンアップを⾃動で実⾏可能になります。また多数の容量が⼩さいファイルを統合する⾃動圧縮機能も備えておりこれらの効果により容量的なコスト改善効果があります。
実際に使ってみる
今回はS3に配置したデータセット(CloudTrailのサンプルデータ)に対して実際にAthenaでクエリしてみたいと思います。
1. S3 Tablesの設定
・S3>テーブルバケットを選択し、「テーブルバケットの作成」
2. S3 Tabledataの設定
・クエリを投げる対象のデータがあるバケットを開き、メタデータタブ>「メタデータ設定を作成」
■⼿順1で作成したテーブルバケットを指定する。
3. LakeFormationでカタログへの権限設定
・LakeFormationから現在のロールへの権限付与を⾏うためにCatalog>s3Tablecatalogを選択し、Actions>Grantを選択する。
・⾃分で使⽤しているIAMリソースを指定して必要な権限を付与する。※今回はSuper userを付与
4. Athenaからクエリを投げてみる
・テストデータのメタデータをクエリできることが確認できました。
所感
所感としてはメタデータ管理をマネージドにできるメリットが⼤きいと感じました。 Glue Data CatalogによるApace Iceberg Tableを利⽤した場合S3の中に物理的にmetadata/プレフィックスが切られファイルが⽣成されます。
このメタデータがIceberg形式のテーブルでは⼀部でもGlacierに移⾏すると全体のクエリが投げられなくなるという仕様のためライフサイクル管理の対象外にする必要がありました。 ただそのためにはS3ライフサイクル管理にてデータセットとメタデータのプレフィックスをGlacier移⾏させるライフサイクルホワイトリストで作成する必要があり、ライフサイクル設計・構築が煩雑になる要因となっていました。
このメタデータの管理をS3 Tablesが担ってくれることでデータセットのライフサイクル管理やガバナンス管理を分離できた点が画期的であると⾔えます。
また、近年Amazon Security Lakeなどマネージドにログを管理する構成の中でもデフォルトでGlueのApache IcebergのテーブルをサポートしているパターンもありましたがこういったサービスでもS3 Tablesとネイティブに連携する機能などが今後提供されれば既存のサービスがさらにマネージドに分析できる可能性も期待されます。
留意点
執筆時点ではus-east-1(バージニア), us-east-2(オハイオ), us-west-2(オレゴン) の3リージョンでのみ利⽤可能となります。 今回「実際に使ってみる」章で利⽤しているS3バケットのメタデータ機能はプレビューになります。
まとめ
第2回となる本稿ではre:InventでリリースされたS3の新機能 S3 TablesについてDeepDiveした内容をお届けしました。 今回はS3 Tablesを利⽤することにより、クエリパフォーマンス向上・データ管理のシンプル化を実現しつつデータ分析を実施できる可能性を確認できました。
参考
(※1)Amazon S3 テーブルの発表 — 分析ワークロード向けに最適化されたフルマネージド型の Apache Iceberg テーブル(※2)AWS re:Invent 2024 - [NEW LAUNCH] Store tabular data at scale with Amazon S3 Tables
(※3)AWS re:Invent 2024 - What’s new with Amazon S3
(※4)CEO Keynote with Matt Garman
(※5)Working with Amazon S3 Tables and table buckets
(※6)Using Amazon S3 Tables with AWS analytics services
著者紹介
藤井大輝 FUJII Daiki
NTTデータグループ 技術革新統括本部 Cloud & Infrastructure技術部
主にAWS上の金融向けパブリッククラウドシステムの基盤開発に従事。
2023年Japan AWS Jr.Championsおよび2024年Japan AWS All Certifications Engineersに選出。
[PR]提供:NTTデータ