Multi-cloud стратегия и миграции
1) Зачем multi-cloud и когда это оправдано
Цели: непрерывность бизнеса (резерв по провайдеру), суверенитет данных/юрисдикции, оптимизация стоимости/скидок, доступ к лучшим управляемым сервисам (ML/антифрод/аналитика).
Компромиссы: рост сложности операций, дублирование компетенций, сетевые egress-издержки.
Ключ: заранее определить, где нужна переносимость, а где допустима vendor lock-in ради скорости/цены.
2) Целевые архитектурные модели
Portable Core: критичное ядро (API, доменные сервисы, данные) — переносимое (K8s, Postgres, Kafka, Redis, MinIO/Vault); периферия — natively-managed.
Active-Active Multi-cloud: два облака обслуживают трафик одновременно (сложно: конфликты данных, глобальная маршрутизация).
Active-Passive (Hot/Warm): один — основной, второй — горячий/теплый DR.
Hybrid: часть в он-прем/часть в облаках (часто для юридических/PII ограничений).
3) Паттерны переносимости
Kubernetes как базовая платформа (алиасы: EKS/GKE/AKS/он-прем K8s).
Service Mesh (mTLS, traffic shifting, locality/failover; Istio/Linkerd).
IaC: Terraform + модульные абстракции; для K8s — Helm/Kustomize + GitOps (Argo/Flux).
Секреты: HashiCorp Vault/External Secrets Operator; абстракция над KMS/HSM.
Хранилища: Postgres (операторы/Patroni), Kafka (операторы/MirrorMaker2), Redis (сентинел/кластер), S3-совместимые (MinIO) для единообразия API.
Наблюдаемость: OpenTelemetry + вендор-нейтральные бэкэнды (Prometheus/Tempo/Loki/ClickHouse).
Аутентификация: OIDC/OAuth2 (Keycloak/Auth0/Entra/Google), единая федерация.
API-слой: Envoy/NGINX/Contour + общие политики (CORS, мандатные заголовки, rate limits).
4) Стратегии миграции (7R — кратко)
Rehost (Lift-and-Shift): быстро, без переработки; хорошо для статлесс/VM, плохо для стоимости.
Replatform: перенос на K8s/упрощение зависимостей (менее рискованно, чем refactor).
Refactor/Repurchase: переписать под portable-паттерны или заменить сервисом SaaS.
Retain/Retire: оставить/вывести из эксплуатации то, что не нужно переносить.
Практика: начинать с реестра сервисов (критичность, RTO/RPO, SLO, зависимости), составить миграционные волны (по доменам).
5) Данные и консистентность
Репликация/CDC: Debezium/страиминг логов для Postgres/MySQL; Kafka MirrorMaker2 для топиков.
Двунаправленная синхронизация: только при строгой идемпотентности и ключах версионирования (vector clock/updated_at).
Dual-write с дедупом: записи помечаются `Idempotency-Key`/`event_id` + outbox/inbox для гарантированной доставки.
Разделение владения: лидер-регион/облако per key/tenant, чтобы избежать конфликтов.
Кэш: локально-региональный; глобальный только через события/TTL (никакого «общего» глобального кэша с сильной консистентностью).
6) Глобальный трафик и сеть
GSLB/DNS: latency/geo-routing + health-checks, weights для канареек/фейловера.
Anycast/Edge/CDN для близости к пользователю, затем — прокладка до ближайшего здорового региона/облака.
Прямые каналы: Interconnect/ExpressRoute/Direct Connect между облаками/он-прем для снижения egress/латентности.
Клиентские политики: короткие таймауты, экспоненциальный backoff+джиттер, итерационные ретраи, идемпотентность write-операций.
7) Безопасность и соответствие
mTLS везде (mesh + SPIFFE/SPIRE или собственная PKI).
KMS/HSM: абстрагируйте API через Vault; сегментация ключей per юрисдикция/тенант.
IAM: единая модель ролей и групп (SCIM/SSO), политика наименьших привилегий, временные креденшелы (STS).
Секреты/ротация: автоматическая ротация токенов/паролей; блокировка «длинных» статических ключей.
Compliance: PCI DSS/GDPR — data residency, изолированные журналы аудита, гео-блоки.
8) Наблюдаемость, SLO и Error Budgets
Сигналы RED/USE + трейсы + профайлы во всех облаках; единый формат логов (JSON + `trace_id`).
Trace sampling tail-based: сохранять ошибки/p99, сегменты по `cloud`, `region`, `tenant`.
SLO per облако/регион + общий агрегат; алерты по burn-rate (multi-window).
Канареечные дашборды «до/после миграции», отчет по регрессам.
9) CI/CD и управление конфигами
GitOps: артефакты образов едины, конфиги — per-environment/region через Helm values/Kustomize overlays.
Секреты через External Secrets Operator (мосты к AWS/GCP/Azure секрет-хранилищам).
Промо-потоки: dev → staging → canary (cloud A) → canary (cloud B) → full.
Release gates: чекаут SLO/Synthetic/Contract-tests перед ростом веса трафика.
10) Стоимость и FinOps
Учитывайте egress-тарифы между облаками, скидки RI/CUD/Savings Plans, marketplace-бандлы.
Правило 80/20: переносите только 20% наибольшего бизнес-риска; остальное — где дешевле/проще.
Downsampling метрик, cold-storage логов, лимиты на трейсы (budget-aware sampling).
Тегирование ресурсов: `env`, `team`, `service`, `tenant`, `cost_center` — для прозрачного биллинга.
11) Планы миграции (playbook)
11.1 Подготовка
1. Инвентарь сервисов/данных/зависимостей; целевые RTO/RPO/SLO.
2. Выбор модели (active-active vs active-passive) и сетевого слоя (GSLB/Anycast).
3. Подготовка песочницы в целевом облаке: кластер K8s, mesh, observability, секреты.
11.2 Прогон и валидация
4. Shadow-traffic: зеркалирование запросов без влияния на прод.
5. Контракт-тесты (OpenAPI/gRPC/CDC) и синтетика по ключевым маршрутам.
6. CDC/репликация: горячая синхронизация данных, сверка консистентности.
11.3 Переключение
7. Dual-write (идемпотентный) ограниченному проценту пользователей/тенантов.
8. Поэтапный traffic shifting (1%→10%→50%→100%) с SLO-гейтами.
9. Freeze/переезд stateful; прокат final cutover; удержание старого контура в «read-only» до финального reconcile.
11.4 После миграции
10. Проверка аудит-логов/журналов, архив старых снапшотов, оптимизация egress/кэша.
11. Обновление runbooks и обучение on-call.
12) DR и тесты отказоустойчивости
GameDay: отключение целого облака/региона; замер фактических RTO/RPO.
Chaos-инъекции: потеря пакетов/рост латентности на кросс-линке, падение брокера/базы.
Автоматические флаги деградации: отключение «дорогих» фич, переход на кэш `stale-while-revalidate`.
13) Антипаттерны
«Чистый» active-active без соглашений владения данными → конфликты/дубликаты.
Общий глобальный кэш с сильной консистентностью — латентность/заторы.
Ретраи без идемпотентности → повторные списания/заказы.
Разные форматы логов/трейсов в облаках — потеря корреляции.
Отсутствие единой модели IAM/секретов.
Миграция «все и сразу» без волн и гейтов.
14) Специфика iGaming/финансов
Юрисдикции и data residency: PII/платежные логи остаются «внутри страны/региона», кросс-облако — только агрегаты/аноним.
Платежные провайдеры: multi-PSP и smart-routing по облакам/регионам; вебхуки — через глобальный брокер с дедупликацией.
Санкционные/комплаенс-фильтры: региональные профили; быстрый failover на разрешенного PSP.
SLO «пути денег» выше общего; отдельные алерты/дешборды per провайдер/регион.
Аудит: неизменяемые журналы транзакций, синхронная запись в два независимых хранилища (WORM/S3 Object Lock).
15) Чек-лист prod-готовности
- Выбрана целевая модель (portable core/active-active/standby); описаны RTO/RPO/SLO.
- IaC/GitOps: модульные Terraform/Helm/Kustomize; единый mesh и политики безопасности.
- Наблюдаемость: OTel во всех средах; общий формат логов; tail-sampling по ошибкам/p99.
- Данные: CDC настроен; dual-write идемпотентен; есть план конфликт-резолюции.
- GSLB/DNS/Anycast и health-checks; поэтапный traffic shifting с SLO-гейтами.
- Секреты и KMS: абстракция через Vault; ротация; сегментация по регионам.
- FinOps: модели стоимости, egress-лимиты, теги и квоты; отчеты по затратам.
- DR-учения проведены; измерены фактические RTO/RPO; обновлены runbooks.
- Контракты API/событий верифицируются в обоих облаках; мониторинг вебхуков.
- Для iGaming/финансов: data residency, multi-PSP routing, журналы WORM.
16) TL;DR
Стройте portable core (K8s + IaC + mesh + OTel + Vault) и выбирайте паттерн многоблачности под бизнес-цели RTO/RPO/SLO и стоимость. Перенос делайте волнами: shadow-traffic → CDC → dual-write → поэтапный трафик с SLO-гейтами. Управляйте данными через идемпотентность и outbox/inbox, трафиком — через GSLB/Anycast, безопасностью — через mTLS/KMS/Vault. Для iGaming — жесткие правила data residency и multi-PSP, отдельные SLO для «денежных» путей.