ハクソク

世界を動かす技術を、日本語で。

TernFS – エクサバイト規模のマルチリージョン分散ファイルシステム

249日前原文(xtxmarkets.com)

概要

  • XTX Marketsは、全世界で50,000以上の金融商品を取引する アルゴリズム取引企業。
  • ストレージ拡張の課題から独自分散ファイルシステム TernFS を開発し、オープンソースとして公開。
  • TernFSは 高いスケーラビリティ ・冗長性・ハードウェア非依存性を実現。
  • アーキテクチャはメタデータシャード、CDC、ブロックサービス、レジストリから構成。
  • 2025年9月時点で500PB超のデータを3拠点で運用中、データ損失ゼロを継続。

TernFS開発の背景と目的

  • XTX Marketsは 統計モデルによる価格予測 と取引を行う金融テック企業。
  • 機械学習研究の拡大とともに 計算資源とストレージ需要が急増。
  • NFSや既存ファイルシステムの限界を超え、 独自分散ファイルシステム の開発を決定。
  • TernFSは あらゆるストレージ用途 に対応し、GPUジョブ間通信や生データ保存にも利用。
  • オープンソース としてGitHubで無償公開。

TernFSの特徴

  • エクサバイト級まで拡張可能、数兆ファイル・数百万クライアント対応。
  • 冗長保存 によるドライブ障害耐性。
  • メタデータサービスに単一障害点なし。
  • スナップショット機能 で誤削除対策。
  • マルチリージョン対応、ハードウェア非依存、TCP/IP通信。
  • 多様なストレージ媒体 （フラッシュ・HDD）をコスト効率的に活用。
  • 独自APIとLinuxカーネルモジュール で読み書き可能。
  • 外部サービス不要・ビルド依存最小限 （C++/Go・一部ベンダーライブラリのみ）。

制約事項

  • ファイルはイミュータブル （書き込み後変更不可）。
  • 小ファイル非推奨 （中央値2MB）。
  • ディレクトリ作成・削除はスループット制約あり。
  • パーミッション管理なし （外部サービス依存）。

TernFSの運用実績

  • 2023年夏に本番運用開始、2024年中頃には 全機械学習ワークロードをTernFSに移行。
  • 2025年9月時点で、 30,000台のディスク・10,000台のフラッシュ・3データセンターで500PB以上 を管理。
  • ピーク時に 秒間数TBのスループット を達成、 データ損失ゼロ。

TernFSアーキテクチャ概要

  • 4つの主要サービス で構成
    • メタデータシャード ：ディレクトリ構造・メタデータ管理
    • CDC（クロスディレクトリコーディネータ） ：シャード間トランザクション
    • ブロックサービス ：ファイル内容の保存
    • レジストリ ：サービス情報・監視

メタデータ管理

  • メタデータ＝ファイル内容以外の全情報 （ディレクトリエントリ、属性、ブロックマッピングなど）。
  • 256論理シャード に分割、各シャードは リーダー＋4フォロワー の5レプリカ構成。
  • LogsDB（Raftライク）＋RocksDB で分散合意・永続化。
  • クライアントはリーダーのみと通信 （フォロワーへの拡張も容易）。
  • ディレクトリ単位でシャード割り当て、ラウンドロビン方式。

クロスディレクトリトランザクション

  • CDCが他シャード間の操作を調整 （ディレクトリ作成・削除・移動など）。
  • CDCも5レプリカ構成、RocksDB/LogsDBで状態管理。
  • CDC経由の操作はスループット制約あり （1万req/s程度）。

ブロックサービス

  • ファイルはブロック単位で分割保存。
  • 1ブロックサービス＝1ドライブ （HDD/フラッシュ）。
  • GoプロセスによるTCP APIでアクセス、ハードウェア非依存。
  • 高密度サーバーで数十～百台のドライブを管理。

レジストリ

  • 全サービスインスタンスのロケーション管理。
  • クライアントはレジストリから情報取得しTernFSをマウント。
  • 全アドレスはIPv4で管理 （カーネルモジュールの簡素化）。
  • RocksDB/LogsDBによるC++プロセスで運用。

まとめ

  • TernFSはXTX Marketsの 急速な成長と多様なストレージ要件 を支える分散ファイルシステム。
  • 高スケーラビリティ・冗長性・柔軟性 を持ち、オープンソースとして公開。
  • 実運用での高信頼性・高性能 を実証済み。
  • 詳細や導入方法は GitHubのREADME 参照。

Hackerたちの意見

