Технології та Інфраструктура → Multi-cloud стратегія і синхронізація

Multi-cloud стратегія і синхронізація

1) Навіщо Multi-cloud

• Стійкості і DR: зниження хмарно-специфічних ризиків (регіональні/платформні збої).
• Географії та комплаєнсу: зберігання та обробка в потрібних юрисдикціях (data residency).
• Продуктивності та вартості: маршрут до ближнього POP, ринковий арбітраж за цінами/квотами.
• Незалежності від вендора: свобода технологій і переговорна сила.
• Ціна питання - складність синхронізації даних, мереж, ідентичностей і процесів змін.

2) Базові моделі розгортання

2. 1 Актив-пасив (multi-cloud DR)

Прод живе в Cloud-A; в Cloud-B - теплий/гарячий стендбай.
RTO/RPO залежать від глибини реплікації: від хвилин (journaling) до годин (backup/restore).
Плюси: простіше і дешевше. Мінуси: RTO вище, ризик «дрейфу» конфігів.

2. 2 Актив-актив (дві бойові площини)

Трафік розподілений між Cloud-A/Cloud-B (GeoDNS/Anycast, GSLB, рівень країни/ASN).
Вимагає продуманої узгодженості даних та ізоляції «blast radius».
Плюси: низький RTO/RPO, ближче до користувача. Мінуси: складність консистентності і тестування.

2. 3 Поділ за доменами (функціональна сегментація)

Платіжне ядро в хмарі з кращими приватними зв'язками до PSP; контент/каталог - в іншому.
Мінімізуйте крос-хмарні синхронізації по гарячих шляхах.

3) Синхронізація даних: стратегії та патерни

3. 1 Типи узгодженості

Сувора (strong): транзакційна синхронна реплікація (зазвичай всередині однієї хмари/регіону).
Остаточна (eventual): асинхронна реплікація; підходить для каталогів, профілів, аналітики.
Гібрид (bounded staleness): допустимий лаг (секунди/хвилини) для читань поза «гарячою» вертикаллю.

3. 2 Техніки реплікації

CDC (Change Data Capture): journal → події → застосування в іншій хмарі; добре для DWH/звітності/кешів.
Event Sourcing: джерело істини - потік доменних подій; з них збираються проекції в кожній хмарі.
CRDT/конфлікт-вільні структури: для редагованих записів/лічильників (наприклад, рейтинги/лідерборди).
Dual-write з ідемпотентністю: запис і публікація подією; приймач забезпечує dedupe (outbox/inbox).
Об'єктні сховища: версіонування + крос-регіон/крос-хмара реплікація (з накладними витратами на egress).

3. 3 Конфлікт-резолюція (приклад)

Правила домену: «остання операція виграє» тільки якщо однотипні idempotent-команди.
Черговість за джерелом істини: платіжний статус фіналізує гаманець, а не навпаки.
Векторний годинник/логічні мітки: для рідкісних колізій в актив-актив записах.
Компенсації (саги): при розбіжності - доменна компенсація (розблокування балансу, сторно транзакції).

3. 4 Практичний макет (гаманець і виплати)

Команди (debit/credit) йдуть в локальний журнал в Cloud-A/Cloud-B.
Події'wallet. changed'публікуються в обидві хмари через міжхмарну шину.
Фіналізація статусів - тільки за підтвердженням PSP; дедуплікація за'operation _ id'.
Підсумкові звіти збираються CDC→DWH в кожній хмарі; вендер-залежні поля нормалізуються.

4) Мережевий шар і глобальний трафік

GSLB (Global Server Load Balancing): GeoDNS/Anycast, health-проби per-cloud, «stickiness» на сесії.
Mesh-овер-інтернет/приватні лінки: IPsec/Cloud-to-Cloud interconnect/приватні peerings.
Egress-контроль: фіксовані NAT-IP по allow-list до PSP/KYC; QoS і ліміти.
Сегментація: окремі підмережі для прод/стейдж; контроль східного трафіку (east-west) міжхмарно.

[Users] → [GSLB/Anycast] → (Cloud-A: Edge/API) ↔ (Cloud-B: Edge/API)

[Services / Data A] ↔↔↔ [Services / Data B]
^   Inter-cloud Mesh   ^
[DWH/CDC A]        [DWH/CDC B]

5) Ідентичність, секрети та комплаєнс

IAM-федерація: єдина IdP (OIDC/SAML), рольова модель проектується в обидві хмари; виключайте «сніжинки».
Секрети і KMS: ключі на стороні кожної хмари (BYOK/HYOK при необхідності), ротації узгоджені; не реплікуйте майстер-ключі безпосередньо.
mTLS/підпис: міжхмарні сервіси по взаємному TLS; події та вебхуки підписуються HMAC з ключами на хмару.
Data residency: теги/класи даних, політики маршрутизації/зберігання (PII/PCI залишаються в країні).
Аудит: WORM-логи, трасування міжхмарних операцій, уніфікований журнал змін.

6) Платформа та абстракції

Kubernetes multi-cluster: кластери в кожній хмарі; уніфікація через GitOps (Argo/Flux), кластерні профілі та policy-as-code (OPA/Gatekeeper).
Service Mesh (multi-cluster): mTLS, retry/breakers, locality-aware routing; чітко обмежувати крос-хмарні виклики.
Сховища (CSI) і кеш: уникайте stateful set з обов'язковим синхронним міжхмарним записом; кеш/прочитання - локально, прогрів асинхронний.
IaC: Terraform/Crossplane для хмарних артефактів; єдині модулі з вендор-специфічними «вставками».
DevPortal/каталог сервісів: метадані про розміщення та залежності per-cloud.

