Чому налаштування CDN для мобільного застосунку ламається на піках
Налаштування CDN для мобільного застосунку виглядає робочим рівно до першого піку: за рівного трафіку запити обслуговують периферійні вузли, відгук стабільний, вихідний сервер майже не навантажений.
Але варто зрости кількості одночасних сесій — вечірній прайм-тайм, розпродаж, розсилка із зображеннями, — і затримки завантаження зростають не плавно, а обвалом: стрічка перестає довантажуватися, екрани відкриваються порожніми.
Перший провал — кеш.
Коли правила кешування задані одним загальним рядком, а не розведені за групами об'єктів (зображення каталогу, обкладинки, статика інтерфейсу, дані профілю), периферійні вузли вважають частину відповідей неперевірюваними й звертаються по них на вихідний сервер щоразу, коли відкривається екран.
Пікове навантаження переїжджає на джерело, і воно починає відповідати повільніше, ніж віддавало б взагалі без роздачі.
Другий провал — мобільна мережа. Користувач заходить у метро, перемикається між мережами, втрачає сигнал на середині довантаження: обірваний запит повторюється повністю, а не продовжується з місця обриву.
Кожен такий випадок — зайвий трафік, зайвий захід на джерело й ще один крок до тих самих затримок завантаження, які людина формулює як «застосунок гальмує».
Третій провал — самі об'єкти. Важкі зображення без адаптації під екран, віддача одного файлу в усіх роздільних здатностях, відсутність стиснення й об'єднання дрібних запитів розганяють обсяг передачі в рази.
Периферійні вузли скорочують відстань до користувача, але не рятують від того, що йому надсилають зайве.
В усіх трьох сценаріях точки відмови ті самі: правила кешування, обробка обривів і підготовка контенту. Розбираємо, як це закривається.
Що дає CDN застосунку: швидкість, стійкість, охоплення
Логіка роботи CDN проста: статика — зображення, шрифти, елементи інтерфейсу, відео, JS-бандли — віддається не з вихідного сервера, а з найближчої до користувача точки присутності.
Перший запит забирає об'єкт з origin, далі він живе в кеші із заданим часом життя й віддається вже з регіону користувача. Різниця у швидкості відгуку на далеких напрямках — кратна, а не «трохи швидше», бо зникає основна складова затримки: шлях пакета через пів світу.
Кешування статики налаштовується за типами контенту, а не «увімкнути й забути». Зображення та шрифти кешуються довго, HTML і дані профілю — коротко або не кешуються взагалі, api-відповіді отримують окремі правила.
Окремо налаштовується інвалідація: під час релізу нові версії ассетів отримують нову адресу, а не скидають кеш повністю за всіма регіонами.
Інакше після кожного оновлення застосунок кілька годин працює у змішаному стані — частина користувачів отримує старий інтерфейс, частина новий.
Стійкість до піків — другий вимірюваний ефект. Масова розсилка, відкриття реєстрації, ефір або сезонна акція створюють сплеск запитів, який вихідний сервер не витримує.
Периферійні вузли приймають його на себе: частка запитів, що дійшли, залишається на рівні звичайного дня, відмов через таймаут немає, а на origin доходить лише частина, яка не кешується — зазвичай відсотки від загального обсягу.
Розвантаження сервера напряму знижує вимоги до його ресурсів і витрати на вихідний трафік, який скорочується в рази.
Працюємо з Cloudflare та іншими мережами доставки: вибір провайдера визначається географією аудиторії, часткою відео й вимогами до захисту. Далі — правила кешування, заголовки керування кешем, резервне джерело й моніторинг частки влучань. Без цього CDN лише переносить навантаження, а не знімає його.
Схеми доставки контенту і коли кожна з них доречна
Вибір схеми доставки визначає не «швидкість загалом», а те, які запити можна віддавати, не доходячи до сервера-джерела. Динамічний контент — персональна стрічка, авторизація, платіжні відповіді — кешувати не можна: помилка в ключі віддає користувачеві чужі дані.
Статика й медіа кешуються за іменем файлу з версією, і саме на них схема дає основний виграш у часі відгуку та навантаженні.
| Схема доставки | Коли підходить | Обмеження |
|---|---|---|
| Готова зовнішня мережа | Аудиторія в десятках регіонів, переважає статика й медіа, свою інфраструктуру тримати не плануємо | Правила кешування задаються в панелі оператора; частина налаштувань за регіонами й швидкість інвалідації залежать від його регламенту |
| Власні вузли | Вимога тримати дані у своєму контурі, покриття одного-двох регіонів | Розширення географії — ручна робота; експлуатація й резервування лягають на команду |
| Гібридна схема | Статика й медіа на зовнішніх вузлах, динамічний і приватний трафік — через свої | Складніша маршрутизація: потрібно синхронізувати конфігурації та правила в двох контурах |
| Пряма роздача з джерела | Невелика аудиторія, майже весь трафік — короткі запити до даних | Затримки й навантаження зростають лінійно з кількістю користувачів, стійкість цілком на джерелі |
Сама схема працює лише разом із правилами кешування: ключ за версією ресурсу, короткий термін життя для контенту, що часто змінюється, примусова інвалідація після релізу клієнта.
Без цього навіть правильно обрана схема віддає застарілі файли — і користувач бачить старий екран після оновлення застосунку.
Етапи впровадження: від аудиту до передачі регламентів
Порядок робіт майже не залежить від розміру застосунку — змінюється лише глибина кожного кроку. Починаємо із замірів: поки немає цифр щодо поточної доставки, будь-яка зміна перетворюється на ставку навмання.
- Аудит доставки. Дивимося, що і звідки віддають сервери: склад контенту, частка повторних запитів від одного користувача, географія аудиторії, час відповіді на першому запиті й на вже прогрітому кеші. Рахуємо, яка частина трафіку взагалі підлягає кешуванню.
- Схема маршрутів. Розділяємо потоки: запити до даних користувача йдуть напряму, статика, зображення й оновлюваний контент — через вузли роздачі. Окремо описуємо роздачу оновлень, щоб викладка нової версії не била по серверах.
- Налаштування кешу. Для кожного типу контенту задаємо свій термін життя й політику оновлення: змінювані файли перевіряються перед віддачею, незмінювані зберігаються довго. Ключ кешу нормалізуємо, щоб копії одного файлу не розмножувалися.
- Перевірка на навантаженні. Проганяємо схему на реальному профілі трафіку — пікові сплески, повільні канали, перша установка застосунку. Фіксуємо частку влучань у кеш, час відгуку й поведінку системи за відмови окремого вузла.
- Обкатка на бойовому трафіку. Вмикаємо поступово, на частині аудиторії, порівнюючи метрики до й після. Так помилка в правилах коштує секунд деградації, а не години.
- Передача регламентів. Віддаємо карту маршрутів, правила кешу за типами контенту, порядок скидання кешу під час релізу, дашборд із метриками та інструкцію для чергового.
Схеми, правила кешування й документація на виході
Після запуску в команди замовника залишається не лише робоча роздача, а й повний комплект артефактів, за якими контур можна розвивати без нас.
Конфігурації ми передаємо в репозиторій, а не «на словах»: зміна проходить перевірку коду, відкочується однією ревізією, а контури підготовки й експлуатації не розходяться між собою.
- Схема маршрутизації — які домени обслуговують статику, медіа й запити застосунку, як трафік ділиться між джерелами й у якому порядку перемикається за відмови одного з них.
- Правила кешування — час життя для кожного класу контенту, версіонування файлів через хеш в імені та перелік того, що не кешується: персональні відповіді й авторизаційні запити.
- Політики доступу — підписані посилання з обмеженим терміном життя, захист від вбудовування контенту на сторонні майданчики, обмеження за регіонами й частотою звернень до джерел.
- Регламент випуску контенту — порядок публікації версії, прогрів кешу до відкриття трафіку, хто підтверджує викладку й як повертається попередня збірка.
- Конфігурація як код — маршрути й правила в репозиторії, розгорнуті в Cloudflare: зміни проходять перевірку й не розходяться між контурами.
- Метрики й оповіщення — частка звернень із кешу, час віддачі за регіонами, сплески помилок і пороги, після яких черговий отримує повідомлення.
- Інструкція з експлуатації — карта доменів і вузлів, рівні доступів, відповідальні та порядок дій під час планових робіт.
Кейс: скоротили час завантаження каталогу втричі
Замовник — мережа магазинів товарів для дому «Северный Дом»: каталог на 40 тисяч позицій, застосунки на iOS і Android.
Картка товару тягла з основного контуру і дані, і кожне зображення, тому за різкого припливу користувачів час відгуку піднімався до 5–6 секунд, а кожне п'яте завантаження обривалося. Вихідний сервер упирався в стелю й віддавав картинки повільніше, ніж їх встигали запитувати.
Що зробили в межах кейсу впровадження
Розділили трафік: статику — фото карток, банери, відеоогляди — винесли на CDN, а через вихідний сервер залишили динаміку й персональні дані.
Налаштували правила кешування за типами об'єктів, версіонування посилань на фото й фонове довантаження прев'ю, щоб каталог відкривався з уже прогрітого кешу. Доставку прив'язали до гео-маршрутизації: користувач отримує контент із найближчої точки присутності мережі.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час відгуку на піку | 5–6 с | 1,7 с |
| Частка перерваних завантажень | 19% | 6% |
| Навантаження на вихідний сервер | 100% | 25–30% |
За десятикратного припливу користувачів у першу хвилину розпродажу каталог відкривався без деградації: мережа доставки приймає запити на себе, а вихідний сервер не доводиться масштабувати під пікове навантаження.
Чим відрізняється кешування статики від потокової доставки
Статика й потік — два різних контракти між застосунком і периферійним сервером. Статика однакова для всіх: оболонка застосунку, зображення, шрифти, скрипти.
Її тримають на периферії з довгим терміном життя й скидають не за таймером, а за зміною імені файлу — під час випуску нової збірки свіжі копії підтягуються одразу, а старі доживають термін без помилок у користувачів.
Персональні дані влаштовані протилежно: відповідь унікальна для конкретного користувача, і спільний кеш на такій відповіді перетворюється на витік між акаунтами.
Тому приватні запити йдуть повз кеш або з ключем за користувачем, а доступ до файлів видається через підписані посилання з коротким терміном життя — посилання, що витекло з логів або переслане далі, перестає працювати раніше, ніж його встигнуть використати.
Потік повністю не кешується: запис розбитий на короткі фрагменти, які збираються на пристрої, і на периферії вигідно тримати лише гарячі фрагменти популярних записів.
Це знімає навантаження з основного сховища, але потребує акуратного налаштування захисту контенту, щоб фрагменти не завантажувалися в обхід застосунку. Змішувати режими в одному правилі не можна — саме на цьому ламається доставка.
Часті технічні сумніви перед початком робіт
Перед початком налаштування CDN виринають ті самі питання: що робити з уже розгорнутою схемою доставки, чи потрібні правки в застосунку й хто відповідає за збої після передачі. Розбираємо їх предметно — від відповідей залежать і строки впровадження, і режим експлуатації.
У нас уже розгорнута своя схема доставки — ламати її?
Ні. Знімаємо карту наявної інфраструктури: джерела, правила кешування, точки відмови. Перемикаємо частками трафіку й звіряємо метрики; зворотне перенесення ваги займає хвилини.
Чи знадобляться правки в коді застосунку?
Зазвичай ні: адреси статики й медіа живуть у конфігурації доставки. Правки в клієнті потрібні, лише якщо переносимо туди логіку вибору джерела, — робимо їх зі зворотною сумісністю.
Що буде за сплеску після розсилки?
Кеш на периферії тримає сплеск: запити не доходять до джерела. Задаємо запас і правила довантаження, щоб поодинокі промахи не давали каскад, плюс поріг захисту від аномалій.
Як зрозуміємо, що доставка працює добре?
Налаштовуємо аналітику доставки: частка влучань у кеш, час до першого байта, повільні регіони, частка помилок за кодами. Зрізи звіряємо до і після перемикання.
Хто відповідає за збої після передачі?
Перші тижні ведемо ми: чергування, розбір інцидентів, правки конфігурації. Далі передаємо схему й регламенти вашій команді або залишаємося на підтримці; час реакції фіксуємо письмово.
Як закрито безпеку контенту?
Доступ до джерел обмежуємо підписом і токенами, щоб посилання не можна було застосувати поза застосунком. Приватні матеріали позначаємо некeшованими, лістинг каталогів закриваємо.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка була точною, а не за аналогією, потрібні ввідні про поточну доставку: що і звідки роздається, як влаштовані адреси файлів, чи є версіонування наборів даних.
Опишіть типи контенту — зображення, відео, оновлювані довідники — і точки віддачі: один вихідний сервер, кілька регіонів або сторонній постачальник.
У відповідь готуємо план впровадження з розкладкою робіт і схемою перемикання без простою: трафік переводиться частками, старі адреси продовжують відповідати, повернення до попередньої схеми доступне на будь-якому кроці.
- Що надіслати для оцінки: схему доставки, список доменів і адрес, звідки контент віддається зараз.
- Профіль навантаження: добовий і піковий обсяг трафіку, географія користувачів, частка відео й великих файлів.
- Вимоги до доставки: як часто оновлюється контент, скільки він живе на вузлах, чи потрібні закриті посилання.
- Склад робіт: налаштування роздачі, правила оновлення й зберігання, захист контенту від вбудовування на сторонніх сайтах, оповіщення про відхилення.
- Схема впровадження без простою: поетапне перенесення частками трафіку, паралельна робота старої та нової схеми, заздалегідь описаний відкат.
- Строки: увімкнення на частині аудиторії — дні, повне перемикання й стабілізація — тижні; залежить від кількості доменів і вимог до посилань.
- Підтримка після запуску: чергування за оповіщеннями, розбір відхилень, перегляд правил оновлення в міру зростання навантаження.
Опишіть задачу й надішліть ввідні — повернемося з оцінкою, планом впровадження та строками для вашого застосунку.
