re:Invent 2025: Amazon S3 Tablesのアーキテクチャ、Iceberg V3対応とIndeedの85PB移行事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Amazon S3 Tables architecture, use cases, and best practices (STG334)
この動画では、Amazon S3 Tablesの最新機能とベストプラクティスが紹介されています。Iceberg V3のdeletion vectorsとrow lineageサポート、最大80%のストレージコスト削減を実現するIntelligent-Tieringストレージクラス、そしてS3 Tablesレプリケーション機能が発表されました。Indeedは85ペタバイトのデータレイクをS3 Tablesに移行し、年間10%以上のコスト削減と開発者時間の大幅な削減を達成しています。パーティショニング、compaction、スナップショット管理の最適化手法が詳しく解説され、特にストリーミングワークロードではスナップショット保持期間を24時間以下に設定することが推奨されています。DuckDB WebAssemblyとAmazon Bedrockを組み合わせた自然言語クエリインターフェースの実装デモも披露されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
re:Inventセッション開始：Amazon S3 Tablesの一年を振り返る
皆さん、こんにちは。本日はご参加いただきありがとうございます。これまでre:Inventを楽しんでいただけていることを願っています。私はAditya Kalyanakrishnanと申します。Adiと呼んでください。S3チームのプロダクトマネージャーを務めております。本日は共同プレゼンターの方々と一緒に登壇させていただきます。IndeedのデータプラットフォームチームのシニアマネージャーであるMin Liさん、そして私がS3で密接に協力しているチームのプリンシパルエンジニアであるYuri Zarubinもおります。Amazon S3 Tablesについてお話しし、私たちが一年を通じて取り組んできたことを共有できることを大変嬉しく思います。
本日は次のような内容をご用意しております。まずS3 Tablesの簡単な概要から始め、その後、過去一年間に私たちがリリースした最近のローンチとアップデートについて詳しく見ていきます。 これまでに行ったすべてのローンチを駆け足でご紹介します。そして、つい最近ローンチした3つの新機能についても掘り下げていきます。そのうち2つを私がカバーします。AWSでロールアウトしたIceberg V3サポートと、S3 Tables向けの新しいIntelligent-Tieringストレージクラスのサポートについてです。その後、Minさんに登壇していただき、Indeedが85ペタバイトという大規模なデータレイクをS3 Tablesに移行している話と、そこから得られる最適化についてお話しいただきます。
その後、Yuriが、皆さんが検討できるワークロードとベストプラクティスについてお話しし、3つ目の新機能であるS3 Tablesレプリケーションについてもカバーします。彼はまた、S3 Tablesを使ってアプリケーションを構築する簡単な方法を示す素晴らしいデモも用意しています。ですので、最後までお付き合いください。そしてセッション終了後も、ご心配なく、私たちはここに、あるいは追い出されたら外におりますので、ご質問があればお答えしますし、今回ローンチしたばかりのこれらの新機能についてさらに詳しい情報もお伝えできます。
S3 Tablesの概要と過去一年間の機能拡張の軌跡
昨年のre:Inventで、私たちはAmazon S3 Tablesをご紹介しました。これは、S3内で直接フルマネージドのApache Icebergテーブルを作成できるものです。S3 Tablesでは、最適化されたパフォーマンスとスケールが得られます。S3 Tablesは、大規模な表形式データを保存するために特別に構築されています。つまり、S3はこれらがIcebergテーブルであることを認識しており、クエリエンジンがS3のスケールを活用できるように最適化された方法でテーブル内のデータをレイアウトすることができます。S3 Tablesがファーストクラスのデータベースリソースであることで、セキュリティコントロールも簡素化され、自動テーブルメンテナンスにより、パフォーマンスとコストの両面からテーブルが最適な状態に保たれるよう継続的に監視しています。
S3 Tablesは、AWSでデータレイクを構築しているお客様にとって、本当に基盤となりつつあります。AWSサービスと直接統合されており、まずGlueデータカタログから始まり、これにより、お客様が選択する多数のAWSサービスやツールを通じて、これらすべてのテーブルを検出できるようになります。それに加えて、すべてのテーブルバケットに組み込まれているIceberg RESTカタログインターフェースを通じてこれらのテーブルにアクセスできるオープンな方法も提供しています。または、AWS内のデータ資産全体を可視化したい場合は、Glueデータカタログに組み込まれているIceberg RESTカタログインターフェースを使用することもできます。
デフォルトで安全性が確保されています。粗粒度の制御が可能で、これらのテーブルリソースに直接IAMポリシーを設定することもできますし、Lake Formationを使用してきめ細かいアクセス制御を提供し、ガバナンスのニーズが満たされるようにすることもできます。このすべてのデータを分析する方法は数多くあります。Data Firehoseを通じてデータをストリーミングし、Glue ETLやEMRを使用してデータセットを変換処理することができます。そして、AthenaやRedshiftを使ってこれらのデータセットをクエリしたり、QuickSightを通じてダッシュボードを構築してこれらすべてのデータセットを可視化したり、さらには自然言語を使ってデータとやり取りすることもできる、一連のツールが用意されています。
さて、昨年S3 Tablesをローンチした際、正直なところ、お客様からの反応と関心の高さには驚かされました。そしてそれが私たちを一年中本当に忙しくさせ、S3 Tablesをより柔軟でデータレイク環境に最適化されたものにするための新機能を追加し続けてきました。私たちは、sortやZ-orderのような高度なコンパクション技術を追加してパフォーマンスとスケールを最適化しながら、これらの高度なコンパクション技術をコスト効率の良い方法で実行するなど、全般にわたって数多くの機能を提供してきました。また、32のAWSリージョンに拡大し、アカウント内のリージョンで作成できるテーブル数を100,000テーブルまでスケールアップしました。さらに、KMSを使用したテーブルレベルの暗号化のようなセキュリティ制御の面でもはるかに柔軟性が高まり、最近では属性ベースのアクセス制御のためにリソースタグを使用する方法も導入しました。
先ほど申し上げたように、AWS内でS3 Tablesを開放するという点で、S3コンソールからAthenaやSageMaker Unified Studio機能に直接アクセスできるようにしたり、Iceberg RESTカタログインターフェースを使用してS3 Tablesに直接接続できるようになった多くのパートナーツールを利用できるようにしたりと、一連の機能強化を行ってきました。実際、Yuriが今日後ほど、パートナーツールの一つであるDuckDBを使用してテーブルとやり取りするための自然言語インターフェースを構築することがいかに簡単かをお見せします。
これらすべての新機能により、 お客様は本当にS3 Tablesを活用できるようになりました。わずか一年の間に、お客様は400,000を超えるテーブルを構築・作成されました。 これは私たちにとって非常に励みになっています。しかし、まだかなり初期段階であり、クラウドにおける表形式データストレージを簡素化するための私たちの旅の始まりに過ぎません。私たちは、ちょうどローンチしたばかりの数多くの新機能について非常に興奮しています。
Iceberg V3機能のロールアウト：deletion vectorsとrow lineageによる効率化
これらの新機能のいくつかをご説明しましょう。まず、AWSで一般提供が開始されたIceberg V3 機能のロールアウトから始めます。Iceberg V3仕様に従って、削除ベクトルと行系統を使用してIcebergテーブルを書き込めるようになりました。これにより、変更を加える方法がはるかに効率的になり、テーブル内の経時的な変更を簡単に追跡できるようになります。この機能は、これらのV3機能をサポートするようになった多くのAWSサービスを通じて利用可能です。
では、これを少し詳しく見ていきましょう。まずはdeletion vectorsから始めます。これは、テーブル内のデータを削除するための効率的な方法を提供します。テーブルは複数のParquetファイルで構成されており、Iceberg V2テーブルでmerge-on-readパターンで行を削除すると、エンジンはこれらの更新ごとにpositional delete filesを追加することになります。これらのpositional delete filesもParquetファイルですが、非常に小さなParquetファイルで、クエリエンジンがこれらの削除された行やフィールドをマスクし、最新の更新でこのデータを効果的にレンダリングできるようにします。
行を削除すればするほど、テーブル内のデータを削除すればするほど、時間の経過とともにこれらのファイルが大量に蓄積されていきます。これにより、エンジンがこれらの多数の削除ファイルをふるいにかける必要があるため、クエリが本当に遅くなり、最終的にはこれらの小さな更新をすべて統合してテーブルを最適化し続けるための作業を基本的に行うために、compactionが必要になります。deletion vectorsを使用すると、これらすべての情報がbitmap vectorを持つ単一のPuffinファイルに統合されます。これにより、クエリエンジンは、これらすべての削除ファイルをふるいにかけることなく、テーブル内の削除されたデータを素早く把握できます。これによる追加の副次的なメリットとして、compaction処理の節約にもつながります。これらの削除ファイルを処理する必要がなくなるため、compactionがはるかに効率的で、さらにコスト効率も良くなります。
もう一つ言及したのはrow lineageです。テーブル内の行とそれらの行の変更を表す正規の方法を把握できる追加のメタデータフィールドが用意されました。各行にはrow IDとsequence numberフィールドがあり、これによりテーブル内で時間の経過とともに発生した変更を把握できます。この場合、データを更新する際に、いずれかのフィールドで編集を行うと、新しいsequence numberで表示されます。このようにして、テーブルのスナップショット全体でこれらの更新が流れていくのを実際に確認できます。同様に、テーブルにデータを追加する場合も同じように機能します。これらの新しい行には新しいrow IDフィールドがあり、それらの変更がいつ行われたかを表すsequence IDもあります。これにより、単純なSQLを使用して時間の経過とともにこれらの変更を追跡することがはるかに簡単になります。
これらすべての新機能は、組み込みのSageMaker Unified Studio統合を通じて使用できるようになりました。Unified StudioはIDEで、S3 Tablesのこれらのテーブルと対話するためのnotebookインターフェースをサポートしています。S3コンソールからSageMaker Unified Studioへはワンクリックで移動でき、このnotebook環境の素晴らしい点は、SQLだけではないということです。Pythonを使用したり、自然言語を使用してテーブルをクエリしたり、対話したりすることもできます。
S3 Tables Intelligent-Tieringサポート：最大80%のストレージコスト削減を実現
次はS3 TablesのIntelligent-Tieringサポートです。これは火曜日のMatt Garmanの基調講演で発表されたばかりです。この新機能は本当にエキサイティングなもので、S3 Tablesを使用するお客様にとって大幅なコスト最適化が実現されます。
Intelligent-Tieringを使用してテーブルを保存すると、時間の経過とともにテーブルストレージコストを最大80%削減できます。
さて、なぜこれを構築したのでしょうか?お客様と話をしたところ、Icebergテーブルのコスト最適化に関して3つの主な課題があることがわかりました。まず、データ量が拡大し続け成長していく中で、データの価値は依然として重要ですが、それでも非常にコスト効率の高い方法で保存したいということです。2つ目は、データを異なるストレージオプション間で手動で移動するためのライフサイクルポリシーを管理したくないということ、そして本当にS3にこれらすべてを任せたいということです。これらはIntelligent-Tieringが持つ特性であり、汎用S3バケットでも同様です。3つ目は、これらのファイルを読み取るメンテナンス操作を手動で調整したくないということです。つまり、実際には使用されていない非アクティブなデータセットで偶発的なティアアップが発生して、ストレージコストが増加することを心配したくないのです。
そこでIntelligent-Tieringでは、お客様が汎用S3バケットで得られるのと同じ体験を提供したいと考えましたが、それを超えて、テーブルメンテナンスをティア対応にしました。これにより、テーブルのメンテナンスを行う際に既存データのストレージコストに影響を与えることがなく、引き続きストレージコストを削減できるようになります。
それでは、どのように機能するかをご説明します。3つのアクセスティアがあり、データはfrequent accessティアから始まります。30日間アクセスがないと、自動的にinfrequent accessティアに移行します。これはfrequent accessティアよりも40%低コストです。さらに60日間アクセスがないと、そのデータはarchive instant accessティアに移行します。これはinfrequent accessティアよりもさらに68%低コストです。これらすべてはファイルレベルの粒度で機能します。つまり、テーブル内で、アクティブにクエリされているデータはfrequent accessティアにありますが、テーブルのよりコールドな部分は、より低温のアクセスティアに移行できるということです。このようにして、データが古くなるにつれて、ストレージコストを最適化できます。
また、変化するアクセスパターンにも最適化されています。infrequent accessティアまたはarchive instant accessティアにあるデータに突然アクセスがあった場合、これは新しい分析ワークロードを実行している場合や、データに対して過去の分析を行いたい場合などですが、そのデータはfrequent accessティアに戻ることができます。パフォーマンスの低下は見られず、その際に取り出し料金も発生しません。このように、データはアクセスパターンに基づいて、これらのティア間を流動的に移行します。
さて、これらはすべて私たちにとって基本的なものです。なぜなら、これは汎用のS3バケットとそこでのIntelligent-Tieringで得られるものだからです。しかし、私たちにとって本当に興味深く、エキサイティングなのはテーブルメンテナンスですよね。コンパクションのために読み取られるファイルであれ、スナップショットの有効期限切れのために読み取られるメタデータであれ、参照されていないファイルの削除であれ、これらの操作は実際にはそれらのオブジェクトを上位層に移動させることはありません。つまり、これらの操作はストレージコストに影響を与えないということです。
それに加えて、私たちが作ったのは、コンパクションに今やガードレールがあり、頻繁アクセス層にあるアクティブにクエリされているデータに対してのみ動作するようになっています。これは、データは一般的に最初に取り込まれたライフサイクルの時点でより高温でアクティブであり、その後徐々に冷却されていくためです。私たちは、コンパクション機能がアクティブに使用されているデータセットのクエリパフォーマンスを最適化するために機能することを本当に望んでいます。これは、クエリされて頻繁アクセス層に戻ってくる非アクティブなデータがある場合にも機能します。これらのファイルがコンパクションの対象となり、最適化されるのです。このようにして、コンパクションは最もアクティブなデータセットを継続的に最適化しながら、より冷たいデータはそのままにしておくことで、コンパクションへの支出に対して最適なリターンが得られるのです。
設定は非常にシンプルです。2つのオプションがあります。基本的には、テーブルを作成する際にストレージクラスをIntelligent-Tieringに設定することができます。また、デフォルトのストレージクラスを設定できる新しいバケットレベルの設定も導入しました。これにより、そのバケットに配置される新しいテーブルは自動的にIntelligent-Tieringに配置されるようになります。
顧客事例：Zita GlobalとIndeedにおけるS3 Tablesの導入効果
私たちが今ローンチした機能は、お客様がすでにS3 Tablesで得ている価値に追加されるものです。ここでは、これらのお客様のいくつかの例をご紹介します。まずZita Globalですが、彼らのAIマーケティングプラットフォームは、大規模で、常に変化し、即座に実行可能なデータに依存しています。数千のApache Icebergテーブルにまたがるペタバイトサイズのレイクハウスの基盤としてAmazon S3 Tablesを使用することで、データの鮮度レイテンシを約80%削減しました。これは、インサイトまでの時間が15分からわずか数分に短縮されたことを意味します。
こちらも素晴らしい例です。Indeedは、雇用市場を理解し、人々を適切な機会と結びつけるために、膨大な量のデータを活用しています。85ペタバイトのデータレイクをS3 Tablesに移行することで、データインフラストラクチャを合理化し、コストを削減しています。私たちは、Minさんにここに来ていただき、Indeedの移行ストーリーを共有していただけることを本当に嬉しく思っています。それでは、Minさん、どうぞこちらへ。
Indeedの85ペタバイトデータレイク移行ストーリー：Min Liによる実践報告
ありがとうございます、Aditya。さて、皆さんこんにちは。私の名前はMin Liで、IndeedのData Platformチームのシニアマネージャーを務めています。本日は、私たちのデータプラットフォーム変革のストーリーをお話しできることを大変嬉しく思います。これは、複雑な従来型のセットアップから、Apache IcebergとAmazon S3 Tablesを活用した、より効率的なデータレイクへと移行したストーリーです。私たちが実現した素晴らしいビジネス価値と、Indeedのコアミッションをより良くサポートするために、いかに迅速に動けるようになったかをお見せします。
Indeedのコアミッションはシンプルですが、非常に大きな取り組みです。私たちは人々が仕事を得られるよう支援しています。私たちが構築するすべてのもの、下すすべての決定は、このミッションに貢献するためのものであり、このミッションを動かすエンジンがデータなのです。データは、雇用市場を理解し、適切な候補者と適切な機会をマッチングし、求職者と雇用主の両方にとってより良い体験を創出するのに役立ちます。これをグローバル規模で効果的に行うためには、私たちはデータのマスターでなければなりません。
注目すべき公開事例として、Indeed Hiring Labがあります。このスライドでご覧いただけるように、これは私たちのデータレイクからのデータを直接活用して、労働市場に関する貴重な洞察を提供しています。チャートでご覧いただけるように、これは米国における過去5年間の給与透明性、求人投稿、賃金のトレンドを示しており、政府の政策立案者によって直接利用されています。
私たちが運用している規模は膨大です。私たちのデータレイクには、15,000を超えるデータセットにわたって85ペタバイト以上のデータがあります。毎日、私たちのプラットフォームは170,000件以上のクエリを処理し、求人レコメンデーションを最新の状態に保つために550テラバイト以上の新しいデータを取り込んでいます。このスライドの右側には、私たちのデータレイクプラットフォームのアーキテクチャ図が表示されています。
この図のすべての詳細を覚える必要はありませんが、私たちが扱っている複雑さを示すためにお見せしたいと思います。ご覧のように、データを生成するチームがさまざまなテクノロジーやツールを通じてデータセットを構築している、数百のカスタマーAWSアカウントがあります。これらのデータセットは、2つの異なる取り込みモードを通じて、私たちのデータレイクAWSアカウントに取り込まれます。読み取り側では、Athena、Trino、Spark、Snowflake、そして社内で構築されたクエリエンジンを含む、さまざまなプラットフォームでのデータ消費をサポートする必要があります。この規模は大きな資産ですが、同時に膨大な技術的および運用上の課題も生み出しています。これを管理することは簡単な作業ではありません。それは私たちにとってボトルネックとなっていました。
最初のステップは標準化でした。昨年、Indeedはデータレーク全体の標準テーブルフォーマットとしてApache Icebergに移行するという戦略的決定を行いました。このビジネス上の理由は明確でした。まず第一に、相互運用性です。私たちは、その仕事に最適なツールを使用できる柔軟性が必要でした。Apache Icebergにより、Athena、Trino、Spark、Snowflakeなどの様々なエンジンで同じ基盤データを活用することができ、ロックインされることがありません。
第二に、Hiveと比較して、Icebergはより優れたメタデータ処理とパーティショニング機能を提供し、その結果、クエリが高速化され、コンピュートコストが削減されます。
最後に、Apache Icebergは、スキーマエボリューション、タイムトラベル、ロールバックといった機能を提供しており、これらは私たちのビジネス継続性を確保する上で非常に重要です。この図でご覧いただけるように、私たちの全体的な目標は、すべてのデータを一箇所に集めることです。しかし、Icebergテーブルフォーマットを選択するだけでは十分ではありませんでした。運用をさらにスケールさせていく中で、私たちは、大規模なIcebergベースのデータレークを自分たちで管理しようとすることが、新たな重大な課題を生み出していることに気づきました。
こちらが、Icebergを大規模に管理する上での4つの主要な課題です。これらが、私たちがAmazon S3 Tablesを採用することになったビジネス上の課題でした。第一に、持続不可能な運用負荷です。私たちは、社内で構築したSparkベースのIcebergメンテナンスジョブの管理だけに、年間2,000時間以上の開発者の時間を費やしていました。これは、お客様向けの新しい製品や機能の構築に費やされていない、膨大なエンジニアリング時間です。
第二に、カスタマーオンボーディングが非常に遅く、手動でした。新しいデータサイエンスチームやプロダクトチームが、私たちのデータレークにIcebergテーブルのオンボーディングを必要とする際、稼働させるまでに丸一日以上の開発時間がかかっていました。350以上のチームを抱える、動きの速いテクノロジー企業において、これは永遠とも言える時間です。私たちのチームがイノベーションのボトルネックになっていたのです。
第三に、信頼性の低いアクセスです。ピーク時のワークロード中に、S3 APIのレート制限に何度も遭遇し、複数のSEV-1およびSEV-2インシデントが発生しました。つまり、重要なシステムがダウンし、ビジネスに直接影響を与えたということです。最後に、データアクセス制御が複雑で安全ではありませんでした。S3オブジェクトごとにタグ付けを行う古い方法は、遅く、コストがかかり、監査が非常に困難でした。これにより、セキュリティリスクとデータアクセスのボトルネックの両方が生じていました。
ここで、AWSとパートナーシップを組み、Amazon S3 Tablesを採用する絶好の機会を見出しました。今年の初めにAmazon S3 Tablesにオールインする決断を下し、その結果として見られたビジネスへの影響は変革的なものでした。まず、データガバナンスの簡素化です。6億以上のデータレイクS3オブジェクトの再分類という、以前は完了するのに数週間かかっていたタスクが、今では1分未満で完了できるようになりました。これにより、データアクセスのストーリーがより機敏で安全になりました。
次に、生産性の向上です。チームごとに1日かかっていた手動のオンボーディング時間を覚えていますか?それを10分未満に短縮しました。社内のお客様は、データをIceberg形式でレイクに取り込み、すぐに価値を提供し始めることができます。また、Amazon S3 Tablesが提供する専門的なメンテナンスのためのAWSマネージドサービスに移行することで、クラウドコストを削減しました。年間10%以上のAWSコスト削減を実現しています。これは、直接的なハードドルの節約であり、利益に直結します。
この点について、Adityaがこのセッションの冒頭で述べたように、近々、Amazon S3 Tablesの新しく発表されたIntelligent-Tiering機能を活用できるようになり、総クラウド支出を継続的に削減できるようになります。それについて非常に興奮しています。そして最後に、プラットフォームチームを解放しました。2,000時間の開発者の負担を覚えていますか?今では、毎年4か月分の開発者の時間をチームに取り戻すことができました。それは、ただシステムを維持するだけでなく、構築とイノベーションに使える4か月です。
段階的移行アプローチと得られた教訓：98%のSLO改善を達成したチーム事例
では、どのようにしてこの移行を実現したのでしょうか?意図的な3段階のアプローチによってこれを達成しました。ここでの鍵は、ビジネスを中断することなく移行を行うことでした。ステップ1は、監査と優先順位付けです。データレイクのクエリログを分析して、テクノロジーとアクセスパターンごとに特性を把握し、最初に移行すべき最もビジネスクリティカルなワークフローを特定しました。
ステップ2は、段階的に移行を開始することです。これが最も重要な部分でした。私たちはHiveからIcebergへデータを変換し、S3 Tablesバケットに格納するデュアルライトパイプラインを構築しました。これにより、ユーザーに影響を与えることなく、すべてを検証することができました。次のスライドで、私たちがどのようにこれを行っているのか、正確にお見せします。そして最後のステップは、自動化と最適化です。私たちは自動化ツールを構築し、すべての新しいデータセットがデフォルトでIcebergフォーマットに、そしてS3 Tablesとして直接移行されるようにしました。
この移行を段階的にどのように実行しているのか、より深く掘り下げるために、データレイク全体を複数のフェーズ、コホート、バッチに分割する方法を示すビジュアル図をご覧ください。一番上から見ていくと、現在レイクには約86ペタバイトのデータがあります。
これを2つの主要なフェーズに分けました。最初のフェーズは、現在ORCファイルフォーマットになっているHiveテーブルを、Iceberg ParquetとS3 Tablesに移行するもので、約67ペタバイトのデータがあります。2番目のフェーズは、すでにParquetフォーマットでデータがあるものの、汎用のS3バケットに保存されているもので、19ペタバイトが含まれています。
最初のフェーズから、さらに複数のコホートに分割しました。そして現在私たちが注力している最初のコホートは、カスタムSparkアプリケーションからアクセスされていないテーブルを移行することです。これにより、各顧客が各ジョブの権限を更新する必要を心配しなくて済みます。さらに一層下に移動すると、最後に最初のコホートから、段階的にバッチでデータを移行しています。まず、すべてが最初から最後まで機能することを証明するために、少数のPOCデータセットを移行しました。その後、約10ペタバイトの最初の本番バッチに移行し、その後バッチ2、バッチ3と、コホート全体が完了するまで進めていきます。このようにして、顧客に影響を与えることなく、段階的にビジネス価値を実現できます。
では、何を学んだのでしょうか？まず、アクセス制御の合理化です。S3 Tablesの大きなメリットは、データレイクのセキュリティを簡素化できることです。数十億の個別のS3オブジェクトにタグ付けしてアクセス制御を管理する代わりに、S3 Tables自体にリソースポリシーを使用できるようになりました。このアプローチにより、データレイク全体に対する統一されたアクセス制御の実施、監査、確保が容易になり、誤ったオブジェクトタグ付けによる潜在的な障害を排除できます。
第二に、Amazon S3 TablesをAWS Glueと使用する際には、Lake Formationのパーミッションに備える必要があります。現在、アクセスは標準的なIAMポリシーを経由してルーティングされません。代わりに、AWS Lake Formationによって管理されています。移行前に、データレイクへの読み取りアクセス、または読み取りと書き込みアクセスを必要とするすべてのアイデンティティを更新する計画を立ててください。最後に、クエリパターンを事前に監査し、更新してください。特にTrinoやSparkのようなクエリエンジンを使用する場合、潜在的なクエリパフォーマンスの問題に備える必要があります。現在のシステムが、Hiveの非標準的なパーティショニング戦略など、古いデータフォーマットに合わせてクエリを書き換えるカスタムプラグインや最適化に依存している場合、これらの最適化は移行中にリファクタリングが必要になる可能性が高いです。
今日の時点では、この移行ジャーニー全体においてまだ比較的初期段階にありますが、Indeedのパートナーチームがこの移行にオンボードされるにつれて、すでに実際のビジネスインパクトが見られています。ここでは、MDNAつまりIndeedのMarketplace Data and Analyticsチームから引用したビジネスインパクトの数字をご覧いただけます。このチームは、人々が仕事を見つけるのを支援するデータプロダクトを直接構築しているチームです。この数字を見てください。HA Insightsチームは、レポートが75%高速化されたと報告しています。Smart Sourcingチームは65%のコスト削減を達成しました。Indeed Interviewsチームは複雑さが88%削減され、Partner Analyticsチームは彼らのSLOにおいて98%の改善を実現しました。
これまでに見られたこれらすべての素晴らしいビジネスインパクトにより、私は次に何が来るのか非常に楽しみにしています。私たちは、Amazon S3 Tablesが、スケールを続ける中でこの移行ジャーニーにおいて大きく貢献できると信じています。それでは、AWSチームに戻します。彼らはS3 Tablesを使用した素晴らしいヒントとベストプラクティス、そしてデモを共有してくれます。ありがとうございました。
パフォーマンスとコスト最適化のベストプラクティス：パーティショニングからメンテナンスまで
ありがとう、Min。昨年のre:InventでS3 Tablesをローンチして以来、私たちは数え切れないほど多くのお客様と、さまざまなパフォーマンスの問題やコストの問題についてお話ししてきました。そして、多くのことを学びました。今年を通じて学んだことのいくつかを、皆さんと簡単に共有したいと思います。 4つの領域をカバーします。1つ目はIcebergのパーティショニングで、残りの3つは3種類のメンテナンスタイプです。compaction、スナップショット管理、そして未参照ファイルの削除についてカバーします。これらがパフォーマンスとコストにどのように影響するかを理解するために、それぞれを見ていきましょう。
まずパーティショニングから始めます。適切なパーティショニングを選択することは非常に重要です。なぜなら、これがAthenaやSparkのようなクエリエンジンがテーブルをスキャンする際にデータをプルーニングすることを可能にするものだからです。これによりクエリパフォーマンスが向上し、もちろんクエリコストも削減されます。
さて、Icebergには様々なパーティションスキームがあります。最もよく使われている2つは、時間ベースのパーティションとハッシュバケットパーティションです。例えば、アプリケーションログをテーブルにストリーミングしているとしましょう。通常、アプリケーションログの場合、タイムスタンプを使ってクエリを実行したいことが多いので、その場合は時間ベースのパーティショニングを使うのが理にかなっています。しかし、顧客IDのようなもので検索することに関心がある場合は、顧客IDカラムにハッシュバケットパーティションを作成するのがおそらく非常に理にかなっています。
さて、テーブルに適したパーティションを選択することは非常に重要な決定ですが、Icebergテーブルの素晴らしい点は、これが一方通行ではないということです。つまり、Icebergでは、パーティションを定義しても、後でいつでも変更できるので、データの進化に合わせてスキーマを変更することができます。ですから、短期的に最適でない決定をしても、長期的には常に正しい決定をすることができます。Icebergを使い始めたばかりの方には、早い段階で適切なパーティショニングの決定ができるよう、データをどのようにクエリするかについて本当によく考えることを強くお勧めします。
では、次はコンパクションについてです。コンパクションの目的は、小さなファイルをまとめてより大きなファイルにすることで、クエリパフォーマンスを向上させることです。コンパクション後のファイルサイズは、target file sizeという設定で制御されます。これはデフォルトのままにしておくことをお勧めします。なぜなら、私たちのテスト経験から、ほとんどのお客様のユースケースでは、これを変更してもパフォーマンスに大きな影響を与えないようだからです。また、選択できるコンパクションモードは4つあります。auto、bin pack、sort、そしてZ orderです。ほとんどのお客様には、autoのままにしておくことをお勧めします。なぜなら、その仕組みは、autoに設定されている場合、これがデフォルトなのですが、テーブルの特定のカラムにソート順が定義されていれば、sortを使用します。テーブルにソート順が定義されていない場合は、単にbin packを使用します。
ただし、検討すべき点が1つあります。それは、クエリが特定のカラムセットでフィルタリングしている場合、Z orderを使用することです。例えば、サイズ、タイプ、ロケーションなど、複数のカラムでフィルタリングしたい製品テーブルがある場合、そのような場合はZ orderを検討した方が良いかもしれません。クエリパフォーマンスが向上する可能性があるからです。しかし、大多数のお客様にとっては、autoのままにしておくことが最適です。
では、次はスナップショットの有効期限についてです。Icebergスナップショットに馴染みがない方のために説明すると、これは異なる時点でテーブルをクエリできるようにする機能です。まず、最大スナップショット数というフィールドがあります。これは基本的に、メンテナンスシステムが保持するスナップショットの最大数です。これについては、デフォルトの120のままにしておけば、大多数のお客様にとって問題ありません。2つ目の設定は、最大スナップショット経過時間(時間単位)です。これはスナップショットがどのくらい古いかということです。さて、これについては、バッチETLワークロードの場合、デフォルトの3日間のままにしておくことをお勧めします。問題なく動作するようです。ただし、ストリーミングワークロードの場合は、24時間以下に減らすことをお勧めします。その理由は、スナップショット数が多いと実際にクエリパフォーマンスが低下するからです。
そして、これについて本当に理解すべき点は、ストリーミングワークロードの場合、テーブルに頻繁にコミットを行い、コミットするたびにスナップショットを作成するということです。例えば1分に1回といった非常に高い頻度でコミットすると、スナップショットの数は数千にまで増加し、これらすべてのスナップショットがルートメタデータファイルに保存されます。そのため、このメタデータファイルが数十メガバイトから数百メガバイトにまで成長するケースを見てきました。そしてその時点で、クエリエンジンがすべての読み取りごとにルートメタデータを読み取る必要があるため、基本的にすべてのコミットと読み取りで100メガバイトを読み書きすることになり、これは非常に非効率的です。ですので、これを24時間以下に削減することが、ストリーミングワークロード、特に高頻度のストリーミングワークロードには推奨されます。
さて、このトピックの最後は、未参照ファイルの削除についてです。これは失敗したコミットをクリーンアップすることでストレージコストを節約します。これはデフォルトの3日間のままにしておくことをお勧めします。これを削減することを検討したい場合は非常に限られていて、例えば、ワークロードが頻繁に失敗する場合、つまり、コミットの失敗が多く発生してテーブルに大量のガベージが蓄積される場合などです。しかし正直なところ、そのような場合は削減を検討してもよいかもしれませんが、デフォルトの3日間のままにしておくことを本当にお勧めします。
では、私たちの推奨事項をまとめましょう。パーティショニングについては、大規模なデータセットをお持ちの場合は、ぜひ時間をかけて検討してください。なぜなら、スケールで良好なパフォーマンスを達成するには、データプルーニングが鍵となるからです。ソートについては、順序を確認してみてください。ただし、必須ではありません。
そして、これは後で変更できるものです。ストリーミングテーブルの場合は、デフォルトから削減することを強くお勧めします。それ以外の場合、バッチETLを行っている場合は、デフォルトのままにしておいてください。そして最後に、参照ファイルの削除については、デフォルトのままにしておいてください。それで十分です。
S3 Tablesレプリケーション機能：運用のシンプルさとスナップショット保護を両立
さて、私はこれまで多くのツールについて説明してきましたが、ここで、皆さんのツールボックスに新しいツールを導入することを誇りを持って発表します。それはS3 Tablesレプリケーションと呼ばれるものです。では、このツールが私たちに何を提供できるのか、詳しく見ていきましょう。最初の質問は、なぜデータをレプリケートしたいのか、ということですよね?
では、最初の理由はパフォーマンスのためです。例えば、シンガポールにデータサイエンティストのグループがいて、データがバージニアにあるとします。クロスリージョンのレイテンシーのせいでパフォーマンスが低下してしまいますので、より最適なパフォーマンスを得るために、クエリが実行される場所の近くにデータをレプリケートしたいと思うかもしれません。2つ目は、もちろんコンプライアンスです。ヘルスケアや金融サービスのような規制された業界にいる場合、これらの業界には通常、冗長性の要件があります。そして3つ目は、もちろんデータ保護です。自分自身のために、誤った削除や悪意のある上書きから保護するためのセカンダリコピーを保持したいと思うかもしれません。
では、もしこの問題を自分たちで解決しなければならないとしたら、どうすればいいでしょうか？1つの方法として、汎用S3上にIcebergテーブルがある場合、S3レプリケーションを使ってすべてのデータをレプリケートすることができます。しかし問題は、データだけでは十分ではないということです。最初の問題は、メタデータファイルを書き直す必要があるということです。Icebergのすべてのマニフェストファイルには、オブジェクトへの絶対パスが含まれています。ですから、これらのマニフェストを別のバケットにレプリケートすると、これらのパスが間違ってしまい、修正する必要があります。基本的にすべてのメタデータを解析し、すべてのファイルパスを変更して、それらを永続化し直す必要があります。かなりの作業量です。
2つ目の問題は、使用しているカタログを手動で更新する必要があるということです。例えばGlueカタログのようなものを使っている場合、レプリケート後の宛先で、すべての新しいコミットに対してこのGlueカタログを更新する必要があります。そして3つ目は、これらすべての複雑な統合とオーケストレーションロジックを維持する必要があるということです。失敗を再実行し、テーブルの状態を追跡し、そしてすべてがエンドツーエンドで耐久性があることを保証しなければなりません。
ですから、もし私たちが実際にこの問題を解決するのに十分なモチベーションがあったとしたら、このレプリケーションアーキテクチャはこのようになります。これは実際にお客様から見た例で、彼らが行っていることです。言うまでもなく、これはおそらくやりたくない大量の作業であり、S3 Tablesを使用していれば、その必要はありません。
では、S3 Tablesは何を提供し、どのように機能するのでしょうか？最初に行うのは、テーブルとネームスペースリソースの名前をミラーリングすることです。レプリケーションを設定すると、両方のテーブルバケットにまったく同じネームスペースとテーブルが作成されます。2つ目は、すべてのデータをレプリケートします。既存のデータがあるテーブルバケットで有効にした場合でも、問題ありません。そのデータをレプリカにバックフィルし、その後、ソースに新しいコミットが到着すると継続的に更新していきます。
第三に、もちろん私たちはIceberg対応ですので、すべてのデータファイル、すべてのマニフェストファイル、スキーマ、パーティションスペックを処理します。タイムトラベルと監査のために正しいスナップショット履歴を維持します。そして第四に、作成するレプリカは読み取り専用で、すぐにクエリ可能です。つまり、Athena、Spark、Trino、Flinkなど、すべてのコンピュートエンジンとすぐに使えます。ソースと同じクエリセマンティクスが得られ、タイムトラベルも機能し、スキーマエボリューションも機能し、すべてが期待通りに動作します。
そしてこれにより、まず運用のシンプルさが得られます。すべてが管理されています。コンソールから数分でレプリケーションを設定できます。Lambda関数を管理する必要もなく、EventBridgeルールをセットアップする必要もありません。カタログの更新は私たちが処理します。スキーマが進化すると、両方のカタログが更新されます。パーティションを追加すると、両方のカタログが同期を保ちます。つまり、今日S3レプリケーションで得られるのと同じ運用のシンプルさが得られるのです。そして二つ目はもちろんスケールです。最初からIcebergに特化したエクスペリエンスであるという事実です。
それでは、簡素化された運用の面にズームインしていきましょう。S3 Tablesレプリケーションを使用する場合、 すぐに使える4つの主要な機能を提供します。まず一つ目は、柔軟なレプリケーションスコープを提供することです。これは、すべてのテーブルをレプリケートするか、一部のテーブルだけをレプリケートするかを選択できるということです。これは、汎用バケットのようなものを使用している場合に、どのプレフィックスをレプリケートしたいかを選択するのと類似しています。二つ目は、組み込みの監査証跡です。すべてのレプリケーションアクションに対して、CloudTrailログが得られます。
これには、テーブルがいつ、どのリージョンにレプリケートされたかといった情報が含まれるため、コンプライアンスチームは完全な監査履歴を得ることができます。三つ目の機能は、リアルタイムモニタリングです。何が起こっているかを正確に教えてくれる特別なAPIがあります。つまり、レプリケーションは完了しているか？保留中か？失敗しているか？失敗している場合、なぜか？といった質問に答えることができます。これをモニタリングダッシュボード、アラートシステム、運用ランブックと統合できます。
最後の機能は本当にクールで、実際にスナップショットを保護する方法です。これをデモンストレーションしましょう。 テーブルレプリケーションがすでに設定されているとします。ここにテーブルAがあります。左側にプライマリがあり、右側にレプリカがあり、この時点で完全に同期しています。それぞれ4つのスナップショットがあります。さて、あなたのチームの開発者、または私たちのチームの開発者が誤ってすべてのデータを削除するスクリプトを実行したとします。 そして、空のスナップショット履歴を持つ空のメタデータをコミットします。これは最悪のシナリオのようなもので、すべてのスナップショット履歴が失われ、データを指さない空のメタデータができてしまいます。
レプリケーションが有効になっている場合、この空のテーブル状態がレプリケートされることになります。しかし、レプリカ内のすべてのスナップショットを破棄する代わりに、実際にはマージされるんです。これは本当に興味深い特性です。なぜなら、これが意味するのは、レプリケーションを設定していれば、ソースで何が起ころうとも、レプリカには常に完全なスナップショット履歴が利用可能だということです。誰かがミスをしてすべてのデータを破壊してしまっても、大丈夫です。レプリカで常に復旧できます。同じことが、例えばアカウントが侵害されてテーブルをいじられた場合にも当てはまります。大丈夫です。常に復旧できます。
このトピックを締めくくるにあたって、レプリケーションと同様に、レプリカをソースとは異なる設定にすることができます。つまり、レプリカのストレージクラス、保持期間、または暗号化を変更できるということで、これによりパフォーマンス、コンプライアンス、データ保護の要件を満たすことができます。最後にこの統計でこのトピックを締めくくりたいと思います。150ペタバイトです。これは現在、S3レプリケーションを使用して毎週レプリケートしているデータ量であり、これはまさにS3 Tablesを支えているのと同じインフラストラクチャなんです。お客様が容量をプロビジョニングしたり、コンピュートを管理したりすることなく、数万のテーブルを持つペタバイト規模のデータレイクをレプリケートできることに、私たちは非常に興奮しています。ぜひこの機能を試してみてください。リリースされた今、私たちは本当にワクワクしています。
開発者向けデモ：DuckDBとBedrockを活用した自然言語クエリアプリケーション構築
さて、今日最後にカバーするトピックは、会場にいる開発者の皆さん向けです。S3で働いていて私が好きなことの一つは、開発者が使用できるシンプルなAPIを提供しているため、開発者コミュニティとの本当に豊かな歴史があることです。本当にインターネットのストレージのようなものなんです。データをS3に書き込むだけのウェブサイトが世の中にたくさんあります。そして、私たちは本当にその体験の一部をIcebergを使ってS3 Tablesにもたらしたいと考えています。
これからS3 Tables上でIcebergアプリケーションを構築するための最新技術をいくつかハイライトしていきます。そして実際にデモを行います。ここでのストーリーは、私がS3で働いていないときは、Lambda Lattesという小さなコーヒーショップのビジネスも運営しているんです。ビジネスオーナーとしての仕事の一環として、売上を伸ばしたり、プロモーションを行ったりするために、顧客のトレンドを分析したいと考えています。このタスクを手助けしてくれる簡単なツールを自分のために構築したいと思いました。
私の要件は何でしょうか？まずDuckDBを使い始めました。会場でDuckDBを使っている方はいますか？何人かいますね。いいですね。私は大ファンなんです。知らない方のために説明すると、DuckDBは本当にシンプルな体験でテーブルをクエリできる素晴らしいCLIユーティリティです。DuckDBを使いたかったのですが、問題は基本的にSQLを書きたくなかったということです。NoSQLが欲しかったんです。自然言語を使いたかったんです。ウェブからアクセスできるものが欲しかったんです。ローカルマシンにDuckDBをインストールする必要がないものが欲しかったんです。そして、完全にサーバーレスな体験が欲しかったんです。
どのようにしてこれを実現したのでしょうか?まず、Reactを使ってWebアプリを構築しました。このReactアプリには、S3 Tablesをクエリするための自然言語インターフェースが搭載されています。Amazon Bedrockを使ってユーザープロンプトをSQLに変換し、そのSQLを取得して、DuckDB WebAssemblyクライアントを使ってブラウザから直接テーブルをクエリします。このアーキテクチャは次のようになっています。
ユーザーがいます。ユーザーは私のReactアプリにプロンプトを発行し、Webブラウザ内で実行されるReactアプリの中で、そのプロンプトを私が書いたこのエージェントコンポーネントに送信します。このエージェントコンポーネントは非常にシンプルです。AWS JavaScriptクライアントを使ってBedrockをループで呼び出すJavaScriptのコードです。プロンプトをBedrockに送信すると、SQLが返ってきます。そのSQLを取得して、DuckDB WebAssemblyクライアントを使ってS3 Tablesにリクエストを送信し、データにアクセスします。データを取得したら、それを画面にレンダリングします。
では、これを使ったデモをお見せします。まず、テーブルバケットを選択するところから始めます。ここでは、Lambda Lattesをテーブルバケットとして選択しています。これでプロンプトを発行できるようになります。では、私のテーブルは何があるか聞いてみます。これによりDuckDBにリクエストが送信されます。2つのテーブルがあることがわかります。customersとordersです。では次に、顧客を表示してくださいと言います。これでBedrockにリクエストが送信され、customerテーブルからselect starが返されます。これが私のcustomerテーブルです。ordersテーブルでも同じことをします。両方のテーブルを見たので、今度はもっと面白いクエリができます。例えば、最も多く支払っている顧客は誰かといったクエリです。Bedrockは、実際に2つの異なるテーブルがあり、それらのカラムを使ってジョインできることを理解します。それを自動的に判断してくれます。ここで、Bobが15ドル使っていることがわかります。彼が最も多く支払っている顧客です。
では、Bobは普段何を飲んでいるのでしょうか?どうやらBobは明らかにmochaに夢中のようです。なるほど、興味深いですね。では次にドリンクごとの収益はどうでしょうか?mochaのようです。これは興味深いですね。私はlatteを専門にしているのに、mochaがトップにあるというのは。そこで今度は実際にプロモーションを展開したいと思います。そこで実際にCSVをアップロードして、DuckDBにこのファイルからpromotionsテーブルを作成するよう依頼できます。DuckDBには、CSVからテーブルを作成する非常に優れた機能があり、すべての異なるカラム名を判断して、S3 Tablesにこのテーブルを作成してくれます。そして、もちろんそれをクエリできます。
次に、作成したドリンクプロモーションによる総収益損失はいくらかと尋ねます。これはおそらく、このアプリでBedrockが処理する最も複雑なクエリの1つです。Bedrockは、ああ、なるほど、promotionsテーブルがあるんですね、それを計算できますよ、と判断し、答えは19ドルのようです。しかし、実際には19ドルはかなりの金額です。それを負担できるかわかりません。そこで今度はプロモーションを更新したいと思います。すべてのアイテムの割引を10セントに設定したいと思います。mochaは削除したいと思います。すでに人気があるので、プロモーションする必要はありません。そして、latteをプロモーションとして挿入したいと思います。本当にlatteの売上を伸ばしたいので。そして、プロモーションの影響を再計算するよう依頼します。
さて、これはかなり複雑なリクエストですね。これから処理が実行されて、この命令を実行するために複数のステートメントが必要だということを実際に判断していきます。これで4つの処理ができました。update文、delete文、insert文、そしてselectと続きます。そして損失を1ドル30セントまで削減できました。これが私がやりたかったことです。はい、デモは以上です。
次は何でしょうか？もしこのようなものを構築することに興味があるなら、シンプルで、ブラウザ上で動くようなものを作りたいなら、試してみるべきことがいくつかあります。まずこのURLにあるDuckDB WebAssemblyシェルです。これは実際に試してみて、どのように動作するかを理解するのに本当に良い方法です。次に、Claudeやあなたがお好みのコーディングアシスタントにDuckDB WebAssemblyアプリケーションを生成するよう依頼してみてください。私はいくつか試してみましたが、どれもかなりうまく動作するようです。基本的に本当に簡単に始められます。ほとんどのLLMはDuckDBを理解していますし、WebAssemblyの使い方も理解しているので、ぜひ試してみてください。そしてそれが動作したら、attachコマンドを使ってS3 Tablesに接続するだけです。もし迷ったら、いつでもDuckDBのドキュメントを参照して詳細を確認できます。
個人的には、これは開発者がアプリケーションを構築し、Web上で新しい体験を可能にする、超エキサイティングな新しい方法だと思います。そして、これが基本的に今日お伝えすることのすべてです。いくつかポイントをまとめます。S3 Tablesを使えば、フルマネージドなIcebergストレージが得られます。そして最近のローンチにより、Indeedのようなより多くのお客様が、データレイク投資に対して最高のパフォーマンスとコストを得ることができます。特定のニーズに基づいてデータレイク操作を調整するための複数のレバーがあります。そしてDuckDBやPyIceberg、さらにはSageMaker Unified StudioのようなAWSサービスなど、多数のIceberg互換ツールを試すことができます。
いくつか追加のリソースがあります。チュートリアルがあり、ワークショップがあり、そしてチェックしていただけるSageMaker Unified Studioのリンクもいくつかあります。ありがとうございました。今後もこのようなセッションを開催できるよう、ぜひモバイルアプリでセッションアンケートにご回答ください。改めて、ご参加ありがとうございました。そしてre:Inventに参加される方は楽しんでください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion