Haystackモデルとマスター・ボリューム・ファイラ

一言でいうと

SeaweedFSは、小さなファイル数百万個を、いくつかの大きなコンテナファイルにパッキングします。ファイルの数だけのinodeも、ファイルの数だけのメタデータ参照もありません。

なぜ必要なのか

サムネイル100万個をファイルシステムに置くと何が起きるか、経験した人は多いでしょう。ディスクの使用量はわずかなのにinodeが枯渇し、lsが何分もかかり、バックアップツールがファイル1つ1つをstatするのに何日も使います。4KBのファイル100万個は、データとしては4GBですが、ファイルシステムにとっては100万個のメタデータエントリです。

オブジェクトストレージが、これをすべて解決するわけでもありません。オブジェクトごとにメタデータのレコードができ、リクエストもオブジェクト単位でかかるので、個数がそのままコストであり、負荷になります。

SeaweedFSは、Facebookのホワイトペーパー(Haystack)に由来するアプローチを使います。小さなファイルを大きなボリュームファイルの中に続けて書き、位置(オフセットと長さ)だけを記憶します。ファイル1,000個が、ボリュームファイル1つに入れば、inodeは1つで、読み取りはオフセットへのシーク1回です。

どう動くのか

3種類のデーモンがあります。

マスター(デフォルトは9333)は、ボリュームの配置だけを管理します。どのボリュームがどのボリュームサーバーにあるか、新しいファイルをどこに書くかを決めます。ファイルのメタデータは持っていないという点が重要です。だから、マスターがボトルネックになりません。

ボリュームサーバー(デフォルトは8080番台)は、実際のデータを持ちます。ボリュームファイル(.dat)とインデックス(.idx)を1組にして置き、ファイルIDでオフセットを探して読みます。

ファイラー(デフォルトは8888)は、その上にディレクトリ構造とPOSIX属性を載せる、別のステートレスなサーバーです。パスベースで書いたり読んだりしたいときは、ファイラーを経由します。S3ゲートウェイも、この上にあります。

基本の流れは、こうです。マスターに/dir/assignをリクエストして、ファイルID(例: 3,01637037d6)とボリュームサーバーのアドレスを受け取り、そのサーバーにファイルをアップロードします。読むときは、/dir/lookupでボリュームの位置を探し、そのサーバーから受け取ります。この2つのステップがSeaweedFSの核心で、ファイラーとS3ゲートウェイは、その上の利便性のための層です。

現場での姿

選択の基準を率直に整理すると、こうなります。小さなファイルが大量にあり、個数がそのまま問題なら、SeaweedFSが強いです。大きなファイルが中心で、S3 APIさえあればよい小規模なら、Garageのような軽い選択肢のほうが向いています。組織の規模が大きく、ストレージチームがあるなら、Ceph RGWが検証済みの選択です。

リスクも、正直に見る必要があります。SeaweedFSは、リリースが最も活発な部類ですが、コミットの集中度が高いです。創始者のコミットは9,968個で、2位(530個)とは桁が違います。プロジェクトが死にかけているという意味ではなく、バスファクターへの懸念が正当であるという意味です。

そして、この判断が実際に必要になった背景があります。MinIOコミュニティエディションは、2025年5月に機能が縮小され、9月から10月に配布が中止され、12月にメンテナンスモードに入り、2026年3月から7月にかけて、リポジトリが順次アーカイブされました。ライセンスは最後までAGPLv3でしたが、high等級のCVEの修正が公式イメージには来ない形で、移行コストがユーザーに転嫁されました。教訓は「MinIOが悪かった」ではなく、単一のベンダーがCLAを握るオープンソースのインフラでは、そのベンダーの事業転換がそのままプロジェクトの運命になる、ということです。データが物理的に居座る層では、このリスクが、移行コストに直結します。

ボリュームがいっぱいになると何が起きるのか

小さなファイルを大きなボリュームに詰める構造には、その構造に固有の運用項目がついてきます。その中で最初にぶつかるのが、ボリューム数とサイズの上限です。

ボリュームサーバーは、ボリュームを無限には作りません。最大数と、ボリューム1つのサイズの上限が決まっていて、書き込めるボリュームが1つもなければ、アップロードはすべて失敗します。このときの症状が厄介で、ディスクには余裕があり、サーバーも生きているので、「なぜ動かないのか」という状態がしばらく続きます。マスターが返す配置情報で、書き込めるボリュームが空になっていないかを見るのが、診断の近道です。上限は、サーバーを立ち上げるときに決める値なので、容量計画では、ディスクのサイズと一緒に、この2つの値も決めておく必要があります。

削除した場所は、すぐには戻りません。ファイルを削除すると、インデックスからは外れますが、ボリュームファイルの中のその場所は、そのまま残ります。回収するには、ボリュームを圧縮する作業を回す必要があり、その間、そのボリュームは読み取り専用になります。そのため、削除が多いワークロードでは、圧縮をいつ回すかが、実際の使用量を決めます。

レプリケーションは、ボリューム単位です。ファイルごとにコピーの数を決めるのではなく、ボリュームを作るときに、そのボリュームのレプリケーション方式が決まるので、あとで変えるには、新しい設定のボリュームを作って移す必要があります。最初に決めるときに、慎重になるべき値です。

そして、ファイラーのメタデータが別のストレージにあることを、忘れてはいけません。ボリュームのデータをバックアップしても、ファイラーのデータベースを一緒に取らないと、パス構造がそっくり消えて、データはあるのにどのファイルが何なのか分からない状態になります。バックアップ計画には、常に2つが一緒に入っている必要があり、復旧テストも、2つを一緒に復元して行います。

次のラボですること

マスター、ボリューム、ファイラーを自分で立ち上げ、ファイルIDを発行してもらってアップロードし、参照します。小さなファイルを500個入れて、ボリュームファイルの数を確認し、最後のラボで、同じコーパスをファイルシステム、S3、SeaweedFSの3か所に入れて、特性を数字で比較します。