いいプロジェクトだね、オープンソースにしてくれてありがとう。ただし、注意すべき制限があるよ。> 「TernFSは小さなファイルには使わない方がいい — 中央のファイルサイズは2MBだよ。」

└

うん、俺も最初にそれをチェックしたよ。小さいファイルに適してるのはSeaweedFSの大きな利点だね。

└

じゃあ、小さなファイルを入れたらどうなるの？パフォーマンスが悪くなる？ファイルが壊れる可能性もあるの？

└

エクサバイト規模のストレージエンジンに取り組んできたよ。こういう制限には良いエンジニアリングの理由があるんだ。もし平均ファイルサイズが1KiBだとしたら、クワドリリオンのメタデータオブジェクトを迅速に検索・管理する必要がある。メタデータに関する操作や調整を信頼性高く行うのは、メタデータ構造自体が何PBもあると難しいんだ。ストレージからこのメタデータを深くページングする必要があると、興味深いエッジケースが出てくる。これを遅くしないためには、独特で異常な設計選択が必要で、複雑さが増す。ほとんどのメタデータはメモリに収まらないし、常にメモリに収まると思われる従来のアーキテクチャの多くもそうだ。単なる1兆のオブジェクトが、アロケータやメタデータなどがスケールする限界に近い。従来のアーキテクチャが崩壊し、ソフトウェア設計が奇妙になり始める前に、英雄的な努力が必要なんだ。ストレージエンジンは信頼性が必要だから、こういう設計の境界を避けるのは理にかなってる。これを破ることは可能だけど、文献がほとんどない多くの興味深い設計やコンピュータサイエンスの問題を引き起こすんだ。

└

ちょっと宣伝させて！ https://github.com/Barre/ZeroFS これは、数十億の小さなファイルを保存する必要があったユースケースのために最初に開発したもので、インフラとしては単一のS3バケットだけで済むんだ。

└

…これで「他のいわゆるエクサスケールファイルシステムと同じ」という位置づけが確定したね。GPFSもあったし…。

TernFSはCephFSとどう違うの？それに、CephFSもペタバイト規模でテストされてるのに、なんでCephFSじゃないの？

└

（免責事項：私はTernFSの著者の一人で、Cephを評価したことはあるけど、詳しくは知らないよ）主な要因は以下の通り。* Cephはメタデータとファイル内容を同じオブジェクトストア（RADOS）で保存するけど、TernFSはメタデータ用に特化したデータベースを使っていて、我々のデータセットの特性（不変ファイル、ディレクトリ間の移動が少ないなど）を活かしている。* CephはPBを保存できるけど、現在TernFSでは約600PBを一つのデプロイメントで保存している。前回チェックしたときは、これが非常に大きなCephのデプロイメントよりも桁違いに多かった。* 一般的に言うと、我々はニーズに簡単に適応できて、何か問題が起きたときにすぐに修正できるシステムを求めていた。Ceph（または他のオープンソースソリューション）を適応させるよりも、新しいものを構築する方が全体的にコストが低いと見積もったんだ。

└

シームレスなリアルタイムの大陸間レプリケーションは、我々にとって重要な機能で、多分最も重要な機能だと思う。AFAIK、Cephではそれができないんだよね（たとえCephが元々の10エクサバイトの目標に1つのインスタンスでスケールできたとしても）。

└

CephFSは（完全に？）POSIXファイルシステムを実装している一方で、TernFSはスケールを優先するために権限や可変性を犠牲にしているようだね。彼らのドキュメントにはカスタムカーネルモジュールがあるって書いてあったけど、今は（今日）ツリー外で出荷されてるんじゃないかな。Cephはツリー内で、FUSE実装もある。ドキュメントによると、TernFSは独自のS3ゲートウェイも持っているけど、RADOSGWはCephFSとは完全に別物らしい。

└

Cephは高性能にはあまり向いてないよね。まだ若いし、思ったよりも複雑だし（つまり、ブロックストレージシステムがあって、その上にファイルシステムのレイヤーを乗せる必要がある）。パフォーマンスを重視するなら、LustreとかGPFS、もしお金があるなら大規模なIsilonシステムがいいかも。

500PB以上のデータ、すごいね。どうして「世界中の50,000以上の金融商品に対する価格予測を出す統計モデル」がそんなにストレージを必要とするのか、知りたいな。

└

私もそう思う。XTXが実際に何をしているのか、理解するのが本当に難しい。トレーディング？VC？AI/ML？彼らのポートフォリオ見たことある？PS: 会社は信頼できそう。成長もすごいけど、やっぱり何をやってるのかは分からない。「電子的流動性」を提供してるって…うーん。

