S3ファイル

2026年4月7日 • 6004語
写真クレジット：Ossewa

ほとんどの人は、キャリアのある時点で「大量データを一か所から別の場所へ移動させる」という非常に苛立たしいプロセスに直面したことがあるでしょう。もしそうでないなら、大きすぎるデータセットとまだ関わったことがないだけなのです。Andy Warfield にとって、そのような経験の一つは UBC（ブリティッシュ・コロンビア大学）で、驚異的な量のシーケンスデータを生成するゲノム研究者たちと共に働く際でした。彼らはそのデータが必要な場所へ届けるメカニズムに時間を無駄に費やし、何度もコピーを繰り返して不整合な複製を管理していました。科学者から機械学習モデルのトレーニングエンジニアまで、あらゆる業界で「データ転送が頭痛の種」であることは間違いありません―それこそ、顧客に提供すべき解決策です。

この記事では Andy が自分たちのチームが考案したソリューション S3 Files について語ります。苦労して得た教訓やユーモラスなエピソード、そして新しいデータ型に名前を付けようとして失敗した例なども紹介します。ぜひお楽しみください。 –W

---

パート 1：S3 の進化する姿

まずは植物学から

実際、人間よりも花のほうが多産だということが分かります。約10年前、Amazon に入社する直前に私の第二回目のスタートアップを終え、UBC に戻って教鞭を執っていました。研究経験の薄い領域を探りたいと思い、ゲノムとコンピュータシステムが交差する分野――特に生物学者がどのようにゲノム研究を行うか――について学び始めました。

結果として、UBC の植物学教授 Loren Rieseberg と共に時間を過ごすことになり、彼はサボテン DNA を研究しています。植物が乾燥や塩分の多い土壌といった厳しい環境で生き残るための特性を理解するためにゲノム解析を行っています。人間の DNA は約30億塩基対、任意の2人の人間は遺伝子レベルで99.9 % 同一です――すべての DNA が驚くほど似ています。一方、サボテンは 3.6 億塩基対と個体間の変異が10倍以上多いという事実があります。

PhD の卒業生 JS Legare がこの冒険に参加し、Loren の研究室でポスドクを終えました。彼らはワークロードをクラウドへ移行する方法を探っていました。ゲノム解析は「バースト並列」コンピューティングの例です：大量の並列計算が比較的短時間に実行されます。ラボ内でローカルハードウェアを使うと、必要な時に高速分析を行える十分な計算リソースが不足し、活発に作業していない間はコンピュート資源がアイドル状態になります。

我々の考えは S3 とサーバーレス計算を使って数万〜数十万のタスクを並列実行し、研究者が複雑な解析を非常に速く行い、終了後にはゼロにスケールダウンできるようにすることでした。生物学者は Linux 上で GATK4（Apache Spark と統合されたゲノム解析ツールキット）という分析フレームワークを使っており、全データは共有 NFS フィルタ上にありました。

S3 をクラウドへ橋渡しするため、JS は「bunnies」（別の多産ジョーク）と呼ばれるシステムを構築しました。解析をコンテナ化して S3 上で実行することで速度・再現性・パフォーマンスが大幅に向上しました。しかし、ストレージ境界で摩擦が生じました：S3 は並列性・コスト・耐久性に優れていますが、ゲノム研究者たちが使うツールはローカル Linux ファイルシステムを前提としていました。結果としてデータは永遠にコピーされ、複数の不整合な複製が管理されるという摩擦が生まれました。この S3 とファイルシステム間の手動コピーパイプラインは、メディア＆エンターテインメント、機械学習の事前トレーニング、半導体設計、科学計算など、多くの分野で繰り返し見られる課題です。データにアクセスする方法が異なるツール間で摩擦を生むと、作業自体が難しくなります。

エージェントはデータ摩擦を増幅させる

