Глобальна доставка статики: налаштування Cloud CDN у GCP

Налаштування GCP Cloud CDN: де роздача статики ламається

Налаштування GCP Cloud CDN закриває одну конкретну проблему: під час роздачі статики із сервера застосунку кожен запит за зображенням, стилем або шрифтом займає обробник, який у цей момент не обслуговує динаміку.

Поки трафік помірний, це непомітно, але вузьке місце при піковому навантаженні проявляється саме тоді, коли кількість одночасних запитів перевищує пул обробників і черга починає зростати швидше, ніж її встигають розбирати.

Далі час відповіді збільшується нелінійно: частина запитів доживає до тайм-ауту балансувальника й повертається помилкою, хоча сам сервер живий. Розмітка приходить швидко, а важкі файли — із затримкою, тому сторінка збирається ривками.

Повторні звернення за тими самими об'єктами підсилюють перевантаження джерела контенту, і воно перестає відповідати навіть на те, що раніше тримало спокійно.

Окремий клас відмов — повільна віддача зображень на далеких плечах. Без вузла доставки поруч із користувачем кожен файл іде через півсвіту, на мобільних каналах губить пакети й обривається на середині передачі. Браузер запитує об'єкт заново, і джерело отримує подвійне навантаження за один і той самий кадр.

Оновлення версії сайту додає сплеск помилок: поки вміст кешу та джерело розходяться, частина відвідувачів отримує нову розмітку зі старими файлами або навпаки. Така неузгодженість тримається від кількох хвилин до години, і весь цей час частина сторінок виглядає зламаною.

Нижче розбираємо, як це закривається на рівні доставки — від вибору режиму кешування до правил скидання під час викладки.

Що дає кешування на межі мережі

Кешування на межі мережі — це проміжний шар між користувачем і джерелом: статика віддається з найближчої до відвідувача точки присутності, а не із сервера. Перше звернення підтягує об'єкт із джерела й кладе його в кеш, усі наступні відповіді йдуть повз застосунок.

Cloud CDN підключається до того самого зовнішнього балансувальника, тому правила маршрутизації та сертифікати не доводиться підтримувати у двох місцях.

Час відповіді та повнота завантаження сторінки

Виграш видно не за середнім, а за хвостом розподілу: 95-й процентиль часу відповіді скорочується у рази, бо запит більше не йде через океан до джерела.

Основа цього — версіонування імен файлів і тривалий термін життя об'єктів у кеші: оновлення релізу змінює імена, стара й нова версії живуть паралельно, і браузер не тягне застарілий файл.

Побічний ефект — повніше завантажуються сторінки: усі ресурси приходять з однієї близької точки, а не чекають по черзі на повільне джерело.

Розвантаження джерела та поведінка під піками

Частка влучань у кеш на статиці зазвичай тримається вище 90%, і джерело перестає бути вузьким місцем: воно займається динамікою, а не роздачею файлів.

Коли виходить оновлення й тисячі користувачів одночасно запитують нову версію, однакові запити згортаються в один похід до джерела — клас помилок при масовому оновленні контенту зникає.

Незалежні вимірювання при порівнянні з прямою роздачею показують ту саму картину: пік трафіку гаситься на межі й до серверів не доходить.

Способи роздачі статики: що вибрати під задачу

Способи роздачі статики різняться не швидкістю взагалі, а тим, де кешується контент і хто відповідає за інвалідацію. Нижче — варіанти, між якими реально вибирають під час переходу на глобальну доставку.

Пряма віддача з об'єктного сховища

Об'єктне сховище віддає файли напряму, без проміжного кешу: це робочий варіант для внутрішніх збірок, артефактів і аудиторії в одному регіоні.

Обмеження проявляються на зростанні — затримка збільшується з віддаленістю клієнта, кожен запит витрачає операції читання, а часті звернення до одного об'єкта впираються в стелю.

Власний прошарок проти керованої роздачі

Свій прошарок кешу дає повний контроль над правилами кешування, але потребує вузлів у кожному регіоні, чергування та оновлень. Керована роздача переносить периферійні вузли й інвалідацію на бік провайдера — команді залишається конфігурація.

Вибір визначається обмеженнями, а не можливостями: гібрид виправданий, коли частина контенту кешується довго, а частина змінюється кожен реліз і потребує скидання кешу за іменем файлу.

Порядок налаштування: від аудиту до передачі

