Содержание
Cloudflare снова урезала расход памяти на 100 ТБ RAM — на этот раз не ускорением кода, а настройкой хеширования серверов в кэширующей инфраструктуре.
Компания уменьшила число хеш-записей на машину с 100 000 до 10 000. По расчетам инженеров, такая схема почти не ухудшает распределение запросов, но резко режет раздутые таблицы в памяти.
Проблема сидела в маршрутизации кэша
Cloudflare много зарабатывает на кэшировании: сервис отдает URL из памяти или с диска, а не тянет страницу с живого сайта. Это экономит время, снижает нагрузку на origin-серверы и делает сеть устойчивее при больших всплесках трафика.
Для такой маршрутизации Cloudflare использует собственный open-source-фреймворк Pingora и алгоритм Ketama. Его задача простая на бумаге: взять произвольный URL и отправить его на подходящий cache-сервер.
URL хешируют в число, примерно как файл можно прогнать через CRC-32. Сервер тоже получает свой хеш, например из IP-адреса и имени. Затем система сопоставляет эти числа по близости на хеш-кольце.
Если серверы стабильны, схема выглядит аккуратно. Одни и те же URL попадают на одни и те же машины. Кэш греется, запросы не скачут туда-сюда без причины.
Почему 100 000 хешей стали лишними
Сложности начинаются, когда серверы исчезают и возвращаются. Если один из четырех серверов держал 25% запросов и внезапно выпал, его нагрузка может переехать на ближайшего соседа. В результате один сервер получает перегрузку, а остальные простаивают.
Классический способ сгладить перекос — добавить каждому серверу много виртуальных хешей. Тогда записи перемешиваются случайнее, а трафик умершего узла равномернее расходится по оставшимся машинам.
У Cloudflare эта страховка разрослась до серьезного объема. На одной машине могло лежать до 100 000 серверных хешей. А поверх базовой схемы работали веса, регионы и ограничения по контенту.
- Вес серверов: более крупные машины должны принимать больше запросов.
- Региональные правила: не каждый сервер подходит для любого запроса.
- Контентные ограничения: часть данных нельзя обслуживать откуда угодно.
После расчетов на алгебре и базовой статистике инженеры пришли к выводу: 100 000 записей уже почти не улучшают результат. После 10 000 хешей ошибка распределения снижается слишком медленно.
Иными словами, Cloudflare держала в памяти большой запас точности. На масштабе домашнего NAS это звучит смешно. На масштабе глобальной сети это превращается в десятки терабайт RAM.
Экономия вышла из двух мелких правок
Главная правка — сокращение числа хешей на 90%, с 100 000 до 10 000 на машину. Вторая — аккуратная работа со структурами данных Rust, где инженеры сэкономили еще 2 байта на каждой записи в карте «хеш — сервер».
Два байта выглядят как пыль, пока записей не миллиарды. В серверной инфраструктуре Cloudflare такие мелочи складываются в стойки памяти, бюджет на железо и энергопотребление.
Хорошая деталь — команда не переписала старый алгоритм поверх прежнего кода. Новый вариант добавили как отдельный путь исполнения v2. Если что-то ломается, инженеры могут быстро вернуться к старой схеме.
Для пользователя это не новость уровня «сайт стал открываться вдвое быстрее». Зато для инфраструктуры это ровно тот тип оптимизации, который отличает зрелую платформу от софта, пожирающего память без счета.
Код Pingora открыт на GitHub, а новый вариант Ketama подключили отдельной зависимостью в конфигурации pingora-ketama; старый путь исполнения Cloudflare оставила для быстрого отката.
