Налаштування Yandex Cloud CDN: вузькі місця роздавання
Налаштування Yandex Cloud CDN починається не з увімкнення роздавання, а з відповіді на питання: що станеться з джерелом, коли кеш перестане його прикривати.
Поки трафік невеликий, проксіювання виглядає безкоштовною надбавкою — запити йдуть до найближчої точки присутності, а сервер-джерело зайнятий лише першим наповненням кешу та оновленням застарілих копій.
На зростанні запитів ця схема ламається одразу в кількох місцях, і кожне вузьке місце джерела видно в логах задовго до того, як користувач помічає затримку.
Перше джерело проблем — промахи кешу. Достатньо, щоб в адресі статики був присутній змінний параметр, щоб на джерелі не розрізняли версії ресурсу, або щоб відповідь віддавалася із заголовком, який забороняє зберігання.
Кожен промах — окремий запит до застосунку, і навіть частка промахів в одиниці відсотків перетворює рівний потік на навантаження, до якого бекенд не розрахований.
Другий сценарій руйнівніший: лавина запитів на перемиканнях. Після випуску нової збірки або при масовому закінченні терміну придатності десятки тисяч копій запитуються одночасно, і все це приходить на джерело одним залпом.
Допомагають різні терміни зберігання за типами контенту, віддавання застарілої копії з фоновим оновленням і примусовий прогрів ключових адрес до відкриття трафіку.
Третє — обриви з’єднань і зайве навантаження на застосунок. Якщо роздавання статики й динаміка йдуть через один і той самий вхід, джерело витрачає ресурс на встановлення з’єднань замість обробки запитів, а повторні спроби після таймауту подвоюють і потроюють потік.
Обмеження одночасних звернень до джерела й коректні таймаути прибирають цей клас відмов. Розбираємо, як це закривається на рівні налаштування Yandex Cloud CDN: правила кешування, поведінка при промаху та розв’язка статики з динамікою.
Що змінюється після впровадження: швидкість і стійкість
Після перемикання трафіку на мережу доставки Yandex Cloud запити відвідувачів обслуговують найближчі до них вузли, а джерело відповідає лише на промахи кешу.
Частка влучань задається політиками: для статики — зображень, стилів, скриптів, шрифтів — вона виходить на 85–95%, для сторінок із персоналізацією тримається в районі 50–70%.
Що точніше кеш-ключ описує варіант ресурсу — query-параметри, мовні та регіональні версії — то вищі влучання й то менший ризик віддати різні версії однієї сторінки.
Час відповіді сторінки падає кратно: статика приходить з вузла поруч із відвідувачем, захищене з’єднання встановлюється на периметрі, до джерела запит часто не доходить узагалі.
У звіті це видно не за середнім, а за 95-м перцентилем — саме він показує, що гальмує не окремий запит, а хвіст розподілу.
Найбільше змінюється клас відмов. Джерело перестає бути єдиною точкою: пік трафіку гаситься на периметрі, а не впирається в його стелю за з’єднаннями й процесором.
Якщо джерело недоступне або відповідає повільно, периметр віддає раніше закешоване — відвідувач бачить сторінку замість помилки.
Доступність під час пікового навантаження перестає залежати від моменту: розпродаж, анонс, публікація у великого каналу — трафік зростає в рази, а час відповіді залишається того ж порядку.
Розвантаження джерела вимірюється напряму: скільки запитів до нього дійшло проти загальної кількості. Влучання в кеш, час відповіді та частку помилок знімаємо до й після перемикання — ефект має бути видно в цифрах, а не на словах.
Схеми роздавання: кеш на краю, проксі, гібрид
Схема роздавання в Yandex Cloud CDN визначає, яка частка запитів доходить до джерела, а яка закривається на найближчому до користувача вузлі.
Вибір роблять не «на смак», а за профілем трафіку: частка статики, частота оновлення, вимоги до приватності та допустима затримка першого байта.
Три робочі конфігурації закривають майже всі задачі, і в межах одного домену їх комбінують за шляхами або за типами контенту. Гібрид знімає з джерела більшу частину трафіку й при цьому не вимагає єдиного часу життя відповіді на весь домен.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кеш на краю | Зображення, скрипти, шрифти, файли збірок: оновлення пачками, жорстких вимог до свіжості немає | Застарівання до інвалідації; за неправильного ключа кешу частина запитів отримає чужу відповідь |
| Проксіювання запитів | Особистий кабінет, оплата, персональні списки: відповідь формується під конкретного користувача | Кешу немає — весь пік іде на джерело, затримка дорівнює відстані до нього |
| Гібридна схема роздавання | Змішаний сайт: статика через край, динаміка напряму, частина шляхів кешується за правилами | Правила кешування, інвалідацію та заголовки доводиться узгоджувати із застосунком |
Правила кешування прописують для кожної групи шляхів окремо: час життя відповіді, ключ кешу з урахуванням параметрів запиту або без них, обхід кешу для авторизованих запитів і cookies, примусова інвалідація під час викочування релізу. Так статика живе на краю годинами, а картка товару не віддає чужу ціну.
Як відбувається впровадження: етапи та точки перевірки
Налаштування Yandex Cloud CDN — це не «увімкнути прискорення», а перенесення точки зустрічі трафіку з джерела на межу мережі.
Роботи йдуть послідовно: спочатку фіксуємо, що реально віддає джерело, потім будуємо схему, перевіряємо її на бойовому й лише потім перемикаємо користувачів.
- Аудит джерела. Дивимося, які типи контенту віддає сервер, які заголовки кешування ставить, як відповідає при помилках і запитах із параметрами. Тут же з’ясовуємо, що кешувати не можна — інакше роздавання почне віддавати застарілі дані.
- Схема роздавання. Розділяємо домени та шляхи: що йде через мережу, що залишається на джерелі, які запити обходять кеш і за якою ознакою.
- Налаштування кешування та сертифікатів. Час життя за типами контенту, ключ кешу, правила скидання; сертифікат на межі, ланцюжок довіри, перенаправлення на захищений протокол для всіх піддоменів.
- Перевірка кешу. Частка влучань, оновлення після публікації, поведінка при недоступному джерелі — за кожним правилом проганяємо тестові запити до перемикання.
- Перемикання трафіку. Переводимо поступово: спочатку частину запитів або неприоритетний домен, стежимо за часткою помилок і часом відповіді, тримаємо зворотний перевід на пряме роздавання.
- Передача. Конфігурація зберігається як код, описуються чергові сценарії — оновити контент, подивитися статистику, зняти навантаження з джерела при збої.
Точки перевірки — після аудиту, перед перемиканням і через добу після нього: на них видно, що схема тримає навантаження й не ламає вже працюючі сценарії.
Що залишається у вас: конфігурації, схеми, регламенти
Усі артефакти передаємо у вашому репозиторії та у внутрішній документації — не в листуванні й не в особистих нотатках інженера. Через місяць після запуску чергова зміна має вміти підняти роздавання й пояснити будь-яке рішення, не розшукуючи автора. Тому перелік на виході фіксований, і кожен пункт перевіряється на прийманні.
- Конфігурації ресурсів Yandex Cloud CDN: origin-групи, джерела, перевірки доступності, таймаути та прив’язка до балансувальника — декларативними файлами з версіонуванням у репозиторії.
- Правила кешування: терміни життя за типами контенту, ключі кешу з урахуванням параметрів рядка запиту й заголовків, окрема поведінка для авторизованих запитів.
- Політики доступу: підпис запитів до джерела, захист від хотлінку, обмеження за рефером і гео, правила обходу кешу для відлагоджувальних перевірок.
- Схема роздавання — маршрут запиту від клієнта через точку присутності до джерела, з точками кешування, зонами відмови та логікою перемикання.
- Документація з TLS: ланцюжок сертифікатів, порядок випуску та продовження, прив’язка до доменів і спосіб аварійної заміни при закінченні.
- Регламент чергової зміни: які метрики дивитися, що вважати інцидентом, пороги реакції, порядок інвалідації кешу та відкату конфігурації.
Кейс: як розвантажили джерело без переписування сайту
Площадку доставки збирали на Yandex Cloud, але початкова схема кешування працювала проти джерела. Джерело віддавало і статику, і API: правила кешу були загальні, параметри запиту потрапляли в ключ, тому однакові скрипти вважалися різними об’єктами.
В акційні години джерело отримувало майже весь трафік, відгук зростав з частки секунди до кількох, частина запитів завершувалася помилкою.
Контент розібрали за класами й прописали правила кешу в проєкті. Версіоновану статику віддаємо з довгим терміном зберігання, сторінки та дані — з коротким, персональні відповіді API йдуть повз кеш.
З ключа прибрали зайві параметри, залишивши ті, що впливають на вміст, а стиснення перенесли на край — джерело перестало витрачати сили на те, що вже лежить у мережі доставки.
Повернення до джерела в пікові години
На джерело додали резервну площадку й обмежили частоту звернень із мережі доставки, щоб сплеск промахів не звалювався одним потоком. Керівні заголовки та мітки версій формує сама збірка: після релізу новий контент забирається один раз, а не на кожен запит.
Результат у вимірюваних величинах
Частка відповідей із мережі доставки зросла з ~55% до 93%, пікове навантаження на джерело впало вчетверо. Відгук статики скоротився приблизно у 2,5 раза, а відмови в пікові години зникли: раніше їх було кілька епізодів на акцію, тепер нуль. Схема тримає сплеск у 3-4 рази вищий за звичайний без правок у застосунку — сайт не переписували.
Чим погранична мережа відрізняється від балансувальника?
Балансувальник навантаження працює всередині вашого контуру: приймає з’єднання, вибирає живий бекенд за перевірками доступності й розводить потоки між зонами.
Його зона відповідальності — розподіл запитів і відмовостійкість застосунку, але кожен запит усе одно доходить до сервера, включно із запитами за статикою.
Погранична мережа вирішує іншу задачу — віддавання статики й закешованих відповідей ближче до відвідувача. Найближча до користувача точка приймає з’єднання, завершує TLS на своїй стороні та віддає готову відповідь із кешу, не піднімаючи запит до вихідного сервера (origin). Влучання в кеш обслуговується на межі, промах іде в контур.
Кешування проти балансування — це й різні метрики ефективності. У балансувальника дивляться на частку успішних перевірок і рівномірність розподілу навантаження, у пограничної мережі — на частку влучань у кеш і швидкість віддавання статики.
Один інструмент не замінює інший: балансувальник не тримає контент у користувача, а погранична мережа не стежить за здоров’ям бекендів.
На практиці їх вибудовують у ланцюжок: трафік приходить на пограничну мережу, вона віддає статику й кешовані відповіді, а решту передає на балансувальник, який розподіляє запити за живими інстансами.
Ключові налаштування тут — правила кешування за типами контенту, час життя об’єктів і коректна інвалідація після релізу. Помилка в них дає або застарілу статику у відвідувачів, або повний прохід трафіку в вихідний сервер і зростання затримок.
Ми розводимо ці ролі на етапі проєктування: спочатку оцінюємо, яка частка трафіку взагалі кешована, потім налаштовуємо правила на межі й лише після цього чіпаємо схему балансування. Так межа знімає навантаження, а балансувальник займається тим, для чого він потрібен.
Часті технічні питання перед впровадженням
Перед стартом зазвичай виринають ті самі питання — вони стосуються не функціональності, а того, як новий прошарок уживеться з уже працюючою інфраструктурою. Нижче короткі відповіді за кожним пунктом; якщо ваша ситуація відрізняється, розберемо окремо.
У нас уже налаштовані правила кешування — їх доведеться переписувати?
Ні, успадковуємо. Заголовки, які віддає origin, залишаються базовим рівнем, поверх додаємо лише потрібне: тривалий TTL для статики, обхід кешу для API та зон з авторизацією. Для кожного правила фіксуємо пріоритет, щоб правило на шлях не сперечалося з правилом на тип файлу.
Як змінювати адресацію origin без простою для відвідувачів?
Нове джерело піднімається поряд і перевіряється запитами доступності до перемикання. Потім переводимо трафік на короткому TTL, а старий тримаємо гарячим запасним — повернення запису дає відкат за хвилини, без переналаштування відвідувачів на боці Yandex Cloud.
Як клієнт отримує актуальну версію сторінки, якщо контент оновили?
Інвалідацією: за точною адресою, за маскою файлів або за групою об’єктів. Статику додатково версіонуємо в адресі — під час релізу посилання змінюються, і з кешу не приходить стара збірка. Для стиснених і мобільних версій враховуємо різні представлення однієї адреси.
Що робити із сертифікатами — випускати нові чи підключати свої?
Можливі обидва варіанти: керований випуск з автоматичним продовженням на домен і піддомени або підключення вашого сертифіката. Приватний ключ при цьому не залишає вашу зону відповідальності, а термін дії контролюється окремо, щоб продовження не залежало від релізу.
Origin закритий для зовнішнього доступу — прошарок зможе його забрати?
Так. Джерело відкриваємо лише для адрес прошарку, інші звернення отримують відмову — напряму в обхід кешу потрапити не можна. Для приватних об’єктів видаємо підписані посилання з обмеженим терміном життя.
Обговоримо вашу схему роздавання контенту
Щоб розбір був предметним, а не загальним, почніть з контексту: де лежить контент, хто його споживачі та що для вас критично — швидкість віддавання, вартість трафіку, стійкість до відмов площадки.
За цими ввідними наші інженери визначать, які групи кешування має сенс заводити, як налаштовувати заголовки керування кешем на origin і чи потрібен окремий контур для динаміки.
Нижче — що надіслати, щоб ми повернулися з оцінкою та планом робіт із роздавання через Yandex Cloud CDN.
- Перелік доменів і піддоменів, для яких планується роздавання, із зазначенням основного та допоміжних.
- Опис origin: статичний бакет, власний вебсервер або кілька джерел, і як між ними розподіляється трафік.
- Обсяг контенту та профіль навантаження: частка статики й динаміки, типи файлів, приблизний обсяг віддавання за добу та пікові сплески.
- Географія аудиторії та вимоги до TLS: свої сертифікати або випуск на боці сервісу, чи потрібен примусовий перехід на захищений протокол.
- Правила оновлення контенту: як часто змінюються файли, чи потрібне точкове очищення кешу за тегами й як швидко нова версія має ставати видимою.
- Поточна схема захисту та доступів: хто керує DNS-зоною, які ролі потрібні нашим інженерам і що залишається під вашим контролем.
- Обмеження та побажання: допустимий час відгуку, вимоги до відмови на резервне джерело та режим роботи при недоступності origin.
Опишіть задачу у вільній формі — навіть якщо частина даних поки невідома, цього достатньо для старту.
Ми поставимо уточнювальні питання за порядком розбору, зафіксуємо схему роздавання та повернемося з оцінкою і планом робіт: етапами налаштування, точками перевірки та критеріями приймання.
