過去の出来事の日付：2026年8月27日。

Cloudflareによると、DNSキャッシュのメモリー内レイアウトに5つの変更を加えた結果、各エントリーに必要なメモリーが56％減少し、同社のインフラ全体で約100テラバイトが解放された。同社はまた、変更の導入後、挿入スループットが43％向上し、検索レイテンシーが19％低下したと報告した。

この取り組みは、1.1.1.1パブリックリゾルバー、Gateway DNS、DNS Firewall、AS112などのCloudflareサービスを支えるプラットフォーム「Big Pineapple」を対象とした。Cloudflareによると、同プラットフォームは常時2500億件を超えるDNSエントリーをキャッシュしている。この規模では、エントリー当たり不要な1バイトがあるだけで、全インフラのメモリー使用量は250ギガバイト以上増える。削減された総量は、同社の第13世代サーバー130台に搭載されたRAMに相当した。

キャッシュされた各項目には、問い合わせを記述するキーと、DNS応答および作成時刻、ヒット回数、生存期間などのメタデータを含む値がある。Cloudflareのエンジニアは、汎用的なRustコンテナー型の柔軟性を必要としない固定データに注目した。

変更の一つでは、応答がキャッシュに入った時点で、拡張可能なベクターと文字列をボックス化スライスおよびボックス化文字列に置き換えた。Rustのベクターはポインター、長さ、容量を保存するが、ボックス化スライスは拡張できないため容量を保持する必要がない。こうしたフィールドは各キャッシュエントリーに8つあった。容量の値を取り除くことで、エントリー当たり64バイトを削減するとともに、ヒープ上に過剰な予約領域を確保することも避けられた。Cloudflareは、削減総量のうち15TB以上がこの措置によるものだとしている。

チームはまた、DNS応答の回答、権威、追加の各セクションを1つのリストにまとめ、セクション境界を2バイトのオフセットで記録した。これにより、別個のポインターと長さの組を2つ削除し、エントリー当たり28バイトを節約した。複数のブール値はビットフラグにまとめられ、構造体をメモリー上で整列させるためRustが挿入するパディングも削減された。

別の最適化では、レコード所有者名に対処した。多くのレコードでは所有者が問い合わせ内のドメインと同じであるため、その名前を再び保存すると重複が生じる。改訂後のキャッシュでは、同一の所有者を省略し、応答の生成時に、すでに利用可能なキャッシュキーから復元する。CNAME経由で到達したレコードなど、所有者が異なる場合には完全な名前が引き続き保存される。

Cloudflareは、カスタムアロケーターと、本番トラフィックを近似する合成エントリーを使って変更を測定した。内訳はAレコード56％、AAAAレコード25％、TXTレコード19％で、各エントリーには1～4件のレコードが含まれた。TXTのペイロードサイズは64～224バイトだった。エンジニアは割り当てサイズとキャッシュ性能の両方を追跡したうえで、展開中には本番インスタンスの常駐メモリーを監視した。

同社は、ベンチマークの入力は実際のトラフィックを正確に再現したものではなく、近似したものだと注意を促した。実際のプロセスメモリーは、キャッシュの占有率、割り当て状態、トラフィック構成、ほかの場所で使われるメモリーによって変動する。そうした制約があっても、本番環境での測定結果は、小さな表現上の選択であっても数千億回繰り返されれば、インフラ規模の節約を生み出し得ることを示している。