Cloudflareは2026年8月27日、パブリックDNS「1.1.1.1」などを支える基盤「Big Pineapple」のキャッシュを再設計し、フリート全体で約100TBのメモリ余力を生んだと発表した。保存後に変化しないデータから可変長コンテナの余白を外し、最後はDNSレコードの表現そのものを見直した。しかもメモリを詰めた代償は出ていない。ベンチマークではキャッシュへの挿入が43%速くなり、参照遅延も19%短くなった。
ただし、100TBは撤去した物理RAMの量でも、サーバーを130台減らしたという報告でもない。本番プロセスが使うワーキングセットの減少分であり、Cloudflareは空いた領域をキャッシュ容量の拡大へ回す計画だ。今回の成果は、巨大なサービスではデータ構造の数バイトが設備規模の余力に変わり、その配置がCPUの待ち時間まで左右することを示している。
2500億項目が1バイトを250GBに変える
Big Pineappleは1.1.1.1のほか、Gateway DNSやDNS Firewall、AS112など複数のサービスを動かし、任意の時点で2500億を超えるDNSキャッシュ項目を保持する。1項目当たり1バイトの無駄でも、フリート全体では250GBを超える計算だ。一般的なアプリケーションなら見逃せる余白が、この規模ではサーバー用メモリの束になる。
キャッシュ項目は、問い合わせ名やレコード種別を持つキーと、DNS応答を持つ値の組である。値にはanswer、authority、additionalの各セクションに加え、作成時刻やTTL、ヒット回数などが入る。EDNS Client Subnet（ECS）を使う場所では、権威サーバーが問い合わせ元ネットワークに応じて応答を変えるため、同じ問い合わせにも複数の版が必要になる。ECSの利用が多い拠点ほど、項目数と項目当たりの占有量が膨らむ。
Cloudflareは効果を測るため、本番トラフィックを近似した合成ベンチマークを用意した。レコード種別はAが56%、AAAAが25%、TXTが19%で、1項目には1〜4レコードを入れた。TXTは他の可変長レコードの代理とし、64〜224バイトに散らしている。独自アロケーターで割り当て量を数える一方、本番では各インスタンスの常駐メモリも追った。ベンチマークと本番観測を分けた点は、最終結果を読むうえで欠かせない。
「もう伸びないデータ」にVecは大きすぎた
最初の変更は、RustのVec<T>とStringをBox<[T]>とBox<str>へ替えることだった。Vecはポインタ、現在の長さ、将来追加できる容量を持つ。ところが、DNS応答はキャッシュへ入った後に内容が増えない。64ビット環境では不要な容量フィールドが1個8バイトを占め、確保済みだが使っていないヒープ領域も残る。
1項目にある8個のVecまたはStringから容量フィールドを外すと、構造体部分だけで64バイト減る。過剰確保されたヒープ領域も消え、2500億超の項目を合わせた効果は15TB以上になった。ここで効いたのは特殊な圧縮ではない。データが今後も増えるという型の前提を、保存後は不変という実態に合わせ直したのである。
次に、answer、authority、additionalを3本のリストで持つ構成をやめ、1本のリストとセクション境界のオフセットへまとめた。削除した2本のリストには、それぞれ8バイトのポインタと8バイトの長さが必要だった。代わりに2バイトのu16オフセットを2個置き、1項目当たり28バイトを削った。複数の真偽値もbitflagへ詰め、Rustがアラインメントをそろえるために挿入するパディングまで縮めている。
3番目は、DNSレコードのowner、つまりレコードが属するドメイン名の省略だ。多くのレコードではownerが問い合わせ名と一致するため、キャッシュキーから復元できる。CNAMEの先にあるAレコードのように名前が異なる場合に限って完全なownerを残す設計へ変え、重複する名前とヒープ割り当てを減らした。
DNSの通信形式も名前の重複を避ける。RFC 1035は、メッセージ内ですでに現れたドメイン名を2オクテットのポインタで参照する圧縮を定めている。ただし、参照のたびに圧縮ポインタをたどるとホットパスの仕事が増える。Big Pineappleは従来、速度を優先して完全なownerを各レコードに持たせていた。今回はキャッシュキーが必ず手元にある条件を使い、重複分を安全に外した。
enumのBox化を経て、ワイヤ形式へ
さらに大きな余白は、DNSレコード種別を収めるRustのenumに潜んでいた。RecordDataはAやAAAAからNAPTRまで異なる大きさのデータを一つの型で扱うが、enum全体の幅は最大のvariantに引っ張られる。Cloudflareの実装ではNAPTRの中身が136バイトあり、タグとパディングを含むenumは144バイトだった。Aは4バイト、AAAAでも16バイトしか使わない。両者がトラフィックの80%超を占めるため、ほとんどのレコードに大きな空白が付いて回っていた。
Cloudflareはまず、大きなvariantをBoxへ移した。するとAとAAAAは1レコード当たり120バイト減る。一方で、箱を増やせばヒープ割り当ても増え、データが離れた場所へ散る。Big Pineappleが使うjemallocでは、32バイトを要求するTXTは32バイトの区分に収まるが、40バイトのMXは48バイトへ丸められ、8バイトが余る。CPUもレコードを読むたびに別の場所を追いかけなければならない。
そこで5番目の変更では、完全なDNS応答ではなく、レコードデータだけを通信時のワイヤ形式で保存した。各レコードを2バイトの長さと生のバイト列に直し、全レコードを単一のBox<[u8]>へ連続配置する。これで144バイト幅のenumとvariantごとの割り当てが消え、CPUが近接したデータをまとめて読めるようになった。
この中間案には実行時の利点もある。A、AAAA、TXTとDNSSECレコードは、応答を作る際にエンコード済みのバイトをそのままコピーできる。CNAMEやNS、MXなどドメイン名を含む型は名前圧縮のための解析が残るが、対象は絞られる。この変更だけで参照遅延は5%短縮した。
挿入側では、直列化に使う作業用バッファを項目ごとに捨てず、次の処理でも再利用する。レコードを書き終えて大きさが確定した時点で、必要量のBox<[u8]>を1回確保してコピーする。個別レコードごとの割り当てを一つへ集約した結果、この変更だけで挿入スループットは13%増えた。
953バイトから420バイト、本番では42〜43%減
5段階の変更を重ねると、合成ベンチマークの正味メモリは1項目953バイトから420バイトへ減った。削減幅は533バイト、率にして56%である。項目当たりの割り当て量も1.1KBから461バイトへ58%減少した。挿入性能は毎秒625000項目から893000項目へ43%増え、参照遅延は828nsから670nsへ19%短くなった。
本番導入は2026年5月18日に始まり、7月6日に全対象サービスで完了した。再起動した直後のインスタンスはキャッシュが空なので、グラフには一時的なメモリの谷が生じる。Cloudflareはキャッシュが埋まった後の安定した水準を比べ、p99の常駐メモリが9.3GBから5.3GBへ43%、p90が6.5GBから3.8GBへ42%減ったと報告している。フリートを合計したワーキングセットの差が約100TBだった。
ベンチマークの56%と本番の42〜43%は、同じ数字の再測定ではない。前者は指定したレコード分布でキャッシュ項目を測り、後者はキャッシュ外のデータも含むプロセス全体を測る。トラフィック構成やキャッシュ占有率、allocatorの状態も変わる。2500億という項目数に533バイトを掛けても、本番の100TBを直接導けない理由がここにある。
Cloudflareは100TBを、Gen 13サーバー130台分のRAMにたとえた。同社のGen 13は1台に768GBを積むため、130台分は99840GBになる。ただし、これは容量の物差しだ。絶対的なフリート台数や撤去した機器、電力削減量、費用への効果は公表されていない。
空いた100TBを何に使うのか
Cloudflareは余った領域を返却するのではなく、DNSキャッシュの最大項目数を増やす方針を示している。Big Pineappleは人気の低い項目を段階的に追い出すARCを使い、同じ登録ドメインへの問い合わせをコンシステントハッシュでデータセンター内の一部ノードへ寄せる。過去の説明では、キャッシュヒットなら1ms未満で応答できる一方、ミスは数百msかかる場合がある。容量が増えて有効な項目を長く残せれば、利用者の待ち時間と上流の権威サーバーへ送る問い合わせを減らせる。
もっとも、その効果はまだ数字で示されていない。Cloudflareは導入前後のヒット率、上流問い合わせ量、エンドユーザーが見るDNS応答時間を公表しておらず、828nsから670nsという値もキャッシュ参照処理のベンチマークである。利用者の応答が一律19%速くなるという結果ではない。
今回の設計変更がサービス品質へつながったかは、増やした容量がどれだけヒット率を押し上げ、ECSのように版が増える条件でも上流問い合わせを抑えられるかで判定できる。その数字が続報で示されれば、100TBの余力はメモリ節約の実績から、DNS全体の待ち時間と負荷を減らす資源へ変わる。