Edge-кеші і POP

1) Що таке POP і навіщо «край»

• Латентність (менше RTT до клієнта).
• Навантаження і вартість на origin (offload).
• Трафік між регіонами/хмарами (egress-економія).

Edge - це не тільки кеш. Сучасні POP підтримують L7-маршрутизацію, WAF/бот-фільтри, rate-limit, А/В/канарки, трансформації та edge-compute (скрипти/функції).

2) Архітектури edge-кешування

2. 1 Плоска vs багаторівнева (tiered)

Плоска: кожен POP ходить на origin. Просто, але дорого для origin.
Tiered/Shield: POP → Shield POP (центральний кеш) → origin. Shield акумулює кеш-промахи, створює «парасольку» для origin.

2. 2 Регіональні сегменти

Розділяйте кешуючі домени по регіонах/юрисдикціях (GDPR/локалізація даних).
Варіант: «EU-only POPs» і «Global POPs», роздільні ключі/правила.

2. 3 Anycast + latency/geo-aware роутинг

Anycast приводить клієнта в найближчий POP по BGP.
Geo/latency-aware перемикає між РОР/регіональними пулами за активними вимірами RTT/помилок.

3) Ключі кеша,'Vary', TTL і свіжість

3. 1 Дизайн ключів

Нормалізуйте запити: сортуйте query-параметри, видаляйте шум (utm, ref).
Включайте семантичні осі: 'tenant','locale', «версію схеми» ('v = 3'), але уникайте PII.
Для приватного контенту - розділяти публічний і приватний кеш (див. § 7).

3. 2 Контроль кешування (HTTP)

• `Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=120`
• 'ETag '/' Last-Modified'для умовних GET (304).
• Vary: мінімізуйте кардинальність ('Accept-Encoding','Accept-Language', іноді'Authorization '/' Cookie'для приватних шляхів).
• Micro-cache для «майже-динаміки»: 1-5 секунд + SWR.

3. 3 Stale стратегії

SWR (stale-while-revalidate): віддаємо застарілу відповідь і тлом оновлюємо.
SIE (stale-if-error): при помилці origin використовуємо кеш до'SIE'-TTL.
Soft/Hard TTL: м'який термін (можна stale), жорсткий (повний промах).

4) Інвалідація: Як оновити «край»

4. 1 За ключем і за тегами

PURGE/BAN по URL/префіксу - грубо, але швидко.
Surrogate-Key/Tags: присвоюйте об'єктам теги ('article:42`, `category:7'), баньте за тегом - масова інвалідація без перебору URL.

4. 2 Подієва інвалідація

При зміні даних в origin публікуйте події (Kafka/NATS) → edge-інвалідатори викликають BAN/PURGE/soft-expire.

4. 3 Версіонування артефактів

Для статики - content-hash в імені файлу.
Для API - змінюйте версію ключа ('v = 4') при несумісних змінах.

5) Захист origin і продуктивність

5. 1 Origin shielding

Вмикайте Shield POP як єдину точку промахів → кратно знижує шторму по origin.

5. 2 Coalescing/single-flight

На краю один запит «пробиває» кеш при промаху; решта чекають (немає наздоганяючого stampede).

5. 3 Rate-limit/Queue/Shedding на edge

При перевантаженні - скидайте низькопріоритетні/анонімні запити в POP, а не на origin.

5. 4 Signed URL / Signed Cookie

Origin прихований за edge. Доступ до приватного контенту - за підписаними посиланнями/куки з TTL і атрибутами (IP/Geo/Path), щоб не роздавати «всім».

6) Транспорт і трансформації

6. 1 HTTP/2–3 и QUIC

HTTP/2: мультиплексування, хедер-компресія.
HTTP/3/QUIC: менше HOL-блокувань і краще на потерьних каналах → нижче p95/p99 TTFB.

6. 2 Компресія і образи

