問題の起源：ゲノム研究者のジレンマ

UBC の植物ゲノム研究が着想のきっかけ

根本的な課題

• 解析ツールはファイルシステム API を前提に設計
• 実データは S3（オブジェクトストア）に存在
• 手動コピーや複数コピーの管理が発生し非効率に
• データ移動コストが研究の本質的作業を圧迫

S3 の過去 2 年間の進化

S3 は単なるオブジェクトストアから多様なデータ形式を扱う
プラットフォームへと変貌しつつある

S3 Tables はすでに 200 万テーブル以上が利用中

S3 Files とは何か

S3 バケット／プレフィックスを直接マウントし
ファイルシステムとして扱える新機能

対応環境と特徴

• EC2 インスタンス / コンテナ / Lambda に対応
• ファイル API とオブジェクト API の双方向アクセス
• どちら側からの変更も相互に反映される
• EFS との統合により NFS 互換マウントを実現

S3 Files の技術仕様

• 128 KB 以下のファイルは即座にデータ取得
• 128 KB 超はメタデータのみ取得してレイジーロード
• 約 60 秒ごとに変更を S3 へ自動コミット
• 読み取りスループット最大 3 GB/s（スケール可能）
• 30 日間未アクセスのキャッシュは自動削除（S3 データは保持）

「Stage and Commit」アプローチ

ファイルとオブジェクトの違いを尊重し、
無理に統合せず明示的な境界を設定する設計

EFS でファイル操作 → S3 へまとめてコミット

4 つの主要トレードオフ

• 一貫性：ファイルのアトミックリネーム vs S3 全オブジェクト更新
• 認可モデル：POSIX パーミッション vs IAM ポリシー（マウント単位で解決）
• 名前空間：変換不可キーはイベント通知で対応
• パフォーマンス：メタデータ局所化 vs 並列フラットクエリ

両者の意味体系を尊重することで既存 S3 アプリを壊さない

既知の制限事項

• ディレクトリリネームは高コスト（コピー＋削除の組み合わせ）
• 5,000 万オブジェクト超のバケットでは警告が表示される
• POSIX 非互換キーはファイルビューに非表示となる
• 明示的コミット制御は現時点では未実装

20 年の進化の集大成

S3 はオブジェクトストアの根幹を保ちながら
複数のアクセスパターンを同時にサポートするプラットフォームへ

• オブジェクト：既存の全ワークロードをそのまま継続
• テーブル：データレイクハウス向けのテーブル管理
• ベクトル：AI / ML 向けの埋め込みベクトル管理
• ファイル：既存ツールをそのまま使えるファイルアクセス

データをコピーせず、S3 上のデータに多様な顔を持たせる