CloudflareがDNSのゾーン構築を対象限定ビルドで削減：自社測定で92.95%がフルビルドを回避、平均メモリは49GiBから7GiBに

2026年11月2日、CloudflareはAlex Fattoucheによるエンジニアリング記事を公開し、DNSのZone Builderが変更のたびに行う作業をどう減らしたかを説明した。Zone Builderは、DNSレコードとゾーン設定の変更をCloudflareの権威DNSサーバーが使えるデータに変換し、分散キーバリューストアのQuicksilverに書き込む。Quicksilverがそれをネットワーク全体に広げる。筆者が2022年にこのパイプラインについて書いたとき、ビルダーは毎秒約250件のレコード変更を受けていた。現在は約700件で、ゾーン設定の変更などの他のイベントが約100件ある。記事は、問題はイベントの数ではなく、一部のイベントが必要とする作業の種類だと述べる。現在、2,000万件を超えるレコードを持つゾーンがあり、Cloudflareは数億件に向かって増えると見込んでいる。

従来の設計には一つの利点があった。フルビルドは、ゾーンがなぜ変わったかを知らなくてよい。ゾーンとすべてのレコードを読み、Quicksilverのキーに変換し、保存済みの内容と比較して、差分だけを書く。小さなゾーンなら安く済むが、すべてのレコードを読んで比較し、ゾーン全体をメモリに保持する点は変わらない。Universal SSLの有効化のようなゾーン設定の変更は、メタデータやゾーン頂点の認証局認可レコードを変えることがあるが、イベントが何が変わったかを示さないことが多かった。そこでCloudflareは、イベントの生成側が変更されたフィールドと、可能なら変更前後の値を含めるようにし、安全と証明できる最小のビルドを選ぶプランナーを作った。

プランナーは五つのビルド種別から選ぶ。リソースのみ、リソースとメタデータ、頂点とメタデータ、パージ、ゾーン全体である。記事が述べる規則は厳格だ。対象を絞ったビルドが書き込むすべてのキーは、フルビルドが書き込む内容とバイト単位で同一でなければならず、それが証明できなければフルビルドを行う。詳細の欠落、未知のイベント、タイムスタンプだけの更新は今もフルビルドを引き起こすため、不確実さが作業の削減に変わることはない。古い状態の削除は2022年と同じ方式で、レコードのイベントには削除されたレコードと更新前の版が含まれ、ビルダーは再構築する各名前の下にある既存のキーをQuicksilverで走査し、古いものを取り除く。最大のゾーンには意図的な例外がある。レコード数が一定のしきい値を超えると、ビルダーはフルビルドに格上げしない。そのようなビルドは完了できず、同じKafkaパーティション上の他の変更を止めてしまうからだ。代わりに頂点、メタデータ、イベントが指す名前を再構築し、まれなケースは手作業で修正できる。

共有された名前が事を難しくする。Quicksilverは各ゾーンのレコードキーを別々に保存するが、同じドメイン名を持つすべてのゾーンに共有される一つのメタデータキーも持ち、そこにはクエリへの応答に使える内部ゾーンIDが並ぶ。顧客の受け入れや解約の過程では、一つのドメインに複数のゾーンオブジェクトが一時的に存在しうる。記事は、イベントからビルドまでの間にデータベースが変わりうるため再読み込みすること、同じゾーンの作業を一つのスケジューラで統合しながらKafkaメッセージを失わないことにも触れている。

Cloudflareは安全性の主張を三つの方法で確かめた。同値性テストは、同じデータベース状態からフルビルドと対象を絞ったビルドを実行し、後者が担当するすべてのキーを比較する。展開中は、絞ったビルドの横でフルビルドも実行した。さらに、ミラーのZone Builderが本番のKafkaストリームを消費し、本番のデータベース状態を読み、顧客にサービスを提供しない別のQuicksilverに書き込んだ。比較器はゾーンの20パーセントを抽出して検査し、記事のダッシュボードは一致した234,313ゾーンで差分率0.31パーセントを示す。大半はタイミングの差である。展開はゾーン名のハッシュで段階的に行い、無料ゾーンを先に、次に有料ゾーンに広げた。

24時間のビルド種別集計では、約86.81パーセントがリソースのみ、2.54パーセントがリソースとメタデータ、2.30パーセントが頂点とメタデータ、1.30パーセントがパージで、92.95パーセントが全ゾーン再構築を避け、フルビルドは7.04パーセントでした。従来の11.88パーセントから約40パーセント減です。別の並行比較では旧本番と新ミラーのスケジューラーが同じイベントを同じ24時間に処理しました。通常の完了遅延はほぼ変わらず、最大p99ピークは14.6分から1.21分に低下。遅延はQuicksilverへの書き込みまでで、世界各地への配信を含みません。Zone Builder導入全体の集計ワーキングセットメモリは平均49GiBから7GiB、ピーク79GiBから12GiBに低下しましたが、展開後のメモリ図を同じ24時間と断定はできません。その後、ゾーンごとの再構築間隔とKafka Aggregatorのバッファを短くして初めて、中央値は約7.7秒から3.3秒に低下しました。粗いヒストグラムの図は約2時間、後の細かいヒストグラムの図は約4時間で中央値は約3.4秒です。

これらはCloudflareが異なる段階と明示された時間幅で報告した自社測定で、全指標が同じ1日の実験だったとも、異なる暦日だったとも断定できません。ビルド比率の分母はビルド回数で、導入全体のワーキングセットメモリは単一ビルドの使用量ではありません。並行比較の遅延は全ビルド種別と顧客プランを合わせた値で、個別ゾーンの保証ではありません。他のチームは変更をイベントに載せ、対象出力の同値性を証明し、巨大ゾーンの例外を含む安全な代替経路を保ち、展開前にミラーで試せます。

技術的に最も価値があるのは、「証明」に対するこの記事の姿勢だ。多くのシステムは速度のために差分処理を行うが、差分の結果がフルの結果と等しいという証拠を持たない。ここでは等価性をテストとして書き、展開時に二種類のビルドを同時に走らせ、ミラー環境と抽出比較器で継続的に監視し、新しい種類の差分が出なくなってから割合を広げている。この多層の検証は、どの単独の性能値よりも、この変更を安心して広げられる理由をよく説明している。