질문에 대한 답변.

이 아키텍처는 클라우드 공급자의 메타데이터 신호를 가로채는 제어 평면을 중심으로 구성됩니다(예: AWS 스팟 인스턴스 중단 알림, GCP 중단 경고) 및 실시간 작업 부하 마이그레이션을 조정합니다. 스케줄러는 스팟 인스턴스 건강 상태와 예비 용량 풀의 실시간 히트맵을 유지하여 온디맨드 및 이차 클라우드 지역에 저장합니다. 종료 경고가 수신되면 시스템은 분산 스토리지에 애플리케이션 일관성 체크포인트를 시작하고(예: Ceph 또는 S3), 예비 용량에서 교체 파드를 동시에 시작합니다. 서비스 메쉬 사이드카(예: Istio)는 연결 드레인 및 HTTP/2 GOAWAY 신호를 사용하여 트래픽을 원활하게 전환하여 요청이 중단되지 않도록 합니다. 마지막으로, 글로벌 로드 밸런서는 건강 검사를 업데이트하여 성공적인 건강 검증 후에만 트래픽을 리디렉션하여 지연이 100ms 기준 미만으로 유지되도록 보장하며, 지리적으로 근접한 대기 영역을 우선 선택합니다.

실제 상황.

고빈도 거래 회사는 컴퓨팅 비용을 60% 절감하기 위해 AWS EC2 스팟 인스턴스를 Kubernetes 기반 리스크 계산 엔진에 활용했습니다. 시장 변동성이 급증할 때, AWS는 기본 us-east-1 가용성 영역 전역에서 대규모 스팟 종료 알림을 발송했습니다. 이로 인해 500개의 파드를 2분 이내에 종료하면서 엄격한 50ms 지연 요구 사항을 충족하는 실시간 거래를 처리할 위기에 처하게 되었습니다.

솔루션 A: 네이티브 Kubernetes 파드 중단 예산.

팀은 표준 파드 중단 예산(PDB)과 클러스터 오토 스케일러에 의존하여 파드를 온디맨드 노드로 우아하게 배출하는 것을 고려했습니다. 이 방법은 간단하고 별도의 커스텀 코드를 필요로 하지 않았습니다. 그러나 120초 종료 창은 상태 저장 리스크 엔진이 복잡한 메모리 내 파생 모델을 지속 저장소로 직렬화하는 데는 불충분하여, 수용할 수 없는 데이터 손실 및 계산 공백이 발생했습니다.

솔루션 B: Velero를 사용한 사용자 정의 선제적 노드 컨트롤러.

또 다른 옵션은 Velero를 활용하여 지속성 볼륨 스냅샷을 가짐으로써 Karpenter를 사용하여 신속한 노드 프로비저닝을 하는 사용자 정의 컨트롤러를 배포하는 것이었습니다. Karpenter는 빠른 노드 시작(30초 이내)에 뛰어났지만, Velero의 50GB 메모리 상태에 대한 스냅샷 및 복원 주기는 평균 3분이 걸렸습니다. 이 지연은 0중단 요구 사항을 위반하며, 대기 거래가 시스템의 버퍼링 용량을 초과하여 누적될 위험이 있었습니다.

솔루션 C: 다중 클라우드 대기 경량화 기반 애플리케이션 수준 체크포인팅.

선택된 솔루션은 CRIU(사용자 공간의 체크포인트/복원)를 사용하여 프로세스 상태를 대기 중인 Redis 클러스터에 30초마다 동결 및 직렬화하는 애플리케이션 인식 체크포인팅을 구현했습니다. 이 아키텍처는 Anthos를 활용하여 크로스 클러스터 서비스 메쉬 연합을 갖춘 GCP Compute Engine에서 예비 대기 풀을 유지했습니다. AWS 종료 신호를 수신하면, 컨트롤러는 즉시 Redis에 최종 델타 동기화를 시작하고, 미리 가져온 컨테이너 이미지를 사용하여 GCP에서 교체 파드를 생성하며, Istio 근접 실패 조정 기능을 활용하여 트래픽을 전환했습니다. 이 접근법은 애플리케이션의 복잡성을 약간 희생했지만, 데이터 손실 없이 60초 미만의 장애 조치를 보장했습니다.

