ハクソク

世界を動かす技術を、日本語で。

S3ファイル

32日前原文(allthingsdistributed.com)

概要

  • 大規模データ移動 の課題とその背景を解説
  • S3 Files という新機能の登場とその意義
  • S3 Tables や S3 Vectors などS3の進化を紹介
  • データとアプリケーションの分離 の重要性
  • 科学・AI分野での 現場の課題と解決策 を具体例で説明

S3 Files登場の背景と課題

  • 大規模データの移動 は多くの業界で長年の課題
  • 研究現場 （例：UBCのゲノム研究）では、データのコピーや複製管理が煩雑
  • Linuxツール や 分析フレームワーク （GATK4など）はローカルファイルシステムを前提
  • S3 はコスト・耐久性・並列性に優れるが、ファイルシステムとの間に 摩擦 発生
  • 結果として、 手動コピー や データの不整合 が頻発

データフリクションとエージェント時代

  • AIエージェント の進化でアプリ開発の障壁が低下
  • 専門知識 と プログラミングスキル の分離が進行
  • アプリの開発サイクル が短縮し、データの価値がさらに重要に
  • ストレージシステム の役割は、「安全に保存する」だけでなく「アプリからの独立性を保つ」こと
  • データフリクション削減 が、今後のストレージ設計の鍵

S3の進化（S3 Tables, S3 Vectors）

  • S3 Tables ：Icebergベースのマネージドテーブル機能
    • データ整合性・耐久性の保護
    • 自動コンパクションやクロスリージョンレプリケーション
    • 200万以上のテーブル運用実績
  • S3 Vectors ：ベクトルインデックスをS3ネイティブで管理
    • AIや検索用途での ベクトルデータ の需要増加
    • SSDやインメモリDBではなく、 S3と同等のコスト・耐久性・弾力性
    • 数百件から数十億件までスケール可能
    • APIエンドポイント経由で シンプルに利用可能

S3 Filesとは何か

  • S3 Files ：S3データを ネットワークアタッチドファイルシステム として直接利用可能に
  • Amazon EFS との統合により、既存S3データをそのままファイルとしてマウント
  • 科学計算・AI・メディア業界 など、ファイルシステム前提のツール利用者に最適
  • 複雑なデータコピーや変換プロセス を不要化
  • S3 TablesやS3 Vectors と並ぶ、新たな「データプリミティブ」として位置付け

S3 Filesの技術的特徴とメリット

  • 既存S3バケット のデータを ファイルシステム経由で即時アクセス 可能
  • EFSのスケーラビリティ と S3の耐久性 を両立
  • アプリケーション変更不要 で、従来のファイルベースツールがS3上のデータを利用可能
  • データの一貫性・整合性 を保ったまま、複数ツール・ユーザーで同時利用
  • データ管理コスト・運用負荷の大幅削減

まとめ：今後のデータストレージの方向性

  • アプリケーションの多様化・高速化 に合わせ、 データアクセスの柔軟性 が重要
  • S3 Files は「データとアプリの分離」をさらに推進
  • 研究・AI・エンタメ など多様な業界での データ活用のハードルを劇的に低減
  • S3 Tables/Vectors/Files の三本柱で、 AWS S3 は「現代のデータ基盤」として進化中

参考: AWS公式ブログ “Launching S3 Files: Making S3 Data Directly Accessible as a File System”

Hackerたちの意見

100% 確認できるわけじゃないけど、AWSはS3をファイルシステムとして使わないようにかなり強く主張してたと思う。なんで今になって変わったんだろう？

└

キャッシュを前に置くことでお金を稼ぐ方法を見つけたんだよね。負荷が減って、パフォーマンスも良くなる。お金が節約できるかもしれないし、できないかもしれないけど。

└

実際にS3の前にファイルシステム（基本的にはAWS EFS）を置いて、透明な同期を行ってるみたい。ブログ記事では、整合性とかオブジェクト名の不一致（不一致はイベントとして顧客に通知される）についてたくさんの注意点が語られてる。長い間S3のファンだったから、このデザインには本当に感心してる。いい妥協だし、このデザインを推し進めた人には拍手を送りたい。

└

元々の意図に関係なく、便利な抽象化だから人々はファイルシステムとして使うだろうし、だったら最適でサポートされた方法でやった方がいいんじゃないかな？

└

かなりのエンジニアリングの努力がないと（ブログ記事を見てね）、オブジェクトストアのセマンティクスとファイルのセマンティクスの不一致が原因で、きっと大変な目に遭うと思う。S3の初期の頃には、キーのプレフィックスに基づくスループット制限みたいな実装の詳細もあって（それは2016年頃に消えたけど）、階層的なディレクトリ構造にはさらに使いづらかった。

└

人々、つまり大規模アカウントの組織にいるアーキテクトやリード開発者たちは、S3をファイルシステムとして使って、通常はクレイジーな超複雑なプロジェクトの基盤にしてるんだ。だから、AWSにそういう風に動作させるプレッシャーが常にあったんだと思う。AWSが受け取るサポートチケットの中には「私のS3を使ったプロジェクトが遅い/時々失敗する/AWSの制限（アカウントごとのバケット数の上限など）にぶつかる」とか「なんで…」って質問が多いけど、AWSの人たちがその場にいることも多いから、S3の技術的な制限を克服するための長期的なプレッシャーになってるんじゃないかな。こういう「新しいコーティングを施して本質的には違うものだと見せかける」抽象化にはあまり賛成じゃないけど、ここにはお金によって強化された社会的プレッシャーがあると思う。

