멀티클라우드: 전략과 현실
Il 멀티 클라우드 2개 이상의 클라우드 제공업체의 서비스를 사용하는 전략 (AWS, Azure, GCP)을 통해 워크로드를 분산하고 공급업체 종속 위험을 줄이고 최적화합니다. 비용. 플랫폼 팀의 경우 멀티 클라우드 IDP를 설계한다는 것은 추상화 구축을 의미합니다. 공급자 간의 차이점을 숨기고 개발자가 없이 배포할 수 있도록 합니다. 기본 클라우드에 대해 걱정하세요.
그러나 멀티 클라우드는 마법의 총알이 아닙니다. 이는 상당한 복잡성을 야기합니다. 인프라 관리, 네트워킹, 보안 및 모니터링. 이 기사에서는 멀티 클라우드가 적합한 시기, 채택할 패턴, 공급업체 종속을 완화하는 방법을 분석합니다. 과도한 복잡성의 함정에 빠지지 않고.
무엇을 배울 것인가
- 멀티 클라우드 전략: 액티브-액티브, 액티브-패시브, 동종 최고
- 이식성을 위한 추상화 계층으로서의 Kubernetes
- 공급자에 구애받지 않는 IaC: 패턴 및 장단점
- HashiCorp Vault를 사용한 클라우드 간 비밀 관리
- 멀티 클라우드 비용 관리 및 최적화
- 클라우드 간 네트워킹을 위한 서비스 메시
멀티클라우드 전략
단일 멀티 클라우드 전략은 없습니다. 조직은 다음을 기반으로 다양한 접근 방식을 취합니다. 귀하의 필요에 따라:
- 액티브-액티브: 워크로드가 여러 클라우드 제공업체에 적극적으로 분산됩니다. 탄력성은 최대이지만 복잡성도 최대입니다.
- 액티브-패시브: 두 번째 공급자로 장애 조치가 가능한 기본 클라우드 공급자입니다. 탄력성과 복잡성 사이의 적절한 균형
- 동급 최고의: 각 공급자의 최상의 서비스 사용(예: 컴퓨팅용 AWS, ML용 GCP, 엔터프라이즈용 Azure) 기능을 최적화하지만 거버넌스를 복잡하게 만듭니다.
- 잡종: 퍼블릭 클라우드와 온프레미스 인프라의 결합. 규제 부문의 지방자치단체(금융, 의료)
# Multi-cloud strategy: active-passive con failover
multi-cloud-architecture:
primary: AWS (eu-west-1)
secondary: GCP (europe-west1)
strategy: active-passive
workload-distribution:
primary-aws:
services:
- all production workloads
- primary databases (RDS PostgreSQL)
- primary cache (ElastiCache Redis)
- primary message queue (MSK Kafka)
traffic: 100% (normal operations)
secondary-gcp:
services:
- read replicas (Cloud SQL)
- DR databases (standby)
- static assets (Cloud CDN)
- batch processing (BigQuery)
traffic: 0% (failover only)
failover:
trigger: "Primary region unavailable for > 5 minutes"
rto: "15 minutes"
rpo: "5 minutes"
steps:
1: "DNS failover (Route53 health check)"
2: "Promote GCP read replicas to primary"
3: "Scale up GCP compute"
4: "Verify service health"
5: "Notify teams"
data-replication:
databases: "Async replication, 5-minute lag"
object-storage: "Cross-cloud sync (rclone)"
secrets: "Vault replication"
추상화 계층으로서의 Kubernetes
쿠버네티스 이는 다중 클라우드 이식성을 위한 가장 효과적인 추상화 계층입니다. Kubernetes에서 실행되는 컨테이너화된 애플리케이션은 EKS(AWS)에 배포될 수 있습니다. 최소한의 변경으로 GKE(GCP), AKS(Azure) 또는 모든 Kubernetes 클러스터를 사용할 수 있습니다.
그러나 이식성은 자동으로 이루어지지 않습니다. 클라우드의 기능이 나타나는 영역은 다음과 같습니다.
- 저장: StorageClass와 PertantVolume은 공급자마다 다릅니다.
- 네트워킹: LoadBalancer, Ingress Controller 및 DNS에는 공급자별 구현이 있습니다.
- 그래요: Pod 인증을 위한 IRSA(AWS), 워크로드 아이덴티티(GCP), Pod ID(Azure)
- 관리형 서비스: 데이터베이스, 캐시 및 관리되는 메시지 대기열이 주요 잠금 벡터입니다.
이식성 트레이드오프
100% 이식성은 비현실적이고 비용이 많이 드는 목표입니다. 추가된 각 추상화 계층 이식성을 위해서는 복잡성과 잠재적인 성능 손실이 발생합니다. 최적의 전략 전자 중요한 휴대성: 컴퓨터(Kubernetes)를 추상화하지만 관리형 서비스를 사용합니다. 성능 및 관리 이점이 종속 위험보다 더 큰 데이터베이스 및 스토리지에 기본입니다.
클라우드 간 비밀 관리
관리 기미 멀티클라우드 환경에서는 특히 중요합니다. 각 클라우드 제공업체에는 자체 비밀 관리 서비스(AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) 개발자는 각각과 별도로 상호 작용할 필요가 없습니다.
HashiCorp 금고 관리를 중앙 집중화하기 위해 가장 많이 채택된 솔루션입니다. 멀티 클라우드 환경의 비밀:
- 집중: 클라우드에 관계없이 모든 비밀에 대한 단일 관리 지점
- 동적 비밀: 임시 자격 증명(데이터베이스, AWS IAM, 인증서)의 온디맨드 생성
- 자동 회전: 애플리케이션 가동 중단 없이 보안 비밀 자동 교체
- 감사: 규정 준수를 위해 비밀에 대한 모든 액세스에 대한 전체 로그
# Vault: configurazione multi-cloud secrets
vault:
storage:
type: raft
ha_enabled: true
nodes:
- vault-0.vault.svc (primary)
- vault-1.vault.svc (follower)
- vault-2.vault.svc (follower)
auth-methods:
# AWS authentication
aws:
path: auth/aws
config:
access_key: ${VAULT_AWS_ACCESS_KEY}
secret_key: ${VAULT_AWS_SECRET_KEY}
roles:
- name: eks-pods
bound_iam_principal_arn: "arn:aws:iam::*:role/eks-pod-*"
policies: [app-secrets]
# GCP authentication
gcp:
path: auth/gcp
config:
credentials: ${VAULT_GCP_CREDENTIALS}
roles:
- name: gke-pods
type: iam
bound_service_accounts: ["*@project.iam.gserviceaccount.com"]
policies: [app-secrets]
# Kubernetes authentication (works on any cluster)
kubernetes:
path: auth/kubernetes
roles:
- name: app-role
bound_service_account_names: ["app-sa"]
bound_service_account_namespaces: ["*"]
policies: [app-secrets]
ttl: 1h
secret-engines:
- path: secret/data/apps
type: kv-v2
description: "Application secrets"
- path: database/
type: database
description: "Dynamic database credentials"
config:
- name: checkout-db
plugin: postgresql-database-plugin
connection_url: "postgresql://{{username}}:{{password}}@checkout-db:5432/checkout"
멀티 클라우드 비용 최적화
멀티클라우드의 장점 중 하나는 다음과 같습니다.비용 최적화 통해 각 워크로드에 대해 가장 저렴한 공급자를 선택합니다. 실제로 이를 위해서는 도구가 필요합니다. 정교한 비용 관리:
- 비용 가시성: 팀, 서비스, 클라우드 제공자별 비용을 보여주는 통합 대시보드
- 적절한 크기 조정: 과잉 프로비저닝된 리소스 식별 및 확장 권장 사항
- 예약된 용량: 예약 인스턴스, 절감 플랜, 약정 사용 할인 관리
- 스팟/선점형: 중단 방지 워크로드를 위해 스팟 인스턴스를 사용합니다.
- 태그 정책: 담당 팀에 비용을 할당하기 위해 필요한 태그
클라우드 간 네트워킹을 위한 서비스 메시
Il 서비스 메시 멀티 클라우드 환경의 네트워킹에 필수적입니다. 이스티오, 특히 서비스 간 통신을 허용하는 다중 클러스터 구성을 지원합니다. 다양한 클라우드 제공업체에 걸쳐 투명하게:
- 멀티 클러스터 메시: AWS, GCP, Azure의 클러스터를 포괄하는 단일 메시
- 트래픽 라우팅: 대기 시간, 지역성, 상태를 기반으로 한 지능형 라우팅
- 자동 장애 조치: 클라우드상의 서비스 성능이 저하되면 트래픽이 리디렉션됩니다.
- 클라우드 간 mTLS: 서로 다른 클라우드 간 통신도 End-to-End 암호화
# Istio: multi-cluster service mesh configuration
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: checkout-service-dr
spec:
host: checkout-service.checkout.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
maxRequestsPerConnection: 10
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
loadBalancer:
localityLbSetting:
enabled: true
failover:
- from: eu-west-1 # AWS primary
to: europe-west1 # GCP failover
distribute:
- from: eu-west-1/*
to:
"eu-west-1/*": 90
"europe-west1/*": 10
멀티클라우드에 대한 실무적 조언
원칙적으로 멀티 클라우드를 사용하지 마세요. 있을 때 채택하세요. 구체적인 비즈니스 사례: 지리적 분포를 부과하는 규정 준수 요구 사항, 특정 공급자 서비스에 대한 필요성, 또는 단일 공급업체에 의존하는 실제 위험이 있습니다. 대부분의 조직에서는 우수한 IaC 및 DR 방식을 갖춘 단일 클라우드 제공업체이면 충분합니다.