Akamai CDN: Property Manager, SureRoute, кешування та безпека

Налаштування Akamai CDN: де ламається роздача трафіку

Роздача ламається не на етапі підключення до CDN, а в експлуатації, коли конфігурація обростає винятками. У Akamai правила живуть у Property Manager і публікуються версіями: спочатку на тестовий контур, потім на бойовий.

Розбіжність версій між регіонами — найчастіша причина, чому в частини користувачів кеш поводиться інакше, ніж у решти.

Перше вузьке місце віддачі контенту — поведінка кешу під піком.

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

Джерело, розраховане на середній трафік, починає повертати 502 і 504 саме тоді, коли віддача найважливіша.

Друге — розбіжні правила кешування між географічними зонами та контурами.

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

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

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

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

Ефект від налаштування: швидкість віддачі, влучання в кеш, стійкість

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

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

Частка влучань у кеш

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

Час відповіді кінцевому користувачу

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

Стійкість до піків і зняте навантаження з джерела

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

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

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

Схеми доставки CDN-контенту: коли що підходить

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

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

Етапи роботи: аудит трафіку, схема кешування, перевірка

Налаштування Akamai CDN іде не від правки конфігурації, а від даних: знімаємо карту трафіку, проєктуємо схему кешування, і лише потім вмикаємо правила на живому потоці.

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

1. Аудит карти трафіку: розбираємо журнали й параметри запитів — які шляхи статичні, які залежать від сесії, де великі тіла, як звернення розподілені за регіонами. На виході — групи контенту зі строком життя та ознаками віднесення запиту.
2. Узгодження схеми кешування: для кожної групи вирішуємо, що зберігається на межі мережі, а що йде до сервера-джерела, які заголовки й cookie прокидаються, а які зрізаються, щоб не розмножувати унікальні копії.
3. Проєктування правил у Property Manager: збираємо їх за пріоритетами — маршрутизація, поведінка при промаху кешу, обробка помилок джерела, віддача застарілого об’єкта. Фіксуємо, яка умова спрацьовує першою при перетині.
4. Складання на проміжному середовищі: тестовий домен, звірка заголовків відповіді, частки влучань у кеш і поведінки при недоступному джерелі. Помилки конфігурації ловимо тут, а не на потоці.
5. Перевірка на бойовому трафіку: правила вмикаємо поетапно, стежимо за часткою влучань, часом відповіді за регіонами та часткою помилок. При відхиленні — повернення до попередньої версії без зупинки віддачі.
6. Передача керування: віддаємо карту трафіку, схему кешування, опис правил і порядок типових правок, щоб команда замовника змінювала налаштування сама й розуміла наслідки.

Конфігурації властивостей, правила кешування та регламенти

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

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

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

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

Кейс: стабільна віддача при різкому зростанні трафіку

Замовник — інтернет-магазин із сезонними розпродажами: у пік трафік зростав у 6-8 разів за кілька годин, і на цьому тлі сайт починав віддавати помилки.

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

Вузькі місця до робіт

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

Результат

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

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

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

Чим керування через панель відрізняється від конфігурації як коду?

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

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

Відтворити середовище з нуля можна лише повторенням кроків руками — і кожна розбіжність випливає вже на бойовому трафіку.

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

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

Технічні сумніви: кеш, інвалідація, доступи

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

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

Ми розкладаємо поведінку кешу за шарами: що саме зберігається на краю, за яким ключем (адреса, параметри запиту, cookie, заголовки), який строк життя контенту виставлено для кожного типу об’єктів і що відбувається при промаху.

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

Чи не почне кеш віддавати персоналізовані сторінки чужим?

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

Як розмежувати доступ до керування конфігурацією?

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

Обговорімо задачу: трафік, географія, вимоги до віддачі

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

Що варто підготувати до обговорення:

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

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