Миграция legacy в облако: стратегии и практика

Когда речь заходит о миграции старых систем в облако, вопрос почти всегда один: как перевести работающее приложение в облако и не остановить бизнес ни на час. Между «выбрать replatform» и «переключить боевой трафик без простоя» лежит инженерная пропасть. Ниже — разбор того, что определяет исход проекта: какую стратегию брать под конкретную legacy-систему, как добиться переключения без остановки, как перенести данные без потерь и не получить счёт за исходящий трафик, который перечеркнёт экономию. Материал — для архитекторов, IT-руководителей и инженеров DevOps.

Почему компании переносят legacy-системы в облако

Под legacy понимают систему, которую дорого и рискованно менять, хотя бизнес от неё зависит: монолит на устаревшем фреймворке, приложение под неподдерживаемую СУБД, связку сервисов на железе с истёкшими гарантиями. Приговор появляется тогда, когда стоимость владения и риски растут быстрее пользы.

Признаки, что система устарела и тормозит бизнес

Кандидата на модернизацию проще распознать по симптомам, чем по «возрасту кода». Тревожны несколько маркеров одновременно:

• Стек вышел из поддержки. ОС, язык или СУБД больше не получают обновлений безопасности, а перейти на актуальную ветку мешают несовместимые зависимости.
• Поддержка дорожает непропорционально. Каждое изменение требует всё больше человеко-часов: код понимают полтора человека, тесты отсутствуют или неактуальны.
• Потолок масштабируемости. Система упёрлась в возможности сервера, а горизонтально не масштабируется из-за состояния в памяти процесса.
• Риски безопасности и соответствия. Незакрытые уязвимости, отсутствие шифрования, невозможность пройти аудит регуляторов.

Если совпадает три-четыре пункта — система накапливает технический и финансовый долг, который придётся гасить разом.

Когда миграция оправдана, а когда выгоднее остаться on-premise

Миграция оправдана, когда нагрузка неравномерна (пики в отчётные периоды, сезонность, маркетинговые всплески), когда нужна быстрая масштабируемость без закупки оборудования, когда собственный парк требует обновления либо нужна отказоустойчивость уровня, который своими силами не построить.

Оставаться на on-premise рационально в обратных случаях. Стабильная, предсказуемая по нагрузке система, работающая годами без изменений, в облаке нередко обходится дороже — особенно если переезжает «как есть», без оптимизации под управляемые сервисы. Сюда же — специфические требования к оборудованию и ситуации, когда данные по закону должны оставаться под полным контролем. Гибридная модель часто оказывается компромиссом: чувствительное ядро остаётся локально, а масштабируемая периферия и резервные мощности уходят в облако.

Стратегии миграции: какую выбрать под свою систему

Выбор стратегии — компромисс между скоростью, стоимостью и тем, насколько глубоко вы готовы трогать код. Канонический ориентир — модель 7 Rs, выросшая из ранней 5 Rs. Она задаёт общий язык для команды и помогает не путать «перенесли» с «модернизировали».

Модель 7 Rs: от Rehost и Replatform до Refactor

Семь подходов покрывают спектр от «не трогаем ничего» до «переписываем заново»:

1. Rehost (Lift and Shift) — перенос ВМ или приложения без изменений. Самый быстрый путь, но облачные преимущества не задействуются, и счёт за «как было» может оказаться выше ожидаемого.
2. Relocate — перенос с сохранением платформы целиком, например кластера VMware vSphere без переупаковки ВМ. Минимальный простой, минимум переделок.
3. Replatform (Lift and Reshape) — перенос с точечной оптимизацией: своя СУБД на ВМ меняется на управляемую базу провайдера, файловое хранилище — на объектное. Кода касаемся минимально, но снимаем часть операционной нагрузки.
4. Refactor (Re-architect) — глубокая переработка под Cloud Native: разбор монолита на микросервисы, контейнеризация, оркестрация через Kubernetes. Самый дорогой и долгий путь, но именно он раскрывает масштабируемость и отказоустойчивость облака.
5. Repurchase (Drop and Shop) — отказ от своей системы в пользу готового SaaS, когда функциональность типовая (почта, CRM, учёт) и поддерживать своё дороже подписки.
6. Retire — вывод из эксплуатации ненужного. Аудит часто вскрывает 10–20% сервисов, которые можно просто выключить.
7. Retain — осознанное решение оставить систему на месте: из-за требований к данным или близкого вывода из эксплуатации.

Главная инженерная ловушка для legacy — слепой Rehost. Старый монолит можно перенести «как есть» за выходные, но в облаке он продолжит потреблять ресурсы так же неэффективно, только теперь вы платите за каждый избыточный гигабайт памяти ежемесячно. Поэтому для нагруженных систем чаще оправдан Replatform, а для будущего ядра бизнеса — Refactor.

