CDN і промах кешу: чому запит іноді йде довгим маршрутом

Один повільний cache miss, який показує всю топологію

Уявімо черговий ранок у платформеній команді. Користувач у Європі відкриває сторінку, найближчий edge cache CDN відповідає швидко для більшості ресурсів, але один cache miss раптом тягнеться довго. На мапі маршрутів видно дивну петлю: запит ніби стартує поруч із користувачем, але дані забирає шляхом, схожим на зайве коло через інший континент.

На перший погляд це виглядає нелогічно. CDN же має бути близько до користувача. Origin розміщений у публічній хмарі. Частина відповідей кешується. Отже, повільний запит хочеться списати на тимчасове навантаження або випадкову мережеву затримку. Але саме тут часто ховається операційна помилка: команда вважає, що близькість IP-адреси означає близькість справжнього backend.

Базова схема: edge cache → upper tier → origin

Для статичних файлів і багатьох API-відповідей CDN працює як кілька рівнів зберігання. Першим запит бачить edge cache. Якщо потрібна відповідь уже там, користувач отримує її швидко. Якщо стається cache miss, CDN може піти не одразу до origin, а спершу до upper tier.

Upper tier корисний тим, що збирає промахи кешу з багатьох edge-вузлів. Замість того щоб десятки edge cache одночасно стукали в origin за одним і тим самим файлом, вони можуть звертатися до одного проміжного рівня. Це покращує cache hit ratio на верхньому рівні й зменшує кількість origin requests.

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

Чому IP близько не означає origin близько

Публічні хмари часто ховають складну топологію за простими адресами. Сервіс може мати anycast або регіональну точку входу, а реальний backend буде в іншому місці. З точки зору CDN, перевірка затримки до IP може показати кілька добрих кандидатів одразу. Адреса відповідає швидко з різних датацентрів, але це не гарантує, що запит уже біля потрібного origin.

У свіжому прикладі Cloudflare описує проблему вибору upper tier для origin у публічних хмарах. Коли cloud origin використовує anycast або regional front end, CDN може не мати очевидного сигналу, який upper tier справді найближчий до регіону origin. У гіршому випадку cache miss іде через точку входу, яка виглядає нормально за latency, але далі трафік робить hairpin routing.

Це не помилка самої ідеї CDN. Це нагадування, що сучасний шлях запиту складається з кількох шарів: DNS, CDN, внутрішня мережа провайдера CDN, хмарний front end, балансувальник і backend. Якщо один шар не знає реальної locality іншого шару, автоматичний вибір може бути неочевидним.

Runbook: як перевірити підозру на довгий шлях

Почніть не з перемикання налаштувань, а з карти фактів. Запишіть, де реально живе origin: наприклад, europe-west1, eu-central-1 або westeurope. Не обмежуйтеся DNS-іменем чи публічною IP-адресою. Якщо origin працює через глобальний load balancer, окремо позначте, куди він направляє трафік у нормальному режимі.

Далі відкрийте CDN logs або аналітику. Відфільтруйте cache miss за конкретним шляхом, країною користувача, статусом відповіді й часом. Порівняйте швидкі й повільні запити. Важливі поля: edge-регіон, статус кешу, час до origin, upstream status, розмір відповіді, кількість повторів.

Потім подивіться на origin pull latency. Якщо користувачі з Європи стабільно мають високий час отримання відповіді від origin, хоча origin теж у Європі, це привід перевірити вибір upper tier. Якщо високий час з’являється лише для cache miss, а cache hit працює добре, проблема не в браузері й не в загальній швидкості сайту.

Окремо перевірте cache hit ratio та origin requests. Падіння cache hit ratio разом зі зростанням origin requests означає, що CDN частіше ходить до origin. Якщо при цьому origin pull latency зросла, ви можете мати одразу дві проблеми: більше запитів і довший маршрут кожного промаху.

Антипатерни, які заважають розслідуванню

Перший антипатерн — дивитися тільки на середню latency. Середнє значення приховує регіональні проблеми. Краще порівнювати percentiles для cache miss окремо від cache hit.

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

Третій — одразу міняти TTL або повністю вимикати tiered cache. Це може зменшити симптом на одному маршруті, але збільшити origin requests і зробити систему дорожчою та менш стабільною.

Краща дія — шукати спосіб передати CDN знання про регіон origin. У різних провайдерів це може називатися інакше: cloud region hint, origin region, topology-aware routing або налаштування upper tier. Назва менш важлива, ніж суть: CDN має розуміти, куди насправді треба тягнути cache miss.

Що винести в production-дизайн

Якщо ваш сайт або API стоїть за CDN, додайте до документації не лише домен origin, а й реальний хмарний регіон, тип балансувальника, очікуваний шлях cache miss і метрики для перевірки. Для multi-region архітектури окремо опишіть, коли трафік має йти в інший регіон, а коли це вже ознака hairpin routing.

CDN зменшує складність для користувача, але не скасовує топологію. Повільний cache miss часто є першим сигналом, що автоматичний вибір маршруту не має достатньо інформації. Завдання команди — не вгадати, а зібрати факти: origin region, CDN logs, origin pull latency, cache hit ratio і кількість origin requests.

Джерела

• Cloudflare Blog: Smart Tiered Cache for Public Cloud Regions — https://blog.cloudflare.com/smart-tiered-cache-for-public-clouds/