└

大量の金融商品に対してすべてのオーダーブックの変更を保持していると、すぐにボリュームが増えていくよね。

いい読み物だった。シェフたちに感謝！高レベルの概要セクションの後に、ファイル作成や検索、読み取りといった一般的な操作の使用例がいくつかあると助かるな。サービスレベルで何が起こるのか、イメージがつくから。

└

そうだね、すごく役立つと思う。実際にはそこまで手が回らなかったし、完璧を求めるあまり良いものを逃したくなかったからね。もし時間があれば、ドキュメントに追加するのは絶対に良いアイデアだよ。

ほとんどのメタデータの活動は単一のシャード内に収まっている: > > - ファイル作成、同ディレクトリ内の名前変更、削除。 > - ディレクトリの内容をリストする。 > - ファイルやディレクトリの属性を取得する。ファイルシステムとオブジェクトストアのトレードオフだと思う？S3のように、ListObjects()は重い処理で、任意のプレフィックスの下には数十億のオブジェクトが存在する可能性がある。単一のインスタンスでスキャンするだけでは不十分だね。

└

確かに異なるユースケースだけど、フォロワーレプリカをスケールのために使っていないってことは、かなり効率的で軽量なんだろうね。ACLがないのも助けてると思う。最低2MBのサイズを指定しているから、ちっちゃいバイトのエクサバイトは期待できないね。オブジェクトストレージでプレフィックスをリストするのと、ファイルシステムで再帰的にリストするのの違いが大きいのかな？S3でも、プレフィックスに対して非常に大きなリストを作成するのは遅いし、小さなファイルは常に扱いづらいから、定期的なコンパクションやファイル名のキャッチは通常価値があるよね。

Hudson River Tradingの分散ファイルシステムについての比較: https://www.hudsonrivertrading.com/hrtbeat/distributed-files...

└

いいね！あと、DeepSeekの3FSも面白いよ。これは中国のHFT企業High-Flyerから出てきたもの。

なんか、ファイルシステムの表面を持ったオブジェクトシステム（不変）って感じだね。ドキュメントをちょっと読んだけど、データは複製されていて、消去符号化はされてないみたい（だから、もしかしたらコストが高いかも？）。多くの人が言ってるけど、上書きや追加、切り詰めとかを気にしなくていいなら「ファイルシステム」はずっと楽になるよね。まあ、どんなユースケースに対して人々が何を考えているのかを見るのはいつも面白い。

└

ブログ記事に書いてある通り、リード・ソロモン符号は使ってるよ。

└

アペンドオンリーは、大規模な堅牢なレプリケートストレージを実現する唯一の方法に近いね。そうじゃないと、特定の論理ブロックが二つの状態（どこかに存在するか、どこにも存在しないか）を持つ代わりに、異なる時間に異なる値を持つことができるシナリオに入ってしまう。例えば、クライアントがブロックの変更の途中で死んでしまった場合など。イミュータビリティは非常に強力な不変条件だよね。それに、これを基にリード・ライトレイヤーを実装することも全く妨げない。例えば、ログ構造のFS設計でね。でも、どうやらこの人たちはその問題を抱えていないみたい。

著者の方がいたら、いくつか質問があります！ > ハードウェアに依存せず、TCP/IPを使って通信するってことは、RDMAは使ってないの？ 現代のNVMeドライブの帯域幅をTCP/IPで効果的に使うのはとても難しいよね。 > 論理シャードは通常の分散合意セットアップで、1つのリーダーと4つのフォロワーに分割される。分散合意エンジンは、LogsDB Raft-likeって呼んでる目的特化型のRaft風実装によって提供されてるけど、これはRaftじゃなくてカスタムアルゴリズム？ 分散合意をゼロから正しく実装するのはすごく難しいから、戦闘実績のある実装を使った方がいいんじゃない？ > ブロックサービスへの読み書きアクセスは、現在Goプロセスによって実装されたシンプルなTCP APIを使って提供されてる。このプロセスはハードウェアに依存せず、Goの標準ライブラリを使ってブロックを従来のローカルファイルシステムに読み書きしてる。元々はGoプロセスをC++で書き直して、ブロックデバイスに直接書き込む予定だったけど、イディオマティックなGo実装が今のところ私たちのニーズには十分なパフォーマンスを示してる。ドキュメントにはTB/sを目指して設計されてるって書いてあるけど、IO集中的なワークロードの場合、ドライブの帯域幅を無駄にしてしまって、多くのノードが必要になるかも。現代の並列ファイルシステムは、RDMAやDPDKを使ってノードごとに80-90GB/sに達することができる。 > これは、各接続が非常に状態を持ち、オープンファイルやロックなどのリソースを保持するNFSのようなプロトコルとは対照的だね。NFSv3以前はそうじゃなくて、状態を持たない（オープンファイルの概念がない）。これがどのように開発され、テストされたのかについての言及はないけど、何か形式的な手法やシミュレーター、カオスエンジニアリングなどを使ってるの？

