Міграція AI-рішення між хмарними провайдерами з мінімальним простоєм

Міграція AI-рішення: де ламається і що втрачає бізнес

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

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

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

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

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

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

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

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

Розбираємо, як це закривається: поетапне перенесення навантаження, прогрів і контроль метрик якості на кожному кроці.

Ефект міграції: простій, відмови, швидкість відновлення

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

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

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

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

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

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

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

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

Способи переїзду: холодний, живий і поетапний перенос

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

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

Як вибрати режим

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

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

Етапи роботи: від аудиту залежностей до передачі

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

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

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

Схеми, політики доступу та регламенти перемикання

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

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

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

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

Кейс: перенесення робочого навантаження без зупинки сервісу

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

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

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

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

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

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

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

Потім — від 5 до 10 відсотків користувацьких запитів, і далі кроками до сотні. Обов’язкова умова — сумісність контурів за форматом вхідних даних, схемою відповіді моделі та версією індексу, інакше порівняння якості на вибірці перетворюється на шум.

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

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

Це саме правило дозволяє розводити потік за когортами — тенантами або типами завдань, а не «випадковими десятьма відсотками», і якість на вибірці залишається відтворюваною.

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

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

Технічні сумніви: зберігання, доступи, зворотний хід

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

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

Як передаються секрети та ключі доступу?

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

Що відбувається з навченими моделями?

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

Чи можна повернутися на попередній контур?

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

Обговоримо задачу: зберімо план перенесення та оцінку

Щоб план перенесення спирався на реальну картину, а не на припущення, починаємо з вихідних даних. Дивимося їх у такому порядку: спочатку зв’язки між сервісами, потім профіль навантаження, далі вимоги до зберігання даних. Так оцінка строків виходить за фактом, а не «на око».

Що корисно надіслати до обговорення задачі:

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

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