Canary deployment ML: чому розгортання нової моделі ламає прод
Нова версія моделі вирушає в прод одним тегом на весь трафік — так виглядає найпоширеніший збій розгортання. Офлайн-перевірки пройдено, відкладена вибірка дає потрібну якість, реліз іде на 100% запитів.
Через пів години моніторинг показує деградацію прогнозів: зростає частка відмов у скорингу, рідкісні сегменти просіли сильніше за інших, а в логах уже відповіді нової моделі по всіх клієнтах.
Відкотити таке розгортання нічим. Якщо реліз публікується поверх попереднього тегу в реєстрі образів, минулий артефакт перезаписано, і «повернути як було» перетворюється на перезбирання з вихідних кодів і повторну валідацію.
Поки це триває, прод-контур відповідає моделлю, якій ніхто не довіряє, і кожна година роботи коштує довіри користувачів.
Справа не в тому, що модель погана. Прод-контур відрізняється від тестового: інший потік запитів, дрейф ознак, нерівномірні сегменти, затримки зовнішніх джерел даних.
Метрика на статичній вибірці нічого не говорить про поведінку на живому трафіку — отже, ризик прод-контуру обмежують до розгортання, а не розбирають після.
Canary deployment саме про це: нова версія отримує малу частку трафіку, зазвичай 1–5%, передбачення порівнюються з еталонною моделлю за сегментами та розподілами, а розходження вище порогу автоматично повертає попередню версію.
Розділення потоку та правила відкату описуються декларативно — в оркестраторах рівня Kubernetes це рівень маніфестів, а не ручних дій чергового. Нижче розбираємо, як такий контур збирається і що потрібно зафіксувати до першого розгортання.
Кероване розгортання моделі: вимірюваний ефект для продукту
На канареечному розгортанні змінюється не лише процедура релізу — змінюється те, що команда бачить і на що встигає зреагувати. Нижче — ефекти, які проявляються вже в перших циклах, і метрики, за якими їх перевіряють.
Частка помилкових відповідей і спостережуваність моделі
Поки нова версія приймає 1–5% трафіку, її показники рахуються окремо від стабільної: частка відмов, розподіл передбачень, затримка, зміщення вхідних даних.
Порівняння йде не «на око», а за еталонним зрізом, зафіксованим до релізу, — розходження видно на перших сотнях запитів, а не через тиждень за відгуками користувачів.
Спостережуваність закриває те, чого немає у звичайному моніторингу сервісу: якість відповіді, а не лише факт відповіді. Збір і розбивка метрик за версіями моделі будуються на Prometheus з алертами на поріг розходження.
Час відкату і зниклий клас відмов
Повернення ваги на стабільну версію — це зміна конфігурації маршрутизації, а не перезбирання і повторний деплой: відкат займає хвилини і не потребує участі всієї команди.
Зникає цілий клас відмов — масове погіршення якості після релізу, коли погані відповіді отримують одразу всі користувачі.
При цьому трафік під наглядом не нульовий: канареечна частка дає достатню статистику, щоб рішення про відкат або розширення приймалося за даними, а не за інтуїцією.
Вартість збою падає не за рахунок «більш акуратних релізів», а за рахунок обмеженого радіуса ураження: помилка залишається на кількох відсотках запитів і гаситься до того, як дійде до всієї аудиторії.
Схеми маршрутизації трафіку для ML: порівняння режимів
Вибір схеми визначається тим, що саме перевіряють: стійкість сервісу чи якість відповідей моделі. Нижче — чотири режими, між якими реально обирають команди, та їх обмеження.
| Варіант | Коли підходить | Чим обмежений |
|---|---|---|
| Канареечне розгортання за часткою трафіку | Потрібна перевірка на живих користувачах при контрольованому ризику: нова версія отримує малу частку запитів, далі частка нарощується за метриками | Потребує автоматичного відкату за метриками, інакше частка зростає «на око»; на рідкісних класах відповідей статистика набирається повільно |
| Тіньовий режим | Копія бойових запитів іде на нову модель, відповіді клієнту не повертаються — якість порівнюють на реальному розподілі | Подвійне навантаження на сервіс моделі; не можна оцінити, як нова відповідь впливає на поведінку користувача |
| Синьо-зелене перемикання | Потрібен миттєвий перевід усього трафіку після прогону перевірок, наприклад при несумісній зміні формату відповіді | Немає проміжних часток: відкат — це повне повернення, потрібен прогрів нового середовища |
| Ручне перемикання | Рідкісні релізи та розбір інцидентів, коли рішення усвідомлено приймає черговий | Залежить від людини: немає градації частки, час реакції дорівнює часу до того, хто помітив проблему |
Що вирішують правила маршрутизації
Частка трафіку — не єдиний важіль: розподіл задається правилами за ідентифікатором клієнта або заголовком запиту, щоб одна сесія не стрибала між версіями.
Для моделей це принципово: розходження відповідей двох версій користувач помічає одразу, а метрики якості розмиваються, якщо порівнювати різні когорти. Тому частку зазвичай фіксують на когорті, а порівняння ведуть за зіставними зрізами трафіку.
Як ми впроваджуємо кероване розгортання: етапи інженерних робіт
Розгортання ML-моделі відрізняється від релізу звичайного сервісу: нова версія може відповідати швидко й без помилок, але давати менш якісні передбачення. Тому частку трафіку прив'язують не лише до доступності, а й до сигналів якості, а перемикання ведуть ступенями.
- Аудит розгортання. Розбираємо, як версії моделі потрапляють у продакшен: де лежать артефакти, як обирається активна версія, чи можна відвести частину трафіку на нову. Відзначаємо місця, де немає зворотного шляху.
- Схема маршрутизації. Визначаємо, де ділиться потік — балансувальник, шлюз або сервіс інференсу, — і як задається частка трафіку: змінюється на ходу чи потребує перезапуску.
- Сигнали якості моделі. Узгоджуємо метрики порівняння версій: частка відмов інференсу, час відповіді, розподіл передбачень, бізнес-метрика на розміченому зрізі. Для кожної — поріг і мінімальний обсяг спостережень.
- Правила перемикання. Фіксуємо в конфігурації стартову частку, крок і паузу між ступенями, умови автоматичної зупинки розгортання.
- Перевірка на трафіку. Ведемо канареечну версію на малій частці, звіряємо сигнали з базовою і нарощуємо ступенями. Для швидкого набору статистики додаємо тіньовий прогін на історичних запитах.
- Регламент відкату. Прописуємо, який сигнал і чий тригер повертає попередню версію, за який час проходить відкат і як перевіряється цілісність після нього.
- Передача. Віддаємо схему маршрутизації, конфігурацію правил, панель метрик і регламент відкату, проводимо розбір з командою.
Комплект постачання: конфігурації, схеми та регламенти відкату
Налаштування канареечного розгортання (canary deployment) для ML-моделей — це не разова правка в конфізі, а набір артефактів, які залишаються у вашої команди.
Через місяць супроводу інженери на стороні замовника самі змінюють частки трафіку, читають метрики й відкочують версію без нашої допомоги.
- Конфігурації розгортання — файли з описом версій, кроків нарощування частки трафіку та порогів, за яких розгортання зупиняється автоматично.
- Схема потоків даних — від вхідного запиту до логування передбачень: де трафік розходиться на дві версії, як порівнюються відповіді, де зберігаються ознаки.
- Політики доступу — розмежування ролей: хто змінює ваги, хто бачить метрики, хто має право на відкат. Окремі області видимості для бойового і тестового контурів.
- Спостережуваність — дашборди за якістю моделі та службовими метриками, алерти на розходження між стабільною і канареечною версією.
- Регламент відкату — критерії спрацьовування, порядок дій, відповідальний за рішення і цільовий час повернення до стабільної версії.
- Документація — інструкції з розгортання, чек-лист перед релізом, опис середовищ і типових збоїв.
- Передача знань — розбір архітектури з вашою командою і запис сесії, щоб підтримка не залежала від нас.
Кейс: переведення рекомендаційної моделі на канареечне розгортання
Як було до впровадження
Рекомендаційна модель оновлювалася раз на два-три тижні, і кожне розгортання йшло одразу на весь трафік — проміжної перевірки на живій аудиторії не було.
Якість у проді безперервно не вимірювалася: орієнтувалися на офлайн-заміри перед релізом, а про деградацію дізнавалися за падінням замовлень, найчастіше вночі. Черговий відкочував вручну — півтори-дві години на діагностику і повернення версії, три-чотири таких випадки на місяць.
Що змінили і що вийшло
Трафік розділили: 5% на нову версію, потім 25%, потім весь потік — просування лише за виконання умов. Онлайн-метрики якості (частка кліків за рекомендаціями і попадання релевантних товарів у першу видачу) звіряються з контрольною групою кожні кілька хвилин.
Поріг якості задано заздалегідь: відхилення метрики нижче контрольної на два процентних пункти або зростання частки відмов запускає автоматичний відкат. Ваги перемикає Kubernetes — повернення на попередню версію йде без участі людини.
Метрики до і після: нічні аварії — було три-чотири на місяць, стало нуль за квартал. Цикл випуску скоротився з двох-трьох тижнів до одного, бо перевірка на 5% потоку займає години і не потребує ручних узгоджень.
Відкат — з двох годин роботи чергового до кількох хвилин за сигналом. Частка розгортань, що доїхали до повного трафіку без відкатів, зросла приблизно до дев'яти з десяти: модель доходить до користувачів швидше, а деградація відсікається на малій частці аудиторії.
Чим канареечне розгортання відрізняється від тіньового режиму?
Тіньовий режим запускає нову модель на копії бойового трафіку: вона рахує передбачення паралельно з поточною, але її відповіді не йдуть користувачу. Впливу на користувачів немає — запити обслуговує попередня версія, а розходження рахуються на тих самих входах. Порівняння виходить чесним за даними, але одностороннім.
Головне обмеження тіньового режиму — немає зворотного зв'язку моделі. Ми бачимо помилки, затримки і дрейф вхідних даних, але не бачимо, як змінюється поведінка людей при нових відповідях.
Частка прийнятих підказок, повторні запити, глибина сесії залишаються за кадром — тіньовий режим ловить технічну деградацію, але не відповідає, чи стало продукту краще.
Канареечне розгортання віддає новій моделі реальну частку трафіку — зазвичай одиниці відсотків — і підвищує її в міру підтвердження метрик.
Вплив на користувачів тут є, зате з'являється справжній зворотний зв'язок: продуктові показники рахуються на тих самих запитах, що й раніше, і їх можна порівнювати з попередньою версією напряму.
Вибір схеми визначається ціною помилки та оборотністю результату. Якщо відповідь моделі перевіряє людина або він не видимий клієнту, починають з малої частки канареечного розгортання.
Якщо помилка помітна і погано відкочується, спочатку проганяють тіньовий режим на реальних даних, а вже потім відкривають трафік. Умови відкату задаються заздалегідь і спрацьовують автоматично — тоді порівняння режимів не перетворюється на ручне чергування біля графіків.
Технічні сумніви: відкат, якість даних, навантаження
Перед увімкненням канареечного деплою на бойовому ML-сервісі виникають одні й ті самі сумніви: хто і як відкочує, як відокремити деградацію моделі від сезонності даних і чи не доведеться переробляти сервіс.
Ручний відкат — це довго і ризиковано?
Ручний відкат безпечний, якщо це перемикання частки трафіку на попередній артефакт моделі, а не перезбирання сервісу. Обидві версії живуть одночасно, ваги правляться одним конфігом, повернення займає десятки секунд. Право натиснути закріплено за роллю, а автотригер за метриками якості страхує.
Як відрізнити деградацію моделі від сезонності даних?
Метрику рахуємо на однаковому зрізі: обидві версії отримують запити в одній пропорції за каналами, регіонами та годинами. Паралельно стежимо за дрейфом вхідних даних — зсувом розподілу ознак.
Якщо входи поїхали і якість впала слідом, це розходження навчальної вибірки з бойовим потоком, а не сезонність.
Чи потрібна переробка сервісу під розділення трафіку?
Зазвичай ні. Якщо сервіс не зберігає стан між викликами, а модель постачається окремим артефактом, розділення робить шлюз — за часткою або службовим заголовком. Переробка потрібна там, де версія вшита в код або вивід іде всередині довгого процесу з накопиченим станом.
Як канареечна версія впливає на навантаження?
Вона забирає частку запитів, тому її пул рахуємо окремо, із запасом під пік. Якщо ресурсів впритул, вмикаємо тіньовий режим: версія отримує копію запитів, не впливаючи на відповідь користувачу, а якість рахуємо офлайн — навантаження на сервіс залишається передбачуваним.
Обговоримо вашу задачу розгортання: повернемося з оцінкою та планом
Оцінка впровадження виходить точною, коли є вихідні дані. Опишіть задачу: що за сервіс, як зараз розгортається нова версія моделі і що у вашому розумінні вважається невдалим релізом. Звіримо це з вашим контуром і повернемося з планом робіт, а не із загальними формулюваннями.
- Схема сервісу: звідки йде трафік, де стоїть балансувальник, куди пишуться відповіді моделі та логи.
- Поточний порядок розгортання: вручну чи автоматично, хто перемикає версію і за якою командою.
- Вимоги до якості: які метрики вважаються погіршенням і на якому обсязі запитів це вже видно.
- Правила відкату: за який час версія має бути повернена і хто приймає рішення про повернення.
- Обмеження контуру: де живуть дані, чи допустимо направляти частину трафіку на нову модель.
- Склад команди та вікна змін, щоб план робіт не конфліктував з поточними релізами.
- Доступи та ролі для налаштування спостережуваності — хто дивиться метрики і хто на них реагує.
З цього збираємо план робіт з етапами, ролями та точками контролю, а наступні кроки фіксуємо після короткого розбору вашого контуру. Напишіть нам і обговоріть задачу — повернемося з оцінкою та планом.
