모놀리식 데이터 센터에서 멀티 클라우드 전략으로의 발전은 처음에는 공급업체 다양화와 가용성에 초점을 맞췄지만, 현대 기업은 이제 운영 비용을 줄이고, 공격적인 지속 가능성 목표를 달성하며, GDPR 및 CCPA와 같은 복잡한 데이터 주권 규정을 탐색해야 하는 동시에 여기에 직면하고 있습니다. 초기 멀티 클라우드 구현은 고정된 재해 복구 구성 및 수동 용량 계획에 의존했으며, 이는 지역 중단 또는 스팟 가격 변동에 대응할 때 경제적으로 비효율적이고 운영적으로 느린 것으로 입증되었습니다. FinOps 관행 및 탄소 인식 컴퓨팅의 출현으로 인해 비판적 경로에서 인간 개입 없이 가격, 성능 및 지구적 영향을 최적으로 조정할 수 있는 지능형 시스템이 필요하게 되었습니다.
기본적인 과제는 AWS, Microsoft Azure 및 Google Cloud Platform 간의 다양한 API 및 의미론적 차이를 정규화하는 동시에 실시간 작업 부하 마이그레이션 동안 제어 평면 상태에 대한 강력한 일관성 보장을 유지하는 것입니다. 지역 간의 네트워크 파편화는 오케스트레이터가 상충되는 스케줄링 결정을 내릴 수 있는 분리된 두뇌 위험을 발생시켜 규제 데이터를 비준수 관할권으로 마이그레이션함으로써 준수 경계를 위반할 수 있습니다. 더욱이, **지속 볼륨 클레임(PVCs)**가 있는 상태 있는 작업 부하는 신속한 대피를 복잡하게 만드는 저장소 친화성 제약을 도입하며, 공격적인 비용 최적화 알고리즘은 서비스 수준 목표를 불안정하게 만드는 진동 루프(플래핑)를 유발할 위험이 있습니다.
지역 Kubernetes 클러스터로 구성된 계층적 제어 평면을 설계하여 중앙 Fleet Manager를 통해 연합하며, 이를 통해 클라우드별 구현을 통합된 gRPC 서비스 메쉬 인터페이스 뒤에 추상화합니다. **Open Policy Agent (OPA)**를 사용하는 정책 엔진을 구현하여 마이그레이션 결정을 승인하기 전에 탄소 밀도 API, 스팟 인스턴스 가격 피드 및 데이터 거주 규정을 포함한 실시간 제약 조건을 평가합니다. 개별 클라우드 공급업체에 한정된 etcd 클러스터를 사용하는 것과 같은 비판적인 메타데이터에 대해 비동기 복제를 사용하여 크로스 클라우드 합의 지연을 피하고, Velero 및 Container Storage Interface (CSI) 스냅샷기를 활용하여 상태 있는 작업 부하의 이동성을 조정합니다.
EU(프랑크푸르트), US(버지니아) 및 APAC(싱가포르) 지역에서 운영되는 글로벌 급여 처리 회사는 사십만 명의 직원에 대한 월급 계산을 처리하면서 클라우드 지출을 최소화하고 유럽 시민 데이터에 대한 GDPR 준수를 보장해야 했습니다.
문제는 AWS us-east-1의 중단 동안 주요 컴퓨팅 클러스터가 중단되고, 동시에 수요 증가로 인해 서유럽의 Azure 스팟 가격이 급등하면서 발생했습니다. 그들의 기존 정적 장애 조치 구성은 GCP에서 벨기에의 EU 작업 부하를 전환하여 데이터 거주 요건을 위반했으며, 운영 팀은 수동 실행서를 실행하는 데 사십 오 분이 걸려 급여 제출 창에 대한 5분 SLA를 훨씬 초과했습니다.
해결책 1: 수동 실행서 기반 장애 조치
이 접근 방식은 수동으로 DNS 레코드를 조정하고 대상 클러스터의 크기를 조정하여 변동이 없는 Terraform 스크립트를 실행하는 대기 엔지니어에 의존했습니다.
장점: 복잡한 자동화가 필요하지 않은 간단한 구현; 준수에 결정적인 결정에 대한 인간의 감독 유지; 자동화가 실패할 위험이 거의 없음.
단점: 반응 시간이 평균 15분에서 30분이며, 수분 이내의 장애 조치 요구 사항을 위반합니다; 비상시가 아닌 기간 동안 비용이나 탄소를 최적화할 수 없음; 고스트레스 중단 시 인간 오류에 취약함.
해결책 2: 정적 멀티 클라우드 Kubernetes와 Federation V2
각 지역의 정적 클러스터에 워크로드를 분산하기 위해 Kubefed(현재 SIG-Multicluster)를 배포하여 레이블 선택기를 기반으로 사전 정의된 배치 정책을 사용합니다.
장점: 네이티브 Kubernetes 통합; YAML 매니페스트를 통한 선언적 구성; 노드 실패 시 사용 가능한 클러스터로의 워크로드 자동 전파.
단점: Federation V2는 실시간 가격 책정 또는 탄소 데이터에 대한 인식이 부족하며, 중앙 API 서버를 통해 과도한 크로스 클라우드 트래픽 비용을 발생시킵니다; 수동 볼륨 재부착이 필요한 상태 있는 워크로드 마이그레이션에서 어려움을 겪습니다.
해결책 3: 사용자 정의 오퍼레이터를 통한 자율 제어 평면
Go로 작성된 Kubernetes Operators를 사용하여 맞춤형 오케스트레이션 레이어를 구축하고, 클라우드 청구 API, Electricity Maps 탄소 데이터 및 마이그레이션을 조정하기 위한 Redis를 기반으로 한 분산 잠금 메커니즘과 통합합니다.
장점: 매분 최적화 결정을 가능하게 하며; 금지된 마이그레이션을 차단하는 OPA 정책을 통해 준수 경계를 강제합니다; 오퍼레이터를 통해 조정된 CSI 스냅샷 복제를 통해 상태 있는 작업 부하의 대피를 지원합니다.
단점: 클라우드 공급업체 어댑터를 구축하고 유지 관리하기 위해 상당한 엔지니어링 투자 필요; 파티션 내성을 테스트하는 데 복잡성 증가; 공급자 간 툭 쑥하는 것을 방지하기 위한 신중한 조정 필요.
선택한 해결책 및 근거
팀은 해결책 3을 선택했습니다. 왜냐하면 자율적 의사 결정만이 비용, 준수 및 탄소라는 상충하는 목표를 최적화하는 동시에 수분 이내의 장애 조치 SLA를 충족할 수 있었기 때문입니다. 준수 요구 사항은 인간 운영자가 압박 하에 신뢰성 있게 실행할 수 없는 코드로서 정책 집행을 요구하며, 재정적 규모(연간 클라우드 지출 수백만 달러)는 사용자 정의 자동화에 대한 엔지니어링 투자를 정당화했습니다.
결과
후속 AWS 중단 동안 시스템은 Prometheus 건강 검사를 통해 자동으로 실패를 감지하고, 실시간 탄소 및 비용 제약에 따라 Azure 및 GCP 대안을 평가하여 약 38초 만에 네덜란드에 있는 GCP(준수 지역)로 12,000개의 중요 급여 포드를 마이그레이션했습니다. 회사는 SLA 위반을 제로로 유지하고, 지능형 스팟 인스턴스 차익 거래를 통해 클라우드 지출을 34% 줄이며, 피크 처리 시간 동안 재생 가능 에너지를 사용하는 지역으로 작업 부하를 이동시켜 탄소 중립 컴퓨팅 작업을 달성했습니다.
활성 마이그레이션 중 멀티 클라우드 영역 간 네트워크 파편화가 발생할 때 제어 평면의 분리된 두뇌 시나리오를 어떻게 방지합니까?
후보자는 종종 클라우드 전반에 걸친 etcd 합의에 의존하는 것을 제안하지만, 이는 높은 대기 시간으로 인해 Raft 하트비트 요구 사항을 위반합니다. 올바른 접근 방식은 Redis Redlock 또는 Consul 기반의 분산 조정 계층을 가진 지역 범위의 etcd 클러스터를 구현하여 전역 잠금을 수행하고, 제어 평면이 스케줄링 결정을 위해 AP(가용/파티션 허용) 모델을 채택하며, 클러스터 용량 상태를 공유하기 위해 유언 프로토콜(HashiCorp Memberlist)을 사용하는 한편, 준수 상태에 대해서는 CRDTs를 사용하여 CP(일관된/파티션 허용) 동작을 유지해야 합니다. 또한 마이그레이션되는 지속 볼륨의 소스와 대상 클라우드 모두가 소유권을 주장할 수 있는 분리된 I/O 시나리오를 방지하기 위해 CSI 드라이버에 울타리 토큰을 구현해야 합니다.
스냅샷을 빠르게 할 수 없는 로컬 SSD 또는 고성능 NVMe 저장소를 사용하는 상태 있는 작업 부하의 마이그레이션을 어떻게 처리합니까?
많은 아키텍트들은 모든 저장소가 CSI 스냅샷을 사용할 수 있다고 잘못 가정합니다. 로컬 저장소가 필요한 고처리량 OLTP 데이터베이스의 경우, 저장소 수준 스냅샷 대신 비동기 논리 복제를 사용하는 핫 스탠바이 패턴을 구현해야 합니다(PostgreSQL 스트리밍 복제 또는 MySQL 그룹 복제). 자율 오케스트레이터는 다른 클라우드에 미리 스탠바이 인스턴스를 준비하고, 반복적으로 동기화된 복제된 데이터로 이를 함께 하여, 스탠바이를 승격하고 Envoy xDS API를 통해 서비스 메쉬 엔드포인트를 업데이트하는 제어된 장애 조치를 실행해야 하며, 이를 위해 제어 평면은 Prometheus를 통해 노출되는 복제 지연 메트릭을 추적하고, 지연이 10초를 초과하면 마이그레이션을 중단해야 데이터 손실을 방지할 수 있습니다.
스팟 가격이 빠르게 변동할 때 플래싱(지속적인 마이그레이션 루프)을 방지하는 비용 최적화 알고리즘을 어떻게 설계하시겠습니까? 숨겨진 데이터 이그레스 수수료는 어떻게 고려하십니까?
후보자들은 종종 단순 임계값 기반 마이그레이션 트리거(예: "가격 차이가 20% 이상이면 이동")를 제안하여 파괴적인 플래핑을 유발합니다. 솔루션은 PID 제어기 또는 감쇠 요소를 가진 강화 학습 정책을 사용하여 의사 결정 루프에 히스테리시스를 구현해야 하며, 알고리즘은 AWS 데이터 전송 비용, 클라우드 간 DNS 쿼리 비용 및 NAT 게이트웨이 수수료를 포함하는 총 소유 비용(TCO)을 계산해야 하며, 단지 컴퓨팅 가격만 고려해서는 안 됩니다. Thanos 또는 Cortex를 사용하여 역사적 비용 추세 데이터를 유지하여 이주가 특정 기간 동안 발생하도록 하여 이주는 발생해야 하며, 최소 30분의 체류 기간을 강제하는 회로 중단기를 구현해야 합니다.