A/B Deployment у Kubernetes: налаштування розподілу трафіку та збір метрик

A/B Deployment: де ламається розподіл трафіку

Розподіл трафіку в Kubernetes налаштовується за пів години: ваги на вхідному балансувальнику, два набори подів, перемикач. Ламається A/B Deployment не на конфігу, а на тому, що дві версії сервісу живуть одночасно.

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

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

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

Третя відмова — відкат релізу вручну за дзвінком.

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

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

Що дає керований розподіл трафіку

Коли трафік розподіляється вагами на маршруті, а не перемиканням «викотити все одразу», частка нової версії стає керованим параметром.

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

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

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

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

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

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

Варіанти розподілу трафіку: порівняння підходів

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

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

Впровадження A/B Deployment: етапи робіт

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

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

1. Аудит маршрутизації кластера. Збираємо карту вхідних точок, об'єктів сервісів і правил: що вже відповідає за розподіл, які налаштування задані поза репозиторієм вручну і які версії застосунків реально приймають трафік.
2. Проєктування схеми розподілу трафіку. Вибираємо ознаку поділу — частка запитів, заголовок або мітка групи користувачів — і фіксуємо, які правила мають спрацьовувати при недоступності однієї з версій. Схема лягає в декларативні маніфести, а не в ручні правки в інтерфейсі.
3. Налаштування розподілу. Розгортаємо правила й ваги, прив'язуємо сесію користувача до версії, обмежуємо частку пробної версії, щоб вона не забрала на себе все навантаження при збої.
4. Метрики та спостережуваність. Позначаємо запити ознакою версії, щоб метрики рахувалися роздільно: частка помилок, час відповіді, глибина проходження ключових сценаріїв за кожною версією окремо.
5. Перевірка під навантаженням. Прогоняємо профіль, близький до реального трафіку: дивимося фактичний розподіл, поведінку при відмові однієї версії та час перемикання ваг.
6. План відкату. Фіксуємо, який сигнал вважаємо аварійним і за якою командою весь трафік повертається на стабільну версію в один крок — без перезбірки й повторного розгортання.
7. Передача в експлуатацію. Віддаємо документацію за схемою, регламент запуску нових експериментів та інструкцію для чергової зміни: як прочитати метрики і що робити при відхиленні.

Артефакти на виході: маніфести, схеми, регламенти

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

• Конфігурації маршрутизації — маніфести з вагами версій, правилами відбору за заголовками запиту та ознаками сесії. Зміна частки трафіку — правка одного параметра, без перезбірки застосунку.

• Політики доступу та ролі — хто змінює ваги, хто лише читає метрики, хто викочує другу версію; права видані за мінімально необхідним набором.

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

• Набір метрик і правила порівняння — які показники вважаємо сигналом відставання версії, на якому вікні спостереження і з якою затримкою вони приходять черговому.

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

• Інструкції для чергової зміни — покрокові сценарії: метрика пішла в мінус, друга версія перестала відповідати, потрібно терміново зняти експеримент.

• Чек-ліст передачі — що ваша команда проходить разом з нашими інженерами на першому самостійному випуску.

Кейс: розподіл трафіку з метриками до і після

До: ручне перемикання та відкат за інструкцією

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

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

На релізних вікнах частка відповідей з кодом 5xx доходила до 1,8%, а причина з'ясовувалася вже після факту.

Після: порівняння варіантів на живому трафіку

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

Вага змінюється правкою одного ресурсу, а не через панель, і знімається одним кроком — відкат став займати близько 40 секунд без перезапуску.

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

За підсумками трьох місяців випусків: ручних операцій залишилося дві замість одинадцяти, частка помилок на проді впала до 0,2%, а 94% релізів пройшли без повернення на попередню версію — відкат перестав бути штатною частиною випуску.

Чим канареечний випуск відрізняється від синьо-зеленого

Канареечний випуск ділить трафік між старою та новою версією частками — 5, 25, 50 відсотків — і підвищує їх у міру зростання показників. Швидкість відкату тут вимірюється секундами: повернення ваги до нуля спрямовує потік на попередню версію без перезбірки й перезапуску.

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

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

Вартість ресурсів під час випуску різниться найсильніше. Канареечному контуру потрібна ємність лише під поточну частку трафіку, і вона зростає разом з вагою; синьо-зеленому — повний дубль середовища, який простоює весь час підготовки та перевірок.

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

Синьо-зелене допускає міграцію всередині вікна перемикання, але спільна база залишається, і несумісна зміна ламає одну зі сторін.

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

Синьо-зелене дає результат «все або нічого» — різна база заважає набрати статистику, і рішення ухвалюють за фактом, а не за даними.

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

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

Чи можна залишити спільну базу між версіями?

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

Наскільки достовірна статистика випуску?

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

Що робити з уже налаштованою маршрутизацією?

Наявні правила зберігаємо: A/B-маршрут вішаємо поверх із вищим пріоритетом і перехоплюємо лише потрібний заголовок або частку трафіку. Перед увімкненням прогоняємо пріоритети на стенді.

Чи сумісні середовища між собою?

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

Обговоримо задачу: що потрібно з вашого боку

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

• Схема маршрутизації як є: ingress або service mesh, які правила ваг уже налаштовані, чи є канареечні релізи і як зараз розподіляється потік між версіями.
• Цільові метрики випуску: за якими сигналами вважаємо версію вдалою — частка помилок, затримка відповіді, конверсія ключового сценарію, глибина бізнес-події.
• Доступи до контуру: тестовий і продуктивний кластери, права на зміну маршрутів і політик, окремий контур для репетиції перемикання ваг.
• Межі експерименту: які версії порівнюємо, чи потрібне утримання користувача в одній групі між сесіями, як поводитися з авторизованими та гостьовими сесіями.
• Бюджет ризику: припустима частка трафіку на нову версію, умова автоматичного відкату й час, за який перемикання має відбуватися.
• Спостережуваність: які збирачі метрик і трасування вже стоять, куди пишуться логи, чи є готові панелі та алерти за розходженням груп.
• Обмеження середовища: режими мережі між сервісами, вимоги щодо шифрування, регламент змін у продуктиві та вікна, коли реліз допустимий.

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