Связка стратегии и уровня простоя: чем платишь за скорость переноса

Стратегию сразу проверяют на главное ограничение проекта: сколько простоя вы можете себе позволить. Чем глубже переработка, тем больше работы заранее, но тем мягче финальное переключение. И наоборот: «быстрый» Rehost при холодном переносе даёт самый заметный простой.

Закономерность простая: простой при переключении обратно пропорционален вложенной заранее работе по репликации и параллельному запуску. Холодный Rehost экономит подготовку, но платит окном недоступности. Refactor и грамотная репликация переносят основную нагрузку на этап до переключения, оставляя на момент переключения лишь короткое окно или незаметную смену маршрута трафика.

Как перенести приложение без простоя

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

Blue-green, canary и поэтапное переключение трафика

Blue-green развёртывание — две идентичные среды. «Синяя» — текущий прод, «зелёная» — новое окружение в облаке. Пока пользователи работают на синей, зелёную наполняют данными, прогоняют через нагрузочное тестирование и проверяют функционально. Переключение — смена маршрута на балансировщике или обновление DNS-записи; для пользователя оно проходит за секунды. Если что-то пошло не так, маршрут возвращают на синюю среду, и откат занимает столько же, сколько переключение.

Canary-выкатка — более осторожный вариант: на новую систему пускают долю трафика — сначала 1–5%, затем 25%, 50% и до 100%. На каждом шаге следят за метриками: доля ошибок (HTTP 5xx), задержки ответа, нагрузка на базу, бизнес-показатели вроде конверсии. Пока показатели в норме — увеличивают долю; при отклонении — откатывают, и проблема затрагивает лишь малую часть пользователей.

При DNS-переключении держите в уме TTL: записи кешируются у провайдеров и клиентов, поэтому за несколько дней до миграции TTL снижают до 30–60 секунд. Поэтапный перевод трафика на уровне балансировщика этого ограничения лишён и для критичных систем предпочтительнее DNS.

Перенести парк виртуальных машин из зарубежного облака без остановки бизнеса помогает миграция из зарубежных сервисов от Cloud4Y на базе VMware vCloud Availability. Сервис реплицирует виртуальные машины между площадкой клиента на VMware vSphere или Cloud Director и облаком провайдера, поддерживает «горячую» и «холодную» миграцию и перенос в обе стороны. Реплика поддерживается в актуальном состоянии заранее, поэтому финальное переключение проходит с минимальным простоем и без потери данных.

Окна обслуживания, обратная совместимость API и план отката

Даже при идеальной репликации остаётся короткое окно обслуживания — момент финальной синхронизации и переключения. Его планируют на время минимальной нагрузки, заранее предупреждают пользователей и сокращают до предела: при горячей миграции это минуты, а не часы.

Отдельная сложность — обратная совместимость API. Если вы переключаете сервисы по очереди, какое-то время старые и новые версии работают одновременно. Значит, изменения API должны быть совместимыми: новые поля добавляются как необязательные, старые проходят цикл устаревания. Принцип «расширяй, потом сокращай» (expand–contract) позволяет менять схему данных и контракты, не ломая работающих потребителей.

План отката (rollback) — часть проекта с чёткими критериями. До переключения зафиксируйте:

• Критерии успеха — пороги: доля ошибок ниже X%, задержка p95 ниже Y мс, расхождение данных нулевое.
• Критерии отката — при каком значении метрики вы откатываетесь, не дожидаясь, пока проблема разрешится сама.
• Точку невозврата — момент, после которого откат невозможен (например, когда старая база начала принимать новые записи без обратной синхронизации).
• Ответственного за решение — человека, который по метрикам даёт команду на откат, чтобы не терять минуты на согласования.

Перенос данных без потерь и роста счетов

Данные — самая недооценённая часть миграции. Приложение поднимается за часы, а терабайтную базу со сложными связями и активной записью переносят неделями. Здесь проваливается больше проектов, чем на самом коде.

Репликация, CDC и dual-write: синхронизация на лету

Перенести базу «стоп — копируем — запускаем» можно только если бизнес терпит простой на всё время копирования. Для крупных СУБД это неприемлемо, поэтому применяют непрерывную синхронизацию.

• Логическая репликация — встроенный механизм СУБД (PostgreSQL, MS SQL), передающий изменения с основной базы на реплику почти в реальном времени. Сначала переносится первичный снимок, затем реплика догоняет основную базу по журналу и держится в актуальном состоянии до переключения.
• CDC (Change Data Capture — захват изменений из журнала транзакций) — отдельный процесс читает журнал СУБД и транслирует каждое изменение в целевую систему. Удобен, когда базы разного типа или поток изменений нужно дополнительно обрабатывать по пути.
• Dual-write (двойная запись) — приложение какое-то время пишет одновременно в старую и новую базу. Даёт контроль, но при сбое записи в одну из баз появляется расхождение, поэтому метод применяют с проверкой консистентности и на ограниченный период.

