Datadog은 2023년 3월 시스템 패치 오류로 인해 전체 컴퓨팅 용량의 60%를 상실하는 대규모 장애를 겪었으며, 이를 해결하기 위해 EU1 리전을 중심으로 계층적 클러스터 복구 전략을 실행했습니다. 복구 과정에서 쿠버네티스의 부모-자식(Parent-Child) 구조를 활용한 순차적 재부팅을 통해 제어 평면과 워크로드를 정상화했으나, 이후 데이터 백로그 처리를 위한 급격한 확장 단계에서 클라우드 인프라의 물리적 한계에 부딪히기도 했습니다. 결과적으로 이번 사례는 복구 우선순위 설정과 클라우드 공급자의 서비스 임계치 이해가 대규모 인프라 운영에 얼마나 중요한지를 보여줍니다.

쿠버네티스 클러스터 계층 구조와 복구 전략

Datadog은 관리 효율성을 위해 쿠버네티스 클러스터 간의 엄격한 계층 구조를 운영하고 있으며, 이는 복구 순서를 결정하는 핵심 요인이 되었습니다.

부모(Parent) 클러스터: 각 리전에 존재하며, 다른 클러스터(자식)의 제어 평면(Control Plane) 구성 요소를 파드(Pod) 형태로 호스팅합니다. 부모 클러스터 자체의 제어 평면은 가상 머신(VM)에서 직접 실행됩니다.
자식(Child) 클러스터: 실제 Datadog 애플리케이션 워크로드가 실행되는 곳이며, 이들의 제어 평면은 부모 클러스터의 워커 노드 위에서 돌아갑니다.
복구 메커니즘: Ubuntu 22.04 패치로 인해 네트워크가 단절된 노드들은 재부팅을 통해 복구가 가능했습니다. 하지만 제어 평면에 접근할 수 없는 상태였기에 가시성 확보와 복구 작업에 초기 난항을 겪었습니다.

단계별 클러스터 복구 프로세스

인프라의 의존성을 고려하여 부모 클러스터에서 자식 클러스터 순으로 엄격한 순서에 따라 복구가 진행되었습니다.

부모 제어 평면 복구 (08:45 UTC 완료): 가장 먼저 부모 클러스터의 제어 평면 노드들을 재부팅하여 시스템의 뿌리를 정상화했습니다.
자식 제어 평면 복구 (09:30 UTC 완료): 부모 클러스터 노드 위에서 실행 중인 자식 클러스터용 제어 평면 서비스들을 복구하여 애플리케이션 노드들을 관리할 수 있는 상태로 만들었습니다.
애플리케이션 노드 복구 (12:05 UTC 완료): 수십 개의 클러스터에 퍼져 있는 수천 개의 인스턴스를 재부팅했습니다. 제어 평면의 과부하를 방지하기 위해 워크로드의 중요도에 따라 순차적으로 진행되었습니다.

확장 단계에서의 기술적 제약 사항

클러스터 자체는 복구되었으나, 장애 기간 동안 쌓인 데이터 백로그를 처리하기 위해 인프라를 확장하는 과정에서 예상치 못한 한계에 직면했습니다.

GCP 피어링 그룹 인스턴스 제한: 백로그 처리를 위해 인스턴스를 늘리던 중, 구글 클라우드(GCP)의 VPC 피어링 그룹당 최대 인스턴스 제한인 15,500개에 도달하여 확장이 중단되었습니다. 이는 문서화된 제한이었으나 극한의 상황에서 임계치에 도달하며 복구를 지연시켰습니다.
서브넷 IP 주소 고갈: 로그 및 트레이스 처리를 담당하는 특정 클러스터들이 평상시의 2배 이상으로 오토스케일링을 시도하면서 할당된 서브넷의 IP 주소가 모두 소진되었습니다.
대응 결과: Google Cloud 팀의 긴급 지원을 통해 피어링 제한을 상향 조정하고, 리소스 우선순위를 재조정함으로써 대규모 백로그 처리 능력을 확보할 수 있었습니다.

대규모 인프라 장애 복구 시에는 구성 요소 간의 의존성을 명확히 파악하여 복구 순서를 정의하는 것이 필수적입니다. 또한, 평상시에는 도달하기 어려운 클라우드 서비스의 논리적/물리적 임계치(Quota)를 재해 복구 시나리오에 포함하여 확장성 계획을 수립해야 합니다.