Чому Azure CDN не прискорює сайт: розбір типових збоїв
Підключення Azure CDN саме по собі не прискорює сайт.
Якщо правила кешування, сертифікати та порядок очищення не налаштовані під реальну структуру статики, метрики не змінюються: час відповіді той самий, навантаження на джерело не падає, частина відвідувачів бачить зламані сторінки. Доставка контенту — не перемикач, а набір пов'язаних параметрів конфігурації.
Найчастіший збій — кеш віддає застарілу версію статики. Вузол спирається на заголовки кешування від джерела: якщо їх немає або термін життя виставлено невірно, файли або не кешуються, або залишаються в кеші після релізу.
Після викладки нової версії браузер отримує старий скрипт упереміш із новим оформленням — інтерфейс розсипається, форма не надсилається.
Другий збій — HTTPS відмовляє на піддомені статики. Сертифікат випущено на основний домен і він не покриває окремий піддомен, або віддається неповний ланцюжок сертифікатів. Браузер блокує такі ресурси: сторінка відкривається, але залишається без зображень і стилів.
Третій збій — джерело не розвантажується. Якщо вузол не віддає статику з кешу, кожен запит іде на сервер застосунку, і пік трафіку кладе його так само, як без доставки контенту.
Окрема причина — ручне очищення кешу після релізу: його виконують не для всіх шляхів, і частина користувачів ще довго бачить суміш версій. Розбираємо, як кожен із цих збоїв закривається.
Що дає налаштоване кешування: вимірювані ефекти
Периметр на Azure CDN змінює профіль навантаження на джерело: частина запитів до нього просто не доходить. Нижче — три ефекти, які видно в метриках після налаштування, а не у звіті про виконану роботу.
Розвантаження джерела та зняття пікового навантаження
Статику — зображення, шрифти, скрипти, стилі — віддає найближча до користувача точка присутності, а не сервер застосунку.
На джерелі залишаються запити до динаміки та API, тому в пік — запуск кампанії, публікація каталогу, масовий вхід співробітників — він отримує у рази менше одночасних з'єднань.
Правила кешування за розширенням і окремий короткий термін життя для розмітки дають прогнозовану частку влучань замість «кешуємо все підряд».
Стабільний час відгуку сторінки під час сплесків трафіку
Коли трафік зростає кратно, відгук визначається наявністю готової копії та відстанню до точки видачі, а не потужністю сервера. Статика з довгим терміном життя виходить з кешу без звернення до джерела, тому графік часу відгуку залишається рівним замість провалу на піку.
Навантажувальний прогін до і після налаштування показує різницю за хвостами розподілу, а не за середнім — саме там видно проблеми.
Єдиний HTTPS і коректні перенаправлення на всіх доменах
Сертифікат живе на периметрі: продовження та зміна ключів не залежать від конфігурації вебсервера.
Правило перенаправлення зводить основний домен, аліаси та HTTP до одного канонічного вигляду зі збереженням шляху та параметрів запиту, тож дублів у пошукових роботів не залишається.
Очищення кешу запускається з CI/CD одразу після релізу — оновлені файли доступні без ручних дій і без вікна, коли частина користувачів бачить стару версію.
Профілі Azure CDN: порівняння варіантів доставки
Профіль доставки визначає, які правила кешування доступні: у стандартного набору це загальні налаштування, у розширеного — правила за шляхами, розширеннями та заголовками запиту.
Вибір варто зафіксувати до перемикання домену: частина варіантів не взаємозамінна без зміни точки входу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Стандартний профіль доставки | статика, однакова логіка для всіх розділів | загальні налаштування, правил за шляхами немає |
| Профіль із розширеними правилами | у API, статики та медіа різний термін життя | правила потрібно версіонувати й тестувати |
| Власний зворотний проксі з кешем | потрібен контроль над ключем кешу та інвалідацією | окремий вузол, який треба експлуатувати |
| Кеш на джерелі | відповіді під авторизацією, приватні дані | канал не розвантажується, виграш лише на повторах |
Правила кешування за шляхами
Правило за шляхом прив'язує поведінку до префікса адреси: /api/ — без кешу, /static/ — година, /media/ — доба. Перший збіг зазвичай зупиняє розбір, тому винятки ставлять вище за загальні маски, інакше персональні відповіді підуть у загальний кеш.
Правила за розширеннями файлів
Правила за розширеннями (.css, .js, шрифти, зображення) читаються простіше й покривають збірку цілком. Слабке місце — адреси без розширення та параметри версії в запиті: їх описують окремо, інакше після оновлення файлу клієнт отримає попередню копію.
На практиці розширений профіль поверх кешу на джерелі дає прогнозований термін життя статики та очищення через програмний інтерфейс з процесу збірки — без очікування завершення терміну після викладки.
Порядок впровадження: від аудиту контенту до передачі
Кешування в Azure CDN налаштовуємо ітераціями: спочатку фіксуємо, що саме роздається, потім описуємо правила і лише потім вмикаємо основний трафік. Порядок виключає випадок, коли кеш уже віддає контент, а правила для нього ще не задані.
- Інвентаризація доменів і типів контенту. Збираємо імена та піддомени, розмічаємо статику, медіа, файли збірки й відповіді сервісів. Для кожного типу зазначаємо, чи кешується він, чи йде в обхід.
- Схема кешування. Задаємо терміни зберігання за групами файлів, правила обліку рядка запиту та поведінку під час оновлення: версіоновані файли отримують довгий термін, точки входу — короткий.
- Прив'язка домену. Підключаємо точку присутності, прив'язуємо домен, звіряємо відповідність доменних записів і порядок віддачі.
- Сертифікат і HTTPS. Випускаємо сертифікат, вмикаємо примусовий HTTPS і перенаправлення, перевіряємо ланцюжок на кожному піддомені.
- Очищення кешу в конвеєрі. Вбудовуємо крок очищення після публікації — збірка сама скидає змінене, без ручних дій чергового.
- Перевірка та передача. Проганяємо сценарії, фіксуємо результат, передаємо доступи, схему й регламент.
Перевірка сценаріїв
Перевірку будуємо на реальних шляхах: оновлення окремого файлу, повний відкат релізу, зміна сертифіката, очищення за маскою. Сценарій вважаємо пройденим лише тоді, коли нова версія видна в усіх точках, а стара не повертається з проміжних сховищ.
Перший реліз і передача
Перший реліз ведемо зі зниженою часткою трафіку: частина запитів іде через мережу доставки, частина напряму. Коли частка влучань у кеш і час віддачі збігаються з очікуваними, переводимо весь потік і закриваємо етап передачею доступів, схеми й регламенту.
Документація, схеми й регламенти після впровадження
Після запуску Azure CDN у команди замовника залишається комплект документів, за яким зміни вносять без нас. Це ж точка входу для нового інженера: за ним видно, чому правило кешування задано саме так і що станеться під час відкату.
Конфігурація та правила доступу
- Правила кешування готовою конфігурацією: файл у репозиторії, де за шляхами та розширеннями задані терміни зберігання — статика з довгим терміном, HTML і відповіді API з коротким або з повним обходом кешу.
- Карта точок присутності: які вузли обслуговують аудиторію, де увімкнено стиснення і де можливості обмежені, щоб не закладати в правила те, що не спрацює в частині регіонів.
- Налаштування HTTPS і перенаправлень: прив'язка сертифіката (керований або власний), примусовий перехід з HTTP, мінімальна версія TLS, правила перезапису шляхів.
- Матриця доступу: хто змінює правила, хто лише дивиться метрики, хто запускає очищення кешу.
Регламент релізу
- Вбудований крок очищення кешу: після викладки конвеєр викликає очищення за маскою шляхів і тегами, чекає підтвердження і йде далі лише за успіху — інакше реліз зупиняється.
- Порядок випуску версій: збірка, викладка, очищення, прогрів, перевірка — із позначкою, які кроки безпечно повторювати.
- Інструкція з перевірки та зняття метрик: контрольні запити до ключових шляхів, стан кешу в заголовку відповіді, частка влучань і час відгуку вузлів, з порогами для відкату.
Кейс: як розвантажили джерело та стабілізували відгук
Що було до налаштування
Вітрина з важкою статикою: зображення каталогу, стилі, скрипти, шрифти. Кеш на Azure CDN жив з одним коротким терміном для всіх типів файлів і без прив'язки до версій збірки — з кешу віддавалася лише третина запитів, решта йшла на джерело.
У години пік відгук зростав разом із трафіком, а після релізу спливав окремий клас відмов: розмітка на кілька хвилин посилалася на файли, яких на периметрі ще не було.
Що зробили
Розвели правила кешування за типами контенту: версіоновані файли збірки отримали довгий термін життя, HTML — короткий з обов'язковою ревалідацією, відповіді API виключили з кешу.
У конвеєр додали крок очищення — кеш інвалідується за масками після публікації артефактів і до перемикання трафіку.
Які метрики отримали
Частка влучань у кеш зросла з третини до більшості — близько чотирьох п'ятих запитів. Звернень до джерела стало приблизно втричі менше, і відгук під час піку перестав зростати: час відповіді тримається на рівні позапікових годин.
Клас «бита статика після релізу» закрито — вікно неузгодженості між викладкою та інвалідацією усунено. Відкатів не знадобилося: попередні артефакти живуть у кеші до кінця терміну, тому повернення на попередню версію залишається миттєвим.
Чим відрізняється очищення кешу від версіонування статики?
В Azure CDN примусове скидання (purge) видаляє об'єкт з вузлів присутності, не чекаючи завершення терміну життя кешу. Операція асинхронна: відповідь приходить одразу, а розходиться по вузлах хвилинами, тому між викаткою та гарантовано новим контентом залишається вікно.
Задається скидання за точним шляхом або за маскою — маска зручніша, але зачіпає все, що збіглося з шаблоном.
Версіонування статики вирішує те саме завдання інакше: збірка кладе хеш в імені файлу, а розмітка посилається на нову адресу. Попередній файл залишається доступним, новий на вузлах ще не зустрічався — інвалідація не потрібна в принципі.
Побічний ефект — старі версії накопичуються у сховищі, тому їх вичищають окремим правилом життєвого циклу.
Вибір диктує змінність імені. Скрипти, стилі, шрифти та зображення версіонуються, їм ставиться довгий термін життя з ознакою незмінності — браузер перестає перепитувати.
Адреси з фіксованим іменем — розмітка, маніфест, конфігурації — так не версіонуються, для них залишається лише скидання.
На практиці це дві політики в одній роздачі. Розмітку віддають з коротким терміном життя і скидають за маскою з конвеєра збірки, асети — з довгим і без скидання взагалі.
Очищення кешу за маскою на кшталт каталогу з усіма асетами ризиковане: масова інвалідація жене трафік на джерело і легко потрапляє на пік навантаження.
Підсумок: зміна імені — норма для файлів, що збираються, скидання — для фіксованих адрес. Змішувати обидві стратегії в одному правилі не варто.
Часті технічні питання щодо кешу та HTTPS
Кеш на межі не скасовує логіку застосунку: спочатку джерело вирішує, чи залежить відповідь від користувача, і лише потім відповідь потрапляє у сховище межі.
Тому майже всі сумніви під час передачі налаштувань — про те, де проходить межа між статикою та персональною відповіддю, і хто нею керує: правило на межі чи заголовки джерела.
Нижче — п'ять питань, які найчастіше спливають на прийманні та в перші тижні експлуатації.
Динамічні сторінки з персоналізацією взагалі можна кешувати?
Можна, але вибірково. Запити з авторизаційними cookie та заголовком авторизації йдуть в обхід кешу, кешуються лише анонімні GET. Для персональних сторінок джерело віддає заборону на зберігання — тоді межа не тримає відповідь ні секунди, і дані не витікають між користувачами.
Чому після релізу частина користувачів бачить стару версію сторінки?
Розбіжність версій виникає, коли розмітка та файли інтерфейсу живуть з різним часом життя. Розмітку віддаємо з коротким часом життя, а файли — з довгим і хешем в імені, щоб старий і новий набори не змішувалися в одній сторінці.
Скидання кешу за зміненими шляхами виконується в конвеєрі збірки до перемикання трафіку: інвалідація розходиться по вузлах не миттєво.
Що станеться із сайтом під час продовження сертифіката?
Керований сертифікат продовжується автоматично, якщо домен указує на межу записом CNAME і не проксіюється стороннім сервісом — перевірка володіння проходить за DNS.
З власним сертифікатом новий завантажується заздалегідь, а попередній залишається активним до завершення перекриття: розрив з'єднання та попередження в браузері не виникають.
Правки на джерелі не з'являються — що перевіряти першим?
Спочатку заголовки самого джерела: вони пріоритетніші за правила межі. Потім — чи входить рядок запиту в ключ кешу: за його відсутності адреси з різними параметрами віддають ту саму відповідь. І третє — чи не надто широко правило обходу за cookie, через яке кеш не наповнюється взагалі.
Як переконатися, що кеш справді працює?
Дивимося ознаку влучання та вік відповіді в заголовках, а не лише час завантаження в браузері. Перевіряємо з кількох регіонів і за різними типами файлів, потім закріплюємо в конвеєрі перевірку: після скидання кешу відповідь має оновитися. Так регрес налаштування ловиться до скарг користувачів.
Обговоримо завдання: що підготувати до старту робіт
Оцінка налаштування Azure CDN прискорюється рівно настільки, наскільки повні вхідні дані. Коли домени, типи контенту та схема середовищ збираються частинами, ми витрачаємо час на уточнення замість проєктування правил кешування. Нижче — мінімальний набір, з яким можна одразу рахувати архітектуру.
- Перелік доменів і піддоменів — із позначкою, які віддають статику, які проксіюють API і не повинні кешуватися взагалі. Окремо — плани щодо нових імен і порядку прив'язки сертифікатів.
- Типи контенту та частки статики — які шляхи кешуємо довго, які перевіряємо на кожному запиті, де контент змінюється часто. Це визначає правила за розширеннями, шляхами та заголовками відповіді.
- Схема середовищ — скільки середовищ, як стенди відокремлені від продакшену, чи потрібні окремі профілі та як розподіляється трафік між джерелами.
- Поточний стан HTTPS — де випускаються сертифікати, чи є власні, чи потрібне примусове переадресування та мінімальна версія протоколу.
- Порядок випуску версій — як сьогодні викладаються збірки, чим запускається скидання кешу і що має статися під час відкату на попередню версію.
- Правила доступу та ролі — хто керує профілем, як видаються права і на які середовища, чи потрібна ізоляція між командами.
- Обмеження джерел — закриті сховища, балансувальники, обмеження за географією та вимоги до журналів запитів.
Опишіть завдання в цьому обсязі — повернемося з оцінкою та планом робіт, включно зі схемою кешування, порядком підключення HTTPS і кроком скидання кешу в конвеєрі випуску.
