CDN cache invalidation: чому застарілий контент живе годинами
Правку викладено на джерело, викладка пройшла без помилок — а користувачі ще годинами отримують попередню версію сторінки. Причина не в релізі: між джерелом і браузером стоїть кеш із власним строком життя, і він не знає, що контент оновився.
CDN cache invalidation у такій схемі залишається ручною операцією з панелі, а не частиною процесу публікації.
Корінь — у розсинхронізації версій. Строк життя кеша задано числом: доба на статику, хвилини або години на розмітку. Публікація ж — це подія.
Поки ці дві сутності живуть окремо, кожен випуск перетворюється на лотерею: частина вузлів уже віддає нову відповідь, частина тримає стару, і конкретний користувач бачить ту версію, яку встиг закешувати першою.
Плата вимірювана, і платить її не інфраструктура, а підтримка. Скарги на стару версію надходять туди, а не до інженерів, і розбір кожної заявки починається із питання «кеш чистили?».
Далі — ручні скидання за URL або по цілій зоні через панель керування, наприклад Cloudflare, де одруківка в шляху залишає застарілий контент жити далі без жодних сигналів.
Окремий біль — скидання всієї зони «про всяк випадок»: воно знімає навантаження з кеша й обрушує трафік на джерело, а наступна правка знову потребує ручної операції.
Розбираємо, як це закривається: прив’язкою інвалідації до публікації, скиданням за тегами замість зон і перевіркою, що після викладки всі вузли віддають нову версію.
Що дає автоматизація скидання: строки, влучання, частка відмов
Автоматичне скидання будується не на повному очищенні кеша, а на мітках: збірка проставляє теги на групи об’єктів — каталог, картку, статику, — а публікація надсилає на периферію лише список змінених міток.
Повне очищення змушує край заново тягнути весь контент із джерела, і за частих релізів це найдорожча операція з можливих. Режим міток скидає десятки об’єктів замість мільйонів.
На графіках це видно одразу: частка влучань у кеш перестає пилкоподібно провалюватися після кожного релізу й тримається в коридорі, близькому до верхньої межі. Навантаження на джерело стає рівним — зникають сплески, коли весь край одночасно перезапитує одні й ті самі сторінки.
Швидкість публікації змінюється якісно: правка доходить до користувача за секунди, а не після спливання часу життя об’єкта в кеші. Заодно зникає цілий клас відмов — «напівоновлений реліз», коли браузер отримує нову розмітку зі старим оформленням або скриптом. Скидання пов’язаних міток одним набором закриває цю розсинхронізацію.
Платформи на кшталт Cloudflare уміють скидати за мітками майже миттєво, але без правил тегування кожен реліз перетворюється на ручний список шляхів. Ми описуємо схему міток один раз — далі скидання викликається з конвеєра збірки й не залежить від того, хто саме випускає зміну.
Способи скидання: за тегом, за шляхом, за версією збірки
Інвалідація на межі не атомарна: поки команда розходиться по десятках вузлів, частина відвідувачів отримує свіжий об’єкт, частина — попередній.
Точність скидання й швидкість поширення пов’язані оберненою залежністю, тому вибір способу — це вибір класу відмов, який ви готові терпіти.
Ламається в сусідніх варіантів різне: за тегом — забутий тег на новому ресурсі, за шляхом — неврахований параметр в адресі, повне скидання — удар усього навантаження по джерелу. Нижче — межі застосовності кожного.
| Варіант | Коли підходить | Чим платите |
|---|---|---|
| Скидання за тегом | один об’єкт входить до десятків сторінок: каталог, картка, видача | кожна відповідь джерела має нести тег; пропущений тег — залиплий контент до кінця строку життя |
| Скидання за шляхом або шаблоном | статика й сторінки з передбачуваною адресою | межі шаблону: параметри в адресі, ліміт на кількість шляхів в одному запиті |
| Версіонування збірок | зібрані скрипти, стилі, шрифти | попередні версії живуть до кінця строку; потрібен реєстр активних ключів |
| Повне скидання | аварійний випадок, помилка в даних | шторм запитів на джерело й просідання бази; вузли оновлюються нерівномірно |
На практиці способи комбінують: версія збірки — для статики, теги — для відповідей із даними, повне скидання залишають аварійним важелем з окремими правами доступу.
Впровадження: від інвентаризації контенту до регламенту скидання
Інвалідація кеша — не один виклик у момент релізу, а послідовність, де кожен крок залишає перевірюваний результат. Якщо пропустити інвентаризацію або залежності, після публікації користувачі отримують суміш версій: розмітка оновилася, а стилі чи дані картки — ні. Порядок робіт, за яким ми ведемо впровадження:
-
Інвентаризація контенту. Розмічаємо все, що віддається через кеш: статика з версією в імені, сторінки, відповіді сервісів, медіа. Для кожного типу фіксуємо допустимий час життя — результат оформлюємо таблицею «тип — строк життя — спосіб скидання».
-
Схема залежностей. Будуємо карту об’єктів, які змінюються разом: сторінка каталогу й картка, шаблон і спільний фрагмент, стрічка та її елементи. Без неї адресне скидання залишає несумісні поєднання — отримуємо граф зв’язків і список складених об’єктів.
-
Налаштування правил скидання. Відходимо від повного очищення до адресного: скидання за мітками, окремі правила для шляхів із параметрами, розділення жорсткого й м’якого режиму. Результат — конфігурація правил у системі контролю версій.
-
Автоматизація в конвеєрі публікації. Виклик скидання стає кроком випуску й спрацьовує після успішного розгортання, з повторами при збої та захистом від дублювання. Результат — крок випуску й журнал звернень замість ручних скидань.
-
Перевірка після публікації. Звіряємо мітки версії та заголовки відповідей на вибірці вузлів у різних регіонах, а не на одному. Результат — автоматичні перевірки й звіт про узгодженість.
-
Регламент і відкат. Описуємо дії при невдалому скиданні, ліміти частоти й захист від лавини звернень. Результат — регламент і відпрацьований сценарій відкату до попередньої версії.
На виході виходить не набір скриптів, а керований процес: скидання запускається публікацією, а не вручну, і підтверджується перевірками.
Конфігурації, схеми залежностей і регламенти скидання
Комплект зібрано так, щоб чергова зміна працювала без нас: інженер відкриває документ, знаходить потрібне правило, скидає кеш і розуміє, що перевірити після. Нижче — що саме залишається у вас на руках разом із налаштованою автоматизацією CDN cache invalidation.
- Карта правил кешування — які шляхи й типи відповідей кешуються, який час життя задано та які заголовки джерела його перевизначають.
- Схема залежностей — граф «сторінка → шаблон → спільні блоки → дані», за яким видно, що інвалідувати при правці одного компонента, не очищаючи весь домен.
- Регламент скидання — порядок дій для трьох сценаріїв: точкова правка, реліз розділу, аварійний відкат на попередню версію.
- Шаблони запитів — скидання за адресою, за префіксом шляху й за міткою, з черговістю та лімітами, щоб не вийти за квоти провайдера.
- Прив’язка до публікації — правило, що запускає скидання після викладки статики, із захистом від повторних спрацьовувань при перезапуску кроку збірки.
- Чек-лист перевірки — еталонний запит, порівняння заголовків відповіді й контроль на кількох вузлах: як переконатися, що об’єкт справді оновлено.
- Матриця відповідальності — хто скидає при штатному релізі, хто підтверджує результат і кого підіймати при розходженні між вузлами.
- Документація щодо кешу та журнал інцидентів — ухвалені рішення, обхідні шляхи й розбір випадків, коли скидання не спрацювало з першого разу.
Усе лежить поруч із конфігурацією у вашому репозиторії, з версіонуванням: зміни регламенту проходять рев’ю так само, як код.
Кейс: затримка оновлення скоротилася з годин до хвилин
Що було
Видання з відвідуваністю в мільйони сторінок на добу тримало HTML і статику на CDN із довгим строком життя в кеші. Частка влучань трималася близько 60%, джерело було спокійним — до першої термінової публікації.
Правку на краю мережі бачили лише після ручного скидання, і черговий скидав кеш повністю по зоні: редакція чекала оновлення від 40 хвилин до кількох годин.
Плата за це — сплеск на джерелі. Після повного скидання всі периферійні вузли йшли за одними й тими самими об’єктами: запити до джерела зростали кратно, час відповіді збільшувався, частина закінчувалася помилкою. Кеш у години пік намагалися не чіпати, тому правки накопичувалися до ночі.
Що змінили
Перейшли на скидання за тегами: кожній сутності — матеріалу, розділу, шаблону — присвоєно ключ, і інвалідація йде за ключем, а не за адресами.
Статику з хешем в імені випустили з довгим строком і позначкою «незмінна», HTML — з коротким строком і віддачею застарілої копії, поки підтягується свіжа.
Скидання стало кроком випуску: викладка, інвалідація заторкнутих тегів, підтвердження від API і лише потім перемикання вказівника на нову версію. Працюємо через Cloudflare — її API скидання за тегами прибрав ручні операції.
Що вийшло
Затримка оновлення впала з годин до десятків секунд: медіана — близько 40 секунд, 95-й процентиль — менше двох хвилин. Частка влучань у кеш зросла з 60% до 96%, бо довгі строки стали безпечними.
Навантаження на джерело в момент скидання зростає в межах 10–15% замість кратного сплеску: відмов немає, а повернення до попередньої версії займає секунди — достатньо повернути попередній вказівник.
Чим відрізняється інвалідація за тегом від скидання за шляхами?
Скидання за шляхами — явний список адрес: застосунок перелічує URL, які потрібно прибрати з кеша. Тег-інвалідація працює інакше: об’єкт при віддачі позначається набором міток, і один виклик за міткою знімає все, що до неї прив’язано. Різниця не у швидкості відповіді, а в тому, хто відповідає за повноту списку — застосунок чи кеш.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Скидання за шляхами | Точкові правки, невеликий набір передбачуваних адрес | Не атомарне: скидання йде посторінково. Повноту списку тримає застосунок, кожен новий шаблон адреси потребує оновлення правил |
| Тег-інвалідація | Каталоги, стрічки, картки, де одна сутність віддається за багатьма адресами | Потрібна підтримка міток на стороні роздачі та розмітка в застосунку, є ліміт міток на об’єкт, помилка в проставлянні ключа тихо залишає запис у кеші |
| Версіонування імен | Статика: скрипти, стилі, зображення, шрифти | Потрібна збірка, де ім’я змінюється разом із вмістом; не працює для адрес, які не можна переписати |
Поведінка при частковому спрацьовуванні відрізняється сильніше, ніж здається. Якщо у списку шляхів не вистачило однієї адреси — наприклад, сторінки каталогу з фільтром — користувачі бачать суміш версій різного віку, і розходження тримається до спливання часу життя запису.
Тег-інвалідація скидає набір цілком, але частковий результат усе одно можливий: об’єкт, якому ключ не проставили при віддачі, залишається в кеші й непомітно випадає зі скидання — тому мітки варто перевіряти тим самим набором тестів, що й самі сторінки.
При змішаному контенті підходи не конкурують. Статику роздають під версіонованими іменами, динамічні сторінки й фрагменти позначають мітками, а скидання за шляхами залишають для точкових правок на кшталт редиректу або сторінки акції.
Мітки при цьому заводять за смисловими сутностями — картка, категорія, стрічка — щоб публікація одного об’єкта не скидала весь кеш і не змушувала джерело перезбирати все заново.
Питання, які виникають на етапі налаштування скидання
На етапі налаштування виникають сумніви, яких не видно в демо: чи можна скинути лише змінені об’єкти, що робити при частих правках у розпал акції та як це працює, якщо контент іде через кілька мереж доставки.
Нижче — короткі відповіді за кожним пунктом, щоб рішення можна було оцінити за ризиками, а не за обіцянками.
Скидання всього кеша чи лише частини?
Повне скидання б’є по кешу цілком: наступний сплеск трафіку йде на сервер-джерело, і час відповіді зростає на всіх сторінках, а не лише на зміненій.
Тому об’єкти розмічаються тегами кеша — за розділом, шаблоном сторінки або ідентифікатором товару — і при публікації скидається лише заторкнута група. Правка однієї картки не зачіпає каталог і головну.
Чи є обмеження на частоту звернень?
Так, і в кожної мережі доставки вони свої. При масових правках — імпорт каталогу, нічна викладка — запити ставляться в чергу, об’єднуються й дедуплікуються: тисяча змін іде одним пакетом, а не тисячею звернень.
Додаємо затримку на згортання серії правок і окремий пріоритет для термінових, щоб не впертися в ліміт у момент розпродажу.
Контент роздається через кілька незалежних мереж — як бути?
Тоді скидання не можна запускати з панелі однієї з них. Потрібен єдиний шар керування: подія публікації викликає розсилання в усі мережі, кожна отримує свій набір тегів, а стан скидання фіксується — повторний запуск не дублює роботу.
Різний час поширення перевіряється за контрольним об’єктом, і лише після цього завдання вважається закритим.
Обговорімо вашу схему оновлення контенту
Оцінка «за описом» майже завжди йде вбік: схема скидання кеша залежить від того, як контент народжується, з якою частотою змінюється і що вже налаштовано на периметрі. Щоб рахувати за фактом, а не за припущеннями, надішліть таке.
- склад контенту: статика, сторінки каталогу, персоналізовані відповіді, медіа — що кешується на загальному рівні, а що адресно;
- частоту й характер правок: планові релізи, потік оновлень цін і залишків, термінові зняття матеріалів;
- поточні правила кешування: заголовки керування, час життя об’єктів, ключі, за якими формується кеш;
- журнали звернень до периметра за кілька тижнів: частка влучань у кеш, коди відповідей, найчастіші адреси;
- сценарії аварій: що публікували, який контент залишався застарілим, як довго це трималося й як гасили;
- доступи: панель керування периметром, репозиторій конфігурації, інструменти публікації — на читання достатньо.
У відповідь повернемо розбір за категоріями: де достатньо короткого часу життя об’єкта, де потрібне скидання за міткою, а де — версіонування адреси.
Окремо покажемо, скільки запитів на скидання йде при звичайному релізі та при масовій правці, і запропонуємо порядок впровадження з точками відкату.