Ставимо роздачу за кроками: поки не зафіксовано типи контенту та схему маршрутизації, будь-які правила кешування доведеться переписувати після першого ж оновлення.

Порядок нижче прибирає переробки на етапі підключення домену й робить поведінку Cloud CDN передбачуваною з першого запиту.

Що фіксуємо на етапі аудиту

Збираємо карту: які шляхи віддаються статикою, які — динамікою, де лежать версії файлів і що змінюється кожним випуском. Окремо виписуємо запити з параметрами та заголовками, які не повинні потрапляти до загального ключа кешу.

1. Інвентаризація контенту. Типи файлів, терміни зберігання, схема версіонування імен — від неї залежить, чи можна тримати файл у кеші довго.
2. Схема маршрутизації запитів. Карта шляхів на бекенд-бакети та сервіси, порядок правил, поведінка для неіснуючих адрес.
3. Правила кешування. Що входить у ключ кешу, які заголовки та параметри ігноруються, терміни за замовчуванням і перевизначення для окремих шляхів.
4. Підключення домену та сертифіката. Прив'язка домену до роздачі, випуск керованого сертифіката, перевірка валідації та перемикання трафіку.
5. Перевірка на контрольних сценаріях. Холодний і повторний запит, оновлення файлу, примусове скидання кешу, коректність заголовків відповіді.
6. Спостережуваність. Журнали запитів, частка влучань у кеш і час відповіді по краю — за ними видно, що налаштування працює, а не виглядає налаштованим.
7. Передача та навчання. Регламент викладки й скидання кешу, схема тестового середовища та розбір із командою, яка далі веде роздачу сама.

Конфігурації, схеми та регламенти роздачі

Передаємо не набір налаштувань у панелі, а відтворюваний комплект: конфігурації в системі контролю версій, схему маршрутизації потоків і регламенти, за якими команда замовника далі працює сама.

Кожен артефакт перевірено на стенді — під час розбору інциденту видно, яке правило відповідає за поведінку кешу.

• Файли конфігурації розподілу та джерел — з описом призначення кожного параметра.
• Схема маршрутизації: які шляхи та типи контенту йдуть на кеш, які — напряму на джерело.
• Політики доступу до контенту: підписані посилання, обмеження за регіонами та заголовками запиту.
• Правила інвалідації кешу: що чиститься точково, а що — за маскою шляху.
• Документація з роздачі: домени, точки входу, відповідальні, порядок діагностики.
• Регламент оновлення версій і розбору інцидентів.

Схема маршрутизації та правила кешування

Описуємо, які шляхи кешуються і на який термін, як обробляються запити з параметрами та що відбувається при недоступності джерела. Схема показує ланцюжок від користувача до сховища — за нею інженер без нас знаходить, де губиться кеш.

Регламент оновлення версій та інвалідації

Фіксуємо порядок випуску: зібрали артефакт, залили, прогріли нову версію, перемкнули трафік, скинули застаріле. Окремим розділом — правило відкату та порядок дій, якщо кеш роздає попередню версію, з кроками перевірок і очікуваною поведінкою системи.

Розвантаження джерела: результати впровадження

Проєкт із великим обсягом медіа та високим піковим трафіком віддавав статику напряму з джерела: збірки скриптів і стилів, шрифти, зображення.

На піках джерело впиралося в стелю, час відповіді на статику зростав, а публікація нової версії іноді віддавала клієнту суміш старих і нових файлів і закінчувалася хвилею помилок. Підключили Cloud CDN окремим шаром доставки та перебудували роботу з кешем.

Ключова зміна — версіонування імен ассетів: хеш в імені файлу дозволив тримати тривалий термін життя для статики й короткий для сторінок, а інвалідація звелася до оновлення одного маніфесту.

Ключ кешу очистили від випадкових параметрів запиту, для популярних файлів налаштували попередній прогрів, а правила для різних шляхів розвели за окремими політиками.

Метрики до та після

Вимірювання знімали на реальному трафіку, звіряючи метрики джерела, влучання в кеш і помилки публікації за однакові періоди до та після.

Джерело перестало бути вузьким місцем і знову зайнялося динамікою, а випуск нової версії більше не супроводжується розбором скарг на «попливлу» верстку.

Що робити, якщо статика вже віддається через сторонній CDN?

Роздачу можна перенести без простою, якщо не змінювати адреси, до яких звертаються клієнти та пошукові системи.

