Cloudflare тестирует сжатие кеша Zstandard: экономия петабайт хранилища

Инженер Cloudflare, стажировавшийся по программе 1.1.1.1 Intern Program, построил прототип под названием Cache Transcoding. Повод, рост цен на память: и оперативная память, и жёсткие диски за последний год заметно подорожали, а Cloudflare держит несколько массивно распределённых хранилищ, включая CDN, и хочет эффективнее использовать уже развёрнутую память.

Идея: подходящие ответы, попадающие в кеш, сжимаются алгоритмом Zstandard (zstd) внутри прокси Pingora ещё до записи на диск. Сжатая форма хранится, пока объект живёт в кеше и перемещается между дата-центрами через многоуровневый кеш (Tiered Cache), а декодируется только перед отдачей клиенту, то есть декодирование происходит один раз на последнем, обращённом к клиенту участке пути. Расход на сжатие оплачивается один раз при попадании объекта в кеш, а экономия места и трафика между дата-центрами повторяется при каждом повторном обращении к этому объекту.

Zstandard, алгоритм сжатия без потерь, разработанный Янном Колле (Yann Collet) в Facebook и открытый в 2016 году. В более ранних тестах сжатия для браузера zstd сжимал данные на 42% быстрее Brotli при почти том же размере файла и давал файлы на 11,3% компактнее gzip при сопоставимой скорости. Прототип использует zstd уровня 3, баланс, дающий большую часть выгоды от сжатия без превращения заполнения кеша в узкое место по процессору.

Сжимают не всё подряд. В выборке трафика Cloudflare изображения, видео и шрифты (медиа), это 21,4% запросов, но 63,3% байт; они обычно уже сжаты, повторное сжатие только тратило бы процессор впустую. Сжимаемый текст, HTML, JSON, CSS и JavaScript, это 67,3% запросов и 22,3% байт; внутри этого текстового среза около 71% приходит без заголовка Content-Encoding, то есть несжатым, и хорошо поддаётся сжатию. В начальных тестах такие подходящие объекты в среднем ужимались до трети исходного размера на диске; на контрольном тестовом корпусе итоговый коэффициент сжатия составил примерно 2,8 раза.

Команда сначала рассматривала вариант сжимать только популярный (часто запрашиваемый) контент, раз такие объекты чаще переиспользуются. Но это не помогло: декодирование происходит при каждой отдаче объекта, поэтому ограничение сжатия только самым популярным контентом снижало экономию места на диске, не давая пропорционального снижения нагрузки на процессор. В итоге выбрали более простую политику: сжимать весь подходящий сжимаемый текст объёмом от 4 КиБ (кибибайт), это захватывает почти всю измеренную выгоду по хранилищу, оставаясь в бюджете по процессору. Понижение порога добавило бы накладных расходов на объект, но почти не увеличило бы экономию: за порогом остаётся лишь около 1% иначе подходящих байт. По модели авторов, при принятых допущениях о трафике и повторном использовании дополнительная нагрузка на процессор от сжатия уровня 3 составляет лишь несколько процентов, точного числа в материале не приводится.

Механика по сценариям: при промахе кеша прокси на базе Pingora кодирует тело zstd перед записью на диск, метаданные кеша фиксируют, что хранимое представление сжато, и сохраняют исходную длину контента; перед выдачей клиенту тело декодируется обратно в исходный вид. При попадании в кеш сжатый объект читается с диска и декодируется; при использовании Tiered Cache сжатое представление передаётся между верхним и нижним уровнями кеша в сжатом виде, а декодирование происходит только на последнем, клиентском участке. Специальная метка в хранилище не даёт объекту быть закодированным повторно: приняв объект от другого уровня, кеш видит, что тот уже хранится в zstd, и сохраняет эту форму.

Архитектуру проверили на контролируемой тестовой зоне: свели логи запросов, метрики Prometheus и трейсы Jaeger. Один из тестовых прогонов отправил более миллиона запросов через 10 кеширующих серверов, половину прогона выполнили с выключенным Tiered Cache, половину, с включённым, чтобы отдельно измерить поведение локального кеша и передачу между уровнями. Два тестовых объекта размером примерно 195 КиБ и 272 КиБ сжались оба примерно в 2,8 раза; авторы прямо оговаривают, что это был намеренно легко сжимаемый тестовый набор и он не отражает весь текстовый контент интернета, прежде чем считать измеренный коэффициент сжатия постоянным для всего парка серверов, нужен более широкий корпус.

