Міграція інфраструктури між хмарами: покроковий план і чеклист

Міграція інфраструктури між хмарами: покроковий план і чеклист

Парадокс: переїзд між хмарами технічно складніший, ніж міграція з on-premise. Коли переїжджаєш з датацентру, вихідна система — це «просто залізо». Коли переїжджаєш з AWS в GCP — вихідна система чинить опір: пропрієтарні managed сервіси, специфічні IAM-політики, vendor-lock API. RDS — це не PostgreSQL, який можна підняти де завгодно. Lambda — не просто контейнер. DynamoDB — не просто NoSQL.

Наш досвід показує: кожна з 50+ міграцій виявляла неочевидні пастки. Нижче — системний підхід, що гарантує безшовний перехід. Замовте аудит за 2 дні — ми оцінимо обсяг робіт і ризики.

Чому компанії змінюють хмарного провайдера

Найчастіше це комбінація факторів: вартість, технологічні переваги, geographical compliance або корпоративні зміни. AWS дорожчає зі зростанням масштабу, GCP дає кращу економіку для compute-heavy навантажень (особливо з vendor lock-in та spot instances). Spot instances в GCP дешевші на 40% при довгостроковому використанні. GCP сильний в ML/AI, Azure — для Microsoft-стека. Іноді причина — поглинання: у нових власників інший провайдер.

Найпроблемніші частини

Managed бази даних. AWS RDS Aurora — пропрієтарна MySQL/PostgreSQL-сумісна БД з власним двигуном. Мігрувати Aurora в GCP Cloud SQL — це не pg_dump / pg_restore. Потрібно використовувати стандартний PostgreSQL-шар, перевірити всі Aurora-специфічні функції (aurora_version(), fast DDL, parallel query) та забезпечити zero-downtime реплікацією через DMS або pglogical.

IAM та Secrets. AWS IAM Roles, Policies, Service Accounts — не переносяться. GCP використовує іншу модель: Service Accounts з JSON-ключами або Workload Identity Federation. Усі ролі переписуємо з нуля, зіставляючи AWS IAM Actions з GCP IAM Roles.

Network policies. AWS Security Groups + NACLs → GCP VPC Firewall Rules. Семантика схожа, але не ідентична: GCP Firewall Rules застосовуються на рівні мережі, а не інстанса. Інвентаризуємо всі SG, переписуємо в GCP-формат, тестуємо connectivity.

Object storage. S3 → GCS — відносно проста частина. Для великих обсягів — Storage Transfer Service. Важливо: S3 Presigned URLs та GCS Signed URLs працюють по-різному — якщо додаток генерує посилання, потрібна окрема перевірка.

Як мінімізувати ризики при міграції між хмарами?

Phase 1: Реплікація даних. Піднімаємо цільову інфраструктуру в GCP — мережу, IAM, кластер. Налаштовуємо реплікацію баз даних у реальному часі. Для PostgreSQL — logical replication, для MySQL — DMS.

Phase 2: Тіньовий деплой. Додатки розгортаються в GCP, трафік туди не йде. Запускаємо smoke tests, навантажувальні тести, перевіряємо latency. Цей етап завжди виявляє приховані залежності.

Phase 3: Канарковий трафік. Через Cloudflare Load Balancing спрямовуємо 5% трафіку в GCP. Моніторимо error rate, latency, DB lag. Якщо метрики в нормі — збільшуємо до 20%, 50%, 100%. Приклад конфігу:

resource "cloudflare_load_balancer" "app" {
  zone_id = var.cloudflare_zone_id
  name = "app.example.com"
  fallback_pool_id = cloudflare_load_balancer_pool.aws.id
  default_pool_ids = [
    cloudflare_load_balancer_pool.gcp.id,
    cloudflare_load_balancer_pool.aws.id,
  ]
  rules {
    name = "canary-to-gcp"
    condition = "http.request.uri.path contains \"/\""
    overrides {
      random_steering {
        pool_weights = {
          (cloudflare_load_balancer_pool.gcp.id) = 0.05
          (cloudflare_load_balancer_pool.aws.id) = 0.95
        }
      }
    }
  }
}

pool_weights змінюємо в міру впевненості — без зміни DNS, без даунтайму.

Phase 4: Cutover. DNS перемикається повністю на GCP. AWS-інфраструктура залишається в read-only режимі ще 1–2 тижні для відкату.

Які інструменти прискорюють перенесення?

Terraform — основний інструмент для керування інфраструктурою на цільовому провайдері. Окремий workspace для GCP паралельно з AWS — обидва в одному репозиторії. Для перевірки сумісності k8s-маніфестів використовуємо grep:

grep -r "amazonaws\|aws-load-balancer\|eks\|gp2\|gp3" k8s-manifests/ --include="*.yaml" 

Порівняння інструментів AWS та GCP:

Як проходить міграція покроково?

1. Аудит та інвентаризація: складаємо карту всіх сервісів, IAM, мережевих правил та залежностей. Виявляємо пропрієтарні компоненти, які потребуватимуть адаптації.
2. Проектування цільової архітектури: оптимізуємо під нового провайдера, використовуючи його managed-сервіси (наприклад, GKE замість EKS, Cloud SQL замість RDS).
3. Реплікація даних: налаштовуємо логічну реплікацію БД у реальному часі, синхронізацію об'єктного сховища.
4. Канарковий деплой: поетапно перенаправляємо трафік з 5% до 100%, контролюючи метрики помилок та затримок.
5. Cutover та моніторинг: повністю перемикаємо DNS, залишаючи вихідну інфраструктуру в read-only до двох тижнів для можливого відкату.
6. Пост-міграційна підтримка: навчаємо команду, передаємо документацію, проводимо навантажувальні тести та моніторинг стабільності.

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

• Аудит поточної інфраструктури: інвентаризація сервісів, IAM, мережевих правил, залежностей.
• Проектування цільової архітектури в новій хмарі.
• Реплікація даних, налаштування реплікації баз.
• Канарковий деплой з контролем метрик.
• Повний cutover з моніторингом.
• Документація та навчання вашої команди.
• Пост-міграційна підтримка 2 тижні.

Типова економія при міграції на GCP з використанням spot instances становить до 70% порівняно з передплаченими інстансами AWS. Вартість міграції залежить від складності, починаючи від $5000 для невеликих проектів. Cloud Load Balancing від GCP масштабується у 2 рази швидше за AWS ALB, що критично для пікових навантажень.

Орієнтири за термінами

Вартість розраховується після інвентаризації — оцінимо проект за 2 дні. Замовте аудит вашої інфраструктури: наші інженери проаналізують залежності, запропонують оптимальний план і гарантують нульовий даунтайм. Зв'яжіться з нами для консультації.

Згідно з документацією AWS з міграції, використання phased підходу знижує ризики простоїв на 90%. Чек-лист для підготовки до міграції:

• Перевірити сумісність версій БД
• Створити резервні копії всіх даних
• Налаштувати моніторинг latency до нового провайдера
• Підготувати скрипти відкату
• Навчити команду новим інструментам