なぜフォルダがないのか

一言でいうと

オブジェクトストレージにディレクトリはありません。img/2026/logo.pngは、スラッシュを含む1つの長いキーにすぎず、その事実が拡張性の根拠です。

なぜ必要なのか

ファイルシステムはツリーです。ディレクトリごとにinodeがあり、ファイル1つを開くには、パスをたどって下りながら、各段階の権限と存在を確認します。この構造は、ローカルディスクでは優れています。ところが、ノード100台にまたがってファイル100億個を置こうとすると、問題になります。ツリーの上位ノードがすべてのアクセスの競合点になり、ディレクトリ1つにファイルを100万個入れると、lsが数分かかります。

オブジェクトストレージは、ツリーを捨てます。フラットなキーバリュー空間だけがあります。キーはただの文字列で、スラッシュに特別な意味はありません。aws s3 lsやコンソールがフォルダーのように見せているのは、プレフィックスでグルーピングした画面にすぎません。

この単純化が何をもたらすかというと、キーをハッシュして、どのノードに置くかを決められます。中央のディレクトリサーバーが不要で、ノードを追加すると、容量とスループットが一緒に増えます。

どう動くのか

その代わり、手放すものも明確です。

1つ目は、部分的な修正がないことです。オブジェクトは、まるごと書くか、まるごと読みます。1GBのファイルの真ん中の1バイトを変えるには、1GBをもう一度アップロードしなければなりません。そのため、ログファイルのように追記し続けるデータには向きません。

2つ目は、名前の変更がないことです。名前の変更は、コピーして削除することです。img/プレフィックスをimages/に変えるには、その下のすべてのオブジェクトをコピーして、削除する必要があります。プレフィックスの設計を最初にきちんと行う必要がある理由です。

3つ目は、POSIXセマンティクスがないことです。ファイルロック、ハードリンク、原子的な名前の変更のようなものがありません。データベースファイルをオブジェクトストレージに置いてはいけない理由です。

4つ目は、一覧の取得が高くつくことです。プレフィックスベースの一覧は可能ですが、「サイズが1MB以上のもの」や「昨日変更されたもの」を探すには、すべてを走査する必要があります。メタデータの検索が必要なら、別にインデックスを置きます。

現場での姿

プレフィックスの設計でよくあるミスが、日付を先頭に置くことです。2026-08-20/user/...にすると、その日に入ってくるすべての書き込みが、同じプレフィックスの範囲に集中します。パーティショニングがキーの順序に基づく実装では、これがホットスポットになります。先頭に、散らばる値(ユーザーIDのハッシュの最初の2文字など)を置くほうが安全です。

そして、オブジェクトストレージに本当に合うワークロードを覚えておくとよいです。一度書いて、何度も読む、大きくて不変なデータです。画像、動画、バックアップ、学習データセット、ビルド成果物。逆に、頻繁に部分修正される小さなデータは、データベースが合っています。

ファイルシステムのように使うと起きること

S3にはディレクトリがなく、キーが長い文字列にすぎません。/は、画面がツリーのように見せるために使う慣習です。この違いが、実務で3つの形で現れます。

名前の変更がありません。mvはコピー + 削除です。100GBのディレクトリの名前を変えると、100GBをコピーして削除します。そのため、キーの設計を最初にきちんとする必要があります。

空のディレクトリがありません。中のオブジェクトをすべて消すと、その「フォルダー」は消えます。s3://bucket/logs/を作っておくことは、0バイトのオブジェクトを作ることにすぎません。

一覧の取得が高くつきます。LISTは1,000個ずつページで返ってきます。オブジェクトが100万個なら、1,000回の往復です。ファイルシステムのlsを思い浮かべて、リクエストのたびに一覧を呼び出すと、コストとレイテンシが一緒に上がります。

キーを設計する方法

昔は「先頭部分をランダムに散らさないと性能が出ない」と言われましたが、今はS3がプレフィックス単位で自動的に分割するので、読みやすい順序にしておくほうがよいです。

logs/2026/09/06/api/instance-42.jsonl.gz
  │    └ 시간 계층 — 수명주기 규칙과 부분 조회에 유리
  └ 종류

❌ 2026-09-06-api-instance-42.jsonl.gz    ← 접두로 못 자른다

時間を階層にしておけば、logs/2026/09/だけを消したり、その月だけを安い等級に移したりするルールを、簡単に書けます。逆に、1行にくっつけると、プレフィックスの条件を作れません。

いつファイルシステムが合うか

オブジェクトストレージが、いつでも答えとは限りません。

	オブジェクトストレージ	ファイルシステム(NFS・EFS)
部分的な修正	不可(全体の再アップロード)	可能
名前の変更	コピー+削除	即座
ロック	なし	あり
POSIXセマンティクス	なし	あり
拡張性	事実上無限	限界がある
単価	安い	数倍高い

既存のアプリケーションがファイルを部分修正したり、ロックを使ったりするなら、オブジェクトストレージにそのまま移せません。s3fsのようなツールでマウントすることはできますが、部分修正が全体の再アップロードになり、ロックは真似にすぎないので、性能も整合性も悪くなります。

書いたあとに変えないもの(ログ・画像・バックアップ・モデルの重み)はオブジェクトストレージが合っていて、絶えず直すもの(作業ディレクトリ・DBファイル)は合っていません。

次のラボですること

ローカルのS3互換サーバーにエイリアスを付けて、バケットを作り、オブジェクトをアップロードし、プレフィックスで整理します。ETagが何なのかを、ローカルのmd5と比べて確認し、サーバーサイドコピーとContent-Typeの指定まで扱ってみます。