Как мы ускорили облачное кэширование: новая стратегия для AWS, GCP, Azure и Oracle Cloud

В 2021 году мы выпустили Smart Tiered Cache (Умное многоуровневое кэширование). Идея: для каждого источника вашего сайта Cloudflare выбирает единственный лучший вышестоящий центр обработки данных для маршрутизации, основываясь на задержке в реальном времени. Щелкните одним переключателем, и мы найдем самый быстрый путь от нашей сети к вашему источнику.

Это работает, пока IP-адрес источника находится в одном фиксированном месте. Публичные облачные источники обычно не имеют такого фиксированного местоположения. Они находятся за anycast или региональными unicast-интерфейсами, поэтому один IP-адрес источника может казаться одинаково близким сразу к десятку центров обработки данных Cloudflare — и зонды задержки не могут за что-то зацепиться. Smart Tiered Cache справляется с этим безопасным способом: когда нет явного победителя, он переключается на несколько вышестоящих уровней. Ничего не ломается. Вы просто теряете то, ради чего стоило иметь единственный ближайший уровень, — эффективность кэширования.

Smart Tiered Cache for Public Cloud Regions (Умное многоуровневое кэширование для регионов публичных облаков) исправляет это, позволяя вам указать подсказку о регионе облака. С этой подсказкой Cloudflare может сопоставить источники публичных облаков с правильным регионом и выбрать лучшие первичные и резервные вышестоящие уровни, даже если сам IP-адрес источника выглядит anycast или неоднозначным.

С момента запуска Smart Tiered Cache стал самой популярной топологией многоуровневого кэширования среди клиентов Cloudflare. Он доступен для всех тарифных планов бесплатно.

Значительная часть нашей работы направлена на его постоянное улучшение. Со временем мы расширили Smart Tiered Cache для поддержки большего количества архитектур источников, включая:

• Ноябрь 2024: Smart Tiered Cache for R2: Мы научили Smart Tiered Cache автоматически выбирать ближайший вышестоящий уровень к фактическому местоположению корзины R2, уменьшая задержку без дополнительной настройки.

• Январь 2025: Smart Tiered Cache for Load Balancing: Мы расширили Smart Tiered Cache, чтобы он выбирал один оптимальный вышестоящий уровень для всего пула балансировки нагрузки, чтобы все источники в пуле использовали один и тот же кэш, улучшая процент попаданий.

У каждого из этих улучшений была общая цель: понять инфраструктуру источника клиента и автоматически сделать наилучшее для этой инфраструктуры.

Хотя мы уже некоторое время улучшали эту систему, у клиентов всё ещё была общая проблема: Smart Tiered Cache не работал, когда источник находится за anycast или региональной unicast-сетью, потому что такая архитектура мешала нам определить местоположение источника. И это не было редким случаем. Источники, размещённые у публичных облачных провайдеров за anycast-адресами, составляют растущую часть Интернета.

Сегодня мы устраняем этот пробел для источников, размещённых на AWS, GCP, Azure и Oracle Cloud.

Smart Tiered Cache работает путём измерения задержки от каждого центра обработки данных Cloudflare до IP-адреса источника. Центр обработки данных с наименьшей задержкой становится вышестоящим уровнем: единственной точкой, через которую все промахи кэша направляются к вашему источнику. Концентрируя промахи кэша в одном центре обработки данных, вы получаете более высокий процент попаданий в кэш, меньше подключений к вашему источнику и меньшую задержку при загрузке с источника. Это хорошо работает, когда источник имеет фиксированный unicast-адрес, который можно надёжно зондировать.

Многие облачные провайдеры используют anycast или региональные unicast-сети для своих балансировщиков нагрузки, внешних сервисов и региональных точек входа. Когда мы зондируем эти IP-адреса, источник кажется «близким» сразу ко многим центрам обработки данных. Это происходит потому, что IP-адрес представляет собой внешний интерфейс облачного провайдера, а не единое физическое местоположение источника. Разные центры обработки данных Cloudflare могут достигать разных ближайших облачных границ для одного и того же IP-адреса, а провайдер затем передаёт запрос по своей собственной сети к фактическому бэкенду. Таким образом, Smart Tiered Cache не может уверенно выбрать один лучший вышестоящий уровень.

На практике это может привести к петлевому трафику через континенты, добавляя целый дополнительный круговой путь. Предположим, ваш источник находится в Сингапуре за anycast-адресом от облачного провайдера. Из-за особенностей anycast наш центр обработки данных в Чикаго может показать наименьшую задержку при зондировании этого IP-адреса. Smart Tiered Cache тогда выберет Чикаго в качестве вышестоящего уровня. Результат: запрос от конечного пользователя в Азии попадает в ближайший центр обработки данных Cloudflare, направляется через континент к вышестоящему уровню в Чикаго, а Чикаго загружает данные из источника обратно в Сингапуре, дважды пересекая океан. Эта петля добавляет сотни миллисекунд задержки и является одной из наиболее часто сообщаемых проблем клиентов с облачными источниками.

