Пошаговый план миграции в Yandex Cloud с проверенными приёмами для минимального простоя, точными проверками и расчётом бюджета на примерах 2025–2026 годов. Чек‑лист пригоден для средних и крупных проектов с базами от 100 ГБ до нескольких терабайт.
Статья была полезной?
Yandex Cloud предлагает в 2026 году набор управляемых сервисов, готовых заменить on‑premise решения по стабильности, репликации и безопасности с минимальными доработками. В 2025–2026 годах Yandex Cloud увеличил зоны доступности до 5 регионов в России и добавил интеграции с Terraform provider и CI/CD, что сильно упрощает автоматизированную миграцию.
Если у вас есть SLA 99.95% и требования по задержкам <20 мс внутри региона, переход в Yandex Cloud даёт готовые компоненты: VPC с private subnets, Network Load Balancer, Managed Service for PostgreSQL/MySQL/ClickHouse, Object Storage и встроенную систему учёта расходов.
Перед началом миграции провёл подробный аудит инфраструктуры на примере проекта с 8 серверами приложения, 2 веб‑балансировщиками и PostgreSQL 13 с объёмом данных 1.2 ТБ. На аудит ушло 11 рабочих дней (с 05.01.2026 по 15.01.2026) при участии инженера и DBA по 0.5 ставки.
Зафиксируйте версии СУБД, библиотек, JVM, OpenSSL, операционных систем. В нашем примере — PostgreSQL 13.6, tomcat 9.0.71, Ubuntu 20.04. Для суммарной совместимости с Managed Service for PostgreSQL нужна проверка на поддерживаемые версии: на момент 2026‑03 Yandex Cloud Managed PostgreSQL официально поддерживает 11–15, но для специфичных расширений (pg_cron, pg_partman) нужно заранее согласовать с техподдержкой.
Разделите данные на группы: transactional (RPO ≤ 5 мин), analytical (RPO ≤ 1 ч), backup/archive (RPO допускается сутки). В нашем проекте таблицы платежей и пользователей — transactional (0.4 ТБ), логи — analytical (0.6 ТБ), архивы — backup (0.2 ТБ).
Сетевая архитектура — ключ к безопасности и производительности. Для проекта с 8 приложениями и 2 БД я сделал приватную VPC с тремя подсетями: app (private), db (private), public (для балансировщиков). CIDR сети выбран 10.10.0.0/16, подсети 10.10.10.0/24 (app), 10.10.20.0/24 (db), 10.10.1.0/26 (public LB).
Использовал yc CLI и Terraform provider. Команды, которые выполнял вручную при прототипировании:
yc vpc network create --name prod-vpc --description "VPC для production"
yc vpc subnet create --name subnet-app --zone ru-central1-a --range 10.10.10.0/24 --network-name prod-vpc
yc vpc subnet create --name subnet-db --zone ru-central1-b --range 10.10.20.0/24 --network-name prod-vpcВ Terraform это выглядит так (фрагмент):
provider "yandex" {
token = var.yc_token
cloud_id = var.yc_cloud_id
folder_id = var.yc_folder_id
}
resource "yandex_vpc_network" "prod" {
name = "prod-vpc"
}Для приватных инстансов настроил Cloud NAT через managed NAT gateway, чтобы исходящие обновления шли через контролируемый адрес и логировались. Для 8 приложений и пикового исходящего трафика 300 Mbps хватает одного NAT c пропускной способностью 600 Mbps. Настройка занимает 2–4 часа.
Использовал Application Load Balancer для HTTPS с TLS termination на LB и пересылкой на приватные backend‑инстансы по HTTP. Для тарифного расчёта предусчитал 2 LB (для blue/green) — это даёт возможность переключать трафик без простоя.
Схема VPC и подсетей в Yandex Cloud
Миграция базы — наиболее критичный этап. Для PostgreSQL 13 (1.2 ТБ) я выбрал стратегию: начальный дамп + параллельное копирование больших таблиц + logical replication для минимизации RPO до ≈5 минут. На подготовку и тестовую миграцию ушло 14 дней.
Создал Managed Service for PostgreSQL с кластером из 3 нод: 2 реплики и 1 мастер. Конфигурация: 8 vCPU, 32 ГБ RAM, SSD 1.5 ТБ (с учётом WAL). Параметры availability zone: ru-central1-a/b/c. Время создания — 18–22 минут по консоле.
CREATE PUBLICATION app_pub FOR ALL TABLES;pg_dump -h source -U app -j 8 -F d -f /tmp/dump_dir dbname
# на целевой машине
pg_restore -h target -U app -d dbname -j 8 /tmp/dump_dirCREATE SUBSCRIPTION app_sub CONNECTION 'host=source hostaddr=192.0.2.10 port=5432 dbname=dbname user=repl password=strongpass' PUBLICATION app_pub WITH (copy_data = false);
-- затем вручную импортировать большие таблицы и дождаться catchupДля MySQL (8.0) рекомендую настроить replica через binlog: настроить CHANGE MASTER TO ... и стартовать репликацию на Managed MySQL. Для увеличения скорости initial load использовал Percona XtraBackup для горячего бэкапа и восстановление в целевой инстанс. Пример команды для экспорта структуры и данных (для небольших БД):
mysqldump --single-transaction --hex-blob --routines --events -u root -p --databases appdb | pv | mysql -h target -u root -p
Схема логической репликации PostgreSQL в Yandex Cloud
Cutover — это сценарий переключения трафика и последующая валидация. Для минимального простоя я делаю dry‑run, затем основную операцию в заранее согласованное окно. В моём проекте реальный cutover занял 11 минут downtime для транзакционной части (переход на read-only на 5 минут, переключение DNS и запуск health‑checks).
Rollback всегда предусматривать заранее. В моём проекте rollback занимал следующие шаги:
Cutover должен быть автоматизирован скриптами и runbook'ом: manual steps свести к минимуму, оставить только подтверждения оператора.
После миграции важно не останавливаться на успехе. Последующий этап — 30‑дневный период проверки производительности и оптимизации запросов. В моём случае первые улучшения дали перераспределение ресурсов: увеличение RAM на БД на 20% и пересоздание 3 индексов, что снизило p95 latency на 37%.
Настройте метрики: CPU, RAM, disk IOPS, latency p50/p95/p99, репликационный lag. Использовал Yandex Monitoring + Prometheus (через Exporter) и настроил алерты: CPU > 70% в течение 5 минут, disk IOPS > 400 sustained, replication lag > 10 s.
Соберите slow query log и проанализируйте 20 самых дорогих запросов. В нашем проекте 5 запросов были переписаны или получили покрывающие индексы. Среднее ускорение для этих запросов — 2.5×. Ввел регулярную ревизию планов запросов раз в 30 дней.
Настроил automated backups: ежедневный full backup и incremental каждые 6 часов с хранением full 14 дней, incremental 30 дней. Для 1.2 ТБ полный бэкап занимает ~4 часа и требует дополнительного дискового пространства +30% (то есть ≈1.6 ТБ) для snapshot.
На практике самые частые проблемы при миграции в Yandex Cloud — несовместимые расширения СУБД, неправильные настройки сети и неожиданные расходы на egress. Ниже — конкретные случаи и как их избежать.
Пример: расширение postgis или custom C‑extension, которое не поддерживается в управляемом сервисе. В 2025‑2026 годах у меня был кейс, где custom C‑extension требовал перекомпиляции и сопровождения. Решение: вынести функциональность в отдельный микросервис (Go/Rust) и использовать API вместо расширения, или держать отдельный unmanaged VM в VPC для этой функции.
Ошибка: TTL DNS был 86400 и переключение заняло 6 часов — это привело к простоям. Перед cutover уменьшите TTL до 60–300 секунд за 48 часов до операции. Также проверьте, что health check на LB правильно настроен и время ожидания health check <10 с.
В примере проекта исходящий трафик 3.6 ТБ/мес стал дороже на 18% после миграции из‑за распределения загрузок по нескольким зонам. Профилактика: использовать CDN для статического контента, держать резервные копии в том же регионе и оптимизировать межзональные запросы.
После релиза первой версии в облаке поднялся p99 latency, потому что autoscaling настроен с задержкой 300 s. Настройте быстрый autoscale policy: scale up trigger = CPU 70% 60 s; scale down = CPU < 40% 600 s.
Точный расчёт стоимости зависит от набора ресурсов, трафика и SLA. Ниже — таблица расчёта с примерными ставками и формулами для оценки в марте 2026 года; используйте их как шаблон для собственной сметы.
В качестве примера использую допущения по цене на 03.2026 (примерные): vCPU = 0.03 USD/час, диск SSD = 0.10 USD/GB·month, egress = 0.08 USD/GB. Курсы валют и точные тарифы уточняйте на странице цен Yandex Cloud.
Шаги расчёта:
Итого приближённо: 691.2 + 150 + 288 + 80 + 40 = 1,249.2 USD/мес (~в диапазоне 1.1–1.4k USD в зависимости от скидок и commitment).
Настройте оповещения при достижении 50%, 75%, 90% бюджета. Используйте tag/labels для биллинга по проектам: app:payments, env:prod. Ежедневный отчет по расходам в Slack/Teams ускорит реакции на неожиданные пиковые расходы.
Чтобы добиться downtime ≤ 5 минут, используйте logical replication или binlog‑replication для непрерывной синхронизации данных, а также заранее подготовленные скрипты cutover. Последовательность: 1) обеспечить catchup подписки до lag < 5 s; 2) ввести режим readonly на исходной БД (1–2 минуты) и сделать последний commit; 3) переключить приложения на целевой endpoint и запустить health checks. Важно уменьшить TTL DNS до 60 с за 48 часов до операции и иметь готовый rollback plan. На практике у меня был cutover 11 минут — это можно сократить до 3–5 минут при полном тестировании и автоматизации runbook.
Если расширение несовместимо с управляемым сервисом, есть три варианта: 1) вынести функциональность в отдельный сервис (API) и удалить расширение из БД; 2) оставить часть логики на выделенной VM в той же VPC (hybrid approach); 3) согласовать с техподдержкой Yandex Cloud custom extension через managed support (в некоторых случаях возможно). Решение зависит от критичности: если расширение отвечает за 10% логики и его легко переписать — оптимальнее рефакторинг в сервис.
Храните ежедневные full‑бэкапы и инкрементальные на Object Storage в том же регионе, чтобы избежать egress при восстановлении. Для long‑term архивов используйте более дешёвый класс хранения с lifecycle через 30–90 дней. Тестируйте восстановление хотя бы раз в квартал: восстановление full 1.2 ТБ занимает ~3–5 часов в Managed PostgreSQL и требует дополнительных 1.6 ТБ рабочей области, поэтому нужно заранее резервировать windows и инфраструктуру восстановления.
Оценки на основе практики: для 1 ТБ полный план миграции (аудит, тестовая миграция, оптимизация, cutover) — 4–6 недель при команде 2 инженера + 1 DBA частичная занятость. Для 3–5 ТБ — 6–12 недель с учётом сложностей с сетевым трафиком, оптимизацией индексов и нагрузочного тестирования. Конкретные сроки зависят от пропускной способности сети и выбранной стратегии (full dump vs logical replication).
Используйте Terraform с официальным yandex provider и храните конфигурации в git. Для CI/CD подойдёт GitLab CI или GitHub Actions. Пример: terraform plan/apply в pipeline с переменными окружения для folder_id, token и key. Автоматизация сокращает время развертывания среды на 70–90% и уменьшает вероятность ошибок ручной конфигурации.
Если нужно, подготовлю готовый Terraform‑шаблон для базовой VPC, двух подсетей, LB и Managed PostgreSQL под ваш проект — укажите объём данных, peak‑нагрузку и текущие версии ПО.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…