Cloudflare тестирует способ увеличить эффективную ёмкость своей сети кэширования без добавления нового оборудования — за счёт сжатия некоторых текстовых ресурсов с использованием алгоритма Zstandard в инфраструктуре на базе Pingora. Прототип, который компания назвала Cache Transcoding, призван уменьшить объём пространства, занимаемого данными на дисках, и объём данных, передаваемых между уровнями кэширования и центрами обработки данных.
Когда подходящий ответ попадает в кэш, его данные преобразуются в сжатое представление с помощью zstd перед записью на диск. Ресурсы остаются в таком виде во время хранения в кэше и передачи через Tiered Cache, а затем распаковываются перед отправкой клиенту. При этом само содержимое файла не меняется: Zstandard является алгоритмом сжатия без потерь, который после распаковки возвращает каждый байт в исходное состояние.
Большой результат при ограниченной вычислительной стоимости
В ходе первоначальных испытаний размер подходящих ресурсов на диске в среднем снизился примерно до трети исходного. Коэффициент сжатия в контролируемой тестовой группе составил 2,834 раза. Стоимость кодирования равнялась 4,31 наносекунды на байт, или примерно 232 мегабайтам в секунду, и возникала один раз при заполнении кэша. В свою очередь, стоимость распаковки составляла 1,56 наносекунды на байт, или примерно 641 мегабайт в секунду, и возникала при каждой выдаче.
В эксперименте используется третий уровень Zstandard как компромисс между скоростью выполнения и размером результата. Согласно модели Cloudflare, увеличение потребления процессора оставалось на уровне нескольких процентов при проверенных компанией предположениях о трафике и повторном использовании. Кроме того, уменьшение объёма данных позволяет каждому серверу хранить больше объектов и снижает вероятность вытеснения полезного содержимого из кэша из-за чрезмерного занимаемого им пространства.
Почему Cloudflare не сжимает всё?
Механизм не ориентирован на все типы содержимого. Изображения, видео и шрифты обычно уже сжаты: в выборке трафика они составляли 21,4% запросов, но 63,3% общего объёма байтов. Повторное сжатие этих данных может загрузить процессор без заметной экономии.
В свою очередь, на HTML, JSON, CSS и JavaScript приходилось около 67,3% запросов и 22,3% байтов. Около 71% этих текстовых ответов поступали от источника без Content-Encoding, что делало их кандидатами на сжатие. Прототип ограничивается ответами 200 OK, в которых не указан Content-Encoding, содержится пригодный для сжатия текстовый тип, а длина известна и составляет не менее 4 KiB.
Без изменений оставляются запросы частичных сегментов, ответы, предварительно сжатые источником, диапазонные запросы, объекты с неизвестной длиной и двоичное содержимое. Cloudflare обнаружила, что порог в 4 KiB исключает большое количество небольших запросов, но удаляет лишь около 1% байтов, которые в противном случае соответствовали бы условиям.
Как механизм работает между уровнями хранения?
При полном промахе кэша верхний уровень получает несжатые данные от источника, затем один раз сжимает их и сохраняет в формате zstd. Эта сжатая форма передаётся на нижний уровень, который хранит её и распаковывает только на пути запроса к клиенту. Если объект присутствует только на верхнем уровне, его можно переместить на нижний уровень без обращения к источнику.
Если объект уже находится на нижнем уровне, сетевой обмен или новое кодирование не требуются: данные zstd считываются с диска, распаковываются и передаются в путь ответа. Система записывает в метаданных, что объект хранится в сжатом формате, чтобы не сжимать его повторно при перемещении между уровнями хранения.
Анализ certi.news: что именно доказывает эксперимент?
Эксперимент показывает, что уменьшение объёма данных непосредственно на уровне хранения может иметь более значительный накопительный эффект, чем оптимизация только процесса заполнения кэша. Стоимость сжатия возникает при поступлении объекта, тогда как экономия пространства и пропускной способности повторяется при каждом его повторном использовании. Это особенно важно для операторов распределительных сетей крупного масштаба, где локальная ёмкость связана с объёмом контента, который можно хранить, а передача данных между уровнями — с потреблением внутренней сети.
Однако результаты не означают, что коэффициент 2,8 раза представляет весь интернет-контент или всю инфраструктуру Cloudflare. Тест производительности основывался более чем на миллионе запросов через десять серверов кэширования, но использовал экспериментальный источник из двух объектов размером около 195 и 272 KiB, которые хорошо поддавались сжатию. Компания признаёт, что до признания этого показателя репрезентативным для всего флота необходим более широкий набор типов и размеров контента.
Cloudflare планирует протестировать более высокие уровни zstd, расширить диапазон содержимого и размеров, настроить условия соответствия требованиям и изучить диапазонные запросы и предварительно сжатые ответы. Поэтому в текущем материале Cache Transcoding остаётся успешным прототипом в определённых условиях, а не объявлением об окончательном распространении механизма на весь трафик Cloudflare.