今日のソフトウェア開発ではエージェント型ツールがどれだけ影響力を持つか、私たちは皆知っています。エージェントはコードを書くのに非常に優秀で、急速に進化しているため「何を意味するか」を考える時間が増えています（Werner も同感）。一つ確かなことは、エージェント型開発がアプリケーション構築コスト――金銭・時間・実用的なスキル―に大きく変化させているという点です。ソフトウェアが存在する限り、成功したアプリはドメイン専門知識とコード作成能力の二つを結合します。エージェントは「ソフトウェアを書く障壁」が常に高いことを示し、今や多くの人がアプリを書けるようになっています――その人々は実装ではなく、アプリのドメインに深いスキルを持つ者です。

私たちはこの状況で「アイデアから稼働コードまでのサイクルタイム」が劇的に短縮されていることを目撃しています。構築コストが崩れ、各アプリは次の参考例となります。アプリは来たり行ったりしますが、データはそれらすべてより長く生きます。効果的なストレージシステムは単に安全にデータを保管するだけでなく、個々のアプリから抽象化・切り離す役割も担います。開発ペースが加速すると、この性質はこれまで以上に重要になります：データを取り付けや操作しやすいほど、新たな試作や探索が可能です。

データ管理者としての S3

ここ数年、S3 チームはこの最後の点に注力しています。S3 でデータへのアクセス方法が単純ではないケース（例えば、生物学者がツール用にデータをコピーする必要がある例）を詳細に検討し、顧客がストレージ作業に気を取られずにデータを扱える場所を広げました。

最初の教訓は構造化データでした。S3 はパーケット形式で数 EB を保存し、平均 2,500 万リクエスト/秒を処理しています。この多くは単純なパーケットか Hive テーブルとして構造化されています。顧客はこのデータをもっと活用したいと考えていました。Apache Iceberg のようなオープンテーブルフォーマットが登場し、挿入・変更・スキーマ変更・スナップショットなどの機能豊富な表抽象化を提供しました。Iceberg は S3 上でテーブル抽象化を高めましたが、オブジェクト API のみでテーブルを公開するために鋭い欠点も残っていました。

Iceberg が普及すると、顧客はセキュリティポリシー管理が難しいと訴え、テーブル保守・コンパクションを自動化したいと望みました。また Spark だけでなく他のツールでもデータを扱いたいという要望も増えていました。2024 年、re:Invent で S3 Tables を発表しました。これは管理型のファーストクラステーブルプリミティブで、Iceberg 上に構築されつつ、データ整合性・耐久性を守り、コンパクションを自動化し、クロスリージョンレプリケーションもサポートします。現在 200 万件以上のテーブルが S3 Tables に保存されています。

同時期に、S3 顧客との対話で類似検索・ベクトルインデックスについての需要が浮上しました。AI の進展は、メディアアーカイブをリアルタイム検索できるベクトルインデックス構築という機会と必要性を生み出しました。RAG（Retriever‑Augmented Generation）や未訓練データにモデルを適用する際にも同様の特性が有効です。

顧客はベクトルインデックスを構築・運用し、強力なベクトルデータベースは存在しますが、ベクトルはメモリや SSD 上で管理され、ライブインデックスとしてコンピュートクラスター上で動作するため、ストレージ観点ではあまり有効ではありません。さらに、ベクトル自体はインデックス対象データよりも多くのバイトを占め、メディアコストが高いことがあります。

そこで re:Invent で S3 Vectors を発表しました。これは S3 ネイティブなベクトルインデックス型です。パフォーマンス・コスト・耐久性は S3 オブジェクトと同等で、数百件からビリオンドのレコードへスケールアップできます。最大の強みは「常に利用可能」な API エンドポイントがあり、類似検索インデックスをサポートするという点です。

そして… S3 Files

本日は S3 Files を発表します。この新機能は Amazon Elastic File System（EFS）と S3 を統合し、既存の S3 データをネットワークアタッチドファイルシステムとして直接アクセスできるようにします。ファイルという話題は Tables や Vectors の仕事よりも長く、さらに興味深いものです――ファイルはオブジェクトストレージとクリーンに統合するのが複雑で難しいデータ型だからです。

S3 Files のアイディアは S3 Tables が登場する前から進めていました。EFS と S3 の両チームが協力し、ファイルシステム API を通じてデータを扱う既存ソフトウェア（データサイエンスツール、ビルドシステム、ログプロセッサー、構成管理、トレーニングパイプラインなど）を考慮しました。エージェント型コード生成ツールはローカルファイルシステムで直接 Unix ツールを呼び出すために素早くファイルをリストし、転送し、コピーする必要があります。