Brotli для тексту, AVIF/WebP для зображень, image-resizing на краю (responsive sizes, DPR).
Кеш-варіанти за форматом/розміром: ключі включають'width/format'( або'Vary: Accept`/Client-Hints).

6. 3 TLS/0-RTT (акуратно)

Ресъмплинг сесій прискорює установку, 0-RTT може бути вразливий до replay → включайте тільки для ідемпотентних GET.

7) Публічний vs приватний edge-кеш

7. 1 Публічний

`Cache-Control: public, s-maxage =...'і мінімальний'Vary'.
Підходить для каталогу, новин, зображень, CDN статики.

7. 2 Приватний/персоніфікований

• Не кешувати на шаред-рівні: `Cache-Control: private'( кеш браузера).
• Key-segmentation: включайте tenant/user-id (або токен-хеш) в ключ і позначайте як private-shared (обережно зі сховищем і PII).
• Signed cookies и Edge-auth: кеш публічний, але доступ за підписом (варіанти з encrypted session state на краю).

8) Edge-compute (Workers/Functions)

Легкі функції на POP: переписування шляху/заголовків, A/B-спліт, нормалізація ключів, SWR-логіка, prefetch сусідніх ресурсів.
Локальний KV/Cache API на POP для мілісекундних операцій.
Обмеження: короткі таймаути/пам'ять, відсутність довгоживучих з'єднань, уважна робота з PII/регіональністю.

Псевдо-приклад (Workers-like)

js export default {
async fetch(req, env) {
const key = normalize(req);
let res = await caches. default. match(key);
if (res) return withHitHeader(res, "HIT");

res = await fetch(req, { cf: { cacheEverything: true }});
const ttl = computeTTL(res);
eventWaitUntil(caches. default. put(key, res. clone(), { expirationTtl: ttl }));
return withHitHeader(res, "MISS");
}
}

9) Приклади конфігурацій

9. 1 Nginx: micro-cache + SWR

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:200m inactive=30m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
proxy_cache api;
proxy_cache_key "$scheme://$host$uri$is_args$args";
proxy_cache_valid 200 2s;          # micro-cache proxy_cache_use_stale error timeout updating;# SIE + SWR proxy_cache_background_update on;
add_header X-Edge-Cache $upstream_cache_status;
proxy_pass http://origin_pool;
}
}

9. 2 Varnish: surrogate keys и BAN

vcl sub vcl_recv {
if (req. method == "BAN") {
if (req. http. Surrogate-Key) {
ban("obj. http. Surrogate-Key ~ " + req. http. Surrogate-Key);
return (synth(200, "Banned"));
}
}
}

sub vcl_deliver {
set resp. http. Surrogate-Key = "article:42 tag:author:7";
set resp. http. Cache-Control = "public, s-maxage=300, stale-while-revalidate=60";
}

9. 3 Envoy (edge-cache фільтр)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. simple_http_cache. v3. SimpleHttpCacheConfig

9. 4 CloudFront-style поведінка (ескіз)

Behavior A: '/images/' - довгий TTL, компресія, vary за форматами.
Behavior B: '/api/' - короткий TTL, SWR, signed cookie, WAF/бот-захист.
Origin Shield включений, статуси 500/502/504 →'stale-if-error'.

10) Спостережуваність, SLO і звітність

10. 1 Метрики

cache_hit_ratio (по POP/регіону/route), byte_hit_ratio.
origin_offload = 1 − (origin_requests / edge_requests).
TTFB/TTL по квантилях, stale_responses_total, revalidations_total.
stampede_prevented_total, coalesced_waiters.
shield_hit_ratio (при tiered), origin_egress_bytes (вартість).

10. 2 Логи/трейси

Логи з мітками'HIT/MISS/STALE/UPDATING/BYPASS', ключ, TTL, POP, tenant.
У розподілених трейсах відзначайте джерело ('edge','origin') і причину (revalidate/stale/error).

10. 3 SLO-приклади