└

ちょっと興味があって聞いてみたんだけど、あなたはここに詳しそうだね。パブリッククラウド（例えばAWS）でRDMAを使ってNVMeを実現することは可能なの？最近これについて調べたけど、私の結論は「無理」だったけど、間違ってたら嬉しいな :)

└

それに、複数のクラウドやオンプレミスで実装された大規模な分散システムが必要で、ノードの故障、交換、拡張、収縮、バックアップ/復元、修理/検証、インストールガイド、エラーの「動物園」みたいな手順が戦闘テスト済みである必要がある。さらに、ジェプセンテストスイートや詳細なCAPトレードオフの説明も必要だよね。FAANGの大きなDFSが他の場所で実装されていない理由があるんだ。元の著者たちが大規模で経験豊富なインフラチームを持っている必要があるから。

└

RDMAは使ってないの？うちのシンプルなGoブロックサーバーは、sendfileを使ってるから、フラッシュボックスのネットワークインターフェースを飽和させることができるよ。RDMAに切り替えるのは簡単だけど（ただのトランスポート層の変更だから）、今のところ必要ないんだ。ここではいくつかの難しい優先順位決定をしなければならなかった。PRは歓迎だよ！ > 分散コンセンサスをゼロから正しく実装するのは非常に難しいから、戦闘テスト済みの実装を使わない理由はないよね？私たちはこういうものを作るのに慣れているし、取引システムは共有状態で動作する巨大な分散システムで、毎秒何百万もの更新がある。今は自動フェイルオーバーは有効にしていないけど、故障は稀だし、ジェプセン後にそれを有効にするつもり。誰かの実装を使ったら、非プライマリ地域のレイテンシを均等化するために必要なマルチマスターのことができなくなる。 > NFSv3やそれ以前のバージョンには当てはまらないけど、ステートレス（オープンファイルの概念がない）傾向がある。NFSv3でも、リクエストが冪等でないから、重複リクエストキャッシュが必要なんだ。すべてのリクエストの冪等性を達成するのは難しいけど、達成できれば報われるよ。

すべての主要なテック企業が独自の分散ファイルシステムを開発している理由があるんだよね。FAANGでは働いたことないけど、これはよく知られた事実なの？聞いたことないな。S3みたいなものを指してるの？これらの大企業は文字通りカスタムファイルシステムを実装してるの？

└

みんなの意見は分からないけど、多分そうだと思う。個人的には、耐久性とレプリケーションがキラー機能だと思う。データ損失を気にしないなら、シングルディスクでも使えるけど、データをレプリケートし始めると、分散ファイルシステムが必要になるよね。テクトニックはFacebookのもので、Googleのはコロッサス。ほかのはよく分からないな。

└

僕が働いているところについてだけコメントできるけど、はい。ある程度は公に議論されているよ。 https://cloud.google.com/blog/products/storage-data-transfer...

└

そうだね、少なくともFacebookとGoogleは分散ファイルサービスを持ってるよ。（Facebookのは歴史的にHDFSに基づいていて、これは古いGoogleの論文に基づいている。）

別の分散ファイルシステムがオープンソースになったのを見るのは素晴らしい！面白い設計の決定がいくつかあるね。いくつか質問があるんだけど： - こういうシステムのスループットやレイテンシをどうやってベンチマークするの？他の分散ファイルシステムがシステムをベンチマークする方法と違うのかな？ - ノードのボトルネックはネットワークそれともストレージ（少なくともスループットに関して）？ - RDMAベースの分散ファイルシステムからの観察では、ネットワークがボトルネックのように見える。 - システムはランダム/シーケンシャルなリード/ライトにどう反応するの？多くのシステムはライトのスケールに苦労している。これはTernFSが設計されているワークロードに影響するのかな？ - FUSEを使う代わりにカーネルモジュールを書く道を選ぶのは非常に興味深いね（3FS [1]を参照）。 - 本番環境でクラッシュはあった？それを追跡するのはどうしてるの？ - カーネルモジュールを使うのとFUSEを使うのとでパフォーマンスにどんな違いがあるの？ [1] https://github.com/deepseek-ai/3FS/blob/main/docs/design_not...