S3 Files をネイティブにサポートすると、データが即座に利用可能になり、最終的には価値が高まります。pandas で S3 データを操作したり、トレーニングジョブに指し示したり、デザインツールで対話したりする際にコピー作業は不要です。S3 Files を使えば EC2 VM、コンテナ、Lambda 関数内に任意の S3 バケットやプレフィックスをマウントでき、ファイルシステム経由でデータへアクセスできます。変更が行われれば、それらは自動的に S3 に反映されます。その結果、オブジェクトをファイルとして扱い、ファイルをオブジェクトとして扱うことが可能になります。

---

パート 2：S3 Files の設計

ビルダーは「データをファイルシステムに置くかオブジェクトストアに置くか」を早期に決めなければならず、永遠にその結果に縛られます。この選択が現在および将来のデータ操作方法を決定し、誤った選択はマイグレーションやコピー自動化レイヤー構築を余儀なくします。

初期のアイディアは「EFS と S3 を巨大なポットに入れて煮込む」だけでした。実際には設計ミーティングで数多くの技術的課題と難しい決断が浮上しました。それぞれのデータ表現（ファイルかオブジェクト）が何かを犠牲にせざるを得ない「容赦の無い妥協」の戦いでした。

そこで、最もシニアなエンジニアを集めて一晩中議論し、最終的に解決策を見つけられず放棄しました。設計が誰も満足できない結果になるのは望ましくありませんでした。

明示的境界：stage & commit

休暇から戻った時点で、ファイルとオブジェクト間の境界を「不可視」ではなく「明示的」に扱うことにしました。S3 へのファーストクラスファイルアクセスはデータ作業用プレゼンテーションレイヤーとして位置づけました。顧客はバケットやプレフィックスに対して S3 マウントを定義し、裏で EFS 名前空間が S3 メタデータをミラーリングします。この境界を通じたトランジットと一貫性は設計の中心でした。

これを stage & commit と呼び、Git のようにファイルシステム上で変更を蓄積し、一定期間ごとにまとめて S3 にプッシュします。データがどこでいつトランジットするかは顧客へ公開され、将来的に進化可能です。

境界を明示的にしたことはチームに驚きを与えました。このアプローチにより、設計上の妥協を避けつつビルダーと連携しながら改善できる道が開きました。

一貫性と原子性

S3 では完全なオブジェクト更新・通知・バージョン履歴が想定されます。ファイルシステムは細粒度変更や一括可視化（atomic rename）をサポートします。S3 条件付き操作はオブジェクトの最初の要素に対しては有効ですが、ディレクトリ移動には完全一致しません。レイヤー分離により両方のモダリティが共存できます：ファイルを変更・名前変更した後、別の時点で全体として S3 に書き込まれます。

認可

認可は難しい問題です。S3 は IAM ポリシーでキー接頭辞（例：「/private/ 以下の GetObject を拒否」）をスコープし、ネットワークやリクエストプロパティでさらに制限できます。ファイルシステムはデータ経路外で権限チェックを行い、永続的アクセスにハンドルを使用します。ファイルは inode 内に権限が存在するため、ハードリンクやディレクトリ権限が影響します。

明示的境界を採用したことで、S3 の IAM ポリシーをバックストップとして維持しつつ、各マウント内でファイルレベルの権限委譲を可能にしました。これにより S3 側でアクセスを無効化できる一方、ファイルビューで細かい制御も実現します。

名前空間意味論

ファイルシステムは「/」というパス区切りを持ち、mmap() などの OS 機能があります。オブジェクトでも「/」が提案されますが、S3 の LIST コマンドでは任意文字をデリミタに指定できます。複数の区切り文字を埋め込んだ多次元構造名を作る顧客もいます。

S3 にはディレクトリは存在しないため、「/」で終わるオブジェクトがファイルとして見えることがあります。20 分間「filerectory」という言葉を使用しましたが、最終的に採用しませんでした。

