YaFF とは何か—Protobuf との関係性
YaFF(Yet another Flat Format)は、Yandex が開発した高性能 C++ シリアライゼーションライブラリです。GitHub で公開されており、Apache 2.0 ライセンス下で自由に使用できます。
重要な点として、YaFF は Protobuf の「置き換え」ではなく、Protobuf メッセージ向けの代替ワイヤフォーマットです。既存の .proto ファイルはそのまま利用でき、スキーマの定義が変わることはありません。変わるのは、メモリ内でのデータレイアウトだけです。
.proto ファイルは単一の情報源として機能したまま、物理的なメモリレイアウトのみが変更される。
実装の観点では、YaFF は Protobuf 互換の C++ API を生成し、バッファからのフィールド読み込みに解析ステップを不要にします。その一方で、解析速度が重要でない部分のコードは従来どおり Protobuf メッセージに変換できるため、段階的な導入が現実的になります。
既存ソリューションとの違い—なぜ YaFF が必要か
本来、Protobuf のような テキストベースのシリアライゼーション形式には、解析コストが付きものです。特に大規模なバックエンドシステムでは、この解析処理が CPU 時間の 10% を超えることもあります。出典: MarkTechPost
ゼロコピーを実現する既存オプションとしては、Google が提供する FlatBuffers が知られています。しかし FlatBuffers には大きな課題があります:
- Protobuf と完全互換ではなく、別途スキーマ管理が必要
- スキーマ進化ルールが Protobuf と異なる
- フィールド変換レイヤーをハンドコーディングする必要がある
多くのチームは、この移行コストが見合わないと判断しています。YaFF が狙うのはまさにそのギャップ—Protobuf の意味論を保ちながら、ゼロコピー読み込みを実現することです。
YaFF の 4 つのレイアウトと性能トレードオフ
YaFF の重要な特徴は、4 種類の「レイアウト」から選択できることです。各レイアウトは、読み込み速度、メモリオーバーヘッド、スキーマ進化への対応力を異なる方法でトレードオフします。
| レイアウト | 読み込み手順 | メッセージあたりのオーバーヘッド | スキーマ進化 | 向いている用途 |
|---|---|---|---|---|
| Fixed | 1 回の読み込み、分岐なし | 0 バイト | 固定スキーマのみ | 小さいプリミティブ型のインライン化 |
| Flat | 2 回の読み込み、分岐 1 回 | 2 バイト | 制限的(型保持) | 密度の高いホットデータ |
| Sparse | 4 回の読み込み、分岐 2 回 | 6 バイト | 無制限 | スパーススキーマ、自由な進化 |
| Dynamic(デフォルト) | Flat または Sparse を実行時選択 | 可変 | 段階的に対応 | 進化中のシステム全般 |
Yandex のベンチマーク結果によると、Flat レイアウトは FlatBuffers の約 3.8 倍高速で、生の C++ 構造体の読み込みの 1.2 倍の速度に収まります。出典: MarkTechPost
Flat レイアウトはホットデータの読み込みで FlatBuffers に対して約 3.8 倍の高速化を実現しながら、生の C++ 構造体の読み込み速度には 1.2 倍の範囲内に留まっている。
Fixed レイアウトはさらに高速ですが、スキーマを一切変更できない「凍結」状態が前提です。一方、Dynamic(デフォルト)は実行時に Flat または Sparse を選択するため、スキーマ進化に対応しつつ、可能な限り Flat の高速性を活かす設計になっています。
本番運用での成果と導入方式
Yandex は既に、自社の広告推薦システムで YaFF を運用しており、CPU 使用率が 10~20% 削減されたと報告しています。これは数千コアの物理サーバ規模で考えると、著しいコスト削減です。出典: MarkTechPost
インフラエンジニアやバックエンド開発者の方にとって注目すべきは、導入が段階的に可能な点です。YaFF の特徴は、次の通りです:
- 一度に全システムを移行する必要がない
- 最もホット(CPU 負荷が高い)なコードパスから導入を開始できる
- 段階的な導入時は、YaFF 形式と Protobuf 形式の相互変換が両端で行われる
このアプローチにより、既存システムへの影響を最小限に抑えながら、段階的にパフォーマンスを向上させることが可能になります。
正直なところ、この設計思想は慎重で現実的だと感じます。完全な置き換えを強要するのではなく、利益が見込める場所から徐々に適用する道を用意することで、本当に採用されるオープンソース プロジェクトになりうるのではないでしょうか。