Meta、推論サーバー ZGateway を公開──大規模 K/V ストア ZippyDB の通信を効率化
Meta の分散 K/V ストア ZippyDB の前にプロキシ層 ZGateway を挿入し、数百万に及ぶクライアントのコネクション数と再接続ストームを削減した。
リリース: 2026-09-03 · 読了 3 分記事の要約
1. 核心（What）
- Metaは、分散K/Vストア「ZippyDB」のクライアントトラフィックを統合管理するプロキシ層「ZGateway」を導入した。
- ZGatewayは、数百万のクライアントと数万のデータベースホストの間でコネクションメッシュを解消するステートレスなプロキシとして動作する。
- リージョンごとのサービスメッシュ「ServiceRouter」を介してデプロイされ、純粋なプロキシとリードスルーキャッシュの2つの形態をサポートしている。
- リクエストのバッチ処理やコエレシング（合流）をプロキシ層で実行し、バックエンドへのRPC負荷を軽減する仕組みを実装している。
2. 影響（Why）
- コネクション爆発と障害の防止: 数百万のクライアントが数万のシャードへ直接接続する多対多のメッシュ構造は、接続の再利用低下に伴うファイルディスクリプタ枯渇やOOM障害を引き起こすため、プロキシで集約する設計が不可欠である。
- クライアント側改修のコスト削減: 数千のチームが管理する100万以上のクライアントホスト側で接続ポリシーを同時に変更することは困難であり、一元管理されたプロキシ層でトラフィック制御を一括して行う方が圧倒的に安全である。
3. 根拠・詳細（How）
- C++エンジンと分散サービスメッシュ: Metaの内部向け厚いC++クライアントをコアエンジンとして採用し、ServiceRouterによるリージョン別ルーティングを用いてクライアントを最寄りのZGatewayホストに接続している。
- リクエストのバッチ処理とコエレシング: 同一の宛先に向かうリクエストを use case と物理シャードごとにグループ化し、単一のバックエンドRPCへとマージすることで効率的な処理を実現している。
4. 展望・課題（Next）
- トラフィック比率の拡大: 現在担っている全ZippyDBトラフィックの約40%から、今後60%超へと適用範囲を順次拡大していく予定である。