S3成長記録 in 2024
2025年3月12日に開催された Storage-JAWS#7 AWS Pi Day 2025直前スペシャル！に登壇させていただきました。今回は2024年のアップデートを振り返りつつ、最近のアップデートの裏側について（妄想を含めて）紹介しましたが、登壇時にお話ししきれなかったことも多く、補足情報なども含めて内容をまとめておきます。
昨年もStorage-JAWS#3でS3成長記録というタイトルで、S3の18年間のアップデートを振り返っているので、見ていただけるとうれしいです。
去年は18年分のアップデートを振り返るのが辛すぎて二度とやるまいと思ったのですが、今年もポチッとLTを申し込んじゃいました。そして来年は20年の節目ですね…。
資料
録画
当日のレコーディングはこちら。なぜか画面が黄色いですね。Night Shiftのせい？
内容
“What's New with AWS” や re:Invent 2024のアーカイブ、 “AWS Blog” 等を参考に、2024年のアップデートを整理しました。取りこぼし、個人的な見解も多々ありますので、ご了承ください。
定番のオブジェクト数の推移です。2013年まではちょくちょくオブジェクト数が公開されていたようで、初年度でいきなり8億個ってのもすごいんですけど、約7年かけて2兆個に到達しました。
それが2021年になると100兆個になりました。2013年までもすごい増えているように見えたんですけど、もう異次元ですね。
2021年以降しばらくオブジェクト数の情報が見当たらなかったのですが、2024年のre:Inforce のキーノートで350兆個に到達していることが発表されました。そして、re:Invent 2024 では400兆個を超えていることが発表されました。わずか半年で50兆個も増えたようで、もうよくわからないレベルですね。
独自基準での整理になりますが、過去19年でS3自体のアップデートと言えそうなものは大体257個あり、そのうち169個が機能に関するものです。なんと2024年が一番多いんです。
re:Invent 2024 で What’s new with Amazon S3 (STG212) というセッションがありまして、その中で過去12ヶ月間で30個と発表されています。私の分類でも、S3のサーバサイドのアップデートが23個、クライアントサイドを含めると29個なので、そんなに外してないのかなとは思います。
What’s new with Amazon S3 (STG212) については、AWSの方がBedrockで日本語の書き起こしを共有されています。
基本機能の強化については、まず11月に発表されたバケット数の上限に着目してほしいです。これは、従来デフォルト100個、最大1000個が上限だったバケット数のクォーターが、デフォルト1万個、最大100万個になったというアップデートです。マルチテナントなシステムでテナント毎にバケットを分けていたりすると、上限1000個じゃ足らなくてプレフィックスで分離してポリシーを頑張って書いたりとか、クロスアカウントを使うということがあったかと思いますが、その必要がなくなりました。アプリケーションから複雑性を取り除けるすごくよいアップデートだったと思います。なお、2000個を超えると少額ですが課金が発生するので、やたらと増やすのは避けた方が良いと思います。ちなみになぜ100万個なのかについては、実質無限として利用者が上限を気にする必要をなくしたかったとのこと。
その直前の10月にListBucketsというAPIでリージョン等を指定したフィルタリングやページネーションがサポートされるというアップデートがありました。真偽は定かではないですが、時系列的に逆向きに見ると、バケット数が増えるからAPIにエンハンスが入ったんではないか？という見方もできます。同月、Service Quotasで汎用バケット数のクォーターが管理可能になったんですが、これも単品で見るとなぜ今さら？って感じですが、その後の布石だったと思うと、ちょっと見方が変わってくるのではないでしょうか？
これまでS3への書き込みを分散処理するためには、アプリ側でコンセンサスメカニズムを書く必要がありましたが、結構難しいし大変でした。それをAWS側でやってくれるのが条件付きリクエストです。我々はビジネスロジックにフォーカスすればよくなったという、すばらしいアップデートですね。
8月に最初に登場したのが条件付き書き込みのif-none-matchです。これはオブジェクトのキーが既に存在する場合の上書きを防止するものです。11月には、既存オブジェクトの更新時にETagが指定したものか検証することで、意図せぬオブジェクトの上書きを防止するif-matchが発表されました。これによって、CASのような処理が簡単に実装できるようになりました。同月には、意図せぬオブジェクトの削除を防止する条件付き削除も可能になりました。これはディレクトリバケット限定となっていますが、汎用バケットでもサポートされる予定のようです。また、汎用バケットではポリシーで条件付き書き込みを強制することもできるようになりました。
次は Express One Zone 関連のアップデートです。
Express One Zone は一貫した一桁ミリ秒の低レイテンシでリクエストを処理できるように設計されたストレージクラスで、re:Invent 2023で発表されました。発表時点では使用可能なリージョンが4つしかなかったんですが、そこに東京が入っていたのは個人的にはすごく嬉しかったです。
スライドを見ていただければわかるように、この1年間で Express One Zone は多くのアップデートが行われています。まず2月に、ど真ん中のUCを狙ったSageMakerとのインテグレーションが発表されました。7月にはCloudTrailでデータイベントを記録できるようになり、オブジェクトのレベルの監査にも対応しました。9月にはSSE-KMSを用いた暗号化に対応。11月にはオブジェクトのライフサイクル管理や、先ほど紹介した条件付き削除が可能になり、利用可能なリージョンも3つ増えました。12月には専用ローカルゾーンでも使えるようになっています。また、Express One ZoneをMountpoint for S3の共有キャッシュに使用することもできるようになりました。Mountpoint for S3はインスタンスのメモリやインスタンスストア、EBSをキャッシュに使用することができましたが、キャッシュはインスタンス内でしか利用できませんでした。このアップデートによって、複数のインスタンスでキャッシュを共有することができるようになりました。
1年間で一番驚いたのが、11月に発表されたオブジェクトへのデータ追加です。これはS3の歴史上初めてだと思いますが、ログを追記していくといった使い方ができるようになりました。
つづいて、S3 Tables と S3 Metadata Tables です。re:Inventの目玉だったので印象に残っている方も多いと思いますが、S3 Tables はフルマネージドのApache Icebergテーブルです。すでにS3にはエクサバイト級のParquet形式のデータが保存されているそうですが、S3 Tablesは汎用S3バケットに保存されているIcebergテーブルと比較して、1秒あたり最大10倍のトランザクションを実現できるとのことです。スナップショットの管理やコンパクションなどのテーブルメンテナンスも自動で行われるし、よいことだらけですね。Glue Data Catalogとも統合されていてRedshiftやAthenaからクエリも可能です。年が明けて1月からは、東京でも使えるようになりました。バケット1つあたり1万テーブルまで作成可能で、CreateTable APIでのスキーマ定義もサポートされました。
Metadata Tables は汎用バケットに保管しているオブジェクトのメタデータをSQLで検索できるというものです。例えば、顧客を特定できるタグをつけて、特定の顧客のデータだけを検索するといったことがやり易くなりました。少々ややこしいのですが 汎用バケットのオブジェクトのメタデータは、システムが管理するテーブルバケットで管理されます。
こうやって整理してみると、ここ1年間のアップデートはデータの「保管」より「活用」にフォーカスしているように見えます。
データベースの世界だと Pupose-built という表現が使われますが、バケットもそうなってきました。
【発表当日は時間不足でスキップ】
ディレクトリバケットやテーブルバケットの裏側についてお話しするにあたり、S3で使用されているらしいErasure Codingとそれによって好循環が生まれていることを少し紹介します。
Erasure Codingは、データを複数のブロックに分割しパリティを付加することで、分割したデータブロックの一部が消失してもデータ全体を復元できるようにする技術です。数学的関数を利用することで高い容量効率を確保でき、ブロックを異なるストレージノードに分散させることで耐久性を高めることもできます。パリティの計算には一般にReed-Solomon符号などが使用されるようですが、S3が使用しているアルゴリズムは不明です。
ポイントは、S3が分割しパリティを付加したデータブロックのコピーを複数のストレージノードに分散配置していると思われることです。ストレージに保存したデータブロックを高速にデータを読みたいと思っても、ブロックの読み取り速度は使用するディスクの性能に制限されますが、分割したデータブロックを複数のディスクに分散配置することで、並行してブロックを読み込むことができます。全体のデータアクセス速度は、一番取得に時間を要したデータブロックに引っ張られますが（いわゆるテールレイテンシー）、他のデータノードから当該ブロックを読み込むといった対策も可能になります。投機的に複数ノードに同時に読み込みに行って、早い方を使用するなどもできる気がします。
通常、ストレージに保存されたデータは、常時アクセスされることはなくコールドです。同じディスクに異なるユーザやワークロードのデータを保存することで、データへのアクセスを分散させ、必要な時に高速で読み込める巨大ストレージを安価に実現していると推測されます。ホットなデータブロックの複製数を増やしたり、配置を最適化してホットスポットを解消するなども行われているかもしれません。Erasure Codingのおかげで多少のブロック消失は問題なく、積極的なリロケーションやアルゴリズムの改善などもやり易い気がします。
スケールはもちろんディスクの調達単価にも貢献しますが、S3はユーザが増えれば増えるほど性能効率もコスパも高くなるという好循環が生まれる構造になっていて、素晴らしい設計だと思います。
では、ディレクトリパケットってどういう仕組みで低レイテンシーを実現しているのかという話です。
容易に想像がつくのは Express One Zone という名前の通り、シングルAZであることでネットワークのレイテンシーを最小化しているということです。これについては、Summit Japan 2024の焼尾さんの資料でも触れられています。昨年8月にJAWS Pankrationでネットワークレイテンシーの話をしたのでそちらも見ていただければと思いますが、AZ間のRTTは1-3msくらいでトータルで一桁ミリの応答性能を実現するにあたって、無視できなかったということかもしれません。
また、ディレクトリバッケットにはSSDが使われているのではないかと思われる情報もあります。S3の内部ではShardStoreというKVSが使われているそうなのですが、形式手法を用いたS3のKVSノードの検証に関する論文が公開されていて、ShardStoreの実装が少し紹介されています。その中で、ある論文を引用しながらShardStoreはシャードデータをLSM-Treeとは別に保存していることが示されています。そしてこの引用された論文が、SSDに最適化されたLSM-TreeベースのKVSに関するものであることから、SSDが使用されているのではないかと推測しています。
Table Bucket については re:Invent の Store tabular data at scale with Amazon S3 Tables (STG367-NEW) というセッション等で結構解説されていて、テーブルというレベルで抽象化したことで、内部の処理をスキップしたり順序を入れ替えたりと最適化ができるようになったということのようです。データ形式もParquetに確定しているので、最適配置もが可能なのでしょう。また、Icebergへのフィードバックやコントリビューションも行われたようです。
Store tabular data at scale with Amazon S3 Tables (STG367-NEW) も、AWSの方がBedrockで日本語の書き起こしを共有されています。
【発表当日は時間不足でスキップ】
S3を利用するためのSDKやクライアントライブラリ関係では、9月にS3に保存したオブジェクトを操作するためのUIコンポーネントであるStorage Browserが発表されました。発表時はPreviewでしたが、12月にGAとなりました。似たようなものを作ったことのある人は結構いる気がしますが、便利になりましたね。12月にはS3のオブジェクトを操作できるフルマネージドなウェブインターフェイスのTransfer Family Web Appsが発表されました。内部ではStorage Browserを使っているのではないかと思いますが、確かな情報源は見当たらず（フロントエンドなんだからソース読めという話ですね）。このリリースにあたり必要になったと言われているのが、9月に公開されたListCallerAccessGrantsというAPIで、S3 Access Grantsで許可されたバケットやオブジェクトを取得できるAPIです。
他サービスとの統合・連携としては、5月にはAmazon OpenSearch Service (AOSS) とのZero ETL統合が発表されました。また、re:Invent 2023で発表されたAccess Grantsが、SageMaker Studio、Redshift、Glueなどで利用できるようになり、組織でのデータ活用を意識したアップデートが複数発表されました。
【発表当日は時間不足でスキップ】
AWSがOLPに掲げるCustomer obsessionを印象づけたのが403関連のアップデートです。これは4月末にあるユーザが空の非公開バケットに高額の請求があったことを報告したことで注目された問題への対策です。請求が発生した直接の要因は、ある人気OSSツールのバックアップ設定のデフォルト値がこのユーザのバケット名になっていたことですが、403（アクセス拒否）で応答されたリクエストに対して課金が発生するのはよくないとAWSも考えたようで、わずか2週間ほどでユーザ自身によるものではない未承認のリクエストには課金しない方針を表明し、8月にはすべてのS3 APIで対策が完了しています。また、リクエストに対するHTTP 403エラーに追加のコンテキストが提供されるようになり、エラーの原因を特定しやすくなりました。CloudTrailでも同様の情報を確認できます。これはおそらく、課金の発生・有無を判断するためにこれらの情報が利用できるようになったのだと推測しています。
そして、2024年で個人的に一番アツいアップデートが、GuardDuty Malware Protection for Amazon S3 です。オンプレの名残りかストレージはすべからくマルウェアスキャンを要求されることも少なくなく、いろいろ苦労していた人は多いと思いますが、ついに解放されました！さらに、2025年2月にはスキャンされたデータ量の1GBあたりの料金が85%も削減されるといううれしいアップデートも発表されています。
9月にはライフサイクル移行ルールにデフォルトの最小オブジェクトサイズ（128KB）が適用されるようになりました。この変更によってストレージクラスに関係なく、デフォルトもしくは明示的に指定したオブジェクトサイズ未満のオブジェクトは移行されなくなりました。
10月には静的ウェブサイトホスティングがAmplify Hostingと統合されました。CloudFrontを別途設定することなくマネージドなCDNに色々お任せすることができるようになりました。発表当時はAmplify HostingはWAFでの保護に対応していなかったのですが、12月にPublic Previewが発表されています。
2024年のアップデートを振り返ってきましたが、S3はデータの保管から活用にフォーカスを移しているように見えて、データを活用するためのアップデートがたくさんありました。S3は活用目的に応じてバケットを使い分ける Purpose-built なストレージサービスの総称のようになってきたなという印象です。個人的には、この流れでJSONに特化したバケットができるとうれしい。S3は基本機能やユーザビリティ強化等の堅実なアップデートを積み重ねつつ、データ活用を手広くカバーしていく「オトナの余裕」を感じさせる Super Storage Service ですね！来年はいよいよ20年の節目です。
余談:「大人の余裕」とスライドに書いていたらSpeakerDeckにマスキングされたので「オトナ」に変えてみたけどダメでしたｗ
登壇者・参加者の方の記事等
自分が見つけられたものを載せていますが、他にもあるよって方はコメントで教えてください。
WordPressのファイル共有にAmazon FSx for OpenZFSを利用する＠木澤 朋隆さん
Windows Server に FSx for NetApp ONTAP を iSCSI 接続してみた＠emiさん
これでいいのか、我が家のスナップショット＠松島 敬一さん
【動画レポ】Storage-JAWS #7 AWS Pi Day 2025直前スペシャル！@keitaさん
Discussion