re:Invent 2024: AmazonS3チームが30の新機能を発表 - S3 Tables、S3 Metadataなど
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - What’s new with Amazon S3 (STG212)
この動画では、Amazon S3チームが過去12ヶ月間に開発した30の新機能について解説しています。構造化データ向けの完全マネージド型Apache Icebergテーブルを提供するS3 Tablesや、非構造化データの管理を容易にするS3 Metadataなどの主要な新機能を紹介しています。また、S3バケットの制限を100万個に引き上げ、条件付きAPIやチェックサムの導入によるセキュリティ強化、S3 Express One Zoneの地域展開拡大、AWS Dedicated Local Zonesでのストレージクラス対応など、基本機能の大幅な拡張についても説明しています。さらに、Mountpoint for Amazon S3やS3 Connector for PyTorch、Storage Browser for Amazon S3といったクライアントサイドの革新的な機能も紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon S3の進化：過去12ヶ月間の30の新機能
私はPaul Meighanで、同僚のMallory Gershenfeldと一緒に来ました。私たちはAmazon S3 のチームで働いており、本日は昨年のre:Inventから過去12ヶ月の間にS3チームが開発してきたすべてについてご紹介させていただきます。 私たちは非常に忙しく活動してきており、今日は多くのコンテンツをご紹介する予定です。これから60分間で30のローンチについてお話しします。
このトークは4つのカテゴリーで構成されています。 まず、今朝のMattのキーノートで紹介された構造化データと非構造化データについての2つの大きなローンチについてお話しします。次に、基本的な部分について説明します。スケール、セキュリティ、パフォーマンス、耐久性など、S3について皆様に意識していただく必要のない部分についてです。最後に、クライアントポートフォリオの最新情報で締めくくります。このセッションは非常に広範な内容を扱うため、200レベルに設定しています。今日は個々のローンチについて深く掘り下げる時間はありませんが、Malloryと私はセッション後、皆様の質問にお答えするために必要な時間だけ残ります。これらの新機能を実際に活用していただけるよう、必要な詳細情報をお伝えしたいと考えています。
S3における構造化データの革新：Amazon S3 Tablesの導入
それでは、構造化データから始めましょう。 S3の初期を振り返ると、最初のワークロードは画像やビデオ、ログ、バックアップなどの非構造化データセットが中心でした。これらは今でも私たちにとって非常に重要なワークロードであり、S3には膨大な非構造化データが保存されています。今日でも、お客様との会話で非構造化データについて頻繁に話題に上がります。しかし、ここ数年で、皆様は私たちを全く異なる方向にも導いてくださいました。
現在、Amazon S3は表形式のデータストアとしても活用されています。Apache Parquetという単一のデータ型だけを見ても、S3にはExabyte規模のParquetストレージがあります。実質的に、行と列を保存するための事実上の標準となっています。S3では、そのParquetデータに対して1秒あたり1,500万以上のリクエストを処理しており、 これは毎日数百Petabyteのデータがコンピュートとの間でやり取りされていることを意味します。これは膨大なデータ量であり、主にアナリティクスアプリケーションを支える表形式データセットとして、皆様がS3をどれだけ活用されているかを示しています。
ここ数年、皆様はS3上のこれらのParquetデータを基盤として革新を重ね、オープンテーブルフォーマットという概念を確立されました。現在最も普及しているオープンテーブルフォーマットはApache Iceberg と呼ばれています。Icebergにあまり詳しくない方のために簡単に説明すると、これはS3内のメタデータファイルでテーブルを定義します。つまり、テーブルの概念と、Parquetで保存される基礎となるデータファイルの両方が、S3バケット内に完全に存在することになります。そして、Amazon AthenaのようなクエリエンジンがIceberg標準を理解し、Icebergのメタデータを使用して、シンプルなSQLクエリを S3 APIコールに変換し、クエリの回答に必要な複数のParquetファイル内の必要なデータ範囲を取得することができます。
このアーキテクチャの素晴らしい点は、テーブルの定義と基盤となるデータファイルがすべてS3内に存在するという、関心の分離が実現されていることです。これにより、様々なクエリエンジンでテーブルにアクセスすることができます。 AthenaやEMR、QuickSight、オープンソースのSparkなど、同じテーブルに対して様々なエンジンでクエリを実行できるのです。このように、クエリエンジンとテーブルに関連する基盤データやメタデータを分離するというパターンは、多くのお客様にとって非常に効果的なアーキテクチャとなっており、一般的にLake Houseアーキテクチャと呼ばれています。
このアーキテクチャは、ここ数年で何千回も導入されてきました。私たちがお客様のLake Houseをペタバイト規模以上に拡張するお手伝いをする中で、Apache Icebergを使用したデータレイクの運用において、いくつかの共通の課題が見えてきました。 1つ目の課題は、規模が大きくなるほどパフォーマンスの向上が必要になるということです。これは特に、S3上のApache Icebergテーブルを環境内の複数のクエリエンジンで共有したい場合に顕著です。2つ目の課題は、テーブルがメタデータで定義されているため、 セキュリティの設定が、バケットポリシーや特定のプレフィックスを保護するポリシーを割り当てるほど単純ではないということです。そして3つ目の課題は、 これらのテーブルの下にある保存コストを最適化するには、より多くの作業が必要だということです。どのデータを削除できるかを本当によく理解する必要があり、一般的なライフサイクルポリシーでは対応できません。
S3 Tablesがもたらす3つの主要な改善点
このため、今朝のMattのキーノートで発表できることを大変嬉しく思います。 Amazon S3 Tablesの発表です。これは、Amazon S3内で完全マネージド型のApache Icebergテーブルを提供するものです。S3 Tablesは、 Table Bucketと呼ばれる新しいタイプのバケットを通じて提供されます。Table Bucketが異なる点は、テーブルを作成および管理するために呼び出すことができる、 テーブル固有のAPIを持っているということです。
テーブルの作成、一覧表示、更新、削除といった基本的なCRUD操作が可能です。また、基盤となるApacheメタデータを管理するための コントロールプレーンAPIもあります。Icebergメタデータのトップレベルを見つけることができ、そのメタデータに対してトランザクションを安全かつ一貫性のある方法で簡単にコミットできます。Table Bucket内でCreate Table APIを使用してIcebergテーブルを作成すると、そのテーブルはAWSのファーストクラスリソースとなります。ARNとエンドポイントを持ち、ポリシーを設定することができます。
これは、お客様にとっても私たちにとっても、アーキテクチャ的に非常に重要な意味を持ちます。Amazon AthenaやAmazon EMRなどのクエリエンジンを導入する際、 これらのテーブルにクエリエンジンを向けます。抽象化のレベルをテーブルレベルまで引き上げたことで、 IcebergとParquetに特化した方法で、テーブルの背後にあるストレージとデータパスを自動的に最適化できるようになりました。Table Bucket内のすべてのデータがParquetとIcebergであることを把握しているため、ショートカットを取ってテーブルをより良いものにすることができます。
実現方法には主に3つあります。1つ目はパフォーマンスに関するもので、 S3のネームスペース全体にデータを効率的に配置し、S3のインデックスを最適化することで、より高いTPSを実現できます。2つ目は、セキュリティの簡素化です。各テーブルがリソースとして扱われるため、Icebergテーブルのセキュリティ制御を、バケット、プレフィックス、アクセスポイントと同じように管理できます。そして、バックグラウンドで自動的にコスト最適化を行います。これらについて、もう少し詳しく説明していきましょう。
S3 Tablesによるパフォーマンス向上の仕組み
まずパフォーマンスについてですが、S3 Tablesは最大10倍のTPS向上と、最大3倍のクエリパフォーマンス向上を実現します。これらは大きな数字ですが、このようなセッションで数字を示す際には、エンジニアの皆さんにその理由を説明するようにしています。私たちは長年re:Inventに参加してきましたが、キー命名に基づいてS3のパフォーマンスを向上させる方法について、多くの講演を行ってきました。キー命名は、データをインデックス全体に分散させる方法を決定する重要な要素であり、S3からより多くのTPSを引き出すための重要な要素です。
テーブルエンドポイントを通過するデータのキー名を自動的に最適化できるため、基盤となるParquetファイルに、S3のネームスペース全体に非常に均一で最適化された方法で分散されるような名前を付けることができます。さらに、S3内の基盤となるメタデータサブシステムであるインデックスを、IcebergとParquetのワークロード向けに特別にチューニングしています。テーブルバケット内のすべてのデータがParquetとIcebergであることが分かっているため、S3の基盤となるインデックスに関するこれら2つの最適化により、汎用バケットと比較してより高いTPSの開始点を実現できます。先週投稿したブログ記事へのリンクを掲載しましたが、これはAmazon Adsとのケーススタディで、S3のTPSとIcebergの関係について詳しく説明しています。このローンチに向けてIcebergに対して行ったオープンソースへの貢献についても触れており、IcebergとS3 TPSの関係をより深く理解したい場合は、そのブログ記事に詳細が記載されています。
S3 Tablesが最大3倍のパフォーマンス向上を実現できると述べましたが、これはバックグラウンドでの自動データコンパクション処理によるものです。Icebergテーブルは複数のParquetファイルによってバックアップされています。多数の小さなファイルによってバックアップされている場合、SQLクエリを実行するために必要なデータを取得するには、S3に対して多くのリクエストを行う必要があります。
これは多くのリクエストが発生することを意味し、テールレイテンシーが問題となり、クエリが遅くなってしまいます。S3 Tablesでは、定期的かつ継続的に基盤となるデータファイルを自動的にコンパクションし、多数の小さなファイルを少数の大きなファイルに常にまとめています。これはユーザーが気にする必要がなく、デフォルトで実行されます。
これにより、ストレージへのリクエスト数を減らしてクエリを実行できるようになります。その結果、テールレイテンシーが削減され、クエリの全体的なパフォーマンスと完了時間に大きな影響を与えます。基盤となるストレージからの各取得は、より少ない大きなファイルから取得されるため大容量となり、返されるペイロードを並列化してスループットを向上させることができます。このようにして3倍という数字を達成しています。画面下部のリンクは、明日投稿予定のベンチマーク結果についてのブログを指しています。今見ると404エラーが表示されますが、明日にはこの3倍という数字を得るために使用したTPC-DSベンチマークのテスト環境について説明するブログが公開される予定です。この数字の背景にある計算について確認したい方は、ぜひご覧ください。また、Compactionの仕組みと、なぜParquetをCompactしてクエリを高速化するのかについても良い概要が示されています。
S3 Tablesのセキュリティとコスト最適化
これがパフォーマンスに関する説明です。最大10倍、そして最大3倍のクエリパフォーマンス向上というマーケティングの背景にある計算についてお話ししました。ここで説明している数字は、このローンチに関連するものです。 セキュリティの面では、テーブルがリソースであるため、通常のIAMリソースポリシーをこれらのテーブルに適用することができます。これは、多くのエンドユーザーが異なるクエリエンジンを使用して、共有テーブルセットへのアクセス、読み取り、書き込みの権限を有効にしたい場合に非常に便利です。お客様からは、データレイクやLake House環境において、コースレベルのテーブルセキュリティコントロールを確立したいというご要望を何度もいただいていました。
個々のテーブルに明示的に権限を割り当てることができるようになったため、それが可能になりました。 さらに、一般的なバケットと同様に、バケットポリシーを作成して、すべてのテーブル、または特定のテーブル、あるいはバケット内のテーブルのサブセットに対する権限を設定することができます。これにより、従来はメタデータとして保存されていたApache Icebergテーブルに対して、他のAWSリソースと同じセキュリティパラダイムを使用できるようになります。 これが、テーブルをAWSの第一級リソースとすることで、S3テーブルのセキュリティをシンプルにする方法です。
ストレージコストの最適化については、Apache Icebergテーブルを支える少数の大きなParquetファイルにデータをCompactする話をしました。これは長期的なパフォーマンスの観点で素晴らしい方法です。これらのテーブルは成長し、より多くのスナップショットが保存され、削除された行などに関連するガベージも発生します。 そしてテーブルは時間とともに成長していきます。テーブルの下からデータを削除するには、何を削除すべきかを知るために、基盤となるParquetがApache Icebergのメタデータにどのようにマッピングされているかを理解する必要があります。
お客様のサポートのため、 テーブルバケット内で毎晩メンテナンスを実行し、スナップショットの有効期限切れとガベージコレクションを行っています。これらのプロセスは、お客様が物理的に管理する必要なく、自動的にバックグラウンドで実行されます。S3ライフサイクルポリシーと非常によく似た仕組みです。 これは、コマンドラインでこれらのメンテナンスポリシーを設定する例です。通常のS3オブジェクトのライフサイクルと同様に、保持するスナップショットの数と、スナップショットを保持する期間を定義しているのがわかります。
これが Table Buckets です。Amazon S3 にとって大きな一歩となります。本日から一般提供を開始できることを大変嬉しく思います。すぐに高いパフォーマンスを発揮し、テーブルが Amazon S3 内のファーストクラスリソースとして扱われるため、セキュリティの確保も容易です。
これらのテーブルは、お客様が設定したポリシーに基づいて、自動的にストレージコストの最適化を行います。これが構造化データに関する私たちの取り組みです。
非構造化データ管理の革新：Amazon S3 Metadataの導入
非構造化データに関して言えば、Amazon S3 には現在400兆以上のオブジェクトが保存されています。私たちの生活で画像や動画がますます一般的になってきたことから、その大部分は非構造化データファイルです。お客様がデジタルトランスフォーメーションを進め、これまで紙媒体だった文書をオンライン化していくにつれて、管理が困難な巨大な非構造化データストアが生まれています。多くのお客様は個々のファイルを追跡するためのメタデータシステムを構築していますが、これはそれ自体が新たな問題を引き起こしています。
大規模な非構造化データストアについてお客様と話をすると、必要なオブジェクトを見つけて作業を実行することが、ますます困難になっているという声を聞きます。 多くのお客様は非構造化データストアと並行してメタデータストアを構築していますが、これらの構築は難しく、ストレージ以外への依存関係が生まれ、レジリエンスとセキュリティの両方を複雑にしています。また、メタデータは最新の状態でなければ価値がないことも分かっています。非構造化データストアのメタデータを保持・追跡する業務に携わっているなら、そのシステムを稼働させ、メタデータを最新に保つために、絶え間ない運用の負担がかかっているはずです。
このような問題を解決するために、本日、Amazon S3 Metadata という新機能のプレビューを発表しました。S3 Metadata は、シンプルな SQL セマンティクスを使って数分でアクセス可能な自動メタデータ生成を実現します。その仕組みをご説明しましょう： クライアントが汎用バケット内のデータセットを更新すると、データセット内のオブジェクトの変更が発生するたびに、システムで管理される Apache Iceberg テーブル（Table Bucket 内）に行が追加されます。Put、Delete、メタデータの更新のたびに、Iceberg テーブルに行が追加されます。これはデータセットに対するすべての変更を記録するものなので、私たちはこれを Journal テーブルと呼んでいます。
Journalテーブルは、AWS以外のプリンシパルに対して読み取り専用のAWS管理テーブルです。このテーブルは、バケットに追加された各オブジェクトに対して、オブジェクトサイズ、ストレージクラス、クライアント情報、暗号化情報など、21個のメタデータフィールドを自動的に提供します。これらのフィールドは、シンプルなSQL構文を使用して簡単にクエリを実行できます。オブジェクト作成後数分以内にSQLコマンドでS3メタデータにアクセスできるこの機能は非常に強力な基本機能であり、お客様がこれを活用して革新的なユースケースを生み出していくことを期待しています。
今朝の発表に先立って、お客様と最も頻繁に議論してきた3つのユースケースについてご説明させていただきます。1つ目は、データセットに対するトレーニングの実施や、エンドユーザー向けのチャージバックレポートの作成など、処理対象のオブジェクトを見つけ出す用途です。アプリケーションのビジネスロジックの中で、処理すべき特定のオブジェクトセットを見つける必要がある場合が多々あります。シンプルなSQLコマンドでフィルタリングして適切なオブジェクトを見つけられる機能は非常に強力で、現在お客様が行っているインベントリレポートのETLパイプライン処理などの追加処理の必要性を軽減し、多くのアプリケーションをシンプルにすることができます。
2つ目のユースケースは、お客様がデータリネージを理解し追跡するのを支援することです。データリネージは複雑なテーマであり、これがオールインワンのデータリネージ機能だと主張しているわけではありません。
しかし、時系列でメタデータに対してクエリを実行できる機能は、データリネージソリューションにとって非常に興味深い構成要素になると考えています。S3メタデータを使用することで、過去のある時点のスナップショットと現在のスナップショットを特定し、その2つのスナップショット間で発生した変更を分析して、現在のデータセットがなぜそのような状態になっているのかをより深く理解することができます。ログ処理やその他の重い処理技術の代わりにSQLステートメントを使用して、時間の経過とともにデータがどのように進化してきたかをより効果的に理解できるこれらの機能は、データリネージの支援に非常に役立つでしょう。
お客様と最も頻繁に話し合っている最後のユースケースは、ストレージの使用状況をより深く理解できるようにすることです。S3 Storage Lensのような専用のプロダクトもあり、これはチャートやグラフを表示してS3全体の傾向や影響を理解するのに優れた役割を果たしています。しかし、ストレージの使用方法に関する非常に具体的な質問に答えるために、SQLプロンプトを立ち上げて特定のクエリを書くことができる機能の代わりになるものはありません。お客様はこの機能を使ってそのような分析を行うことができるようになると考えています。
このような話をお客様とすると、最初によく聞かれる反応の1つは、S3のメタデータをSQLで照会できるのは非常に便利だが、自社独自のメタデータがあり、それを使って私たちのシステムメタデータをビジネスに関連する情報で拡張したいというものです。システムが自動的に提供するメタデータを独自のカスタムメタデータで拡張する方法は3つあります。 S3のオブジェクトタグを使用してオブジェクトにカスタムフィールドでメタデータを付与することができ、これらのオブジェクトタグはS3メタデータジャーナルテーブルに反映されます。 PUTリクエストでユーザー定義メタデータを追加することもできます。これはヘッダー入力で、変更可能なメタデータをオブジェクトに追加し、ジャーナルテーブルから照会可能になります。 あるいは、Table Bucket内に独自のカスタムテーブルを作成し、私たちが生成・管理するシステムテーブルと結合することもできます。
実は、ユーザー定義カスタムメタデータの最大のユーザーは私たち自身なんです。今朝、Amazon Bedrockを通じた新しいビデオ生成機能も発表しました。Amazon Bedrockは、生成したビデオをS3バケットに保存する際に自動的にアノテーションを付けます。ここに示している例では、AI生成ビデオに付与されるメタデータに変換されるヘッダーを確認できます。そして下部では、バケット内のAI生成ビデオをすべて特定するためにジャーナルテーブルに対してどのようなクエリを実行できるかの例を示しています。これは、アプリケーションがこの機能と連携して、S3バケット内でデータがどのように、誰によって作成されているかについての興味深い洞察を提供する一例です。
S3の基本機能強化：スケール、セキュリティ、耐久性の向上
これが、今朝のMattのキーノートで発表された2つの大きな新機能の概要です。構造化データ向けのS3 Tables（S3での完全マネージド型Apache Icebergテーブル）と、ジャーナルテーブルを作成し、シンプルなSQLコマンドでS3メタデータを照会できる新しいS3メタデータ機能（プレビュー中）です。次に、スケールから始まる基本的な部分についてご説明します。 長年にわたり、お客様は多くのS3バケットを作成してきました。特に、マルチテナント構成を実現したいアプリケーションなど、実際に多くのS3バケットを必要とするユースケースがあります。多くのISVのお客様は、自社のS3ユーザーにサービスを提供する際に、従来から長年1アカウントあたり1000バケットだったS3バケット制限に直面しています。バケット数の制限に達した場合、
これを回避するための方法がいくつかあります。 個々のプレフィックスに対してポリシーやストレージ管理ポリシーを作成することで、1つのバケットに複数のアプリケーションを含めることができます。それでも足りない場合は、複数のAWSアカウントにバケットを分散させることができます。これらのテクニックは確かに正しく、私たちも完全にサポートしていますが、 バケット制限のためにアプリケーションにこれほどの複雑さを追加しなければならないのは適切ではないと考えています。
私たちの制限を気にする必要がないようにしたいからです。 これは単にお客様にとってもう1つの運用上の懸念事項であり、私たちはこれを解消したいと考えています。さらに、バケット内の個々のプレフィックスに対してポリシーを作成することは、 ポリシーの作成とクロスアカウント権限の管理に複雑さを加えます。マルチアカウント構成は完全に支持していますが、確かに複雑さを増すものであり、私たちのバケット制限を回避する目的でのマルチアカウント構成は望ましくないと考えています。
数週間前、私たちはS3バケットの制限値を引き上げました。 現在、1つのAWSアカウントで最大100万個のバケットを作成できるようになりました。これは非常に大きな数字で、この発表をした際には「誰が100万個ものバケットを必要とするのか」という皮肉な反応をたくさんいただきました。もっともな指摘ですが、私たちがこの数字を設定した目的は、お客様が制限について考える必要がないよう、制限自体を実質的に取り除くことでした。
制限値の引き上げに加えて、何千、何万、あるいは100万個ものバケットを管理する可能性のある世界に対応するため、ポートフォリオの様々な部分に変更を加えました。 汎用バケットのService Quotasサポートを追加しました。これにより、サポートに連絡する代わりに、AWS Management ConsoleのService Quotasで現在使用しているバケット数を確認できるようになりました。現在すべてのAWSアカウントに設定されているデフォルトの制限値である10,000を超える場合は、Service Quotasを通じて100万までの引き上げをリクエストできます。また、 S3のList Buckets APIにページネーションとフィルタリングを追加し、何万ものバケットがある場合でも、絞り込んで短いリストを取得できるようにしました。
これがスケールに関して行った変更です。お客様の障壁となっていた制限を取り除けたことを大変嬉しく思っており、他にも皆様の妨げとなっている制限がないか探しています。S3は制限を感じさせないものであるべきだと考えており、それを実現することが常に私たちの目標です。 次に耐久性についてですが、S3の11ナインの耐久性設計を実現するために、実際には4つのシステムが働いています。 昨年のre:InventでのS3ディープダイブセッションでは、これらの4つのシステムについて詳しく説明しており、そのリンクがこちらにあります。
11ナインの耐久性を支える数学的手法やテクニックに興味がある方は、昨年のビデオをご覧ください。4つのシステムとは、システム内でデータが移動する際にビットが変更されないようにするエンドツーエンドの整合性チェック、複数のストレージデバイスにわたるデータの冗長保存、時間の経過とともにデータが正しい状態を保っているかを確認する定期的な監査、そして1つのリージョン内の複数のアベイラビリティーゾーンにわたるデータの分散です。
日曜日に行った更新は、最初の要素であるエンドツーエンドの整合性チェックに関するものでした。 現在の整合性チェックの仕組みについて簡単に説明しますと、クライアントからオブジェクトを受け取ると、S3 APIでそのオブジェクトのチェックサムを取得し、 永続的に保存された後にも同じくチェックサムを取得します。これらのチェックサムを比較して一致することを確認し、その後でようやく アプリケーションに200の成功レスポンスを返します。
これは、Checksum Bracketingと呼ばれるテクニックです。これはデータの永続性を確保するためのベストプラクティスであり、S3内でデータを移動する際に常に使用する非常に重要なテクニックです。マイクロサービス間でデータが受け渡される際にビットが反転しないようにすることで、大きな永続性の向上が図れます。このBracketingにより、S3 APIで受け取ったビットが確実に保存されたことを確認できます。
ただし、これではクライアントからS3へのデータ転送中にビットが反転していないことを確認することはできません。特に、データがパブリックインターネットを経由する場合、お客様や私たちが所有していない複数のネットワークデバイスを経由することになるため、この問題は顕著です。
この問題に対処するため、新しいデータ整合性のデフォルト設定を導入し、ネットワーク経由のデータ検証を改善し、オブジェクトのメタデータに新しいチェックサム情報を追加しました。最新バージョンのSDKでは、クライアント側でチェックサムを取得し、それをS3 APIで取得したチェックサムと照合し、さらにデータが永続的に保存された後に取得したチェックサムと照合します。これにより、お客様のアプリケーションからストレージまで、ネットワーク経由でのエンドツーエンドの整合性チェックが可能になり、データ転送のこの部分を保護することができます。
これは、データがS3 APIに到達する前の段階についてです。さらに、オブジェクト全体のCRCチェックサムをオブジェクトのメタデータに保存します。これはS3のデフォルトの動作を変更するものであるため、今後数週間かけて展開される予定です。新しいPutリクエストのすべてにおいて、S3メタデータ内でCRCチェックが確認できるようになり、Headリクエストで確認することができます。これにより、お客様は私たちの作業を検証することができます。EC2インスタンス内のクライアント側やお客様のラップトップからこのCRCを実行し、私たちが保存したと主張するものと比較することができます。これはマルチパートアップロードの場合でも同様で、いつでも検証可能な全オブジェクトのチェックサムを提供します。
これにより、クライアントからストレージまでのネットワーク経由での永続性を証明することができます。この永続性の保証は、分散アプリケーションについて考える場合にはより複雑になります。分散アプリケーションでは、複数のクライアントが同じS3のキーに書き込む可能性があります。例えば、画面上のクライアント1がマルチパートアップロードを開始し、時間をかけてS3のキースペース内の特定のキーにパートをアップロードしている最中に、クライアント2が同じキー名に対して単純なPut Objectを実行した場合、クライアント2は200の成功レスポンスを受け取ります。クライアント1がアップロードを完了した時点でも、同様に200の成功レスポンスを受け取ります。これは悪夢のようなバグの元となります。すべてのクライアントが200の成功レスポンスを受け取っているにもかかわらず、クライアント2がアップロードしたペイロードは実質的にS3に保存されていないか、200の成功レスポンスを受け取ったにもかかわらず上書きされてしまうのです。
分散アプリケーションのユースケースに対応するため、年の夏と先週の2回のローンチで、Amazon S3に条件付きリクエストを導入しました。分散アプリケーションのデータ耐久性を簡素化するために、put-if-absentとput-if-matchの条件を使用できるようになりました。先ほどの図に戻りますと、クライアント1が処理を行っている際にクライアント2が成功応答を受け取った場合、if-no-match条件付きでマルチパートアップロードを完了すると、クライアント1はprecondition failedエラーで失敗します。これにより、S3に書き込もうとする2つのクライアント間で競合が発生していることが分かり、問題のトラブルシューティングと修正の方向性を示すことができます。
現在、4つの新しい条件付きリクエストのプリミティブが利用可能です。if-none-matchによるputでは、指定した名前のキーが存在しない場合にのみオブジェクトを正常にputできます。また、オブジェクトを意図的に上書きする際にcompare-and-swap操作を行いたい場合は、if-match条件を指定できます。deleteにもif-match条件を用意しています。これらは現在directory bucketsで利用可能で、まもなくすべての機能で利用できるようになります。if-match条件付きdeleteを使用することで、確実に正しいものを削除できます。さらに、IAM condition keysも用意しており、条件付き書き込みのみを許可するようなバケットポリシーを作成することもできます。以上が条件付き書き込みについての2つのアップデートです。
Malloryにバトンタッチする前に、最後にセキュリティに関するいくつかのアップデートについてお話しします。まずは、すべてのAWS開発者が苦労している403 Access Deniedエラーのトラブルシューティングについてです。従来、Amazon S3ではこれが困難でした。その理由は、403エラーの原因となるポリシーを適用できる場所が多すぎるからです。バケットに対するポリシー、アクセスポイントに対するポリシー、VPCエンドポイントに対するポリシー、Block Public Accessの設定、組織レベルでのSCPなど、リクエストを許可するかどうかを判断する際に評価されるポリシーフラグメントが数多く存在します。
予期せぬ403レスポンスを受け取ってトラブルシューティングを行う必要がある場合、それは困難な作業となり得ます。そのため、403エラーに追加のコンテキストを加えることにしました。8月に、AWS アカウント内で行われたリクエストに対して、開発者が403エラーの原因を特定しやすいように、より詳細な情報を提供するようになりました。この追加コンテキストには、ポリシーのタイプ、拒否の理由、403を受け取ったプリンシパルに関する情報が含まれます。画面には例をいくつか表示しています。バケットポリシーやリソースポリシーによる明示的な拒否の例、Block Public Accessによる403の例、そして組織レベルのSCPによってリクエストが拒否された場合にもその旨を通知します。このリンクはS3のドキュメントへのリンクで、このローンチで追加された追加コンテキストの例を含む403エラーのトラブルシューティングに関する大幅な更新が含まれています。
Amazon S3 Access Grantsは昨年のre:Inventでローンチされました。これにより、S3へのアクセス許可をOktaなどの環境内のIdentity Providerと連携させることができます。エンドユーザーがビジネスに参加・離脱する際のS3データセットへの権限の付与と取り消しが非常に簡単になります。昨年以来、Access Grantsの対応サービスを拡大してきました。Amazon SageMaker、Amazon Redshift、AWS Glue ETL、boto3、そしてV1 Java SDKのサポートを追加しました。Access Grantsのサポート範囲を拡大することに注力してきており、お客様がこれを採用してセキュリティを大規模に簡素化し始めていることを大変嬉しく思っています。
現在Access Grantsを利用している最大の顧客は、このre:Inventで発表する別のローンチに関連しています。それについては後ほどMalloryがAWS Transfer Familyのローンチに関連してAccess Grantsを活用する方法について説明します。AWS Transfer Familyの新機能を開発する中で、Access Grantsに新しいAPIが必要だということが分かりました。それがListCallerAccessGrants APIです。このAPIを使用すると、コードでエンドユーザーがS3内のどのデータセットにアクセスできるかを判断できます。アプリケーションで顧客が利用可能なデータセットを表示したり、閲覧・選択できるようにしたい場合、この新しいAPIは最適な選択肢となります。
S3のパフォーマンス向上：S3 Express One Zoneと地理的拡大
以上がセキュリティ面についての説明でした。ここからは私の同僚のMalloryに引き継ぎたいと思います。パフォーマンスに関して言えば、これまで以上に計算負荷の高いワークロードが増えていることを私たちは認識しています。アプリケーションはより高いトランザクション処理能力を必要とし、テールレイテンシーの影響を受けやすく、ピーク時の計算コストを押し上げています。Amazon S3は1秒あたり1億5000万リクエストを処理できるスケーラビリティを持っています。本日は、リクエストパス全体の最適化、サーバーサイドとクライアントサイドの新機能の追加、新しい連携機能の追加、そしてより多くの地域でのサービス展開を通じて、お客様が必要とするパフォーマンスを実現する方法についてお話しします。
昨年のre:Inventで、最も頻繁にアクセスされるデータセットに対して、一貫した一桁ミリ秒の初回バイトレイテンシーを提供するために特別に設計された新しいストレージクラス、Amazon S3 Express One Zoneを発表しました。S3 Expressは、データアクセスの読み取り速度を10倍に高速化し、Standardと比較してリクエストコストを50%削減できます。このようなパフォーマンスを実現できたのは、S3に2つの新しい設計コンセプトを導入したからです。
簡単に説明させていただきます。1つ目は、Directory Bucketと呼ばれる新しいバケットタイプの導入です。これにより初めて、バケットを作成する際に単一のAWS Availability Zoneを指定して、オブジェクトをコンピューティングワークロードと同じ場所に配置し、ネットワークレイテンシーを削減することができるようになりました。このタイプのバケットには、リクエストスケーリングモデルが最初から組み込まれています。2つ目は、リクエストごとの認証ではなく、セッショントークンに基づく新しい認証メカニズムを導入したことです。認証に起因するレイテンシーを削減するため、Create SessionのAPIがSDKとCLIに自動的に組み込まれています。
これらを組み合わせることで、S3 Expressはレイテンシーに敏感なアプリケーションが1分間に数百万のトランザクションに簡単にスケールできるようになり、しかも高可用性と高耐久性を維持できます。機械学習のトレーニング、インタラクティブな分析、メディアコンテンツの作成などのユースケースに最適です。お客様がS3に保存されたデータの価値を引き出すために、多くの他のAWSサービスに依存していることを私たちは理解しています。そこで、お客様のニーズに基づいて、機械学習のユースケースに向けてS3 Expressとの連携機能を追加しました。Amazon SageMakerのFast File Modeを使用したトレーニングジョブのサポートを追加し、S3 Standardと比較して最大5.8倍のパフォーマンス向上を実現しています。
また、PyTorch向けのS3 Connectorのサポートを追加し、分析ユースケースについては、Amazon EMRのサポートを拡張して、コンテナベースのワークロード向けのAmazon EMR on EKSやAmazon EMR Serverlessなど、他のデプロイメントモデルも含めるようにしました。 サーバーサイド暗号化については、カスタマーマネージドキーを使用したAWS Key Management Serviceのサポートを追加し、 ガバナンスとコンプライアンスのユースケースについては、CloudTrailのサポートを拡張してすべてのデータプレーン操作を含めるようにしました。また、ストレージコストの最適化を支援するため、オブジェクトを経過時間に基づいて自動的に期限切れにするS3ライフサイクル期限切れAPIのサポートも追加しました。
継続的なデータワークロードに関する性能ニーズも重要な分野です。ロギング、インタラクティブ分析、メディアブロードキャストなどのアプリケーションでは、新しいデータが常に入ってきており、既存のオブジェクトにデータを追加したいというニーズがあります。 例えば、ロギングアプリケーションで100キロバイトのファイルがあり、そこに2キロバイトのデータを追加したい場合を考えてみましょう。 現在のS3オブジェクトは不変であるため、一度にこれを行うことはできません。この分野でのパフォーマンスを向上させるため、 Amazon S3 Expressで既存のオブジェクトにデータを追加するサポートを追加しました。これにより、以前はローカルストレージでデータを結合してから最終的なオブジェクトをS3にコピーし直す必要があったアプリケーションが簡素化されます。
先ほどの100キロバイトのファイルの例に戻りましょう。 今度はS3 APIと新しいヘッダーを使用して、既存のオブジェクトに追加する部分を指定します。200レスポンスを受け取ると、すぐに新しいオブジェクト全体を読み戻すことができます。 素晴らしいのは、追加するオブジェクトの最小サイズに制限がないことです。また、既存のS3 PUT APIのヘッダーを使用するため、新しい権限も必要ありません - 書き込み権限があれば十分です。さらに、この処理は1つのオブジェクトに対して最大10,000回まで繰り返すことができます。
S3 Expressは昨年ローンチ時に4つのリージョンでサービスを開始しました。 最近、IrelandとOhio、Mumbaiを含む3つの新しいリージョンのサポートを追加しました。地理的なユースケースといえば、 特にパブリックセクターや高度に規制された産業の一部のお客様には、データ主権に関する要件があることを認識しています。これらのお客様は、物理的に隔離されたインフラストラクチャにアプリケーションを保存し、特定の主権国の場所（多くの場合、AWSリージョンがない場所）にデータを保存することが求められています。
これらのニーズに対応するため、今週初めにAWS Dedicated Local Zones向けのS3ストレージクラスを発表しました。 Dedicated Local Zoneは、単一のお客様またはコミュニティが専用で使用するためにAWSが完全に管理し、お客様が指定した場所またはオンプレミスのデータセンターに配置されるAWSインフラストラクチャの一種です。Dedicated Local Zonesでは、お客様は現在、ディレクトリバケットを作成し、 単一のDedicated Local Zoneを指定してそこにオブジェクトを保存することができます。
ゾーン型ソリューションとして、S3は Dedicated Local Zonesにおいて、S3 Express One ZoneとOne Zone-Infrequent Accessという2つのゾーンストレージクラスをサポートしています。これらのストレージクラスは、データの分離要件やデータレジデンシー要件に対応するため、特定のデータ境界内にデータを保存することを目的として設計されています。オブジェクトデータは、お客様が Dedicated Local Zoneをデプロイした指定の場所にローカルに保存される一方、IAMポリシー、CloudTrailログ、CloudWatchメトリクスなどの管理データは親リージョンに保存されます。AWS Dedicated Local Zonesでのストレージクラスのサポートにより、これはAWS Digital Sovereignty Pledgeと、クラウドにおける最先端の主権管理機能を提供するという私たちのコミットメントを拡張するものです。
S3クライアントポートフォリオの拡充：使いやすさと高性能化
ここまでは、サーバーサイドの改善点について説明してきました。しかし、AWSでは、S3のエクスペリエンスはS3 APIだけでなく、クライアントソフトウェア、SDK、コネクタにまで及ぶと考えています。私たちの役割は、これらをシンプルで使いやすく、高性能なものにし、S3を直接扱わないアプリケーションのための変換インターフェースとして機能させることだと考えています。これをS3への入り口として捉えています。これらの目標を実現するため、昨年私たちは Mountpoint for Amazon S3やS3 Connector for PyTorchを含む、Amazon S3のクライアントファミリーを導入しました。
Mountpoint for Amazon S3は、バケットをコンピュートインスタンスにマウントし、ローカルファイルシステムのように利用できるオープンソースのファイルクライアントです。ローカルファイルシステムのAPIコールを、S3オブジェクトに対するS3 REST APIコールに自動的に変換します。高スループットのパフォーマンスを実現するよう設計されており、パフォーマンスのベストプラクティスのためにAWS共通ランタイムライブラリをベースにしています。Mountpointは、S3 Expressでのデータ追加やAWS Dedicated Local Zonesでのディレクトリバケットなど、先ほど説明した機能をサポートしています。
バケットをマウントする際、インクリメンタルアップロードフラグを使用できるようになり、Mountpointが自動的に新しいヘッダーとS3 PUT APIを使用するため、追加の操作は必要ありません。ディレクトリバケットや汎用バケットをマウントする際のプロセスは同じで、完全なバケット名を指定するだけです。特にディレクトリバケットの場合、アベイラビリティーゾーンまたはオブジェクトを配置したDedicated Local Zone IDのいずれかであるゾーンIDが含まれます。また、Mountpointのキャッシュオプションのサポートを拡張し、S3 Express One Zoneによる新しい高性能な共有読み取りキャッシュを追加しました。
このキャッシュは複数のコンピュートインスタンス間で共有でき、どのようなデータセットサイズにも柔軟に対応できます。マウント時には、ソースバケットを参照し、共有キャッシュ用の新しいキャッシュタイプ機能を使用して、キャッシュを保存するディレクトリバケットを指定します。最高のパフォーマンスを得るには、ワークロードと同じアベイラビリティーゾーンにディレクトリバケットを作成することをお勧めします。初回の読み取りリクエスト時、Mountpointはデータをディレクトリバケットキャッシュに格納します。同じデータに対する後続の読み取りリクエストでは、この共有キャッシュにより、S3 Standardと比較して最大7倍の高速化を実現できます。オブジェクトが利用できない場合は、リクエストをソースのマウントされたバケットにルーティングします。このキャッシュを使用することで、ローカルインスタンスストレージのプロビジョニングサイズに制限されることなく、ディレクトリバケットとS3 Express One Zoneでスケールできます。
昨年、私たちはPyTorch向けのS3 Connectorを導入し、S3にデータを保存するPyTorchトレーニングジョブの高スループットを実現しました。それ以降、PyTorch Lightningを含む2つの追加MLフレームワークのサポートを追加しました。PyTorch LightningはS3の読み取りとリストリクエストを自動的に最適化し、 ローカルインスタンスストレージを経由せずに直接S3にデータを保存することで、チェックポイントのパフォーマンスを向上させます。
第一に、そして第二に、並列でのロードと処理を可能にするPyTorchの機能である分散チェックポイントのサポートを追加しました。分散ジョブは数時間、場合によっては数日間実行されることが多いため、このコネクターはEC2とS3間のネットワーク帯域幅を最適化してより高いスループットを実現します。これにより、ローカルストレージへの書き込みと比較して最大40%のパフォーマンス向上を実現できます。
お客様から改善を求められていたもう一つのクライアントサイドの課題は、エンドユーザーが自社のアプリケーション内でデータにアクセスできるようにすることでした。これまでお客様は、独自のカスタムUIを作成・管理するか、制御が限られ、コストがかかり、メンテナンスが困難な場合が多いサードパーティの統合に頼っていました。そこで私たちはStorage Browser for Amazon S3を開発しました。Storage Browserは、アプリケーション内のエンドユーザーに、S3に保存されたデータを操作するためのシンプルなインターフェースを提供します。AWS AmplifyのJavaScriptとReactライブラリとして提供され、デフォルトでS3マルチパートアップロードを使用することで、S3への高スループットデータ転送を自動的に最適化します。
Storage Browserは、エンドユーザーが権限を持つデータのみを表示し、3つの異なる認証モードをサポートしています。1つ目は、先ほどPaulが説明したAWS IAM Identity CenterとS3 Access Grantsを使用する方法で、企業のIDに基づいてS3アクセスを自動的に付与することでスケールでのデータアクセス管理を支援します。2つ目は、WebアプリケーションやモバイルアプリケーションのためのAmazon CognitoアイデンティティプラットフォームとともにAmplifyを使用する方法で、企業ディレクトリに属さないサードパーティプロバイダーをS3のデータに接続したい場合に最適な選択肢です。3つ目は、AWS STSトークンをStorage Browserに提供することで、独自の管理サービスを利用する方法です。Storage Browserは、ボタン、見出し、アイコンなど、既存のアプリケーションのブランドアイデンティティスタイルに完全にカスタマイズすることができます。
Storage Browserは、アプリケーション内でコンポーネントを直接設定できる完全な制御を提供します。また、Storage Browser for S3を基盤とするAWS Transfer Family web appsもローンチしました。web appsを使用することで、ワークフォースに対して、S3内のオブジェクトの閲覧、アップロード、ダウンロードができる、完全にブランド化されたセキュアなWebベースのポータルを提供することができます。これにより、ユーザーフレンドリーなインターフェースとURLを備えたブラウザベースの転送が可能になります。AWS Transfer Familyコンソールから数回クリックするだけで共有可能なURLを作成でき、認証されたエンドユーザーはS3 Access Grantsを使用して権限のあるデータにアクセスできます。これにより、アプリケーションインフラストラクチャを管理する必要なく、Storage Browserと同じセットアップとメリットを得ることができます。
Webアプリケーション内では、ブランディングを反映するためにロゴやタイトルをカスタマイズすることもできます。 同様の課題として、静的Webサイトのホスティングがあります。現在、お客様はコンテンツの保存にS3バケットを使用できますが、S3以外にも、DNSの管理やロギング、モニタリングの設定など、多くの一般的なタスクを行う必要があります。そこで、この分野でのイノベーションを促進するため、 Amplifyホスティングとの新しい統合機能を追加しました。S3コンソールで数回クリックするだけで、S3バケットをAWS Amplifyホスティングで管理されているWebサイトに接続できるようになりました。バケットとデプロイされたアプリケーション間の接続を記憶しているため、シングルクリックでコンテンツの作成と更新が可能です。この接続は、 S3バケットのプロパティタブからAmplifyアプリに対して作成を開始できます。
以上で、60分間で30の新機能のご紹介を終わります。 S3 TablesとS3 Metadata Tablesによる構造化データと非構造化データの新機能について説明しました。より高いバケット制限、新しい条件付きAPI、新しいチェックサムなど、ストレージの基本機能を拡張しました。S3 Express One Zoneとの統合による性能の向上や、AWS Dedicated Local Zonesへの展開についてお話ししました。また、MountpointやPyTorch、Storage Browser、Transfer Family Webアプリによるクライアントサイドの革新についても触れました。本日はご参加いただき、ありがとうございました。これらの機能に関するフィードバックと、皆様が次に構築されるものを楽しみにしています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion