Миграция в облако: планирование, перенос и оптимизация

Миграция в облако: с on-premise и между провайдерами

Production-сервер с 8-летней историей: три поколения разработчиков, никакой документации, crontab -l выдаёт 47 задач, половина из которых непонятно зачем. MySQL 5.6, EOL более двух лет назад. PHP 7.2. Пачка bash-скриптов в /opt/scripts/ без git. Задача — перенести это в Yandex Cloud за два месяца без остановки сервиса. Вот с чего мы начинаем.

Аудит перед миграцией: что реально живёт на сервере

Первое, что делаем — полная инвентаризация. Не по памяти тимлида, а инструментами.

# Что запущено и слушает порты ss -tlnp # Все процессы с их cmdline ps auxf # Cron всех пользователей for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done # Зависимости PHP-приложения composer show --installed # Установленные пакеты с датой dpkg-query -W -f='${Package} ${Version} ${Status}\n' | grep installed # Хардкод localhost в конфигах grep -r "127.0.0.1\|localhost" /etc/app/ /var/www/ --include='*.{php,yml,conf,env}' 

Systemd units, initd-скрипты, supervisor-конфиги, nginx виртуальные хосты — всё фиксируем. Неочевидный момент: ss -tlnp часто показывает сервисы, о которых никто из команды не знает. Memcached на нестандартном порту, внутренний HTTP-сервер метрик, старый Zookeeper. Каждый такой сервис — зависимость, которую нужно либо мигрировать, либо сознательно выключить.

Профиль нагрузки. Нас интересуют пиковые значения за последние 90 дней — не средние. Если Grafana или Zabbix не настроены, смотрим sar (если sysstat установлен), /var/log/mysql/slow_query.log, vmstat 1 60 во время пиковой нагрузки. Без понимания пиков — невозможно выбрать правильный размер облачных инстансов.