チームは境界を活かし、両方の側で既存の命名規則と意味論を維持するよう決定しました。オブジェクトまたはファイルが境界を越えられない場合、イベントを発行して顧客に監視・対処を促します。

パフォーマンス

ファイルとオブジェクトの名前空間はまったく異なる最適化対象です。ファイルシステムではメタデータへの多くのアクセスが必要で、ディレクトリレコードも頻繁に更新されます。高速ファイルシステムは同一ホスト上に全てのメタデータを共存させます。

オブジェクトネームスペースはフラットで、非常に並列なポイントクエリと更新が最適化されています。1 つの「ディレクトリ」には数十億オブジェクトが存在し、何百千ものクライアントが同時にアクセスできます。

導入を重視しました：S3 は20 年間存在しており、顧客は既存データで即座に利用できるソリューションを求めています。ほとんどのアプリはファイルとオブジェクトを同時に使用せず、多段階パイプラインで使い分けます。

したがって次の解決策を提供しました。

• ファイルビュー：NFS の close‑to‑open 一貫性を完全サポート
• オブジェクトビュー：S3 の atomic‑PUT 強一貫性を完全サポート
• 同期レイヤーで両者を接続

---

仕組み

ディレクトリに初めてアクセスすると、S3 Files は S3 からメタデータをインポートし、同期ビューを生成します。128 KB 未満のファイルはデータも取得；それより大きいファイルはメタデータのみを取得し、実際に読み取るまで S3 からフェッチされません（遅延 hydration）。これにより数百万オブジェクトがあるバケットでも即座に作業できます。

ファイルの作成・変更は集約され、約60 秒ごとに単一 PUT として S3 にコミットされます。同期は双方向で行われ、他アプリが同じバケットを変更した場合、S3 Files は自動的に検知しファイルシステムビューへ反映します。両方から同時に変更がある衝突が起きたら、S3 を真実源として lost+found ディレクトリへ移動し、CloudWatch 指標でイベントを通知します。

30 日間アクセスされていないファイルはファイルビューから除外（evicted）されますが、S3 には残るためストレージコストは作業セットに比例します。

Read bypass

高スループットの連続読み取りでは、read bypass が自動的にデータパスをリダイレクトし、並列 GET を直接 S3 に送信します。これによりクライアントあたり約 3 GB/s の性能が達成でき、複数クライアントでテラビット/秒へ拡張可能です。

---

現在の制限と今後の作業

• リネーム は S3 にネイティブな rename がないためコストが高く、プレフィックス下の全オブジェクトをコピー＆削除する必要があります。50 百万オブジェクト以上のマウントでは警告します。
• 明示的コミット制御は未実装です。60 秒間隔は多くのワークロードで十分ですが、すべてに対応できるわけではありません。
• 一部オブジェクトキーは POSIX ファイル名として無効なためファイルシステムビューには表示されません。

約 9 ヶ月間顧客ベータを実施し、これらの点について学び続けています。存在しないことを偽装するよりも、率直に共有したいと考えます。

---

ファイルとサボテン

Loren の研究室で JS がキャッシュ・命名レイヤー構築に多大な時間を費やしました。データ転送摩擦は顕著であり、私が学んだ教訓は「異なるデータ操作方法は崩すべき課題ではなく、サービスすべき現実」であるということです。

サボテンは変異に繁栄し、データアクセスパターンも同様です。S3 Files の最も魅力的な点は、ファイルとオブジェクト間の境界を明示的に設けたことです。この決定がシステム全体を改善しました。

Stage & commit は今後も進化させる余地があります：トランジット制御の細分化やパイプライン・ワークフローとの統合など。両側を妥協なく実現できる基盤として位置づけます。

20 年前、S3 はオブジェクトストアとして始まりました。Tables、Vectors、そして Files を経て、現在は「データが永続しつつ必要に応じて扱える場所」として拡張しています。私たちの目標は、ストレージシステムを作業から外すこと――周りで回避せざるを得ないものではなくなるようにすることです。まだ途中ですが、この方向性には大いにワクワクします。

Werner が言うように、「さあ、構築しろ！」