Домен залишається тим самим, змінюється лише мета, на яку він указує: спочатку це сторонній сервіс, потім — зовнішній балансувальник із бакетом-джерелом і ввімкненим кешуванням. Запис перемикається останнім, після того як нову конфігурацію перевірено на окремому тестовому імені.

Перевірка до перемикання — це тіньовий прогін: частина запитів іде на нову роздачу за тестовим доменом або окремим заголовком, і ми звіряємо коди відповідей, заголовки кешування, поведінку при промаху, віддачу стиснених файлів і запитів діапазонами. Окремо дивимося великі та рідко запитувані об'єкти — розбіжності найчастіше спливають саме там.

Накопичені правила — редіректи, терміни життя об'єктів за типами файлів, обмеження за підписом посилань, фільтри за джерелом запиту — переносяться в політики кешу та правила маршрутизації.

Якщо в правила немає прямого аналога, його виносять на рівень застосунку: зберегти поведінку важливіше, ніж акуратно закрити переїзд.

План відкату готують заздалегідь: стара роздача залишається робочою та наповненою до кінця міграції, термін життя запису знижується завчасно, повернення — це зворотна зміна мети, яка займає хвилини. Основний трафік перемикають хвилями: спочатку одна частка запитів або один напрямок, потім решта.

Технічні сумніви перед впровадженням

Питання перед викладкою в інженера майже завжди ті самі: як швидко правка дійде до користувача, що буде, якщо джерело відвалиться, чи не зламає це збірку. Відповідаємо щодо кожного — на рівні конфігурації, а не загальних слів.

Що віддається, якщо джерело недоступне?

Поки копія в кеші жива, вузол віддає її, не звертаючись до джерела, — падіння бакета користувач не помічає. Помилки кешуються окремо й коротким терміном, щоб 404 не залипав на години.

Додатково тримаємо версіонування об'єктів і резервний бакет, який перемикається зміною адреси джерела.

Чи впливає CDN на збірку та викладку?

Збірка не змінюється — додається крок публікації артефактів і, за потреби, скидання кешу. Якщо в іменах файлів є хеш вмісту, вони незмінні: викладаємо нову версію без інвалідації, а короткий термін життя залишаємо лише в точки входу. Так реліз не залежить від квоти на скидання.

Як обмежити доступ і піти від гарячих посилань?

Закритий бакет плюс підписані посилання з обмеженим терміном: сторонній ресурс не зможе вбудувати ваш файл і з'їсти трафік. Для потокового відео підпис видається на сесію через cookie. Додатково відсікаємо чужі домени перевіркою джерела запиту.

Де дивитися статистику кешу?

Ключова метрика — частка влучань у кеш, у розбивці за кодом відповіді та типом об'єкта. Для статики вона тримається високою, для сторінок із коротким терміном життя низькою — і це нормально. Дивимося обсяг віддачі, топ адрес і промахи; деталізація за запитами вмикається в журналах хмари.

Обговоримо задачу роздачі статики та план робіт

Щоб повернутися з планом робіт і оцінкою, готувати технічне завдання не потрібно — достатньо того, що у вас уже є: схеми роздачі, логи й опис аудиторії. Чим конкретніші вихідні дані, тим менше припущень в оцінці й тим передбачуваніші строки. Нижче — що корисно мати під рукою до обговорення задачі роздачі.

• Типи та обсяг контенту: статичні сторінки, зображення, відео, шрифти, обсяг зберігання й добовий приріст — від цього залежить стратегія кешування та кількість джерел.
• Географія користувачів: де розташовані основні аудиторії та їхні частки в трафіку — визначає склад точок присутності й правила маршрутизації запитів.
• Поточна схема роздачі: звідки контент віддається зараз, які заголовки кешування виставлено й що вже налаштовано на стороні джерела.
• Вимоги до доступу: приватні файли, підписані посилання, обмеження за країнами, захист джерела від прямих звернень.
• Цільові показники: час відповіді на статику, очікувана частка влучань у кеш, допустимий час застарівання контенту після публікації.
• Процес публікації: як і як часто оновлюється контент, чи потрібне примусове очищення кешу за кнопкою й хто відповідає за викладку.
• Організаційні ввідні: доступи до хмарних проєктів, політики безпеки, зручне вікно для змін на проді.

На цьому наборі ми збираємо план робіт: етапи, склад змін у конфігурації роздачі, схему перевірки після перемикання та точки, де потрібна ваша участь. Опишіть задачу роздачі у вільній формі — повернемося з оцінкою та планом.