Настройка CDN для доставки контенту мобільного додатка
Без CDN запит за зображенням профілю з Мінська йде на сервер у Амстердамі або Сінгапурі — 80–150 мс тільки на RTT, без урахування часу відповіді сервера. CDN кешує контент на найближчому до користувача вузлі. Для мобільного додатка з медіаконтентом це різниця між відчуттям "швидко" та "повільно".
Що через CDN, що ні
CDN має сенс для статичного або рідко мінливого контенту: зображення, аватарки, відео, PDF, OTA-оновлення, оновлення ресурсів гри (Addressables, Asset Bundles). API-запити з динамічними даними через CDN не кешуються у стандартній конфігурації — для них потрібен API Gateway або Edge Functions.
Важливий момент: персональні дані користувачів (документи, особисті фото) через публічний CDN з довгим TTL — ризик. Для таких файлів використовуйте Signed URLs з коротким часом життя.
Вибір провайдера
| Провайдер | Сильні сторони | Коли вибираємо |
|---|---|---|
| Cloudflare CDN | Безплатний тариф, проста настройка, DDoS-захист | Стартап, обмежений бюджет |
| AWS CloudFront | Нативна інтеграція з S3, Lambda@Edge | Інфраструктура вже на AWS |
| Google Cloud CDN | Інтеграція з GCS, GKE | Інфраструктура на GCP |
| BunnyCDN | Низька ціна, хороша швидкість у СНД | Аудиторія в СНД, вартість важлива |
| Fastly | Edge computing, Varnish під капотом | Потрібні складні правила кешування |
Для аудиторії в Росії та СНД перевіряйте наявність POP-вузлів у Москві та Санкт-Петербурзі — не всі великі CDN мають їх зараз.
Настройка кешування
Стратегія TTL залежить від типу контенту:
-
Аватарки користувачів: короткий TTL (1–24 години) + версіонування через query string (
?v=hash) або шлях (/avatars/v2/user-123.jpg) - Статичні ресурси програми (іконки, фони): довгий TTL (30–365 днів) + cache-busting через хеш у назві файла
- Відеоконтент: streaming через Range requests, середній TTL
Cache-Control: public, max-age=2592000, immutable — для ресурсів з хешем у назві. immutable говорить браузеру та HTTP-клієнту не перевіряти свіжість до закінчення max-age.
На стороні мобільного додатка: OkHttp на Android кешує відповіді якщо сервер відправляє правильні заголовки. Настройка Cache з розміром 50–100 МБ на диску + CacheControl при побудові запитів дозволяє працювати офлайн з закешованим контентом.
На iOS: URLCache з diskCapacity 100 МБ. Для медіа — NSURLRequest.CachePolicy.returnCacheDataElseLoad.
Інвалідація та очищення
CDN кешує по URL. Зміна файла без зміни URL не приводить до оновлення кешу до закінчення TTL. Три підходи:
-
Версіоновані URL (
/assets/logo-a1b2c3d4.png) — найкращий варіант, не потребує ручного очищення -
Query string версіонування (
/assets/logo.png?v=42) — простіше, але деякі CDN ігнорують query string при кешуванні (потрібно явно включити) - Ручне очищення через API — для терміних замін. Cloudflare, AWS CloudFront, BunnyCDN мають API, інтегруємо в CI/CD pipeline
Моніторинг
Після настройки перевіряємо:
- Cache Hit Ratio на дашборді CDN — цільове значення 90%+. Якщо нижче — TTL занадто короткий або багато унікальних URL
- Bandwidth savings — скільки трафіку обслуговує CDN проти origin
- P95 латентність по регіонам — переконуємось, що цільові ринки отримують прискорення
У мобільному додатку логуємо X-Cache заголовок відповіді (якщо CDN його відправляє) в аналітику — дозволяє бачити реальний hit rate з точки зору клієнта.
Терміни настройки: один-два робочих дні для базової конфігурації. Складні правила (Edge Functions, geo-routing, Signed URLs) — три-п'ять днів.