ハクソク

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

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

2025年9月18日原文(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以上の金融商品に対する価格予測を出す統計モデル」がそんなにストレージを必要とするのか、知りたいな。

Hacker Newsで議論の続きを見る