Міграція high-load сервісу без простою: як синхронізувати дані, зберегти сумісність і передбачити зворотну міграцію — досвід SharksCode
Коли сервіс працює 24/7 і має зовнішніх та внутрішніх споживачів, вікна для технічного обслуговування фактично не існує. З таким завданням стикнулася команда SharksCode, коли мігрувала high-load backend-компонент разом із його data layer на нову інфраструктуру та нову схему зберігання даних. Стара реалізація почала обмежувати масштабування та ускладнювати незалежне масштабування навантаження на читання й запис. Тим часом будь-які зміни схеми та релізи ставали дедалі ризикованішими. Компанія готувала систему до подальшого росту й хотіла зробити це без жодної хвилини простою.
Коли сервіс працює 24/7 і має зовнішніх та внутрішніх споживачів, вікна для технічного обслуговування фактично не існує. З таким завданням стикнулася команда SharksCode, коли мігрувала high-load backend-компонент разом із його data layer на нову інфраструктуру та нову схему зберігання даних. Стара реалізація почала обмежувати масштабування та ускладнювати незалежне масштабування навантаження на читання й запис. Тим часом будь-які зміни схеми та релізи ставали дедалі ризикованішими. Компанія готувала систему до подальшого росту й хотіла зробити це без жодної хвилини простою.
Підготовка як половина успіху
Перед стартом команда зафіксувала повну картину системи. Сюди увійшли всі сервіси-виробники та споживачі, API- й event-контракти, залежності від бази, критичні користувацькі сценарії, а також SLO та baseline поточного сервісу. Нову систему перевіряли навантажувальними тестами на показниках, що перевищували production baseline, тож інженери заздалегідь бачили запас міцності. На цьому ж етапі окреслили головні ризики, серед яких втрата чи дублювання даних, розсинхронізація стану двох систем, деградація latency та перевантаження бази під час подвійного запису.
Обидві версії певний час працювали паралельно. Це стало основою безпечного переходу. Команда дотримувалася принципу: спершу робимо сумісним споживача, а вже потім змінюємо виробника. У роботі допомагали backward-compatible зміни контрактів. Замість обовʼязкових полів команда додавала опціональні, а між старою й новою моделлю працювали адаптери. Версіонування контракту застосовували лише там, де без breaking changes обійтися було неможливо. Завдяки цьому переключення сервісу не потребувало одночасного релізу всіх залежних систем.
Синхронізація даних під час переходу та захист від дублів і порушення порядку подій
Для міграції обрали подвійний запис із event-based синхронізацією за схемою request → primary system → event/outbox → new system. На першому етапі джерелом правди залишалася стара система, тоді як нову наповнювали історичним backfill, поточними подіями та повторною синхронізацією пропущених записів. Щоб тримати процес під контролем, інженери налаштували автоматичний reconciliation. Він постійно звіряв між системами кількість записів разом з їхніми ідентифікаторами, статусами та контрольними агрегатами.
Кожна операція отримувала унікальний operation/event ID. Поверх цього працювала ідемпотентність із дедуплікацією. Повторні запити оброблялися через retry з backoff та unique constraints. Перед оновленням стану система звіряла version і timestamp події. Без такого захисту повторна доставка могла створити зайву операцію, а старіша подія ризикувала перезаписати новіший стан. Команда окремо перевіряла повторну доставку однієї події та зміну порядку її надходження.
Цей сценарій дав один із найпоказовіших технічних уроків. Подія зі статусом v2 могла бути оброблена раніше за затриману подію зі статусом v1. Без додаткового захисту старіший стан перезаписував актуальний. Проблему помітили завдяки reconciliation та розбіжностям між системами. Після цього інженери додали версію сутності та перевірку sequence перед оновленням. Зʼявилася також окрема метрика out-of-order events. Аномальна кількість відхилених оновлень стала тригером для алерту.
До роботи з реальним трафіком команда окремо перевірила весь сценарій міграції. Використовували integration і contract tests, load tests, schema validation, replay production-like traffic та end-to-end migration tests. Окремо моделювали timeout залежностей, повторну й дубльовану доставку подій, зміну їхнього порядку, недоступність нової бази даних, падіння consumer та відновлення після накопичення backlog. Сценарій rollback тестували окремо так само, як і основний migration flow.
Поетапне переключення, контроль метрик та відкат, продуманий заздалегідь
Від big bang свідомо відмовилися. Трафік переводили сходинками shadow → 1% → 5% → 10% → 25% → 50% → 100%. Спочатку нова система отримувала shadow traffic без впливу на результат. Після підтвердження коректності через feature flag почали спрямовувати реальні запити. Частку збільшували тільки після стабільного вікна спостереження.
Увесь цей час команда стежила за станом обох систем. Під наглядом були швидкість та відсоток помилок, поведінка бази під навантаженням, затримки в чергах і повторні запити. Окремо інженери контролювали розбіжності даних між системами та успішність бізнес-операцій.
Серед ключових показників команда окремо контролювала error rate, p95/p99 latency, timeout rate, database CPU/IO, queue lag, retry rate та кількість data mismatches. До наступного етапу переходили лише тоді, коли показники нової системи залишалися не гіршими за baseline. Зростання помилок, деградація p95/p99, накопичення queue lag, розбіжності даних або ризик перевантаження бази були сигналом зупинити переключення.
Маршрутизацію тримали під контролем feature flag та конфігурації, тож повернути трафік на стару систему можна було без нового деплою. Стара версія весь час отримувала потрібні дані. Операції, що вже пройшли через нову систему, синхронізувалися назад через event pipeline та reconciliation. Автоматичний rollback спрацьовував при порушенні порогу помилок, втраті чи пошкодженні даних, критичній деградації latency та неконтрольованому рості backlog. Сценарій відкату проходив таке саме окреме тестування, як і основний міграційний flow.
Після завершення міграції команда зафіксувала стабільнішу p95/p99 latency, менше інцидентів під час пікового навантаження, скорочення ручних операцій і швидше відновлення. Горизонтальне масштабування стало простішим, а зміни окремих компонентів більше не вимагали скоординованого релізу великої кількості залежних сервісів.
Головний висновок
Міграція high-load сервісу без простою тримається на дисципліні підготовки й повазі до старої системи, яка працює аж до останнього перевіреного етапу. Коли всі складові переходу продумані заздалегідь, міграція перестає бути стрибком у невідоме й перетворюється на керований процес із чіткими критеріями на кожному кроці. Такий підхід дозволив команді SharksCode оновити інфраструктуру непомітно для користувачів і закласти основу для спокійного росту сервісу надалі.
