Cloudflare высвободила около 100 ТБ оперативной памяти не закупая новые серверы и не меняя модули RAM: компания просто пересобрала DNS-кэш Cloudflare на уровне структуры данных. Для тех, кто строит высоконагруженные сервисы, новость неприятно полезная: иногда десятки терабайт теряются не в архитектуре дата-центра, а в одном лишнем байте на запись.
О деталях, как пишет Tom's Hardware, рассказал системный инженер Cloudflare Себастиан Нойтебом в техническом разборе платформы Big Pineapple, на которой работает публичный резолвер 1.1.1.1. Команда уменьшила размер одной записи кэша с 953 до 420 байт. На масштабе Cloudflare это не косметика: в кэше одновременно хранится более 250 млрд DNS-записей, поэтому даже один лишний байт в каждой записи обходится флоту серверов более чем в 250 ГБ памяти.
Самое интересное в этой истории не цифра 100 ТБ, а способ, которым ее получили. Cloudflare внесла пять изменений на уровне реализации в Rust. Первый шаг — отказ от growable-контейнеров Vec и String в пользу фиксированных boxed slices там, где данные после помещения в кэш уже не растут. Это убрало лишние поля capacity и само по себе, по данным компании, сэкономило больше 15 ТБ памяти. Дальше инженеры схлопнули три списка DNS-записей в ответе в один буфер с 2-байтовыми смещениями, перестали хранить owner names там, где они дублируют исходный домен, и начали восстанавливать их при чтении. Последний штрих — хранение record data в виде сырых length-prefixed байтов wire-format вместо раздутого универсального представления, из-за которого 4-байтовая A-запись занимала столько же места, сколько редкая и заметно более тяжелая NAPTR.
На бумаге это выглядит как праздник для любителей микроптимизаций, но Cloudflare подчеркивает более приземленный эффект: система стала не только компактнее, но и быстрее. Плотная упаковка данных улучшила локальность для CPU cache, а значит многие типы DNS-записей теперь можно почти напрямую копировать в ответ, не пересобирая их поле за полем. В бенчмарках компании пропускная способность вставки выросла с 625 тыс. до 893 тыс. записей в секунду, то есть примерно на 43%. Задержка lookup снизилась с 828 до 670 наносекунд, или на 19%. Для обычного пользователя это незаметные числа, но на глобальном резолвере такого масштаба именно из таких наносекунд потом складываются расходы на железо, хвосты задержек и количество запросов, которые придется отправлять выше по цепочке к authoritative servers.
Изменения выкатывали с середины мая до начала июля, и за это время p99 resident memory на инстанс упала с 9,3 до 5,3 ГБ. Важно, что речь идет не о локальной оптимизации одной машины, а о повторяемом результате по всей глобальной инфраструктуре. Cloudflare прямо связывает эту работу с ростом цен на серверную память. Ее серверы Gen 13 оснащаются 768 ГБ DDR5-6400, и такой объем компания выбрала еще в марте, когда оценивала вариант на 1 152 ГБ и отказалась от него в том числе из-за дорогой памяти. На этом фоне освобожденные 100 ТБ выглядят не как красивый инженерный кейс для блога, а как способ не покупать лишние сотни дорогих модулей просто потому, что код раньше был слишком щедр к аллокатору.
Для Cloudflare это уже не первый заход на тему «сначала перепишем, потом купим железо». В сентябре прошлого года компания завершила еще один большой проект по возврату памяти — переписала слой обработки запросов FL2 на Rust. В аппаратной части она тоже давно играет в эффективность, а не в тупое масштабирование: например, раньше делала ставку на 96-ядерные AMD EPYC 9684X в серверах Gen 12. На фоне дефицита и удорожания памяти этот подход выглядит все менее романтичным и все более обязательным. Эпоха, когда можно было безболезненно закидать проблему RAM и назвать это «производительностью», в инфраструктурных сервисах заканчивается.
Для разработчиков и техлидов здесь есть довольно прямой вывод. Во-первых, низкоуровневые решения о layout в памяти не являются преждевременной оптимизацией, если у вас сотни миллиардов объектов и горячий путь на каждом запросе. Во-вторых, удобная абстракция дорого стоит, когда ее поле capacity дублируется миллиарды раз. В-третьих, эффективность структуры данных может дать двойной выигрыш: меньше памяти и меньше latency, а не компромисс между первым и вторым. DNS-кэш Cloudflare в этом смысле показательный пример для любой команды, которая строит кэши, очереди, индексы, каталог сервисов или собственный in-memory слой поверх Rust, Go или C++: прежде чем обсуждать закупку новых узлов, полезно посчитать, сколько на самом деле стоит один байт в вашем объекте.
Освобожденную память Cloudflare не собирается «монетизировать» переходом на более скромные конфигурации серверов. Логика обратная: компания хочет отдать ее обратно под более крупные кэши, чтобы повысить hit rate и реже ходить к внешним авторитативным DNS-серверам. И это, пожалуй, главный сигнал для отрасли. Следующий раунд борьбы за эффективность будет не только про более быстрые чипы и новые стойки, а про то, кто сумеет плотнее упаковать данные и не платить за собственную лень в коде. В больших распределенных системах DNS-кэш Cloudflare напомнил простую вещь: лучший апгрейд железа иногда начинается с очень внимательного взгляда на структуру одного объекта в памяти.