S3 Filesと変化するS3の姿

 (allthingsdistributed.com)
11 ポイント 投稿者 GN⁺ 23 일 전 | 4件のコメント | WhatsAppで共有
  • 大規模なデータ移動の非効率を減らすため、S3データにファイルシステムのように直接アクセスできる S3 Files が導入された
  • この機能は Amazon EFSとS3を統合し、EC2、コンテナ、Lambda などから S3バケットをNFSとしてマウントして読み書きできるようにする
  • 内部的には stage と commit の構造を使って変更を定期的にS3へ反映し、ファイルとオブジェクト間の双方向同期をサポートする
  • S3 Files は S3 Tables、S3 Vectors とともに、S3を統合データプラットフォームへ拡張する中核コンポーネントとして機能する
  • S3はもはや単純なストレージを超え、データ中心の統合ワークスペースへ進化し、開発者がデータを直接活用できる基盤を提供する

S3の変化とS3 Filesの設計

  • データ移動の難しさとS3 Filesの出発点

    • 大規模データを移動するプロセスは、科学研究から機械学習までさまざまな産業で継続的な非効率の原因となっている
    • UBCのゲノム研究の事例では、研究者たちはS3とローカルファイルシステム間のコピー作業に多くの時間を費やしていた
    • このような データ摩擦(data friction) は、ツールごとにデータへのアクセス方法が異なるために発生する
    • S3 Files はこの摩擦を減らすため、S3データへ直接ファイルシステムのようにアクセスできるよう設計された

  • エージェント型開発とデータの重要性

    • エージェント型ツール(agentic tooling) の発展により、アプリケーション開発の速度と多様性が急速に増している
    • コード記述の障壁が下がることで、ドメイン専門家が自らアプリケーションを構築できる環境が生まれている
    • アプリケーションの寿命は短くなり、データが長期的に残る中核資産として浮上している
    • ストレージは単なる保管場所ではなく、データをアプリケーションから分離して継続的に活用できるようにする抽象化レイヤーであるべきだ

S3の新しいデータプリミティブ

  • S3 Tables

    • S3は構造化データを扱うため、Apache Icebergベースの S3 Tables を導入した
    • Icebergの機能を維持しつつ、データ完全性の保護、自動コンパクション(compaction)、クロスリージョンレプリケーションなどを提供する
    • 現在、200万個以上のテーブルがS3 Tablesに保存されており、さまざまなアプリケーションがこれを基盤に構築されている

  • S3 Vectors

    • AIの発展により、ベクトルインデックスへの需要が増加している
    • 従来のベクトルデータベースはインデックスをメモリやSSDに保存するが、これはコストとスケーラビリティの限界を持つ
    • S3 Vectors は、S3オブジェクトに近い コスト・性能・耐久性プロファイルを持つ完全弾力的なベクトルインデックスを提供する
    • 数百件から数十億件のレコードまで拡張可能で、類似度検索(scalar similarity search) のためのAPIエンドポイントを提供する

S3 Filesの登場

  • 概要

    • S3 Files は Amazon EFS をS3に統合し、S3データにネットワークファイルシステム(NFS)のように直接アクセスできるようにする
    • EC2、コンテナ、Lambdaなどから S3バケットまたはプレフィックスをマウントして、ファイルのように読み書きできる
    • 変更内容は自動的にS3へ反映され、ファイルとオブジェクト間の双方向同期をサポートする

  • 設計上の難題

    • ファイルシステムとオブジェクトストレージは根本的に異なるデータモデルを持つ
    • 当初はEFSとS3を単純に結合しようとしたが、「受け入れがたい妥協(unpalatable compromises)」 しか残らなかった
    • ファイルは細粒度の変更と同時アクセスをサポートする一方、オブジェクトは不変性と全体単位の更新を前提としている
    • S3のイベント通知システムは1日あたり3,000億件を超える通知を処理し、オブジェクト単位の変更を基盤として動作している