7) CI/CD і управління змінами

Єдиний моно-репо/моно-спеки з параметризацією per-cloud (фічі, квоти, типи балансувальників).
Canary/Blue-Green per-cloud: випуск окремо в Cloud-A/Cloud-B + порівняння метрик.
Тест-матриця: інтеграційні тести «oblako↔oblako», реплей інцидентів, синтетика з гео.
Версіонування контрактів: Schema Registry загальний, правила сумісності (backward-compatible MINOR).
Change freeze на EOL-міграції: коли світчіть трафік між хмарами.

8) Observability і управління SLO

Наскрізний trace_id: проклейка через шлюз → сервіс → брокер → споживач в іншій хмарі; лейблы `cloud`, `region`, `api_version`, `partner`.
SLO per-cloud/per-region: дашборди доступності/латентності/помилок і inter-cloud lag (затримка реплікації).
Аномалії міжхмарної синхронізації: альберти на зростання DLQ, збільшення «conflict rate», відставання CDC.
Status-сторінка: публічні статуси по хмарах і регіонах.

9) FinOps: вартість Multi-cloud

Egress і міжхмарні канали: основна стаття витрат; мінімізуйте чаттер, агрегуйте події, використовуйте локальні проекції.
Дублювання ресурсів: warm pools, зарезервовані інстанси/коммітменти в кожній хмарі → балансуйте.
Профілі навантаження: зміщуйте не-критичні фонові джоби в хмару з кращою ціною/квотою.
Лічильники «вартості узгодженості»: $/сек lag, $/GB реплікації, $/конфлікт - прозорість для бізнесу.

10) Кейси для iGaming/фінтех

Платежі/гаманець (рівень суворої узгодженості): актив-пасив зі швидким failover; події фіналізації статусів - єдине джерело істини; реплікація журналів.
Каталог ігор/промо/рейтинги: актив-актив з eventual, CRDT-лічильники для статистик; TTL-кеш на читання.
Звітність регуляторам: локальні вітрини DWH, крос-хмарна агрегація асинхронно; гарантії свіжості (SLO freshness).
Маркетинг/повідомлення: оркестрація з гео/хмари, ліміти на крос-хмарні виклики; дедуплікація відправлень.
KYC/AML: паралельні провайдери в різних хмарах, нормалізація відповідей і єдина політика прийняття рішень.

11) Приклади рішень (фрагменти)

11. 1 Outbox→CDC (ідемпотентність)

BEGIN TX apply(domain_command)
insert into outbox(event_id, aggregate_id, type, payload, hash)
COMMIT
//Replicator reads outbox, publishes to inter-cloud bus;
//receiver executes inbox-dedupe on event_id/hash.

11. 2 Політика конфліктів (псевдо)

if operation. type in {CAPTURE, REFUND}:
source = PSP_EVENT elif operation. type in {LIMIT_SET, LIMIT_REMOVE}:
source = RG_SERVICE apply_if_newer(source, aggregate_version)

11. 3 Мережева політика

Міжхмарні виклики дозволені тільки для'events','idp','catalog-sync'; прямі'wallet. write'- заборонені (локально).

12) Безпека і ризик

Blast-radius: ліміти на міжхмарну пропускну здатність і черги, щоб помилка/петля не «затопила» обидві хмари.
Гардрайли автоматизацій: AI-Ops/ранбуки не можуть змінювати конфіги двох хмар одночасно без мультисигналу.
Тести на «розрив» зв'язку: поведінка при split-brain, зростання черг, таймаути і авто-деградації.

13) Чек-лист впровадження

1. Визначено домени суворої/остаточної узгодженості та цільові RPO/RTO per-domain.
2. Обрано модель (актив-пасив/актив-актив/сегментація доменів).
3. Міжхмарна мережа: GSLB, mesh/приватні лінки, фіксовані egress-IP, WAF/бот-захист.
4. Схеми даних в Registry, правила сумісності; outbox/inbox повсюдно.
5. Ідемпотентність і дедуплікація (ключі, TTL-сховище, hash).
6. CI/CD: параметризація per-cloud, canary окремо, загальний реліз-центр.
7. Observability: 'trace _ id', лаг реплікації, conflict-rate, DLQ-моніторинг.
8. IAM-федерація, KMS/секрети на хмару, аудит доступів.
9. FinOps: бюджети egress, алерти на міжхмарні витрати.
10. Регулярні DR-дрилі: фейловер хмари, симуляції split-brain.

14) Анти-патерни

Синхронні крос-хмарні транзакції по «гарячому» шляху (wallet/write) → крихкість і хвости P99.
Єдиний «майстер-кластер» БД для двох хмар → SPOF через мережу.
Реплікація «всього і відразу» без категорій даних → вибух витрат і конфліктів.
Відсутність outbox/inbox та ідемпотентності → дублікати виплат/зарахувань.
Секрети, «переїжджають» через S3-бакети/труби у відкритому вигляді.
Неврахований egress і приховані міжхмарні чати сервісів → непередбачувані рахунки.

15) Підсумок

Multi-cloud - це не «дві галочки в консолі», а дисципліна проектування даних, мереж і процесів змін. Чітко розділіть домени за вимогами до узгодженості, обмежте крос-хмарний «гарячий» шлях, використовуйте CDC/event sourcing і ідемпотентність, вимірюйте лаги і конфлікти, і тримайте витрати під контролем. Тоді Multi-cloud стане інструментом стійкості і швидкості, а не джерелом нічних інцидентів і рахунків за egress.