S3 Files を「ファイルインターフェース」として見る
Amazon S3 Files が出てきて、S3 上のデータを OS からファイルシステムのように扱えるようになった。
Lambda からもマウントできるので、「これで S3 上のファイルを普通に開けるなら、いろいろ使い道が広がるのでは」と感じるのは自然だと思います。
実際、それは半分正しいと思います。
ただし、もう半分は注意が必要で、S3 Files は “S3 を DB 向けストレージに変える機能” ではなく、“S3 をファイルとして扱いやすくする機能” と理解したほうがズレにくい。
この記事では、S3 Files の魅力を正面から語るというより、まず向かないワークロードを切り分け、その上でなぜ SQLite はハマりやすいのかを整理してみる。
S3 Files の前提を仕様ベースで押さえる
S3 Files は、S3 上のオブジェクトをファイルシステムとして扱うための仕組みである。
ただし内部的には、単に「S3 がそのままローカルディスクになった」わけではない。
AWS の説明では、S3 Files はアクティブなワーキングセットだけを高性能ストレージへコピーして、ファイルアクセスの低レイテンシを実現する。
小さく頻繁にアクセスされるファイルは高性能ストレージから返し、大きな読み取りは S3 からストリーミングされる、という設計になっている。
この時点で見えてくるのは、S3 Files が提供している価値が「永続ブロックストレージ」ではなく、S3 データに対する高性能なファイルインターフェースだということだ。
さらに、同期モデルも重要である。
S3 Files では、ファイルシステム経由で書き込んだ変更は約60秒バッチしてから S3 にエクスポートされる。これは急速な連続書き込みを1回のオブジェクト更新にまとめるためで、S3 リクエスト数やバージョン増加を抑える狙いがある。
この仕様から、S3 Files は次のように理解すると整理しやすい。
- 読み取りはかなり高速化されうる
- ただしデータの本体は S3 にある
- 書き込みはローカルファイルシステム感覚の即時 S3 反映ではない
- 低レイテンシなファイルアクセスと、S3 の耐久性・容量を両立させるための仕組みである
S3 Files に向かないもの
1. 即時反映が前提のデータ
S3 Files は、書いた変更を即座に S3 API から観測する用途には向かない。
理由は明確で、書き込みは約60秒バッチされてから S3 にコピーされるからだ。
この仕様は、たとえば次のような設計と相性が悪い。
- ある処理がファイルシステム経由で書き込む
- 直後に別の処理が S3 API でそのオブジェクトを読む
- その内容がすでに反映されていることを期待する
このような設計は、S3 Files の同期モデルを理解せずに組むと噛み合わない。
「ファイルに書いた」ことと「S3 上のオブジェクトがもう更新された」ことは同義ではない、というのがまず大前提になる。
2. 細かい更新を大量に刻むワークロード
S3 Files は、連続書き込みをまとめてエクスポートするように設計されている。
つまり裏を返すと、細かい更新を高頻度で繰り返す用途では、ローカルSSD感覚の効率は期待しにくい。特に小さい I/O を大量に発生させるワークロードでは、ベストプラクティス上も注意が必要になる。
AWS のベストプラクティスでも、大きめの I/O を推奨しており、小さな I/O を大量に繰り返すワークロードは効率が落ちやすい。
さらに、ディレクトリの rename / move についても、S3 にネイティブなディレクトリ概念がないため、実際には多数のオブジェクト書き換えと削除を伴うことがある。
このため、以下のような用途は微妙になりやすい。
- 小さな差分を高頻度で上書きする状態ファイル
- 作業中の中間ファイルを何度も書き換える処理
- 1つのファイルに対して短い間隔で連続更新を入れ続ける用途
- 大量ファイルのディレクトリ移動や rename を多用する運用
S3 Files は便利だが、ローカル SSD のように「小さく速く頻繁にいじる作業場」として考えるとズレる。
3. 厳密なファイルシステム互換を前提にするソフトウェア
S3 Files は NFS ベースのファイルシステムとして高い互換性を持つ一方で、mandatory locking は未対応でロックは advisory、hard links も非対応など、一部の機能には制約がある。
そのため、ローカルディスクと完全に同じ前提で扱うのではなく、非対応機能を踏まえて設計可否を判断した方がよい。
このため、以下のような期待をそのまま載せるのは危ない。
- POSIX 的ふるまいを前提にした厳密なロック
- フル機能のローカルファイルシステムを前提にした実装
- 「普通のディスクだから当然こう動くだろう」という前提
4. 本番トランザクション DB の本体ストレージ
ここは誤解されやすい。
S3 Files を見て、「では PostgreSQL や MySQL のデータファイルを S3 に置いて運用できるのでは」と考えたくなる。
しかし、その理解はかなり危ない。
PostgreSQL は PGDATA 配下に複数のファイルやディレクトリを持ち、pg_wal を含む複数の構成要素を DB サーバープロセスが管理する。
さらに PostgreSQL の物理ストレージは、通常 8KB の固定ページを基礎にしており、単純な「1つのファイルを開く」世界ではない。
ここで重要なのは、PostgreSQL / MySQL は“ファイルに保存されるDB”ではあるが、“ファイルそのものがDB”ではないということだ。
実体はサーバープロセスがロック・ログ・整合性制御・ページ管理を含めて運用するシステムであり、単にファイルアクセスができるだけでは土台として足りない。
S3 Files 側も、ロックや同期の性質に制約があり、書き込みの S3 反映も即時ではない。
したがって、本番の OLTP 系 DB の本体ストレージとして見るのは不適切だと考えたほうがよい。
5. レコード単位の即時更新が中心の業務データ
S3 はオブジェクトストレージであって、日常的な業務レコードを1件ずつ更新していく本体のデータストアとして作られてはいない。
S3 Files が入っても、この本質は変わらない。
たとえば次のような用途は、S3 Files 上のファイルで処理したくなる気持ちはわかるが、あまり自然ではない。
- 在庫数の逐次更新
- ユーザー属性の即時更新
- 注文状態の頻繁な変更
- 複数ユーザーによる同時更新
こうした用途は、基本的には RDS / Aurora / DynamoDB のように、更新競合や低レイテンシな読み書きを前提に作られたサービスの仕事である。
6. 更新ファイル数が非常に多いワークロード
S3 Files の仕様では、エクスポート性能の目安として 1ファイルシステムあたり最大 800 files/sec が示されている。
インポート側も 最大 2,400 object changes/sec の処理能力目安がある。
この数字は決して小さくないが、逆にいえば同期能力には上限があるということでもある。
大量のファイル変更を短時間に集中させる設計では、当然ながら保留中のエクスポートが増えうる。
つまり S3 Files は、「無限に追従する魔法の同期機構」ではない。
高頻度・大量更新系のワークロードは、仕様上の上限を見ながら設計する必要がある。
S3 Files が向くもの
ここまでで向かないものを先に切った。
その上で、S3 Files がかなり気持ちよくハマる領域も見えてくる。
1. 共有参照データ
AWS も、Lambda から S3 Files をマウントする用途として shared data や large reference data files を挙げている。
つまり、大きめの辞書ファイル、参照用 CSV、モデルファイル、テンプレート、静的な補助データのような、頻繁には変わらないが複数の処理から参照したいものにはかなり向いている。
2. 永続的なファイル出力
Lambda の出力先としても相性がよい。
一時的な /tmp ではなく、処理結果をそのまま永続的な共有ファイルとして残したいとき、S3 Files の恩恵は大きい。
これはレポート生成、CSV 出力、変換済み成果物の保管、バッチ処理の出力などで特にわかりやすい。
3. 既存のファイル前提資産の移行
S3 Files の価値が一番わかりやすいのはここかもしれない。
既存コードや既存ライブラリが「ファイルパスを受け取る」ことを前提にしている場合、S3 API ベースに全面書き換えせずに済む可能性がある。
つまりこれは、新しいストレージモデルを学習するというより、既存のファイル文化を S3 の上に接続するための機能として見ると理解しやすい。
なぜ SQLite はハマるのか
S3 Files の仕様を見ると、SQLite のようなファイルを直接開くモデルのDBは、サーバープロセス前提の PostgreSQL / MySQL よりもインターフェースの恩恵を受けやすい。
SQLite は、アプリケーションが DB ファイルを直接開いて使うというモデルを取る。
つまり、S3 Files によって「S3 上のデータをファイルとして扱える」ようになると、その恩恵を非常に素直に受け取れる。
これは PostgreSQL や MySQL とは対照的である。
PostgreSQL は物理的にはファイル群に保存されるが、利用モデルとしてはあくまでサーバープロセス越しに使う DB である。
一方 SQLite は、利用モデルそのものが「ファイルを開く」なので、S3 Files のインターフェース変更がそのまま価値になる。
ただし、SQLite がハマるからといって何でもよいわけではない。
向いているのはあくまで次のようなケースだと思う。
- 小規模
- 読み取り中心
- 更新頻度が低い
- 高い同時書き込み性能を求めない
- SQLite 資産をそのまま持ち込みたい
要するに、SQLite + S3 Files は「RDB の完全代替」ではなく、ファイルDBを安価で永続化しつつ、Lambda などから扱いやすくする実装パターンと見るのがよい。
S3 Files のメリットを、向かないものから逆算して言い換える
ここまでを踏まえると、S3 Files のメリットはかなりクリアになる。
1. S3 の高い耐久性を持つデータに、ファイルとして触れられる
S3 は 11ナインの耐久性を案内している。
S3 Files は、その耐久性の高いデータを API 越しの object としてではなく、OS から扱いやすい file として見せてくれる。
2. 毎回ダウンロードして /tmp に置いて再アップロード、を減らせる
Lambda のような環境では、従来は S3 オブジェクトを取得してローカル一時領域へ置き、処理後にアップロードし直す流れが多かった。
S3 Files はその往復をかなり単純化できる。
3. 「S3 に置く意味があるファイル」を扱う体験を改善する
共有参照データ、成果物、静的資産、SQLite ファイルのように、そもそも S3 に置く意味があるものに対して、利用体験を大きく改善する。
これは API の置き換えというより、アクセスモデルの改善である。
結論
S3 Files を一言で表すなら、
「S3 を DB 化したもの」ではなく、「S3 にあるべきデータをファイルとして扱いやすくしたもの」 だと思う。
そのため、向かないものはかなりはっきりしている。
- 即時反映が必要なデータ
- 細かい更新を大量に刻むワークロード
- 厳密なローカルファイルシステム互換が必要なソフトウェア
- 本番トランザクション DB の本体
- レコード単位の即時更新が中心の業務データ
- 同期上限を超えるような大量更新系
逆に向いているのは、
- 共有参照データ
- 永続的なファイル出力
- 既存のファイル前提資産
- SQLite のようなファイル DB
である。
SQLite のようなファイル直接アクセス型DBは相性がよく、PostgreSQL や MySQL のようなサーバープロセス前提のDBとは向き・不向きが分かれやすい。
S3 Files の価値は、S3 に置く意味があるデータに対して、OS レベルの扱いやすさを持ち込んだことにある。
この線引きを先に理解しておくと、S3 Files をかなり正しく評価できる。