Stage and Commit の設計原理

  • 境界を機能へ転換

    • ファイルとオブジェクトの違いを隠すのではなく、明示的な境界として設計した
    • 変更はEFSで stage(一時保存) され、一定周期ごとに commit(コミット) されてS3へ反映される
    • このアプローチはGitのバージョン管理の概念から着想を得ており、時間・ポリシーベースのデータ転送制御を可能にする

  • 一貫性と原子性

    • ファイルシステムの原子的(rename、move)操作と、S3のオブジェクト全体単位の更新を並行してサポートする
    • 2つのレイヤーを分離することで、各システムの一貫性モデルを保ちながら単一のデータビューを提供する

  • 権限管理

    • S3のIAMポリシーとファイルシステムのinodeベース権限は構造的に異なる
    • S3 Files はマウント単位の権限付与によって両者の仕組みを分離する
    • S3 IAMポリシーは最終的なバックストップ(backstop) として維持され、データ境界の変更時にもアクセス制御を可能にする

  • 名前空間の不一致

    • S3にはディレクトリ概念がなく、パス区切り文字(delimiter) も任意に指定できる
    • ファイルシステムとの不一致を解消するため、双方の命名規則をそのまま維持する
    • 互換性のないオブジェクトは移動させず、イベントを発生させて開発者が処理できるよう設計されている

  • 性能と遅延(latency)

    • ファイルシステムはメタデータ中心のアクセスに、S3は大規模並列アクセスに最適化されている
    • ほとんどのワークロードではファイルとオブジェクトに同時アクセスしないため、2つのモデルを完全統合するより同期レイヤーを維持する方が現実的だ
    • ファイルビューはNFS一貫性、オブジェクトビューはS3の強い一貫性を維持し、同期レイヤーが接続役を担う

S3 Filesの動作方式

  • 基本構造

    • S3 Files はEFSをバックエンドとして使用し、ファイルシステム体験を提供する
    • ディレクトリアクセス時にS3メタデータを取得して同期されたビューを生成し、128KB以下のファイルは即座にデータもロードする
    • 大容量ファイルは 遅延ロード(lazy hydration) によって必要時にデータを取得する
    • 変更内容は約60秒ごとにS3へ単一のPUTでコミットされ、双方向同期を行う

  • 競合と管理

    • 両側で同時に修正が行われた場合、S3が信頼できる唯一の情報源(source of truth) と見なされる
    • 競合したファイルは lost+found ディレクトリへ移動され、CloudWatchメトリクスとして記録される
    • 30日間アクセスされなかったファイルはファイルシステムビューから削除され、コスト最適化が図られる

  • 性能最適化

    • read bypass 機能により、大容量のシーケンシャル読み取り時には並列GETリクエストでS3から直接読み込む

      • クライアントあたり3GB/sのスループットを達成し、複数クライアントではテラビット級の拡張性を確保する

  • 制約と今後の改善予定

    • S3にはネイティブなrename操作がないため、ディレクトリ名変更時には全体のコピー・削除が必要になる
    • 5,000万個以上のオブジェクトを含むマウントには警告が表示される
    • 明示的なコミット制御は初期バージョンには含まれない
    • 一部のオブジェクトキーはPOSIXファイル名として表現できず、ファイルビューから除外される

データ多様性とS3の進化

  • データアクセス方式の共存

    • UBCの研究事例のように、開発者はデータ移動・キャッシュ・名前管理に多くの時間を費やしている
    • S3チームは Tables、Vectors、Files によって多様なデータアクセス方式を統合的にサポートする
    • ファイルとオブジェクトの違いをなくそうとするのではなく、それぞれの特性を認めて境界を機能化している

  • S3の拡張された役割

    • S3は単純なオブジェクトストレージから、多様なデータ形態を支える統合ストレージプラットフォームへ進化している
    • Tables、Vectors、Files によって、作業スタイルに合わせてデータを直接活用できる
    • 目標は、ストレージが作業の妨げではなく、透明な基盤インフラになることだ
    • 今後も stage/commit 制御、パイプライン統合などの機能拡張を継続する予定だ

  • 結論

    • S3 Files はファイルとオブジェクトの明示的な境界を維持しながら、両者の利点を組み合わせる
    • 20年前にオブジェクトストレージとして始まったS3は、今やデータ中心の統合ワークスペースへ発展した
    • 「さあ、作ってみよう(Go build!)」というメッセージのように、S3は開発者がデータでより速く実験し構築できる基盤として位置づけられている

関連記事

4件のコメント

 
xguru 23 일 전

ああ、これからは「一緒に読むとよい記事」が関連する公式記事をうまくつないでくれるので助かりますね。
こうして紹介記事と公式記事が別になっている場合、どう扱うべきかいつも悩んでいたのですが、
「一緒に読むとよい記事」がうまく機能していてうれしいです..（笑）

これでS3は、ファイル・テーブル・ベクトルをすべて含むデータプラットフォームへと拡張していくんですね。

モダンなクラウドインフラの出発点だったS3が、20年を経て再定義されるような感覚です
 
rtyu1120 17 일 전

S3 と透過的にファイル構造が共有されるわけではありませんが、ZeroFS という、S3 をデータベースとして使い POSIX 準拠のファイルシステムを動かすオープンソースも存在します。S3 上で PostgreSQL を動かすデモでかなり人気がありました。

https://www.zerofs.net/
 
rtyu1120 17 일 전

以前S3エンジニアが創業したArchilで自社製品と比較した記事もあるので、一緒に読むと面白いです（笑）

https://x.com/jhleath/status/2042613823522377933
 