Cache Transcoding остаётся прототипом, а не продакшн-функцией: авторы описывают его как эксперимент, показавший, что при протестированных условиях компромисс выгоден и архитектура укладывается в бюджет по процессору, сохраняя контент неизменным. Дальнейшие шаги: проверить более высокие уровни сжатия zstd, протестировать более широкий диапазон типов и размеров контента, донастроить параметры критериев отбора, а также изучить работу с диапазонными (range) запросами, с уже сжатыми ответами источника и с передачей сжатого объекта нижестоящим компонентам без декодирования там, где они это уже поддерживают.

Ключевые факты

• Cloudflare (по программе для стажёров 1.1.1.1 Intern Program) прототипировала Cache Transcoding, сжатие подходящего кеш-контента алгоритмом Zstandard (zstd уровня 3) внутри прокси Pingora перед записью на диск.
• Сжимают только несжатый текст (HTML, JSON, CSS, JavaScript) от 4 КиБ, это 67,3% запросов и 22,3% байт трафика; уже сжатые медиа (21,4% запросов, 63,3% байт) не трогают.
• В начальных тестах подходящие объекты в среднем ужимались до трети исходного размера на диске; на контрольном корпусе итоговое сжатие составило примерно 2,8 раза.
• Экономия места и межцентрового трафика повторяется при каждом повторном обращении к объекту из кеша (в том числе через Tiered Cache), а расход на сжатие, только один раз при заполнении кеша.
• Это прототип, не продакшн-функция: тест прошёл более миллиона запросов на 10 серверах, но дальше планируют проверить более высокие уровни zstd, больше типов контента и донастроить параметры отбора.

Почему это важно

Cloudflare держит массивно распределённые хранилища, включая свою CDN, а память, и оперативная, и дисковая, за последний год заметно подорожала. Cache Transcoding, способ увеличить эффективную ёмкость кеша на уже развёрнутом железе: подходящий текстовый контент сжимается алгоритмом Zstandard перед записью на диск, что экономит и место на диске, и трафик между дата-центрами Cloudflare, ценой лишь небольшого роста нагрузки на процессор.

Кому это важно

В первую очередь, инженерам, которые проектируют и эксплуатируют распределённые кеши и CDN: в материале подробно разобрана архитектура (критерии отбора контента, работа с многоуровневым кешем, защита от повторного кодирования), которую можно использовать как образец при проектировании собственных систем. Косвенно это важно и клиентам Cloudflare, эффективнее используемая память означает больше устойчивости и потенциально ниже издержки на инфраструктуру у поставщика их CDN.

Как это применить

Cache Transcoding, внутренний прототип Cloudflare, а не публичный продукт или API, которым можно воспользоваться напрямую; в материале нет ни цены, ни условий доступа, ни сроков выхода в продакшн. Практическая ценность для стороннего инженера, в самой архитектуре: кодировать объект один раз при попадании в кеш и хранить его в сжатом виде вплоть до отдачи клиенту, использовать простой набор критериев отбора (тип контента, отсутствие уже применённого сжатия, минимальный размер от 4 КиБ) вместо избирательного сжатия только популярных объектов, которое, как показал этот эксперимент, работает хуже.

Можно ли доверять

Источник, официальный инженерный блог Cloudflare, а сам эксперимент прозрачно описан как прототип, построенный стажёром, с указанием методики (более миллиона запросов через 10 кеширующих серверов, сведение логов, метрик Prometheus и трейсов Jaeger). Авторы сами оговаривают главное ограничение: тестовый корпус был намеренно легко сжимаемым и не отражает весь текстовый трафик интернета, поэтому измеренный коэффициент сжатия 2,8 раза пока нельзя считать постоянной величиной для всего парка серверов, нужен более широкий корпус.

Риски и подводные камни

Главная оговорка, сама методика измерений: тестовый корпус подобрали заведомо хорошо сжимаемым, и заявленное сжатие примерно в 2,8 раза может не повториться на репрезентативной выборке реального интернет-трафика. Дополнительная нагрузка на процессор указана лишь как «несколько процентов» по модели, точного измеренного числа в материале нет. Наконец, это по-прежнему прототип: сроков выхода в продакшн, дальнейших метрик и решений по итогам следующих тестов (более высокие уровни сжатия, больше типов и размеров контента) в статье нет.

Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.