ZeroFS: S3 互換ストレージ向けのログ構造ファイルシステム
ZeroFS: S3 互換ストレージ向けのログ構造ファイルシステム
ZeroFS は S3 互換オブジェクトストレージを、利用可能な POSIX ファイルシステムまたは生のブロックデバイスへと変換します。ログ構造エンジンを利用することで、ZeroFS はクラウドバケットをプライマリストレージとして扱えるようにし、オブジェクトストレージのスケーラビリティと従来のファイルシステムが要求するインターフェースとの橋渡しを実現します。
アーキテクチャとストレージエンジン
ZeroFS はログ構造アプローチを用いて S3 互換バケット内のデータを管理します。データをその場で上書きする代わりに、書き込みは不変オブジェクトとして扱われ、コンパクションプロセスが削除されたデータから領域を回収します。
エンジンの主な技術的特性は次のとおりです。
- 不変セグメント: ファイルデータは 32 KiB のエクステントに分割され、不変セグメントオブジェクトとして格納されます。別途メタデータインデックスがこれらのエクステントを追跡し、チェックポイントやリードレプリカがバケットの一貫したビューを維持できるようにします。
- 暗号化と圧縮: すべてのデータはアップロード前に XChaCha20-Poly1305 で暗号化されます。データキーは Argon2id で導出されたパスワードからラップされます。暗号化前にデータは zstd または lz4 で圧縮され、読み取り時にコーデックが検出されるため、データ移行なしで圧縮設定を変更できます。
- キャッシュ: S3 の往復遅延(通常 50〜300 ms)を緩和するため、ZeroFS は設定可能なメモリおよびディスクキャッシュを実装しています。これらのキャッシュからのウォームリードはマイクロ秒単位で返されます。
- TRIM サポート: ファイルシステムや ZFS プールからの discard コマンドは対応するエクステントを解放します。その後コンパクションがライブデータを再パックし、空のセグメントを S3 から削除してストレージコストを削減します。
アクセスプロトコルとインターフェース
ZeroFS はストレージバックエンドとやり取りするための 3 つの主要手段を提供し、すべて単一のユーザースペースプロセス内で動作します。
POSIX ファイルシステム (NFS と 9P)
- NFS: macOS、Linux、Windows、BSD など主要 OS からネイティブ NFS サポートを利用してマウントでき、クライアント側ソフトウェアは不要です。
- 9P: NFS よりも POSIX セマンティクスに近い動作を提供します。バンドルされた FUSE クライアントを含み、ルート権限なしでのマウントや自動再接続をサポートします。
生ブロックデバイス (NBD)
- NBD (Network Block Device): バケットを生ブロックデバイスとして提供します。これらのデバイス上に ext4 ファイルシステム、ZFS プール、または VM のブートディスクを配置できます。新しいデバイスはサーバー再起動なしで実行時に追加可能です。
高可用性とデータ整合性
ZeroFS は耐久性と一貫性を確保するために複数の機能を実装しています。
- 正直な fsync: 成功した
fsyncは、すべての確認済み書き込みが S3 に永続化されたことを保証します。フェイルオーバーが発生しフラッシュされていない書き込みが失われた場合、続くfsyncは偽の成功ではなくエラーを返します。 - 高可用性 (HA): オプションのスタンバイインスタンスが同じバケットを介してリーダーを追跡します。スタンバイはリーダーが確認したがまだフラッシュされていない書き込みを保持し、フェイルオーバー時に自動的に引き継いでそれらの書き込みを保持します。
- チェックポイント: 名前付きチェックポイントにより、特定の時点でファイルシステムをキャプチャし、読み取り専用で開くことができます。
- リードレプリカ: 複数の読み取り専用インスタンスが同一バケットを提供でき、単一ライターによる変更を自動的に取得します。
検証とテスト
ZeroFS はその安定性とパフォーマンスを検証するために、広範な公開 CI パイプラインを利用しています。
- POSIX 準拠:
pjdfstestスイートをすべての変更に対して実行し、権限、所有権、リンク、リネーム動作を検証します。 - カーネル検証:
xfstestsスイート(ext4 と XFS の検証に使用)を NFS、9P、FUSE で実行します。 - エンドツーエンド ZFS テスト: CI は ZeroFS ブロックデバイス上に ZFS プールを構築し、Linux カーネルソースツリーを抽出してフルスクラブを実行し、チェックサムエラーがないことを確認します。
- ストレステスト:
stress-ngと並列 Linux カーネルコンパイル (make -j$(nproc)) を使用してシステムをテストします。 - モデルベースチェック: Jepsen の
local-fsスイートを用いて、ランダム操作履歴に対するファイルシステムモデルを検証し、クラッシュリカバリテストも行います。
コミュニティの見解と反論
プロジェクトは高度な技術的野心を示す一方で、Hacker News のコミュニティディスカッションではいくつかの注意点が指摘されています。
- レイテンシの懸念: 一部のユーザーは、サブミリ秒の書き込み主張は誤解を招くと指摘しています。測定対象はネットワークやカーネルのレイテンシであり、データが S3 に永続化されるまでの時間ではない可能性が高いからです。
"The sub-millisecond writes with data in S3 is false and impossible. If you look at the benchmark the fsync is not timed, so this is just the latency of either the network or in kernel file operations..."
抽象化のオーバーヘッド: 批評家は、オブジェクトストアをファイルシステムで抽象化することは、オブジェクトストアとファイルシステムの動作差により本質的に非効率であると指摘しています。アプリケーションを「オブジェクトストア対応」にする方が良いという意見もあります。
パフォーマンス vs. Ceph: 一部のユーザーは、ローカル S3 環境では ZeroFS のパフォーマンスが Ceph などの代替手段に比べて大幅に低く、特に小規模 I/O 操作で顕著であると主張しています。
メタデータ管理: フェイルオーバー時のメタデータ取り扱いについて疑問が呈され、HA を簡素化するためにメタデータがバケット内に完全に格納されているかどうかが議論されています。