На практике для крупных СУБД чаще выбирают связку «первичный снимок + репликация по журналу»: она минимизирует и простой, и риск рассинхронизации. Двойную запись оставляют для случаев, когда нужно подстраховать переключение возможностью писать в обе системы сразу.

Проверка целостности данных и контроль стоимости трафика

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

Второй неочевидный фактор — стоимость исходящего трафика (egress). Когда данные уезжают из зарубежного облака, провайдер берёт плату за каждый гигабайт на выходе. Порядок цифр на примере компании, переносящей базу и файловое хранилище общим объёмом 50 ТБ:

Суммы ориентировочны: итог сдвинется в зависимости от тарифа провайдера, региона и реального объёма изменений. Сократить расходы помогают: сжатие данных перед передачей, перенос только актуальных данных, исключение того, что подлежит выводу из эксплуатации, и выбор провайдера с бесплатными входящим трафиком и внутренними перемещениями. Российские провайдеры, как правило, не тарифицируют входящий трафик, поэтому основная статья — именно выход из исходной зарубежной платформы.

План миграции и российские требования

Воспроизводимый проект отличает наличие порядка действий, критериев перехода между этапами и заранее оговорённого отката. Ниже — рабочий каркас, масштабируемый и на одно приложение, и на целый парк систем.

Чек-лист проекта: от аудита зависимостей до вывода старой системы

1. Аудит и инвентаризация. Карта систем, их зависимостей, интеграций и потоков данных. Здесь же выявляются кандидаты на Retire и неочевидные связи, обрыв которых ломает соседние сервисы.
2. Выбор стратегии под каждую систему. Для каждого приложения — своя буква из 7 Rs, исходя из критичности, допустимого простоя и бюджета.
3. Оценка данных и трафика. Объёмы СУБД, скорость изменений, расчёт стоимости переноса и исходящего трафика.
4. Пилот. Перенос одной некритичной системы целиком — от репликации до переключения. Пилот вскрывает проблемы методики до того, как они затронут бизнес-критичные нагрузки.
5. Нагрузочное тестирование. Проверка новой среды под реальным и пиковым профилем. Пропущенный нагрузочный тест — частая причина, по которой «успешная» миграция падает в первый же час боевого трафика.
6. Финальная синхронизация и переключение. Окно обслуживания, перевод трафика по выбранной схеме (blue-green или canary), контроль метрик.
7. Стабилизация и наблюдение. Несколько дней-недель работы новой системы под наблюдением с готовым планом отката.
8. Вывод старой системы. Только после подтверждённой стабильности — отключение, архивирование данных и высвобождение ресурсов. Спешка на этом шаге лишает вас страховки.

Требования 152-ФЗ, размещение в РФ и миграция 1С без простоя

Для российского бизнеса к технической части добавляется регуляторная. Если в системе есть персональные данные, действует 152-ФЗ: данные граждан РФ должны храниться и обрабатываться на серверах, физически расположенных в России. Это отсекает значительную часть зарубежных площадок и делает миграцию с уходящих западных облаков не только технической, но и юридической задачей. Для платёжных данных добавляется PCI DSS, для ряда отраслей — отраслевые требования к защите информации.

Размещение в дата-центре уровня Tier III на территории РФ закрывает сразу два вопроса: соответствие требованиям по локализации и инженерную отказоустойчивость. При переносе персональных данных важно, чтобы провайдер мог подтвердить соответствие документально — аттестация и сертификации (ISO 27001, соответствие 152-ФЗ) снимают часть нагрузки по доказыванию с вашей стороны.

Главные выводы

Перенос legacy в облако — это не выбор «правильной» буквы из модели 7 Rs, а согласование трёх вещей: глубины переработки, допустимого окна недоступности и способа переноса данных. Чем меньше простоя вы готовы допустить, тем больше работы придётся вложить заранее — в репликацию, параллельный запуск новой среды и проверку её под реальной нагрузкой. Холодный Rehost экономит подготовку ценой видимого простоя; Replatform и Refactor вместе с непрерывной синхронизацией данных переносят основную нагрузку на этап до переключения.

Предсказуемость проекта складывается из конкретики, а не из общих намерений. Это аудит зависимостей и честный выбор стратегии под каждую систему, репликация по журналу или CDC вместо переноса с остановкой, проверка целостности данных до переключения, заранее посчитанная стоимость исходящего трафика и план отката с измеримыми критериями. Для российских компаний к этому добавляется размещение в РФ под требования 152-ФЗ и PCI DSS и отдельная проработка таких сценариев, как миграция 1С.