"Для '/api/list': p99 TTFB ≤ 250 мс, edge hit ≥ 70%, byte-hit ≥ 80%, origin error-offload ≥ 90%».
«Частка'stale-if-error'відповідей ≤ 1% за добу».

11) Безпека, приватність, відповідність

WAF/бот-менеджмент - на edge для фільтрації до origin.
Регіональність даних: зберігайте приватні артефакти тільки в допустимих POP; використовуйте регіоно-специфічні ключі та ACL.
Підписи і токени на edge, не віддавайте приватні відповіді з публічного кешу.
PII-мінімізація: не включайте персональні дані в ключі; шифруйте cookie; короткі TTL для персоналізації.

12) Типові рецепти

12. 1 «Майже динаміка» (стрічки/списки)

Micro-cache 1-3 з + SWR на edge, shield включений, single-flight, negative-cache для порожніх результатів 1-5 с.

12. 2 Хмари зображень/медіа

Edge-ресайз/форматування (WebP/AVIF), кеш-варіанти по'width/format', довгі TTL, інвалідація за тегами контенту.

12. 3 API з персоналізацією

`Cache-Control: private'або signed cookie + ключ-сегментація (tenant), короткі TTL, SWR для «майже публічних» частин відповіді.

12. 4 Великі розпродажі/піки

Прогрів ключових ресурсів (prewarm), збільшення TTL на статику, агресивний SWR/SIE, жорсткі ліміти на origin, включений Shield.

13) Анти-патерни

Без'Vary'при різних відповідях → витоку/неправильні дані.
Величезний'Vary'→ кардинальність → низький hit.
Загальний кеш для prod/experiments → забруднення.
Немає single-flight → шторм промахів на origin.
SWR без обмежень → гонки оновлення і лавина validate-запитів.
Edge-кеш приватних відповідей як public → інциденти безпеки.
Відсутність tiered/shield при worldwide-навантаженні → перегрів origin.

14) Чек-лист впровадження

• Картуйте POP-покриття, увімкніть anycast + latency-routing.
• Виберіть tiered/shield і політики single-flight/coalescing.
• Спроектуйте ключі і Vary (мінімальна кардинальність, без PII).
• Налаштуйте TTL/SWR/SIE (soft/hard TTL) та negative-cache.
• Увімкніть signed URL/cookie, заховайте origin, увімкніть WAF/бот-фільтри.
• Організуйте інвалідацію: Surrogate-Key/BAN + event-driven.
• Підніміть метрики hit/byte-hit/offload/TTFB і дашборди per-POP.
• Прогрів перед піками, runbooks на шторм/перевантаження.
• Тести на приватність/регіональність, аудит ключів і політик.
• SLO/помилковий бюджет для edge і критерії авто-твіків TTL/SWR.

15) FAQ

Q: Як вибрати TTL на краю?
A: Відштовхніться від допустимої застарілості і мети hit-ratio. Для «майже-динаміки» - 1-5 с + SWR; для довідників/зображень - хвилини/години з інвалідацією за подіями/тегами.

Q: Коли потрібен Shield POP?
A: При глобальному трафіку або гарячих ключах: shield різко знижує промахи на origin і стабілізує «наздоганяючі» хвилі.

Q: Як кешувати авторизовані відповіді?
A: Або'private'( браузер), або public з signed cookie/URL і сегментацією ключа (без PII), або взагалі bypass для критичних персональних даних.

Q: Що робити з HTTP/3?
A: Включати: особливо виграє мобільний/потерьний канал. Контролюйте сумісність проксі і fallback на HTTP/2.

16) Підсумки

Edge-кеші і мережа POP - фундамент швидкісних і економних платформ. Успіх визначається правильним ключем і'Vary', розумними TTL/SWR/SIE, інвалідацією за тегами/подіями, tiered/shield захистом origin, а також спостережуваністю (hit/offload/TTFB) і дисципліною безпеки/приватності. Дотримуйтесь чек-листа - і «край» стане вашим прискорювачем, а не джерелом сюрпризів.