Metaのデータ圧縮フレームワークOpenZLを掘り下げる
はじめに
2025年10月、Meta（旧Facebook）が新しいオープンソース圧縮フレームワーク 「OpenZL」 を公開しました。
公式ブログ（Meta Engineering Blog）では、「Zstandard（Zstd）」の次世代として紹介されています。
この記事では、
- MetaがなぜOpenZLを開発したのか
- どんな課題を解決したかったのか
- どんなケースで活用できるのか
を、公式資料・論文・Meta内部事例をもとに解説します。
背景：Zstdの次を求めたMeta
Metaはこれまで、自社内のあらゆるサービス（Facebook、Instagram、WhatsAppなど）で Zstandard (Zstd) を圧縮の標準として利用してきました。
Zstdとは何か
Zstandard (Zstd) は、Meta（当時Facebook）が2015年に公開した高速・高圧縮な汎用圧縮アルゴリズムです。
LZ77系の辞書圧縮に加え、Huffman符号化とエントロピーモデルを組み合わせることで、
「gzip並みの圧縮率を2〜5倍速く」「xz並みの圧縮率を10倍速く」を目指した設計が特徴です。
現在では、以下のように非常に広く利用されています。
| 分野 / ソフトウェア | 用途例 |
|---|---|
| Linuxカーネル・systemd | ログやcoredumpの圧縮形式 |
| Docker / containerd | イメージレイヤーの圧縮 |
| Git 2.18以降 | リポジトリ圧縮に採用 |
| Kafka / RocksDB / Cassandra | データ転送・ストレージ圧縮 |
| Cloudflare / AWS / Meta内部 | Webトラフィック・ログ圧縮 |
Zstdは「汎用圧縮のデファクトスタンダード」とも言える存在で、今やgzipの後継として多くのソフトウェアで使われています。
Zstdが抱えていた課題
Zstdは優れた汎用圧縮アルゴリズムですが、Metaのように膨大かつ多様なデータを扱う環境では、いくつかの限界が見えていました。
| 課題 | 内容 |
|---|---|
| データの構造を無視して圧縮している | JSON・Thrift・Parquetのような「構造化データ」は内部に明確な型やパターンがあるが、Zstdはそれを考慮できない |
| 各データタイプごとに最適化が必要 | 画像・数値・ログなど形式ごとに最適な圧縮アルゴリズムが異なるが、それを一元的に管理するのは困難 |
| カスタム圧縮の運用コストが高い | フォーマット特化の圧縮器を作ると、コード保守・デコーダ互換性の維持・監査コストが膨らむ |
Metaは「圧縮の性能だけでなく、スケーラビリティと運用性」に課題を感じていたのです。
OpenZLとは？ — “フォーマットを意識する圧縮”
OpenZL（Open Zipline）は、Metaが開発したフォーマット意識型の圧縮フレームワークです。
従来の「すべてのデータをただのバイト列として圧縮する」アプローチから一歩進み、データ構造（型やフィールド情報）を理解した上で最適に圧縮することを目的としています。
特徴まとめ
| 特徴 | 説明 |
|---|---|
| 構造を意識した圧縮 (format-aware compression) | データ構造をプロファイル（スキーマ）として明示的に扱い、構造に応じた最適変換・符号化を適用する |
| 圧縮グラフ（DAG）モデル | データを複数のストリームに分解し、各ストリームに対して最適な圧縮ノードを組み合わせる「圧縮グラフ」を構築する |
| ユニバーサルデコーダ | どんな形式の圧縮でも、単一のデコーダで展開可能（圧縮フレーム内にグラフ仕様を埋め込む） |
| プロファイル駆動 | データ型（int, float, stringなど）を「プロファイル」で記述しておき、それに基づいて圧縮戦略を最適化する |
| 学習・自動最適化可能 | 圧縮プロファイルをトレーニングによって最適化できる（Managed Compression基盤との統合） |
なぜMetaはOpenZLを作ったのか
Metaの公式アナウンスおよび論文「OpenZL: A Graph-Based Model for Compression (arXiv:2510.03203)」から、狙いを整理すると以下の通りです。
1. 構造化データを活かした圧縮率向上
Meta内部では、Thrift形式のシリアライズデータや列指向ストレージ、embeddingベクトルなど、構造を持ったデータが大量に存在します。
これらを単純にバイト列として扱うと冗長性を十分に削れません。
OpenZLでは「データ構造（型、範囲、順序）」をもとに最適な符号化を選択し、Zstdよりも10〜30%の圧縮率改善を実現しています。
例:
- Thrift構造体 → 各フィールドを分離して個別最適化
- Embeddingベクトル → float16の量子化＋デルタ圧縮
- 列指向DB → 各カラム型ごとの変換（delta, RLE, dictionaryなど）
2. 圧縮方式の「運用地獄」を回避
Metaのデータは膨大で、多様なサービス間で共有されています。
データ形式ごとに異なる圧縮ライブラリを管理していた時期もありましたが、それはメンテナンス負荷の大きな課題となっていました。
OpenZLでは、すべての圧縮を単一のユニバーサルデコーダで復号可能にすることで、この問題を解決しています。
- 圧縮戦略（圧縮グラフ）はフレーム内に埋め込み
- 将来の圧縮器アップデートでも過去のデータをそのまま解凍できる
- セキュリティ監査・バージョン管理のコストが激減
3. ストレージ・ネットワークコスト削減
Metaは世界最大級のストレージ基盤を運用しています。
1〜2割の圧縮効率向上は、ペタバイト単位でのストレージ削減につながり、運用コストに直結します。
さらに、モデル学習・分散システム・ログ転送など、I/Oや帯域がボトルネックになる領域で劇的な改善が見られたと報告されています。
Meta内部の実運用例
論文「OpenZL: A Graph-Based Model for Compression」では、Meta内部での具体的な適用事例が紹介されています。
| 対象データ | 説明 | 効果 |
|---|---|---|
| Thriftシリアライズデータ | RPCやメッセージングに使われる構造体形式 | Zstdよりも圧縮率5〜15%改善 |
| 列指向DB (Nimble) | 内部分析基盤のカラムデータ | 圧縮率約10%改善、読み出し速度も向上 |
| Embeddingストレージ | 機械学習向けベクトルデータ（bfloat16） | 約30%圧縮率向上 |
| モデルチェックポイント | 学習済みモデルの重み・テンソル | I/Oコスト削減、転送効率改善 |
Metaの論文によれば、「OpenZLはZstd利用のかなりの割合を置き換えている」と述べられています。
OpenZLのアーキテクチャ概要
OpenZLの圧縮は**グラフ構造（DAG）**で表現されます。
圧縮時には以下の情報がフレームに埋め込まれます。
- 圧縮グラフ（各ノードの操作情報）
- バージョン・メタデータ
- SDDL（データ構造の簡易記述）
伸長側はこのフレームを解析し、ユニバーサルデコーダで再構築を行います。
これにより「どんなプロファイルで圧縮されても1つのデコーダで展開可能」になります。
どんなケースで活用できるのか
OpenZLはMetaだけでなく、他の大規模データ処理にも応用可能です。
| 適用領域 | 期待できる効果 |
|---|---|
| データウェアハウス（BigQuery, Redshiftなど） | 列ごとの型情報を活用して圧縮率改善 |
| ログ集約・監視基盤（Elasticsearch, Lokiなど） | 構造化ログ（JSONなど）を効率的に圧縮 |
| 機械学習パイプライン | 埋め込み・特徴量・チェックポイントの転送効率向上 |
| IoT / センサーデータ収集 | フィールド構造を明示することで帯域削減 |
| 分散システム通信（RPC, gRPCなど） | メッセージ構造を理解した軽量化 |
注意点・今後の展望
OpenZLはまだ若いプロジェクトであり、以下のような制約があります。
- テキスト主体のデータでは効果が薄い
- 最適化にはトレーニング（プロファイル学習）が必要
- 小さなデータチャンクではメタデータオーバーヘッドが増える
とはいえ、圧縮技術の次の進化方向を示す重要なステップであることは間違いありません。
今後は以下の方向に拡張が進むと考えられます。
- プロファイル自動生成／AI最適化
- GPU・ASIC向けの高速デコーダ
- 他言語（Python, Rustなど）バインディングの整備
- クラウドデータ処理基盤への統合（Spark, Flink, Arrowなど）
まとめ
- MetaはZstdの限界を超えるために、構造を理解する圧縮フレームワークを開発した
- OpenZLは圧縮グラフ＋ユニバーサルデコーダという新しいアプローチを採用
- Meta内部では、Thrift・DB・Embeddingなどで最大30%の圧縮改善を実現
- 構造化データを扱うあらゆる領域で有効になりうる