Cloudflare、1.1.1.1のDNSキャッシュ最適化で約100TBのRAMを削減（2026）

Cloudflareは2026年で最も具体的なシステム記事の一つを公開しました。Rust上のDNSキャッシュ項目のメモリレイアウトを最適化し、1.1.1.1 を支えるフリート全体でおよそ 100 TBのRAM を解放——サーバ追加なし、しかも参照を遅くするトレードオフなしです。

2026年8月27日のエンジニアリング投稿で、Sebastiaan Neuteboomは Big Pineapple（1.1.1.1、Gateway DNS、DNS Firewall、AS112などの共有解決基盤）に対する5段階のレイアウト変更を説明しました。TechSpotやGIGAZINE、開発者向けアグリゲータも同じ数字を伝えています。

要点一覧

Cloudflareの投稿と続報から、プラットフォーム規模・エントリ削減・速度向上・本番ロールアウト期間を一表にまとめます。

項目	内容
プラットフォーム	Big Pineapple — 1.1.1.1ほかCloudflare DNS
規模	フリート同時 2500億+ キャッシュエントリ
エントリあたり	953 → 420 bytes（−56%）
割り当て量	1.1 KB → 461 bytes（−58%）
解放RAM	約100 TB（Gen 13サーバ約130台相当）
挿入スループット	+43%（625k → 893k entries/s）
参照レイテンシ	−19%（828 ns → 670 ns）
本番p99メモリ	9.3 → 5.3 GB（−43%）
ロールアウト	2026年5月18日 – 7月6日

DNS規模では数バイトが高い

Big Pineappleは巨大なインメモリキャッシュを持ちます。コールドスタート時は空で、クエリで埋まり、拠点ごとの上限で古い／不人気項目を追い出します。

2500億超 の同時エントリでは、1バイトの無駄がフリート全体で 250 GB超 のRAMになります。EDNS Client Subnet（ECS）を使う拠点では、同一クエリ名でもクライアント網ごとに別答えをキャッシュするため、さらに膨らみます。

書き込み一度きり・毎秒数百万回読みの構造では、成長可能な Vec / String は「タダ」ではありません。

つのRustレイアウト変更

リゾルバ全体の書き換えではなく、キャッシュ表現の締め直し——5段階を出荷しながら計測。

1. 使わないcapacityを捨てる

挿入後は成長しないため Vec / String を Box<[T]> / Box<str> に置換。capacity語と過剰確保を削除——8フィールドで約 64 bytes、加えてヒープ浪費。この一手だけで 15 TB超。

2. リストとポインタを減らす

Answer / authority / additional を1リスト＋u16 オフセットに統合——エントリあたり約 28 bytes、フラグ詰め込みでパディングも削減。

3. 任意のowner名

多くのレコードのownerはクエリ名と同じ。Option で共通ケースをキーから復元し、CNAME系の分岐だけヒープ保持。

4. 大きなenumバリアントをBox

RecordData は稀な大型型（NAPTR約136 bytes）に合わせて肥大化。大型をBoxし、多いA/AAAAが約 144 bytes の税を払わないように。

5. ワイヤ形式バイト

最大の効果：長さ付き生DNSワイヤを連続 Box<[u8]> に。多くのA/AAAA/TXT/DNSSECは応答へmemcpy可能で、局所性が改善しBoxingコストもほぼ消える。

ベンチマークと本番結果

合成負荷（約56% A、25% AAAA、19% TXT代用）と、ロールアウト中の実RSSの両方を公開。

指標	前	後	変化
エントリ正味	953 bytes	420 bytes	−56%
割り当て量	1.1 KB	461 bytes	−58%
挿入スループット	625,000 /s	893,000 /s	+43%
参照レイテンシ	828 ns	670 ns	−19%
インスタンス（p99）	9.3 GB	5.3 GB	−43%
インスタンス（p90）	6.5 GB	3.8 GB	−42%
フリート working-set	—	−約100 TB	≈ Gen 13 ×130

本番の削減率はエントリ単純計算より小さめ——プロセスRSSにはキャッシュ以外も含まれるため、両指標を併記しています。

解放したメモリの使い道

アイドルのまま寝かせるのではなく、同じメモリ予算で キャッシュ容量を増やす 再投資——ヒット率向上と上流クエリ削減。キャッシュ構造の追加最適化も検討中です。

メモリ常駐ホットパスでは、レイアウト監査の目的は「請求削減」だけでなく容量と遅延の両立であることが多い、という示唆でもあります。

DNS以外に効く理由

書き込み一度のコレクション

作成後に伸びないなら固定スライス。数十億オブジェクトではcapacityと過剰確保が実コストになる。

稀な大型バリアント

enum/unionは最大バリアント基準。稀な巨物をBoxし、多い小ケースを密に。

ホットパス向け直列化

ほぼそのまま再送出するなら、豊かな解析構造よりワイヤ／直列化バッファが有利なことがある。

埋め込みキャッシュ、feature store、セッション状態など、インプロセス索引全般に同じ勘が効きます。

FAQ

何を変えたか、速度は落ちたか、ロールアウト期間、「100 TB」が単機かフリートか——短い答えだけ欲しい場合はここからどうぞ。

質問	回答
何を最適化した？	Big Pineapple（1.1.1.1など）のDNSキャッシュ項目のメモリレイアウト。
RAM削減で遅くなった？	いいえ——挿入 +43%、参照レイテンシ −19%。
本番ロールアウト期間は？	2026年5月18日〜7月6日、段階リリース。
「100 TB」は単機？	フリート全体のworking-set削減。