^{Пример петлевого трафика: трафик направляется к вышестоящему уровню в Чикаго только для того, чтобы получить данные из источника в Сингапуре, что приводит к ненужному межконтинентальному круговому пути.}

Чтобы устранить этот ненужный обмен, Smart Tiered Cache научился обнаруживать anycast-источники с помощью физического ограничения: скорости света. Мы измеряем задержки зондирования из нескольких контрольных центров обработки данных по всему миру до источника. Если суммарные задержки от двух контрольных центров быстрее, чем свет мог бы физически пройти по оптоволокну между ними, значит, источник отвечает из нескольких мест, а не из одного. Это означает anycast.

^{Мы обнаруживаем anycast-источники, сравнивая задержки зондирования из нескольких центров обработки данных Cloudflare. Если два пути быстрее, чем физически возможно для одного местоположения источника, источник, вероятно, отвечает из нескольких мест.}

Когда Smart Tiered Cache обнаруживает anycast-источник, он действует наверняка: не привязывает этот IP к одному вышестоящему уровню. Вместо этого он переключается на топологию многоуровневого кэширования с несколькими вышестоящими уровнями. Многоуровневое кэширование по-прежнему работает, но распределение трафика по нескольким уровням вместо одного означает, что больше запросов достигает источника. Для некоторых конфигураций это приемлемый компромисс. Но если вы хотите один вышестоящий уровень, близкий к источнику, который находится в публичном облаке за anycast-адресами, до сих пор не было хорошего варианта — до сих пор.

Из панели управления Cloudflare перейдите в Caching > Tiered Cache > Origin Configuration (Конфигурация источника). Найдите IP-адрес источника, нажмите «Set Region Hint (Установить подсказку региона)» и укажите облачный регион (например, aws:us-east-1 или gcp:europe-west1). Smart Tiered Cache возьмёт управление на себя. Обратите внимание: в панели управления подсказки региона можно установить только для источников, чьи IP-адреса мы определили как anycast.

^{На странице Tiered Cache перейдите к таблице Origin Configuration и нажмите значок редактирования рядом с IP-адресом источника, чтобы установить подсказку региона.}

Вы можете устанавливать подсказки по одному IP-адресу или массово редактировать облачные регионы для всех IP-адресов источников сразу. Помимо панели управления, такая же конфигурация доступна через API и через Terraform, так что вы можете интегрировать её в свои существующие рабочие процессы «инфраструктура как код».

Мы запускаемся с AWS, GCP, Azure и Oracle Cloud, а в будущем добавим больше провайдеров.

Каждые несколько часов мы загружаем последние файлы диапазонов IP-адресов от каждого поддерживаемого облачного провайдера. Эти файлы сопоставляют каждый облачный регион с его текущим набором IP-префиксов, поэтому, когда провайдер добавляет, удаляет или переназначает подсеть, мы это фиксируем.

^{Схема системы Smart Tiered Cache for Public Cloud}

Мы сопоставляем эти подсети с нашей базой данных вышестоящих уровней, которая строится на основе непрерывного зондирования задержки, обновляемого каждые 15 минут. Для каждого облачного региона каждая совпадающая подсеть добавляет взвешенный голос на основе текущего назначения вышестоящего уровня. Вышестоящий уровень с самым сильным сигналом становится первичным вышестоящим уровнем региона. Первичный и резервный уровни всегда берутся из разных точек присутствия (PoP), поэтому потеря одной PoP не может вывести из строя обе.

В некоторых регионах недостаточно данных зондирования — например, возможно, облачный провайдер нового региона ещё разворачивается, или в регионе нет источников, подключённых к Cloudflare, поэтому голосовать нечем. Мы возвращаемся к географии: ближайшая из наших Tier 1 PoP. По мере того как источники появляются в сети и накапливаются данные зондирования, регион незаметно переключается с этой географической догадки на вариант, подтверждённый реальными данными.

Всё это означает, что работа по выбору оптимального региона для вашего кэша — постоянное зондирование, алгоритмический выбор лучшего вышестоящего уровня для каждого региона, географические запасные варианты, отказоустойчивость между PoP — выполняется на нашей стороне. Ваша задача — выбрать подсказку региона.

Если ваш anycast-оригин находится в публичном облаке, вы можете включить это сейчас. В панели управления перейдите в Caching > Tiered Cache > Конфигурация ориджина. Найдите IP-адрес вашего ориджина, нажмите Set Region Hint и выберите свой регион.