Сегодня мы объединяем Data Cache с Runtime Cache, предоставляя разработчикам единый продукт для кэширования данных в различных фреймворках и API. Если вы используете кэширование fetch в Next.js или unstable_cache, вам не потребуется менять свой код. Проекты тарифов Pro и Enterprise получат увеличенные квоты хранилища.
Runtime Cache позволяет вашему коду повторно использовать полученные или вычисленные данные в разных запросах без необходимости развертывать отдельную службу кэширования. За последний год мы улучшили производительность чтения при пиковых нагрузках, увеличили квоты хранилища и упростили анализ использования кэша.
Copy link to headingЗачем мы создали Runtime Cache
Data Cache изначально был запущен как служба кэширования данных Vercel для App Router в Next.js, используемая для кэширования fetch и unstable_cache. В отличие от кэширования в CDN, которое сохраняет полные HTTP-ответы, Data Cache сохраняет данные, которые ваше приложение использует для формирования этих ответов. Например, страница товара может повторно использовать кэшированные данные каталога, формируя персональный ответ для каждого посетителя.
Мы хотели, чтобы разработчики имели доступ к этой службе независимо от Next.js. В прошлом году мы представили Runtime Cache с прямым API: getCache из @vercel/functions. Приложения могут использовать его для проверки флажков функций (feature flags) в Routing Middleware, кэширования контента CMS во время сборки, а также для кэширования данных в приложениях SvelteKit и Nuxt.
Фреймворки также могут предоставлять доступ к этой службе через собственные API. На Vercel сам Next.js использует API Runtime Cache для функции 'use cache: remote', которая кэширует результаты работы функций и компонентов.
Copy link to headingКак работает Runtime Cache
Инфраструктура, лежащая в основе Runtime Cache, представляет собой распределенную службу кэширования, общую для множества команд. API на Go обрабатывает запросы, опираясь на пулы Redis в каждом регионе Vercel. Каждый час служба обрабатывает более 440 миллионов операций чтения и переносит свыше 18 ТБ данных.
Каждый регион имеет собственный кэш. Попадание в кэш (cache hit) требует одного круга запроса к службе кэширования в том регионе, где выполняется ваш код. Vercel управляет аутентификацией с помощью краткосрочных учетных данных, поэтому вам не нужно управлять ключами API.
При промахе кэша (cache miss) ваше приложение или фреймворк получает или вычисляет значение и записывает его в кэш этого региона. Служба не проверяет наличие кэшированной копии в других регионах.
Каждая кэшированная запись хранит свои теги и время записи. Когда служба считывает запись, она проверяет отдельное хранилище тегов в том же регионе на предмет временных меток инвалидации этих тегов. Если какой-либо тег был инвалидирован после записи элемента, запись считается устаревшей.
Например, приложение может пометить все кэшированные данные о товарах тегом catalog. Когда каталог изменяется, инвалидация этого тега записывает всего одну временную метку, даже если этим тегом владеют миллион записей. Службе не нужно находить и удалять эти записи по отдельности.
Инвалидация немедленно обновляет хранилище тегов в регионе, получающем запрос. Общая инфраструктура тегов Vercel, которая также используется CDN, распространяет временную метку через глобальный конвейер рассылки, обычно доставляя ее в другие регионы в течение нескольких сотен миллисекунд.
Ваше приложение или фреймворк выбирает, что кэшировать, и обрабатывает промахи. Runtime Cache отвечает за региональное хранение, аутентификацию и распространение инвалидации тегов по регионам.
Copy link to headingЧто мы выпустили
Copy link to headingБолее быстрое чтение при пиковых нагрузках
Проверка актуальности записи добавляет зависимость к каждому попаданию в кэш. Во время всплесков трафика медленный шард в хранилище тегов мог задерживать чтение даже тогда, когда кэшированное значение уже было доступно.
Мы добавили механизмы защиты (circuit breakers), которые позволяют оперативно проверять актуальность с помощью временных меток тегов, кэшированных в памяти, чтобы запросы на чтение могли выполняться, не дожидаясь ответа от медленного шарда. Во время такого резервного переключения чтение может на короткое время считать недавно инвалидированные данные актуальными.
Мы включили эти механизмы защиты во всех регионах в августе. Во время самых сильных всплесков в нашем крупнейшем регионе задержка чтения службы кэширования на перцентиле p99 снизилась примерно до одной пятой от прежнего уровня при сопоставимом трафике. Оповещения дежурных инженеров об этом типе сбоев прекратились.
Copy link to headingБольше хранилища и меньше вытеснений
В июне мы увеличили квоты хранилища Runtime Cache для проектов Pro, а в октябре — для проектов Enterprise, предоставив приложениям больше места для повторно используемых данных. Это снижает необходимость вытеснять кэшированные записи ради освобождения места под новые данные. Среди проектов Enterprise с частыми вытеснениями коэффициент промахов кэша сократился примерно вдвое в течение суток.
Copy link to headingБольше прозрачности в поведении кэша
Мы добавили маркеры развертывания, причины ревалидации и показатель использования записи в раздел Runtime Cache интерфейса Observability. Это помогает сопоставлять изменения в поведении кэша с релизами, видеть причины обновления записей и выявлять данные, которые записываются в кэш, но редко считываются.
Copy link to headingИнтеграция Data Cache в Runtime Cache
Мы упрощаем кэширование на Vercel, объединяя все функции на базе Runtime Cache. До сих пор кэширование fetch в Next.js и unstable_cache использовали Data Cache, в то время как getCache и 'use cache: remote' использовали Runtime Cache. Миграция объединяет все четыре API под управлением Runtime Cache, предоставляя вам и агентам кодирования единый набор квот хранилища и инструментов мониторинга.
Если вы используете кэширование fetch или unstable_cache, в вашем коде ничего не меняется. На тарифе Pro каждый проект и окружение получают собственную квоту памяти, в 8 раз превышающую прежний пул Data Cache для всей команды. Проекты Enterprise получают в 10 раз больше хранилища Data Cache, чем раньше.
Операции чтения и записи Data Cache, которые ранее не тарифицировались, теперь будут следовать ценовой политике Runtime Cache. Новые команды начинают использовать Runtime Cache автоматически, а существующие команды получат информацию о миграции и выставлении счетов заранее.
Ознакомьтесь с журналом изменений (changelog), чтобы узнать подробности о развертывании, ценообразовании и раннем подключении. Перед миграцией проверьте использование кэша и следуйте руководству по оптимизации, чтобы сократить избыточные чтение и запись.
