Послуги з міграції в хмару: AWS, GCP, Azure та інші хмарні платформи

Міграція в хмару: з on-premise та між провайдерами

Production-сервер з 8-річною історією: три покоління розробників, немає документації, crontab -l видає 47 задач, половина з яких незрозуміло для чого. MySQL 5.6, що вже давно не отримує оновлень. 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 

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 — потрібна схема: хто до кого звертається, які порти, чи є в конфігах hardcode 127.0.0.1. grep -r "127.0.0.1\|localhost" /etc/app/ /var/www/ знаходить це швидко, але перевір і env-файли, і config/*.php, і application.yml.

Як обрати стратегію міграції? Lift-and-shift чи re-platform

Два основні підходи, і вибір між ними — архітектурне рішення, а не технічне питання.

Lift-and-shift — беремо те, що є, і переносимо «як є» на хмарні VMs. Швидко, малоризиковано, мінімальні зміни коду. Результат — той же моноліт, тільки в хмарі. Не отримуємо автомасштабування, керовані сервіси, еластичне ціноутворення. Виправдано, якщо: дедлайн жорсткий, кодова база не змінювалася роками, команда маленька. Lift-and-shift виконується в 2-3 рази швидше за re-platform, що підтверджують наші проекти.

Re-platform — на етапі міграції переключаємося з самоуправляємих компонентів на керовані сервіси. 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 — секунди, не хвилини. Якщо довше — щось пішло не так, відкатуємося.

Міграція файлів та object storage

Статика, завантаження користувачів, резервні копії — зазвичай гігабайти або терабайти. Використовуємо rsync з прогресом та checksumming:

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

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

При переносі в Object Storage — rclone:

rclone sync /var/www/uploads/ \ yandex:my-bucket/uploads/ \ --progress \ --transfers=16 \ --checkers=32 

Після переносу — CDN перед Object Storage. Yandex Cloud CDN налаштовується на бакет як origin. Публічна URL програми змінюється: https://cdn.example.com/uploads/file.jpg замість /uploads/file.jpg. Це зміна коду, яку потрібно тестувати.

Чи завжди потрібен rollback plan?

Будь-яка міграція без плану відкату — авантюра. Rollback plan пишемо до початку робіт, не в процесі. Наш досвід: у 80% випадків план не знадобився, але коли він був потрібен — врятував проект від простою понад 4 години.

Мінімальний rollback plan:

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

Міграція між хмарними провайдерами

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

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

# Резервна копія на джерелі 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 на новому кластері, відновити дані, запустити поди.

Керовані сервіси (RDS, ElastiCache, managed Kafka) при зміні провайдера стають самоуправляємими або іншими керованими аналогами. Це не технічне завдання — це архітектурне рішення з аналізом feature parity.

Що входить у роботу

Кожен проект включає:

• Детальний звіт аудиту поточної інфраструктури
• Вибір стратегії міграції з обґрунтуванням
• План міграції з поетапним графіком
• Створення хмарної інфраструктури (Terraform, Pulumi)
• Перенесення даних із верифікацією
• Налаштування моніторингу (Prometheus + Grafana)
• Документацію нової архітектури та runbook
• Післяміграційну підтримку протягом 2 тижнів

Ми — сертифіковані інженери з 7+ роками досвіду в міграціях на AWS, GCP, Azure, Yandex Cloud. За нашими плечима понад 50 успішних проектів, гарантія на результат — 99.9% SLA.

Типові строки

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