Налаштування CDN, за якого кеш не ламає динаміку
Кешування на CDN ламає динаміку не через малий TTL, а через відсутність правила: що допустимо віддавати з краю, а що зобов'язане доходити до джерела.
Коли статику, HTML і відповіді API обслуговує одна політика, частина сторінок застигає в застарілому вигляді, а частина промахується повз кеш за кожного запиту — і джерело отримує те саме навантаження, що й без CDN.
Промахи кешу майже завжди наслідок ключа.
Якщо в ключ потрапляють усі параметри рядка запиту й заголовки, що змінюються від користувача до користувача, той самий файл зберігається десятками копій: частка влучань падає до одиниць відсотків, а навантаження на джерело зростає кратно.
Ключ збирають під сенс ресурсу, а зайві параметри вирізають на краю — тоді повторні звернення справді обслуговуються з кешу.
Статика з хешем в імені файлу живе довго й оновлюється без інвалідації: новий файл приходить за новою адресою, а скидання кешу не потрібне взагалі.
З HTML так не можна — сторінку позначають як умовно свіжу, з перевіркою за ETag, або дають коротке вікно життя з фоновим оновленням stale-while-revalidate.
В API відповіді розмічають за призначенням: публічні довідники живуть за загальним строком, персональні позначаються як приватні й не кешуються на загальних вузлах.
Окреме завдання — вузьке місце віддачі. Джерело має обслуговувати лише те, що не може віддати край, а одночасні запити на той самий промах схлопуються в один похід до бекенду.
Тоді застарілий контент видно передбачувано й не довше за задане вікно, а навантаження на джерело перестає повторювати піки трафіку.
Розбираємо, як це закривається на практиці: які політики вішаємо на групи ресурсів і як перевіряємо, що кеш не підмінює свіжі дані.
Що дає вибудуваний кеш: влучання, швидкість, стійкість
Частка влучань у кеш і час відгуку сторінки
Ключ кешу й TTL задаємо за типами контенту: для статики з хешем в імені файлу — довгий, для HTML — короткий з ревалідацією за ETag, для API — окремий, з урахуванням заголовка авторизації та Vary.
На Cloudflare і аналогах такий набір піднімає частку влучань у кеш до 85–95% на типовому сайті, і саме вона, а не запас потужності джерела, визначає час відгуку сторінки: відповідь віддає найближчий вузол, а не сервер застосунку.
Розвантаження джерела та поведінка під піком
Кожне влучання — це запит, який до джерела не дійшов. На розпродажі або після публікації матеріалу джерело отримує на порядок менше звернень, і черга на ньому перестає бути вузьким місцем.
Директива stale-while-revalidate додає стійкості: відвідувачі отримують копію з кешу, поки оновлення йде у фоні й не блокує видачу.
Клас відмов, який зникає разом із налаштуванням
Правило «повільне або завалене джерело не повинне валити сторінку» виражається в stale-if-error: за відповіді помилкою клієнт отримує останню валідну копію.
Доступність під піком перестає залежати від того, чи витримало джерело навантаження, — і разом із налаштуванням зникає цілий клас відмов, який зазвичай і дає основну частку простоїв.
Варіанти кешування: пограничні вузли, проміжний шар, гібрид
Вибір між пограничним кешем, проміжним шаром і гібридною схемою визначається не «швидкістю», а часткою динаміки в трафіку, географією аудиторії та тим, наскільки болюча видача застарілої відповіді.
Пограничні вузли на кшталт мережі Cloudflare, власний кешувальний контур перед застосунком і комбінація обох вирішують різні завдання — порівнюємо за умовами застосовності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пограничний кеш | Статика й публічні сторінки, аудиторія розкидана за регіонами | Скидання за подією доходить до вузлів із затримкою; немає доступу до внутрішніх даних застосунку |
| Проміжний шар кешу | Багато приватних відповідей і складні правила скидання, застосунок однорідний | Увесь трафік іде через один контур — зростає зв'язність і вимоги до його відмовостійкості |
| Гібридна схема | Статика на пограничних вузлах, динаміка — на проміжному шарі | Складніша в супроводі: два набори політик і два місця для діагностики |
Роздача статики
Для статики ключ кешу будується за версіонованим іменем файлу, а не за шляхом. Тоді час життя можна ставити довгим і позначати відповідь незмінною: новий реліз приносить нові імена, а старі об'єкти доживають свій строк без примусового скидання.
Публікація зводиться до завантаження файлів у сховище, і погранична мережа підхоплює їх за першим запитом.
Правила для динаміки
Тут логіка зворотна: короткий час життя плюс скидання за подією. HTML віддається з малим строком і фоновим оновленням, щоб відвідувач не чекав на перезбирання сторінки, а персональні відповіді або не кешуються, або розділяються за ознакою авторизації.
Спалахи трафіку гасить мікро-кеш на кілька секунд — він знімає навантаження із застосунку й при цьому не перетворює дані на застарілі.
Порядок робіт: аудит трафіку, правила, перевірка, передача
Розбираємо не конфігурацію, а факти: як трафік ходить зараз, що на ньому кешується і де джерело отримує навантаження повторно. Без журналів звернень і поточних заголовків відповіді будь-яка правка правил — угадування. Тому ведемо роботи етапами, де кожен крок перевіряємо й зворотний.
-
Аудит трафіку. Беремо журнали звернень за репрезентативний період, рахуємо частку повторних запитів і влучань у кеш за групами контенту. Окремо виписуємо те, що кешувати не можна: авторизовані розділи, відповіді з персональними даними, кошик і оформлення замовлення.
-
Карта маршрутів. Зіставляємо шаблони адрес, параметри рядка запиту й заголовки, які впливають на ключ кешу. Фіксуємо місця, де за однією адресою віддаються різні відповіді, — це основне джерело «залиплих» сторінок і чужих даних у кеші.
-
Правила кешування. Задаємо роздільні TTL: довгі для статики й медіа, короткі для HTML з обов'язковою перевіркою актуальності, точкові для API — тільки там, де відповідь однакова для всіх. Прописуємо заголовки керування кешем на боці застосунку, а не лише в налаштуваннях мережі доставки.
-
Скидання й викладка. Налаштовуємо очищення за шляхами й мітками, прив'язуємо його до релізу: після публікації нового збирання користувач отримує свіжі файли, а не версію з кешу.
-
Перевірка на бойовому трафіку. Вмикаємо правила на частині трафіку, звіряємо частку влучань, коди відповідей і розбіжності з джерелом. Відкат — однією правкою конфігурації, без викатки застосунку.
-
Передача регламентів. Віддаємо документацію щодо правил, чек-ліст для релізу, схему скидання й набір метрик у моніторинг, щоб команда далі змінювала TTL і маршрути самостійно.
Конфігурації, правила інвалідації та схеми на виході
Налаштування закінчується не звітом, а комплектом артефактів, з яким команда замовника працює без нас. Конфігурація лежить у репозиторії, доступи розділені, а поведінку кешу описано так, що її можна відтворити на іншому середовищі й перевірити без автора змін.
- Файли конфігурації в системі контролю версій: правила кешування за типами контенту, заголовки Cache-Control і Vary, значення s-maxage і stale-while-revalidate, історія правок і відкат.
- Правила інвалідації: скидання за тегами й префіксами шляхів після релізу, повне скидання — лише як аварійна операція, окремий порядок для статики, відповідей API і HTML.
- Схема проходження запиту: що віддається з найближчого вузла, що йде до джерела, на якому кроці додаються заголовки й як рахується частка влучань у кеш.
- Розмежування доступу до панелі керування: ролі для розробки, підтримки й аналітики, заборона повного скидання без погодження, журнал дій за кожною зміною.
- Інструкції для підтримки: регламент на скидання кешу, перевірку свіжості після викатки й порядок дій за застарілої відповіді — з командами й очікуваним результатом.
- Карта відповідності типів контенту й TTL: які розширення та маршрути віднесено до кожного профілю — щоб новий розділ сайту не випадав зі схеми під час додавання.
Кейс: як прибрали просідання й знизили навантаження на джерело
До: кеш налаштовували «на око»
Проєкт — вітрина з каталогом і особистим кабінетом: статика, HTML-сторінки та API за одним CDN. У кеш потрапляло близько 40% запитів, а TTL стояв однаковий — година на все, включно з відповідями API з персональними даними.
У пікові години джерело отримувало майже весь потік: час відгуку на 95-му процентилі доходив до 1,9 с, а після кожної викладки черговий вручну скидав кеш за десятками шляхів, часом забуваючи частину — користувачі бачили стару ціну й стару наявність.
Що змінили
Розвели правила за типами контенту. Статику віддаємо з довгим TTL і версіонуванням в імені файлу — оновлення не потребує скидання взагалі. HTML кешуємо коротко, з віддачею застарілої копії, поки перезбирання тягне свіжу.
Відповіді API кешуються лише там, де ключ включає користувача й параметри запиту, решту позначено як приватне. Замість ручних скидань — мітки на контент і один виклик інвалідації на викладку: Cloudflare сам розкочує його по вузлах.
Після
Частка відповідей з кешу зросла до 94%, звернення до джерела впали вчетверо, а час відгуку під тим самим піком — з 1,9 до 0,3 с. Ручних скидань стало одне-два на тиждень замість двох сотень, і майже всі — штатний крок викладки.
Видача перестала «дрижати»: прострочена копія віддається миттєво, поки свіжа їде з джерела, тому користувач не бачить ані порожнього екрана, ані старої ціни після оновлення каталогу.
Чим відрізняється кешування статики від API під час налаштування CDN?
Статика й відповіді API застарівають із різною швидкістю: файл збирання з хешем в імені не змінюється до наступного релізу, а список замовлень втрачає актуальність за секунди. Одне правило на весь домен дає або застарілі дані в інтерфейсі, або кеш, який не віддає нічого.
| Тип контенту | Час життя запису | Перевірка актуальності |
|---|---|---|
| Збирання та зображення з хешем в імені | до наступного релізу | не потрібна: ім'я змінюється разом із файлом |
| HTML і сторінки каталогу | хвилини | умовний запит за ETag, відповідь 304 |
| Публічні відповіді API | секунди | перевірка на актуальність або віддача старої копії з фоновим оновленням |
| Авторизовані відповіді | не кешуються | обхід кешу за заголовком авторизації |
Розділення правил робиться не на весь домен, а на рівні шляхів і типів контенту: у статики довгий строк життя, в API — короткий з обов'язковою перевіркою.
Ключ кешу враховує адресу разом із параметрами запиту й мовою, тому видача за фільтрами та локалями не змішується, а авторизовані відповіді виносяться окремим правилом.
Перевірка актуальності відокремлює свіжість від повторного завантаження: вузол віддає відповідь 304, поки вміст не змінився, і повний об'єкт — щойно змінився. За короткого часу життя запису перший запит після закінчення строку йде до джерела, решта отримують уже готову копію.
Інвалідація прив'язана до випуску: під час деплою скидаються лише зачеплені шляхи або теги, а не кеш цілком. Так довгий строк для статики й короткий для API уживаються в одній схемі без ручних правок.
Сумніви на старті: інвалідація, приватні дані, зневадження
Скидання кешу, приватні розділи й перевірка того, що кеш реально працює, — три питання, які випливають ще на етапі проєктування політики, а не після запуску. Нижче — короткі відповіді на них.
Як скинути кеш, якщо вийшов помилковий реліз?
Точкова інвалідація за шляхами й мітками — робочий інструмент, але вона не миттєва: на вузлах кешу копія живе до закінчення свого строку.
Тому політику будуємо так, щоб помилку можна було зняти, не зачепивши решту: статика й скрипти публікуються з версією в імені файлу, а стара версія витісняється сама в міру оновлення посилань.
Чи не потраплять приватні дані в загальний кеш?
Приватні розділи, особистий кабінет і авторизовані запити ми не кладемо в загальний кеш узагалі — це правило фіксується на рівні конфігурації, а не на дисципліні розробників. Логіка проста: якщо відповідь залежить від того, хто її запитав, вузол кешу не має права її зберігати. Публічним залишається лише те, що однакове для всіх.
Як переконатися, що кеш працює як задумано?
Спостережуваність кешу — це частка влучань у розбивці за типами контенту: окремо статика, окремо сторінки, окремо відповіді бекенду. Якщо за картинками й стилями частка влучань висока, а за сторінками раптово просіла, отже правило зламано або з'явився новий параметр в адресі.
Ці метрики виводимо на дашборд разом із даними сервера-джерела — видно, яка частка трафіку до нього взагалі не доходить.
Що робити під час інциденту: частина користувачів бачить стару версію?
Розбір інциденту починається зі звірки: що віддав вузол кешу і що віддав джерело на ту саму адресу. Далі дивимося, на якому вузлі залишилася стара копія, знімаємо її точково й правимо правило, через яке вона пережила оновлення.
Найчастіше причина — забута мітка або надто довгий строк для адреси, яка змінюється за кожного релізу.
Обговоримо вашу схему кешування і повернемося з оцінкою
Точна оцінка й план робіт тримаються на розумінні того, як влаштований ваш трафік і як ви публікуєте контент.
Нижче — те, що розбираємо на першій розмові: без цих ввідних будь-яка політика кешування виходить усередненою і або переплачує за промахи, або починає віддавати застарілі сторінки.
Обговоримо завдання предметно — за кожним пунктом нам достатньо вашої статистики по вузлах, доступу до конфігурації та досвіду експлуатації.
- Профіль трафіку: частки статики, запитів до API і розмітки, добові піки, співвідношення унікальних і повторних звернень — від цього залежить досяжна частка влучань у кеш.
- Типи контенту й допустиме застарівання: каталог, стрічка, персональні й авторизовані відповіді — що можна тримати в кеші, а що зобов'язане йти на джерело.
- Обмеження джерела: запас за пропускною здатністю, ліміти на кількість звернень і поведінка за масового промаху кешу після скидання.
- Вимоги до скидання кешу: як швидко правка має ставати видимою, чи є версіонування шляхів або групові мітки для інвалідації.
- Схема публікації: як реліз доїжджає до вузлів і як це узгоджується з інвалідацією, щоб не віддавати змішані версії.
- Доступи й права: де зберігається конфігурація, хто змінює правила і як фіксуються зміни TTL.
- Режим підтримки: чи потрібен моніторинг частки влучань, оповіщення про зростання трафіку на джерело й регламент правок політики.
Опишіть завдання — повернемося з оцінкою та планом робіт: розкладка TTL за типами контенту, порядок інвалідації й склад моніторингу.