GN⁺ 23 일 전
Hacker News の意見

  • これは実質的に S3FS を使いつつ、アクティブデータや小さなランダムアクセス向けのキャッシュ層として EFS（AWS のマネージド NFS サービス）を有効にする構成だと思う
    問題は、EFS の 高価な料金体系 がそのまま付いてくる点
    — すべての書き込みは GB あたり $0.06 で、書き込み中心のワークロードには致命的になり得る
    — キャッシュから読む場合は GB あたり $0.03 が課金され、128KB を超える大きな読み取りは S3 バケットから直接ストリーミングされるので無料
    — キャッシュは GB あたり月額 $0.30 だが、主に 128KB 以下の小さなファイルだけを継続保存するので、コストはそれほど大きくなさそう

    • 大きなファイル読み取り（>128KB）が常にキャッシュを経由しないという理解で合っているのか気になる
      S3 のレイテンシ はかなり悪いほうなので心配

  • “NFS provides the semantics your applications expect” という文句は、今まで見た中でいちばん笑った

    • アプリケーションは、ネットワーク切断ひとつで システムコールが無限待機 状態に陥ったり、ファイルシステムがアンマウント不能になったりすることを期待していない

  • Hugging Face Buckets も最近、バケットをファイルシステムのようにマウントできる機能を追加した
    hf-mount 変更ログ

  • 同期まわりが気になった
    AWS ドキュメントによると、
    /mnt/s3files/report.csv を修正したあとで S3 バケットに別バージョンがアップロードされると、競合時には自分の版が .s3files-lost+found-file-system-id ディレクトリへ移され、バケット版で置き換えられるらしい
    つまり、競合時の自動復旧ディレクトリ が存在する

  • FiberFS はほぼ最初の公式リリース段階にある
    内蔵キャッシュ、CDN 互換、JSON メタデータ、並行性安全性を備え、あらゆる S3 互換ストレージを対象にしている

    • Amazon 自身の FUSE 実装 と比べてどうなのか気になる。もう第 3 版まで出ている

  • AWS がローカル NVMe ストレージ とのマネージドなブリッジを提供してくれたらいいのにと思う
    NVMe は EBS よりずっと速く、EBS は EFS より速い
    NVMe 上にキャッシュ層を載せればかなり速くなりそうだが、完全統合型の選択肢のほうが理想的

    • EFS が単なる NFS マウントなら、NVMe ボリュームを付けて cachefilesd を設定し、自分で実装することもできそう
      例えば 
      mkfs.ext4 /dev/nvme0n1 && \
mount /dev/nvme0n1 /var/cache/fscache && \
mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
      こんな感じでそのまま動くかもしれない
      実質 3 行コマンドなのに、これを マネージドサービス として出すのが AWS らしい動き

  • AWS は以前、S3 をファイルシステムとして使うなと言っていたはずだが、なぜ今になって変わったのか気になる

    • 今回は S3 の前段に実際のファイルシステム（EFS）を置いて 透過同期 を行う構成に見える
      ブログでも 一貫性の問題 や オブジェクト名の扱い といった注意点に触れている
      S3 ファンとしては、こういう設計はかなりうまい折衷案だと思う
    • 大企業の顧客アーキテクトたちはずっと前から S3 をファイルシステムのように使ってきた
      AWS に寄せられる サポートチケットの圧力 と「なぜできないのか」という要求が積み重なって、結局この方向に進んだのだと思う
      個人的には「本質的に違うものを新しい包装で包み直した」アプローチに見えてあまり好きではないが、$$$ の社会的圧力 が作用した例なのだろう
    • これは技術力の低いユーザー層まで取り込もうとする戦略に見える
      “S3asYourFS.exe” みたいなツールを使う人たちも AWS の顧客にできるから
      ただ、AWS の カスタマーサポート能力 を考えると、これが賢明な判断かどうかは疑問
      それでも、毎月料金を払うユーザーが増えるという誘惑は大きかったはず
    • どうせ人々が S3 をファイルシステムのように使うなら、むしろ 公式サポート したほうがいいと思う
    • 結局 AWS は手前にキャッシュを置いて 収益モデル を作ったということ
      ユーザーにとっては性能が良くなり、AWS は負荷を減らせる
      お金を節約できるかもしれないし、できないかもしれない

  • これで SQLite データベース を保存するとどうなるのか気になる
    たぶん読み取り専用レプリカ程度にしか使えず、Litestream のようなバックアップには向かないのでは

    • SQLite の ロック機構 は NFS では安全ではないので動かない

  • NFS の ロック動作 もすでに十分複雑なのに、そこへリモートの S3 バックエンドを混ぜたらさらに混乱しそう

  • Werner Vogels は本当にすごい人だ
    昔 DynamoDB を勉強していたときに彼の文章を初めて読んで、それ以来ファンになった