Назад
Cloudflare оптимізувала DNS-кеш 1.1.1.1 і зекономила 100 терабайтів пам'яті
SiTech AI Team3 წთ. საკითხავი

Cloudflare оптимізувала DNS-кеш 1.1.1.1 і зекономила 100 терабайтів пам'яті

П'ять змін у структурі зберігання записів зменшили обсяг одного запису на 56%. У бенчмарках швидкість вставки зросла на 43%, а затримка пошуку впала на 19%. Розгортання тривало з травня по липень 2026 року.

Інженери Cloudflare п'ятьма послідовними оптимізаціями зменшили споживання пам'яті DNS-кешем більш ніж удвічі. Про це йдеться в публікації в блозі компанії від 27 серпня; зміни стосуються Big Pineapple — платформи, на якій працюють публічний резолвер 1.1.1.1, а також Gateway DNS, DNS Firewall і AS112.

Кеш на 250 мільярдів записів

Big Pineapple одночасно зберігає понад 250 мільярдів записів DNS-кешу. Оскільки кожен запис існує водночас у сотнях дата-центрів, навіть один зайвий байт на запис означає понад 250 гігабайтів пам'яті по всьому парку серверів. Кожен елемент кешу — це пара «ключ-значення»: ключ описує запит (ім'я, тип запису, ознака автентифікації, тег), а значення зберігає саму відповідь — секції answer, authority та additional, а також метадані: час створення, лічильник влучань і TTL.

Розмір кешу різний у різних дата-центрах. Коли використовується EDNS Client Subnet (ECS), авторитативні сервери повертають різні відповіді залежно від мережі клієнта, тож Cloudflare кешує кілька версій одного запиту.

П'ять змін у структурі зберігання

Вплив кожної зміни вимірювали на випадково згенерованих записах, наближених до продакшн-трафіку: 56% A, 25% AAAA і 19% TXT, від одного до чотирьох записів на елемент.

Заміна полів Vec і String на Box<[T]> та Box<str> прибирає поле capacity і зарезервоване під зростання місце в купі — це 8 байтів на поле, 64 байти на запис і понад 15 терабайтів на весь парк. Зберігання секцій answer, authority та additional в одному списку з 2-байтовими зсувами замість трьох окремих списків економить ще 28 байтів на запис. У більшості записів owner збігається з доменом запиту, тому тепер це поле не зберігається, а ім'я відновлюється з ключа кешу під час читання.

Ще дві зміни стосуються розміру enum у Rust. Дані запису, збережені як enum, завжди мають розмір найбільшого варіанта — NAPTR на 144 байти, — хоча запису A потрібно лише 4 байти, тож більшість записів марнувала понад 120 байтів. Винесення великих варіантів у купу це виправило, але додало округлення алокатора й розкидані виділення. Останній крок зберігає дані записів як сирі байти дротового формату в одному буфері з 2-байтовими префіксами довжини: це повертає локальність, і більшість записів копіюється у відповідь напряму.

Результати в продакшені

У бенчмарках обсяг одного запису зменшився з 953 до 420 байтів (−56%), а виділення — з 1,1 КБ до 461 байта (−58%). Швидкість вставки зросла з 625 000 до 893 000 записів за секунду (+43%), затримка пошуку впала з 828 до 670 наносекунд (−19%).

Розгортання тривало з 18 травня по 6 липня 2026 року, і пам'ять знижувалася поетапно. На p99 резидентна пам'ять одного інстансу впала з 9,3 ГБ до 5,3 ГБ (−43%), на p90 — з 6,5 ГБ до 3,8 ГБ (−42%). Загальна робоча пам'ять парку менша приблизно на 100 терабайтів — приблизно стільки оперативної пам'яті, скільки в 130 серверах Cloudflare покоління Gen 13. Компанія планує вкласти звільнену пам'ять у збільшення ємності кешу, що підвищить частку влучань і зменшить кількість запитів угору за ланцюжком.

SSiTech

SiTech — веброзробка з підтримкою AI

Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.