결과.

이 회사는 대규모 종료 이벤트 동안 98%의 작업 부하를 90초 이내에 성공적으로 대피시켰습니다. 평균 장애 조치 지연 시간은 45ms로, SLO를 훌쩍 넘겨 99.99%의 가용성을 유지했습니다. 사후 분석 결과, 이러한 다중 클라우드 스팟 인스턴스 전략의 회복력이 입증되면서 순수 온디맨드 사용에 비해 55%의 비용 절감이 확인되었습니다.

후보자들이 자주 놓치는 것.

스팟 인스턴스 네트워크가 파편화되지만 종료 신호가 지연되거나 손실될 때 분할 뇌 시나리오를 어떻게 방지합니까?

후보자들은 종종 2분 경고가 보장된다고 가정합니다. 실제로는 네트워크 파편화로 인해 신호 전달이 지연될 수 있습니다. 이 솔루션은 etcd 또는 Consul을 사용한 임대 메커니즘을 구현하여 작업 부하가 시간 제한된 잠금을 유지하도록 합니다. 제어 평면이 파편화로 인해 임대를 갱신할 수 없는 경우, 해당 노드를 의심 상태로 지정하고 새 트래픽 라우팅을 중지합니다. 동시에 분산 로그(예: Apache Kafka)의 톰스톤 기록은 고립된 인스턴스가 계속해서 처리하더라도 재연결 시 결과가 신선하지 않은 것으로 거부되도록 보장하여 충돌하는 상태 업데이트를 방지합니다.

인스턴스가 체크포인트 중간에 강제로 종료될 수 있는 경우, 최종 동기화 중 데이터 일관성을 어떻게 확보합니까?

많은 사람들이 간단한 체크포인팅을 제안하지만 "마지막 마일" 일관성 문제를 무시합니다. 올바른 접근법은 Copy-on-Write(COW) 의미론과 원자 commit 프로토콜을 사용하는 것입니다. 최종 동기화 이전에 애플리케이션은 할당을 일시 중지하고(GC 일시 중지 또는 애플리케이션 후크를 통해), CRIU를 사용하여 메모리 스냅샷을 생성하고 S3에서 S3 강력한 일관성으로 저장하거나 RADOS 원자 트랜잭션을 사용하는 Ceph에 쓰도록 합니다. 이 시스템은 2단계 커밋(2PC) 패턴을 사용하여 체크포인트를 준비하고 제어 평면에 확인한 다음, 연결을 드레인합니다. 종료가 커밋 페이즈 중에 발생하면 대기 인스턴스는 이전 일관된 체크포인트로 롤백하고 Kafka 오프셋 로그에서 이벤트를 재생합니다.

수천 개의 스팟 인스턴스가 동시에 종료 알림을 수신하고 제한된 대기 용량을 두고 경쟁할 때, 우는 허드 문제를 어떻게 완화합니까?

후보자들은 대규모 퇴거 중 자원 경합을 자주 간과합니다. 솔루션은 제어 평면 계층에서 토큰 버킷 알고리즘을 구현하여 대기 풀의 수용 속도에 맞게 마이그레이션을 제한합니다. 또한, 우선 순위 클래스(Kubernetes의 PriorityClass)를 활용하여 중요한 재무 작업 부하가 대기 용량에서 덜 중요한 배치 작업을 선제적으로 중단하도록 합니다. 압력 신호 메커니즘은 API 게이트웨이에 들어오는 요청을 일시적으로 큐에 저장하게 하여, 새 인스턴스가 마이그레이션 직후 동시 트래픽 급증으로 압도당하지 않도록 방지합니다. 마지막으로, 예측 기계 학습 모델이 AWS 스팟 가격 이력을 분석하여 예상되는 종료 물결 15분 전에 대기 용량을 사전 조정하여 전환 곡선을 부드럽게 합니다.