└

これによって、技術的にあまり得意じゃない人たちが「S3asYourFS.exe」みたいなランダムなプログラムをダウンロードして使う大きな顧客層が開けると思うけど、その一方でその機能をサポートしたり、技術的にあまり得意じゃない人たちからのサポートコールにも対応しなきゃいけなくなるね。そのビジネス判断が理にかなってるかは分からないけど（AWSはプロのクライアントに対応するためのカスタマーサポートインフラも不足してるし）、みんなが月額料金をAWSに払うようになる可能性は魅力的すぎる果実かもしれないね。

└

これが技術者の考え方だけど、顧客はこれを求めてるから、結局は作られるよ。

これは基本的に、EFS（AWSの管理されたNFSサービス）をアクティブデータと小さなランダムアクセスのためのキャッシュ層として使ったS3FSだね。残念ながら、EFSの高額な料金もついてくる。 — すべての書き込みは$0.06/GBかかる。なぜなら、すべてが最初にEFSキャッシュに書き込まれるから。書き込みが多いアプリケーションには致命的かもしれない。 — キャッシュにヒットする読み取りは$0.03/GBで請求される。大きな読み取り（>128kB）は、基盤のS3バケットから直接ストリーミングされるので、これは無料。 — キャッシュは$0.30/GB/月で課金される。すべてがキャッシュに書き込まれる（整合性のため）けど、どうやら小さなファイル（<128kB）の永続ストレージにしか使われないみたいだから、あまり高くはならないはず。

└

大きな読み込み（>128kB）は、基盤となるS3バケットから直接ストリーミングされるので、無料なんだよね。常にキャッシュなし？S3はレイテンシがかなり悪いからね。

└

これ、私も心配してた。S3をファイルシステムとして使う理由は、コストを最小限に抑えるためなんだよね。だから、s3fsの代わりにこれを使う理由があまり見当たらない。

同期の部分が気になってたんだよね：https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-fil... > 例えば、ファイルシステムを通じて /mnt/s3files/report.csv を編集したとする。S3 Filesがあなたの変更をS3バケットに同期する前に、別のアプリケーションが新しいバージョンのreport.csvを直接S3バケットにアップロードしたとする。S3 Filesがその衝突を検出すると、あなたのバージョンのreport.csvをロスト＆ファウンドディレクトリに移動して、S3バケットのバージョンと置き換える。 > ロスト＆ファウンドディレクトリは、ファイルシステムのルートディレクトリに「.s3files-lost+found-file-system-id」という名前で存在する。

これは最初の公式リリースにかなり近いね：https://fiberfs.io/ キャッシュ内蔵、CDN互換、JSONメタデータ、同時実行安全で、すべてのS3互換ストレージシステムをターゲットにしてる。

└

これをAmazonのFUSE実装と比べるとどうなる？今は3回目の大きな再誕を迎えてると思うけど。

ローカルのNVMeストレージへのマネージドブリッジを提供してくれたらいいのに。AWSのNVMeはEBSに比べてめっちゃ速いし、EBS（ノード専用アクセスのブロックデバイス）はEFS（マルチノードアクセス）よりも速いんだよね。さらにキャッシュをNVMeファイルシステムの上に置けばもっと速くなると思うけど、完全に統合されたオプションがあればもっと良いよね。

└

EFSはただのNFSマウントだから、自分でNVMeボリュームをインスタンスにアタッチして、NFSマウント上にcachefilesdみたいなものを設定してNVMeを指すことができるんじゃないかな。mkfs.ext4 /dev/nvme0n1 && \ mount /dev/nvme0n1 /var/cache/fscache && \ mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3filesがそのまま動くかな？EFSでは動くんだけど。実質的に3つのシェルコマンドだけのマネージドサービスを提供する価値があるとは思えないけど、これがAWSの話だからね。

「NFSはアプリケーションが期待するセマンティクスを提供します」って、今まで読んだ中で一番面白いことの一つだわ。

└

アプリケーションは、ネットワークの不具合でシステムコールが無限にブロックされることを想定してないの？ そうなると、実質的に終了できなくなって、ファイルシステムもアンマウントできなくなるよね。

└

S3やGCSで自分で作るのと比べると、確かにそうだね :)

Hugging Face Bucketsも最近、バケットをファイルシステムとしてマウントするサポートを追加したよ: https://huggingface.co/changelog/hf-mount

S3をファイルシステムとして使う問題は、変更不可能（immutable）なところだね。S3 Filesでもそれは変わってない。大きなファイルがあって、その中の1バイトを変更したり、名前を変えたりすると、全ファイルを再アップロードしなきゃいけない。これは、キャッシュに収まるくらいの小さいファイルの読み込みが多いワークフローには便利そう。

└

CoWファイルシステムとあまり変わらないよね。ファイルがオブジェクトに1:1でマッピングされる必要はないし、ファイルを小さなチャンクに分けて、もっと細かい編集を可能にすることもできるよ。

これ、ZFSのオブジェクトストレージバックエンドと比べてどうなの？ https://news.ycombinator.com/item?id=46620673

このアーキテクチャを考える最良の方法は、EFSとS3の双方向同期がある感じだね。一方に書き込んで、もう一方から読み出すことができるし、その逆も可能。各々の中では一貫性が保たれてるけど、間ではそうじゃない。