하이브리드 클라우드: on-prem + 클라우드
1) 왜 하이브리드와 언제 정당화 되는가
운전자: 규제 요구 사항 (데이터 상주/PII), 기존 온 프림 투자, "독점" 시스템 대기 시간, 비용 관리, 관리 클라우드 서비스 액세스.
트레이드 오프: 네트워크 및 보안의 복잡성, 역량 중복, 데이터 및 구성 요소의 동기화, 운영 위험.
모토: 중요한 경우 휴대용; 수익성이 높은 클라우드 네이티브.
2) 하이브리드 모델
프렘 확장: 데이터 센터 확장으로 클라우드 (새로운 마이크로 서비스/분석, 전면).
로컬 앵커가있는 클라우드 우선: 클라우드 코어, 온 프렘-회계 시스템/결제 게이트웨이/PII 스토리지.
구름 파열: 구름의 탄성 피크 (배치, 프로모션 피크), 기본 볼륨-로컬.
DR to Cloud: 온 프렘을위한 핫/웜 클라우드 리저브 (RTO/RPO 관리).
Edge + Core: PoP/edge 노드는 사용자에게 더 가깝고 루트 데이터/ML은 클라우드에 있습니다.
3) 네트워크 및 연결
3. 채널 1 개
IPsec/SS (Site-to-Site VPN) -빠르게 시작하고 대기 시간이 길고 지터가 높습니다.
다이렉트 라인 (DC/ER/IC, MPLS) -예측 가능한 SLA, 지연 미만, 더 비쌉니다.
듀얼 링크 + BGP-내결함 및 라우팅 제어.
3. 2 개의 주소 및 경로
교차점이없는 단일 RFC1918 다이어그램; CIDR은 앞으로 몇 년 동안 계획하고 있습니다.
국경에서만 NAT- 돔; NAT가없는 동서.
환경 격리 (v/stage/prod), 세입자, 공급자를위한 세그먼트/VRF.
3. 3 시간 및 DNA 정책
단일 NTP (클럭 = 암호화/서명의 운명).
스플릿 수평선: 내부 영역 (svc. 클러스터. 현지, corp.local), 외부-공개.
인바운드 트래픽을위한 건강 기반 GSLB.
4) 정체성과 접근
SSO 연맹: OIDC/SAML, 온 프렘 IdP 클라우드 IdP; SCIM 프로비저닝.
최소 특권의 원칙에 따라 역할; MFA의 브레이크 글래스 계정.
머신 아이덴티티: mTLS의 SPIFFE/SPIRE 또는 메쉬 -PKI.
RBAC "엔드 투 엔드": Git/CI/CD → 클러스터/메쉬 → 브로커/DB → 로그.
5) 플랫폼: Kubernetes + GitOps
5. 단일 실행 계층 1 개
동일한 버전/CRD의 클러스터 온 프렘 및 클라우드.
GitOps (Argo CD/Flux): 단일 차트/오버레이, 드리프트 제어, 프로모션 스트림.
5. 2 서비스 메쉬
Istio/Linkerd: mSL 기본값, 지역 인식 밸런싱, 장애 조치 간 클러스터.
매니페스트 코드에서 L7 정책 (JWT, 헤더, 속도 제한, 재 시도/회로/시간 초과).
5. 3 예 (K8 토폴로지 및 메시)
yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }6) 데이터 및 스토리지
6. 1 기지
프렘 마스터, 클라우드 읽기 복제본 (분석/디렉토리).
클라우드 마스터 + 온 프렘 캐시 (로컬 통합을위한 낮은 대기 시간).
로컬 쿼럼이있는 SQL/NoSQL (Cockroach/Cassandra) 을 분배했습니다.
루프 사이의 CDC/로그 복제 (Debezium); 처리기의 dempotency.
6. 2 개체/파일/블록
복제/버전 지정이있는 S3 호환 스토어 (온 프렘 MinIO + 클라우드 S3/GCS); 감사를위한 WORM.
백업: 3-2-1 (3 부, 2 개 미디어, 1 개-오프 사이트), 정기적 인 복구 확인.
6. 캐시와 대기열 3 개
사이트 당 Redis/KeyDB 클러스터; 글로벌 캐시-이벤트/TTL을 통해서만.
Kafka/Pulsar: MirrorMaker 2/복제기; 키-소비자의 데드 업/dedempotency.
7) 보안 및 규정 준수 (제로 트러스트)
어디에서나 mTLS (메쉬), TLS 1. 둘레에 2 +; 암호화되지 않은 채널을 비활성화
비밀: HashiCorp Vault/ESO; 단기 토큰; 자동 회전.
KMS/HSM: 관할 구역/임차인에 따라 분할 된 키; 예정된 암호화 회전.
세분화: 관리자 액세스를위한 네트워크 정책, 마이크로 세분화 (NSX/Calico), ZTNA.
로그: 불변성 (Object Lock), 엔드 투 엔드 'trace _ id', PII/PAN 마스킹.
8) 관찰 가능성, SLO 및 사건 관리
모든 곳에서 OpenTelemetry SDK; 프렘과 클라우드에서 수집기.
테일 샘플링: 100% о차이나있는 신디사이트, p99, 레이블 '사이트 = 온프렘' 클라우드 ',' 지역 ',' 테넌트 '.
슬라이스 별 SLO 및 오류 예산 (경로/테넌트/제공자/사이트); 연소율에 의한 경고.
엔드 투 엔드 대시 보드: RED/USE, 종속성 맵, 카나리아 비교 (마이그레이션 전/후).
9) CI/CD 및 구성
아티팩트의 단일 레지스트리 (풀스루 캐시 온 프렘).
프로모션 스트림: dev→ 스테이지 (on-prem) → 카나리아 (cloud) → prod; 또는 그 반대-목표에 따라.
검사: 계약 테스트 (OpenAPI/gRPC/CDC), 정적 분석, IaC 연결, 이미지 스캔, SLO 게이트.
10) DR/BCP (연속 계획)
서비스 당 RTO/RPO. 예:- 카탈로그/착륙: RTO 5-15 분, RPO 제곱 5 분;
- 지불/지갑: RTO
- 런북: GSLB/웨이트 전환, 클러스터에서 대기 상태 향상, 기능 플래그 "경량 모드".
- GameDays: 분기 별-사이트/채널 연결 해제, 실제 RTO/RPO 검증.
11) 비용과 FinOps
온 프렘과 클라우드 사이의 탈출은 주요 "숨겨진" 비용입니다. 캐시하고 하이킹을 최소한으로 유지하십시오 (SWR, 가장자리).
태그 지정: '서비스', 'env', '사이트', '테넌트', 'cost _ center'.
규칙 80/20: "중요한 핵심" 의 20% (나머지는 더 저렴한 곳) 를 이동/유지합니다.
다운 샘플링 메트릭, "핫/콜드" 로그 참조, 예산 인식 샘플링 추적.
12) 작업량의 배치 패턴
13) 구성 요소의 예
13. IPsec S2S 1 개 (아이디어)
onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss13. 2 테라 폼 (태그/라벨 스 니펫)
hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site" = var. site # onprem cloud
"tenant" = var. tenant
"cost_center" = var. cc
}
}
}13. 3 Vault + ESO (프렘에서 클라우드 클러스터까지의 비밀)
yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }14) 안티 패턴
CIDR → 나는 혼돈을 교차시킨다; 먼저 주소 계획, 채널입니다.
강력한 일관성 → 대기 시간과 분할 뇌를 가진 하나의 "공유 된" 글로벌 캐시.
dempotency → 이중 쓰기/주문이없는 배상.
내부에 mSL/Zero Trust가없는 "Naked" VPN-손상된 경우 측면 이동.
DR 연습 부족: 계획은 실제로 작동하지 않습니다.
K8/CRD/연산자 버전 간의 불일치 → 균일 한 차트의 불가능성.
'trace _ id' 및 마스킹이없는 무료 형식의 로그는 불가능합니다.
15) iGaming/Finance의 세부 사항
데이터 레지던트: PII/결제 이벤트-온 프렘/지역 회로; 클라우드에-집계/익명.
PSP/KYC: 다중 제공 업체; 클라우드에서 로컬 게이트웨이로의 스마트 라우팅, 백업으로 대체; 중복 제거가있는 브로커를 통한 웹 후크.
"돈 경로": 총 이상의 개별 SLO; HMAC/mTLS, 'Redure-After', 'Idempotency-Key' 가 필요합니다.
감사: WORM 스토리지 (Object Lock), 불변의 트랜잭션 로그, 중요한 이벤트에 대한 양방향 기록 (프렘 + 클라우드).
관할권: 국가/브랜드 당 KMS/Vault 키 세분화; 주변의 지오 블록.
16) Prod 준비 점검표
- 주소 계획, DNA, NTP-하나; S2S 링크 + 전진 보호 링크 (BGP).
- 단일 신원 (SSO/OIDC/SAML), MFA, 최소 권한; 서비스를위한 SPIFFE/SPIRE.
- 모든 사이트의 K8, GitOps, 동일한 운영자/CRD; 지역 인식 LB 서비스 메쉬 (mesh)...
- 데이터: CDC, 일관성 테스트, RPO/RTO 정책, 3-2-1 백업 및 일반 복원 드라이브.
- 보안: Vault/ESO, 회전, 네트워크 정책, ZTNA; 로그는 불변입니다.
- 관찰 가능성: 사이트/지역/테넌트 별 OTel, 테일 샘플링, SLO/예산; 카나리아 대시 보드.
- CI/CD: 계약 테스트, IaC 린팅, 이미지 스캔; SLO에 의한 릴리스 게이트.
- DR- 런북, GameDays는 실제 RTO/RPO를 측정했습니다. 컷오버/롤백 버튼.
- FinOps: 출구 제한, 태그 및 보고서, 메트릭/로그/트레일 보존 정책.
- iGaming 세부 사항: 데이터 레지던트, 다중 PSP, WORM 감사, 지불을위한 개별 SLO.
17) TL; DR
하이브리드 = 프렘과 클라우드의 두 세계에서 공통 실행 플랫폼 (K8s + GitOps + 메쉬 + OTel + Vault). 네트워크와 신원을 계획하고 CDC/idempotency를 통해 데이터를 휴대 할 수 있으며 Zero Trust 전체의 보안을 차별화하고 SLO/오류 예산 신뢰성을 측정하며 DR을 교육합니다. 감사.