Зависимости между сервисами. На монолитных серверах всё связано напрямую через localhost. В облаке сервисы разъедутся по разным IP — нужна схема: кто к кому обращается, какие порты, есть ли хардкод 127.0.0.1 в конфигах. grep -r находит это быстро, но проверяй и env-файлы, и config/*.php, и application.yml.

Как выбрать стратегию миграции?

Два основных подхода — lift-and-shift и re-platform. Выбор между ними — архитектурное решение, а не технический вопрос.

Lift-and-shift — берём то, что есть, и переносим «как есть» на облачные VMs. Быстро, малорискованно, минимальные изменения кода. Результат — тот же монолит, только в облаке. Не получаем автоскейлинг, managed-сервисы, elastic pricing. Оправдано, если: дедлайн жёсткий, кодовая база не менялась годами, команда маленькая.

Re-platform — на этапе миграции переключаемся с самоуправляемых компонентов на managed-сервисы. MySQL 5.6 → Yandex Managed PostgreSQL 15. Redis на VM → Yandex Managed Redis. Файловое хранилище → Object Storage. Это занимает больше времени, но результат — реально облачная архитектура. Риск: несовместимости при смене БД, изменения в коде, которые нужно тестировать.

Третий вариант — re-architect (контейнеризация, микросервисы) — в рамках миграции нецелесообразен. Это отдельный проект. Совмещать облачный переезд с переписыванием архитектуры — прямой путь к провалу обоих.

Сравнение подходов:

Паттерны миграции данных

Это самая сложная часть. Данные — единственное, что нельзя откатить.

Strangler Fig для постепенного переноса

Паттерн Strangler Fig (описан в книге «Шаблоны корпоративных приложений» Мартина Фаулера): новые запросы постепенно перенаправляются на новую инфраструктуру, старая работает параллельно. Балансировщик (nginx, HAProxy) направляет часть трафика на новые серверы, часть — на старые. Соотношение меняется по мере проверки работоспособности.

upstream backend_old { server 192.168.1.100:8080 weight=9; } upstream backend_new { server 10.0.1.50:8080 weight=1; } # canary: 10% на новый, 90% на старый split_clients "${remote_addr}${date_gmt}" $backend { 10% backend_new; * backend_old; } 

Для stateless-сервисов это работает хорошо. Для stateful — нужна репликация данных в обоих направлениях на период параллельной работы.

MySQL → managed PostgreSQL: реальные грабли

Прямой дамп не работает между разными СУБД. Инструменты: pgloader, AWS Schema Conversion Tool (работает и не с AWS), ручная конвертация DDL.

pgloader умеет читать из MySQL и писать в PostgreSQL напрямую:

LOAD DATABASE FROM mysql://user:pass@old-server/mydb INTO postgresql://user:pass@new-server/mydb WITH include drop, create tables, create indexes, reset sequences, foreign keys SET MySQL PARAMETERS net_read_timeout = '120', net_write_timeout = '120' CAST type bigint to bigint drop typemod, type varchar to text; 

Но pgloader не обрабатывает специфику MySQL, которая несовместима с PostgreSQL:

• ENUM в MySQL конвертируется в TEXT или кастомный тип — надо решить до миграции
• MySQL-специфичные функции в stored procedures (GROUP_CONCAT, IFNULL, DATE_FORMAT) — переписываем вручную на PostgreSQL-аналоги
• utf8mb4 в MySQL = utf8 в PostgreSQL (PostgreSQL всегда использует 4-byte UTF-8), но COLLATION нужно явно задать
• Автоинкрементные поля: в PostgreSQL это SERIAL или GENERATED ALWAYS AS IDENTITY — после импорта нужно сбросить sequences через setval

Проверка после миграции: SELECT COUNT(*) FROM для каждой таблицы на обоих серверах, сравнение хэшей ключевых записей. Расхождение в 1 строку из миллиона — катастрофа, если это заказ или транзакция.

Синхронизация в реальном времени во время cut-over

Cut-over — момент переключения DNS/балансировщика с старого на новый сервер. Цель: минимизировать окно, когда данные на старом сервере изменяются, а на новый не попадают.

Для MySQL → MySQL (lift-and-shift): настраиваем репликацию old-master → new-slave на период миграции. Cut-over:

1. Включаем maintenance mode в приложении (или переключаем балансировщик на страницу «технические работы»)
2. Ждём, пока SHOW SLAVE STATUS на новом сервере покажет Seconds_Behind_Master: 0
3. На старом: FLUSH TABLES WITH READ LOCK
4. Проверяем SHOW MASTER STATUS — позиция лога
5. На новом: STOP SLAVE после достижения той же позиции
6. Меняем connection string в приложении → перезапускаем
7. UNLOCK TABLES на старом
8. Переключаем DNS/балансировщик

Окно read-lock — секунды, не минуты. Если дольше — что-то пошло не так, откатываемся.

Миграция файлов и объектного хранилища

Статика, загрузки пользователей, бекапы — обычно гигабайты или терабайты. rsync с прогрессом и checksumming:

rsync -avz --checksum --progress \ --exclude='*.tmp' \ /var/www/uploads/ \ user@new-server:/var/www/uploads/ 

Для терабайтных объёмов — rsync с --bwlimit чтобы не перегрузить канал на старом сервере во время работы. Первый прогон делаем заранее (за день-два до cut-over), второй — непосредственно перед переключением, только дельту.

При переносе в Object Storage используем rclone sync с 16 параллельными потоками. После переноса — CDN перед Object Storage. Yandex Cloud CDN настраивается на бакет как origin. Публичный URL приложения меняется: https://cdn.example.com/uploads/file.jpg вместо /uploads/file.jpg. Это изменение кода, которое нужно тестировать.

Как мигрировать между облачными провайдерами?

Переход с AWS на Hetzner или между российскими провайдерами — отдельный сценарий. Kubernetes workloads переезжают относительно чисто: экспорт манифестов через kubectl get all -A -o yaml, замена cloud-специфичных аннотаций (StorageClass, LoadBalancer annotations), деплой на новый кластер.

Velero для backup+restore Kubernetes ресурсов:

# Backup на источнике velero backup create full-backup \ --include-namespaces=production,staging \ --storage-location=aws-s3 # Restore на целевом кластере velero restore create --from-backup full-backup \ --namespace-mappings "production:production" 

PersistentVolumes — сложнее. Velero делает volume snapshots через CSI-драйвер, но снапшоты привязаны к провайдеру. Между провайдерами: остановить поды, скопировать данные через временный rsync-под, создать PVC на новом кластере, восстановить данные, запустить поды.

Managed-сервисы (RDS, ElastiCache, managed Kafka) при смене провайдера становятся самоуправляемыми или другими managed-аналогами. Это не техническая задача — это архитектурное решение с анализом feature parity.

Почему rollback plan обязателен?

Любая миграция без плана отката — авантюра. Rollback plan пишем до начала работ, не в процессе. Минимальный rollback plan:

• Условия отката: что именно должно сломаться, чтобы откатываться
• Точка невозврата: после каких действий откат невозможен или стоит дороже, чем решить проблему
• Конкретные команды для переключения обратно на старый сервер
• Ответственный за принятие решения об откате
• Временной лимит: если через X часов проблема не решена — откат автоматически

Типичные сроки

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

Что входит в работу

• Детальный аудит текущей инфраструктуры с документированием всех зависимостей
• Выбор стратегии миграции (lift-and-shift или re-platform) с обоснованием
• Поэтапный перенос данных с верификацией целостности
• Конфигурация managed-сервисов (СУБД, Redis, Object Storage, CDN)
• Обновление connection strings, env-файлов и CI/CD пайплайнов
• Разработка и тестирование rollback plan
• Мониторинг после cut-over в течение 48 часов
• Документация новой инфраструктуры (диаграммы, runbook)
• Обучение команды заказчика работе с облачными сервисами

Наш опыт и гарантии

Над миграциями работают инженеры с сертификатами AWS Solutions Architect, CKA и Terraform Associate. Средний опыт в облачной инфраструктуре — 7+ лет. За последние 5 лет провели более 60 успешных переносов, включая проекты с отказоустойчивостью 99.99%. Гарантируем:

• Целостность данных на каждом этапе (проверка хэшей, контрольные суммы)
• Время простоя не более согласованного окна (обычно 15–30 минут)
• Полную поддержку в течение 2 недель после завершения миграции

Оценим ваш проект — пришлите описание текущей инфраструктуры, и мы предложим стратегию с примерными сроками.

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