기술 및 인프라 → 멀티 클라우드 전략 및 동기화
멀티 클라우드 전략 및 동기화
1) 멀티 클라우드 이유
멀티 클라우드-다음을 위해 두 개 이상의 퍼블릭 클라우드 (또는 온 프렘과의 조합) 를 사용합니다
탄력성 및 DR: 클라우드 별 위험 감소 (지역/플랫폼 장애).
지리 및 준수: 올바른 관할 구역 (데이터 레지던트) 의 보관 및 처리.
성과 및 비용: 가까운 POP로가는 경로, 가격/할당량에 대한 시장 차익 거래.
벤더로부터의 독립: 기술의 자유 및 협상력.
문제의 가격은 데이터, 네트워크, ID 및 변경 프로세스를 동기화하는 복잡성입니다.
2) 기본 배포 모델
2. 1 자산 책임 (멀티 클라우드 DR)
Prod는 Cloud-A에 산다. 클라우드 -B에서-따뜻한/핫 스탠드 바이.
RTO/RPO는 분 (저널링) 에서 시간 (백업/복원) 까지 복제 깊이에 따라 다릅니다.
장점: 더 간단하고 저렴합니다. 단점: RTO 높음, "드리프트" 구성 위험
2. 자산 2 개 (전투 비행기 2 대)
트래픽은 Cloud-A/Cloud-B (GeoDNA/Anycast, GSLB, 국가 수준/ASN) 사이에 배포됩니다.
신중한 데이터 일관성과 "폭발 반경" 격리가 필요합니다.
장점: 사용자에게 더 가까운 낮은 RTO/RPO. 단점: 일관성과 테스트의 복잡성.
2. 3 도메인 별 분할 (기능 세분화)
PSP에 대한 최상의 개인 연결을 갖춘 클라우드의 결제 코어; 내용/디렉토리 - 다른 내용.
크로스 클라우드 핫트랙 동기화를 최소화하십시오.
3) 데이터 동기화: 전략 및 패턴
3. 일관성 유형 1 개
강력한 거래 동기 복제 (일반적으로 동일한 클라우드/영역 내).
최종 (최종): 비동기 복제; 카탈로그, 프로필, 분석에 적합합니다.
뜨거운 수직 외부의 읽기에 대한 바운드 부실-유효 지연 (초/분).
3. 2 복제 기술
CDC (데이터 캡처 변경): 저널 → 이벤트 → 다른 클라우드의 응용 프로그램; DWH/보고/캐시에 좋습니다.
이벤트 소싱: 진실의 원천-도메인 이벤트의 스트림; 이것들로부터 각 구름에 조립 된 돌출부가 있습니다.
CRDT/충돌없는 구조: 편집 가능한 항목/카운터 (예: 등급/리더 보드).
demempotency를 사용한 이중 쓰기: 이벤트 별 기록 및 출판; 수신기는 dedupe (아웃 박스/받은 편지함) 을 제공합니다.
객체 저장: verioning + cross-region/cross-cloud 복제 (탈출 오버 헤드 포함).
3. 3 충돌 해결 (예)
도메인 규칙: 동일한 유형의 dempotent 명령 인 경우에만 "마지막 작업이 승리합니다".
진실의 근원에 따른 주문: 지불 상태는 지갑을 마무리하며 그 반대도 마찬가지입니다.
벡터 시계/논리 레이블: 자산 자산 레코드의 드문 충돌.
보상 (sagas): 불일치의 경우-도메인 보상 (잔액 차단 해제, 거래 역전).
3. 4 실제 레이아웃 (지갑 및 지불)
명령 (직불/크레딧) 은 Cloud-A/Cloud-B의 로컬 로그로 이동합니다.
이벤트 지갑. '는 클라우드 간 버스를 통해 두 구름에 모두 게시됩니다.
상태 마무리 - PSP 확인 만; 'operation _ id' 에 의한 중복 제거.
최종 보고서는 각 클라우드에서 CDC → DWH로 수집됩니다. 공급 업체 종속 분야가 정규화되었습니다.
4) 네트워크 계층 및 글로벌 트래픽
GSLB (Global Server Load Balancing): GeoDNA/Anycast, 클라우드 당 건강 샘플, 세션 당 끈적 끈적함.
메쉬 오버 인터넷/개인 링크: IPsec/Cloud-to-Cloud 상호 연결/개인 피어링.
탈출 제어: 허용 목록에 의한 PSP/KYC에 의한 고정 NAT-IP; QoS 및 한계.
세분화: prod/stage를위한 별도의 서브 넷; 동서 교통 관제는 클라우드 간 제어입니다.
[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), 회전이 동의했습니다. 마스터 키를 직접 복제하지 마십시오.
mSL/서명: 클라우드 간 뮤추얼 SL 서비스; 이벤트 및 웹 후크는 클라우드 키와 함께 HMAC에 의해 서명됩니다.
데이터 레지던트: 태그/데이터 클래스, 라우팅/스토리지 정책 (PII/PCI는 국가에 남아 있음).
감사: WORM 로그, 크로스 클라우드 추적, 통합 변경 로그.
6) 플랫폼 및 추상화
Kubernetes 멀티 클러스터: 각 클라우드의 클러스터; GitOps (Argo/Flux), 클러스터 프로필 및 코드 정책 (OPA/게이트 키퍼) 을 통한 통일.
서비스 메시 (멀티 클러스터): mSL, 재 시도/차단기, 지역 인식 라우팅; 클라우드 간 호출을 명확하게 제한합니다.
스토리지 (CSI) 및 캐시: 필수 동기식 클라우드 간 기록으로 고정 세트를 피하십시오. 캐시/읽기-로컬 비동기 워밍업.
IaC: 클라우드 아티팩트를위한 Terraform/Crossplane; 공급 업체 별 "인서트" 가있는 단일 모듈.
DevPortal/서비스 카탈로그: 클라우드 당 위치 및 종속성 메타 데이터.
7) CI/CD 및 변경 관리
클라우드 당 매개 변수화 (기능, 할당량, 밸런서 유형) 가있는 단일 모노 레포/모노 사양.
Canary/Blue-Green per-cloud: Cloud-A/Cloud-B + 메트릭 비교에서 별도로 릴리스하십시오.
테스트 매트릭스: 통합 테스트 "oblako SL oblako", 재생 사건, 지리 합성.
계약 버전링: Schema Registry 일반, 역 호환 MINOR 규칙.
EOL 마이그레이션에서 동결 변경: 구름 사이의 트래픽을 전환 할 때.
8) 관찰 및 SLO 관리
종단 간 추적 _ id: 게이트웨이 → 서비스를 통한 크기 조정 → 다른 클라우드의 중개인 → 소비자; 독일어 '클라우드', '지역', 'api _ version', '파트너'.
클라우드 당 SLO/지역별: 가용성/대기 시간/오류 대시 보드 및 클라우드 간 지연 (복제 대기 시간).
클라우드 간 동기화 이상: DLQ 성장 경고, "충돌 률" 증가, CDC 지연.
상태 페이지: 클라우드 및 지역별 공개 상태.
9) FinOps: 멀티 클라우드 비용
탈출 및 클라우드 간 채널: 주요 비용 항목; 대화를 최소화하고 이벤트를 집계하며 로컬 프로젝션을 사용하십시오.
중복 리소스: 따뜻한 풀, 각 클라우드의 예약 된 인스턴스/주석 → 균형.
로드 프로파일: 중요하지 않은 배경 bs을 최상의 가격/할당량으로 클라우드로 이동시킵니다.
"일관성 비용" 카운터: $/sec 지연, $/GB 복제, $/충돌-비즈니스 투명성.
10) iGaming/fintech 사례
지불/지갑 (엄격한 일관성 수준): 빠른 장애가있는 자산 책임; 상태 마무리 이벤트는 진실의 유일한 원천입니다. 로그 복제.
게임 카탈로그/프로모션/등급: 최종적으로 자산 자산, 통계에 대한 CRDT 카운터; 읽기 당 TTL 캐시.
규제 기관에보고: 로컬 DWH 상점, 비동기적으로 크로스 클라우드 집계; 신선도 보장 (SLO 신선도).
마케팅/알림: 지리/클라우드 오케스트레이션, 크로스 클라우드 통화 한계; 제출 중복.
KYC/AML: 다른 구름의 병렬 공급자, 응답 정규화 및 단일 의사 결정 정책.
11) 샘플 솔루션 (조각)
11. 1 개의 송신기 → CDC (demotency)
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 네트워크 정책
클라우드 간 통화는 '이벤트', 'idp', '카탈로그 동기화' 에만 허용됩니다. 똑바로 지갑. 쓰기 '- 허용되지 않음 (로컬).
12) 안전과 위험
폭발 반경: 오류/루프가 두 구름을 "홍수" 하지 않도록 클라우드 간 대역폭 및 대기열을 제한합니다.
자동화 가드 레일: AI-Ops/ranbooks는 다중 신호 없이는 두 구름의 구조를 동시에 변경할 수 없습니다.
의사 소통 중단 테스트: 분할 뇌 동작, 대기열 성장, 타임 아웃 및 자동 저하.
13) 구현 점검표
1. 엄격한/최종 일관성 도메인 및 정의 된 도메인 당 대상 RPO/RTO.
2. 선택된 모델 (자산 책임/자산 자산/도메인 세분화).
3. 클라우드 간 네트워크: GSLB, 메쉬/프라이빗 링크, 고정 출구 IP, WAF/봇 보호.
4. 레지스트리, 호환성 규칙의 데이터 스키마; 아웃 박스/받은 편지함은 어디에나 있습니다.
5. 이데올로기 및 중복 제거 (키, TTL 스토리지, 해시).
6. CI/CD: 클라우드 당 매개 변수화, 카나리아 별도, 공통 릴리스 센터.
7. 관찰: 'trace _ id', 복제 로그, 충돌 속도, DLQ 모니터링.
8. IAM 페더레이션, KMS/클라우드 비밀, 액세스 감사.
9. FinOps: 예산 예산, 클라우드 간 비용에 대한 경고.
10. 일반 DR 드릴: 클라우드 페일러, 분할 뇌 시뮬레이션.
14) 반 패턴
동기식 크로스 클라우드 핫 패스 트랜잭션 (지갑/쓰기) → 취약성 및 P99 테일.
네트워크를 통한 두 개의 구름 → SPOF에 대한 데이터베이스의 단일 "마스터 클러스터".
데이터 범주가없는 "한 번에 모두" 복제하기 → 비용 및 충돌의 폭발.
아웃 박스/받은 편지함 및 demempotency → 중복 지불/크레딧 부족.
비밀은 열린 형태로 S3- 버킷/파이프를 통해 "이동" 합니다.
설명되지 않은 탈출 및 숨겨진 클라우드 간 서비스 채팅 → 예측할 수없는 계정.
15) 결론
멀티 클라우드는 "콘솔의 두 진드기" 가 아니라 데이터, 네트워크 및 변경 프로세스 설계 분야입니다. 일관성 요구 사항에 따라 도메인을 분명히 분리하고, 클라우드 간 핫 트랙을 제한하고, CDC/이벤트 소싱 및 demempotency를 사용하고, 지연 및 충돌을 측정하고, 비용을 통제합니다. 그런 다음 멀티 클라우드는 심야 사건 및 탈출 청구서의 출처가 아닌 복원력과 속도를위한 도구가됩니다.