Datadog / k8s

2023-03-08 incident: A deep dive into the platform-level recovery | Datadog (새 탭에서 열림)

2023년 3월 발생한 대규모 장애 당시 Datadog은 전체 컴퓨팅 용량의 60%를 상실했으며, 이를 복구하기 위해 계층화된 쿠버네티스 구조에 따른 체계적인 재부팅 전략을 수행했습니다. EU1 리전의 복구 과정에서 팀은 단순한 노드 재가동을 넘어 클라우드 제공업체의 피어링 그룹 제한과 서브넷 IP 고갈이라는 예상치 못한 인프라 한계에 직면했습니다. 이 글은 대규모 인프라 장애 시 제어 평면(Control Plane)의 복구 순서와 백로그 처리를 위한 과도한 스케일 아웃이 유발하는 2차 병목 현상을 상세히 다룹니다. **계층적 쿠버네티스 구조와 복구 전략** * Datadog은 관리 효율성을 위해 '부모(Parent)-자식(Child)' 형태의 계층적 클러스터 구조를 사용합니다. 부모 클러스터는 자식 클러스터의 제어 평면을 포드(Pod) 형태로 호스팅하며, 자식 클러스터는 실제 애플리케이션 워크로드를 실행합니다. * 장애의 원인이 된 시스템 패치(Ubuntu 22.04의 systemd-networkd 관련 이슈)로 인해 네트워크 연결이 끊긴 노드들을 복구하기 위해 엄격한 순서에 따른 재부팅을 진행했습니다. * 복구는 (1) 부모 클러스터 제어 평면 노드 재시작, (2) 부모 노드 위에서 실행되는 자식 클러스터 제어 평면 포드 복구, (3) 수천 개의 자식 클러스터 애플리케이션 노드 재시작 순으로 이루어졌습니다. * 특히 제어 평면에 과부하가 걸리지 않도록 노드 재시작 속도를 조절했으며, 워크로드의 중요도에 따라 클러스터별 복구 우선순위를 설정했습니다. **인프라 확장 제한으로 인한 복구 지연** * 모든 컴퓨팅 용량을 복구한 후, 장애 동안 쌓인 대규모 데이터 백로그를 처리하기 위해 급격한 스케일 아웃(Scale-out)을 시도하는 과정에서 예상치 못한 제한에 부딪혔습니다. * **GCP 네트워크 피어링 제한:** EU1 리전 내 인스턴스 수가 15,500개에 도달하며 구글 클라우드의 네트워크 피어링 그룹 제한에 걸려 약 4시간 동안 추가 인스턴스 생성이 차단되었습니다. 이는 구글 측과의 긴급 협력을 통해 한도를 증설하여 해결했습니다. * **서브넷 IP 주소 고갈:** 로그 및 트레이스 처리를 담당하는 특정 클러스터들이 평상시보다 2배 이상 스케일 아웃을 시도하면서 서브넷 내 사용 가능한 IP 주소가 바닥났습니다. * 평소 IP 사용률을 66% 이하로 유지하도록 모니터링해왔으나, 백로그 처리를 위한 폭발적인 수요는 평상시 변동 폭을 훨씬 상회하는 수준이었습니다. 결과적으로 특정 클러스터들은 약 6시간 동안 최적의 속도로 데이터를 처리하지 못했습니다. **교훈 및 실용적 권장사항** 복구 계획을 세울 때는 단순히 시스템을 정상화하는 것을 넘어, 장애 이후 발생할 '데이터 백로그 처리'를 위한 초과 용량 확보 시나리오를 반드시 고려해야 합니다. 클라우드 제공업체의 하드웨어 리소스 한계뿐만 아니라 네트워크 피어링, 서브넷 IP 할당 범위와 같은 소프트웨어적/구성적 제한 사항을 사전에 파악하고, 극단적인 스케일링 상황에서도 유연하게 대처할 수 있는 여유 용량(Headroom) 설계가 필수적입니다.

Failure is inevitable: Learning from a large outage, and building for reliability in depth at Datadog | Datadog (새 탭에서 열림)

2023년 3월, 데이터독(Datadog)은 인프라의 약 50~60%가 중단되는 대규모 장애를 겪으며 시스템의 일부가 마비될 때 플랫폼 전체가 완전히 다운된 것처럼 보이는 '정방형 파형(Square-wave)' 장애 패턴을 확인했습니다. 이를 계기로 데이터독은 모든 장애 상황을 완벽히 방지하는 것은 불가능하다는 점을 인정하고, 장애 발생 시에도 시스템이 점진적으로 기능을 유지하는 '우아한 성능 저하(Graceful Degradation)'를 최우선 가치로 삼게 되었습니다. 데이터 유실 방지, 실시간 데이터 우선 처리, 부분적인 결과 제공을 핵심 원칙으로 설정하여 인프라 전반의 회복 탄력성을 재설계하는 대대적인 변화를 추진하고 있습니다. **"결함 없음" 설계의 한계와 Square-wave 장애** - 과거 데이터독은 데이터의 '정확성'을 보장하기 위해 100% 완벽한 데이터가 수집될 때까지 쿼리 결과를 반환하지 않도록 시스템을 최적화했습니다. - 이러한 설계는 일부 노드가 다운되었을 때 시스템 전체가 응답을 멈추게 하여, 사용자에게는 플랫폼이 완전히 중단된 것처럼 보이는 이진적(Binary) 장애를 초래했습니다. - 고전적인 근본 원인 분석(RCA)을 통해 특정 트리거를 제거할 수는 있지만, 소프트웨어 업데이트, 인증서 만료 등 무한한 장애 원인을 모두 예방하는 것은 불가능하다는 결론에 도달했습니다. **우아한 성능 저하를 위한 새로운 우선순위** - 시스템 구성 요소가 완벽하게 작동해야만 가치를 제공하는 '결함 방지(Never-fail)' 아키텍처에서 '더 잘 실패(Fail better)'하는 구조로 전환했습니다. - 데이터 유실 방지: 처리가 늦어지더라도 고객의 데이터가 영구적으로 사라지지 않도록 보장합니다. - 실시간성 우선: 가용 자원이 부족할 때 오래된 데이터보다 실시간 데이터를 우선적으로 처리하여 현재 상태를 파악할 수 있게 합니다. - 부분 결과 제공: 모든 데이터가 준비되지 않았더라도 정확도가 확인된 범위 내에서 부분적인 데이터를 즉시 시각화합니다. **데이터 유실 방지를 위한 영구적 수집 저장소(Persistent Intake Storage)** - 장애 당시 메모리나 로컬 디스크에만 머물던 미복제 데이터가 노드 유실과 함께 사라졌던 문제를 해결하기 위해 파이프라인 초기 단계에 디스크 기반 영구 저장소를 도입했습니다. - 수집(Intake) 직후 데이터를 복제된 저장소에 즉시 기록함으로써, 후속 처리 시스템이 정체되거나 노드가 유실되더라도 데이터 손실 없이 재처리가 가능하도록 설계했습니다. - 이를 통해 네트워크 지연이나 하위 시스템의 과부하 상황에서도 데이터 수집 단계에서의 안정성을 확보했습니다. 모든 장애를 차단하려는 시도보다는, 장애 상황에서도 시스템이 어떻게 부분적으로나마 작동할 수 있을지를 설계 단계부터 고민해야 합니다. 대규모 분산 시스템을 운영한다면 데이터의 완전성(Completeness)과 가용성(Availability) 사이의 균형을 재검토하고, 최악의 순간에도 사용자에게 최소한의 가시성을 제공할 수 있는 복구 탄력성을 구축하는 것이 권장됩니다.

Our journey taking Kubernetes state metrics to the next level | Datadog (새 탭에서 열림)

Datadog은 대규모 Kubernetes 환경에서 오픈소스 도구인 kube-state-metrics(KSM)를 운영하며 겪은 확장성 문제를 해결하기 위해 오픈소스 커뮤니티에 직접 기여하여 성능을 대폭 개선했습니다. 기존 KSM은 수천 개의 노드와 수만 개의 포드가 있는 환경에서 지표 수집 시간이 수십 초에 달하고 데이터 용량이 비대해지는 성능 저하 문제를 안고 있었습니다. 이를 해결하기 위해 KSM v2 개발 과정에 참여하여 지표 생성 프로세스를 최적화함으로써 수집 속도를 15배 향상하고 대규모 클러스터에서도 고해상도 데이터를 안정적으로 확보할 수 있게 되었습니다. **KSM의 작동 원리와 기존의 한계** * KSM은 Kubernetes API 서버를 리스닝하며 객체의 상태 지표를 생성하는 서비스로, 인포머(Informer) 패턴을 사용해 클러스터 수준의 메타데이터를 OpenMetrics 형식으로 노출합니다. * Datadog 에이전트는 15초마다 `/metrics` 엔드포인트를 크롤링하여 데이터를 수집하며, 필요에 따라 `label_joins` 설정을 통해 메타데이터를 결합해 지표의 가독성을 높입니다. * 하지만 기존 구조에서는 쿼리 시점에 대량의 데이터가 한꺼번에 덤프되고, 지표 생성 과정에 개입할 수 있는 훅(hook)이 부족하여 성능 확장에 제약이 있었습니다. **대규모 환경에서의 확장성 병목 현상** * 리소스당 지표 생성량을 분석한 결과 노드는 약 9개, 포드는 약 40개의 지표를 생성하며, 수만 개의 포드가 있는 환경에서는 매 수집 주기마다 수백만 개의 지표를 처리해야 합니다. * 이로 인해 네트워크 호출 시간이 수십 초로 늘어나고 데이터 크기가 수십 메가바이트에 달하게 되어, 지표의 정밀도를 낮추거나 수집 주기를 강제로 늦춰야 하는 상황이 발생했습니다. * Datadog은 이를 해결하기 위해 포드, 노드, 기타 리소스별로 KSM 배포를 물리적으로 분리하는 전략을 사용했으나 이는 임시방편에 불과했습니다. **오픈소스 기여를 통한 성능 최적화** * Datadog 팀은 내부적인 수정을 넘어 KSM v2.0.0의 메인 커뮤니티와 협력하여 지표 생성 로직과 빌더(Builder) 구조를 근본적으로 개선했습니다. * 결과적으로 지표 수집 프로세스 소요 시간을 기존 대비 15배 단축하는 성과를 거두었으며, 이는 대규모 인프라 운영의 핵심적인 전환점이 되었습니다. * 이러한 경험은 오픈소스 커뮤니티에 기여하는 것이 개별 기업의 인프라 문제를 해결함과 동시에 기술적 생태계 전체의 성능을 끌어올리는 가장 효과적인 방법임을 시사합니다. **실용적인 결론 및 추천** 대규모 Kubernetes 클러스터를 운영 중이라면 KSM v2 이상의 버전을 채택하여 최적화된 지표 수집 성능을 확보하는 것이 필수적입니다. 또한 단일 KSM 배포에서 성능 저하가 발생할 경우, 본문에서 언급된 것처럼 리소스 유형별(Collectors)로 배포를 분리하여 부하를 분산하는 전략을 검토해 보시기 바랍니다.

2023-03-08 incident: A deep dive into the platform-level impact | Datadog (새 탭에서 열림)

2023년 3월 8일 발생한 Datadog의 전사적 서비스 장애는 시스템 관리 데몬인 systemd의 동작 변경과 자동 보안 업데이트 설정이 결합되어 발생한 이례적인 사건입니다. Ubuntu 22.04 환경에서 systemd-networkd가 재시작될 때 기존 IP 라우팅 규칙을 모두 삭제하는 새로운 기본 동작이 활성화되었고, 이것이 전 지역 노드에 동시다발적인 자동 패치로 실행되면서 대규모 네트워크 중단으로 이어졌습니다. 이 사고는 인프라 전반에 걸친 자동화된 변경 관리와 점진적 배포 원칙이 보안 패치라는 예외 상황에서 어떻게 무력화될 수 있는지를 보여줍니다. **systemd-networkd의 IP 규칙 삭제 동작** * 2020년 12월 배포된 systemd v248부터 `systemd-networkd`는 시작 시 자신이 파악하지 못한 모든 IP 규칙(IP rules)을 삭제(flush)하는 동작을 도입했습니다. * 이후 v249에서 `ManageForeignRoutingPolicyRules` 설정을 통해 이 동작을 거부할 수 있는 옵션이 추가되었으나, 기본값은 여전히 기존 규칙을 삭제하는 방식이었습니다. * Datadog이 마이그레이션 중이던 Ubuntu 22.04는 이 위험한 기본 설정이 포함된 systemd v249를 사용하고 있었습니다. **보안 패치와 자동 업데이트의 결합** * 2023년 3월 7일, systemd의 CVE 취약점을 해결하기 위한 보안 패치가 Ubuntu 저장소에 업데이트되었습니다. * Datadog의 서버들은 Ubuntu의 기본 설정인 `unattended-upgrades`를 사용하고 있었으며, 이는 매일 특정 시간(06:00 UTC)에 보안 업데이트를 자동으로 수행하도록 설정되어 있었습니다. * 이 보안 패치가 설치되면서 `systemd-networkd` 서비스가 재시작되었고, 그 즉시 노드의 핵심적인 네트워크 라우팅 규칙들이 모두 삭제되었습니다. **점진적 배포 전략의 무력화** * Datadog은 평소 새로운 OS나 설정을 도입할 때 실험용 클러스터부터 시작해 스테이징, 소규모 리전, 대규모 리전 순으로 수주에 걸쳐 점진적으로 배포하는 엄격한 프로세스를 따릅니다. * 하지만 시스템 레벨의 자동 업데이트(unattended-upgrades)는 이러한 점진적 배포 통제를 우회하여 전 세계 모든 리전의 노드에 거의 동시에 적용되었습니다. * 결과적으로 전체 서버의 90% 이상을 차지하던 Ubuntu 22.04 노드들이 동시다발적으로 네트워크 불능 상태에 빠지게 되었습니다. **실용적인 교훈과 권장사항** 운영 환경에서 OS 배포판을 업그레이드할 때는 시스템 구성 요소(특히 systemd와 같은 핵심 데몬)의 기본 동작 변경 사항을 상세히 검토해야 합니다. 또한, 보안을 위한 자동 업데이트라 할지라도 인프라 전체에 동시에 적용되는 방식은 위험할 수 있으므로, 업데이트 주기를 리전별로 분산하거나 자체적인 패키지 미러를 통해 보안 패치 역시 점진적 배포 파이프라인의 통제하에 두는 것이 권장됩니다.

Using the Dirty Pipe vulnerability to break out from containers | Datadog (새 탭에서 열림)

리눅스 커널에서 발견된 Dirty Pipe 취약점은 권한이 없는 프로세스가 읽기 권한만 가진 파일에 데이터를 쓸 수 있게 허용하며, 이를 통해 컨테이너 환경에서 호스트 시스템의 루트 권한을 탈취할 수 있는 심각한 위협을 초래합니다. 특히 Kubernetes 환경에서 널리 쓰이는 컨테이너 런타임인 runC의 실행 바이너리를 페이지 캐시 수준에서 변조함으로써, 격리된 컨테이너를 탈출하여 호스트 시스템을 완전히 장악하는 시나리오가 가능합니다. 본 글에서는 이 취약점의 기술적 배경과 함께 실제 컨테이너 탈출이 이루어지는 공격 메커니즘을 상세히 설명합니다. **컨테이너 런타임과 runC의 구조적 취약성** - Kubernetes는 containerd나 CRI-O 같은 런타임을 통해 컨테이너를 관리하며, 실제 프로세스 생성은 OCI 규격을 준수하는 하위 레벨 런타임인 runC가 담당합니다. - runC는 컨테이너 내부 프로세스를 실행할 때 자신을 포크(fork)한 뒤 `execve` 시스템 콜을 호출하는데, 이때 `/proc/self/exe` 경로를 통해 호스트에 있는 runC 이진 파일에 대한 파일 서술자(File Descriptor)를 열어두게 됩니다. - 과거 CVE-2019-5736 취약점에 대한 대응으로 runC를 읽기 전용으로 마운트하는 방어책이 도입되었으나, Dirty Pipe는 커널의 페이지 캐시를 직접 수정하므로 이러한 파일 시스템 수준의 권한 제한을 무력화합니다. **Dirty Pipe를 이용한 컨테이너 탈출 과정** - 공격자는 먼저 취약한 웹 애플리케이션 등을 통해 권한이 제한된 일반 컨테이너에 침투한 뒤, 호스트의 runC 바이너리가 실행되기를 대기합니다. - 관리자가 `kubectl exec`와 같은 명령을 수행하여 컨테이너 내부에서 runC가 구동되는 순간, 공격 프로세스는 `/proc/<runC-pid>/exe`를 통해 호스트의 runC 실행 파일에 접근합니다. - Dirty Pipe 공격 프리미티브를 활용하여 페이지 캐시에 로드된 runC 바이너리 내용을 공격자의 악성 ELF 코드로 덮어씁니다. - 이렇게 변조된 runC는 호스트의 루트 권한으로 실행되므로, 공격자는 호스트 시스템에서 임의의 명령(예: 호스트 이름 확인, 루트 권한 쉘 실행 등)을 수행하며 컨테이너 격리를 완전히 무너뜨립니다. **메모리 기반 공격의 비영구적 특성** - Dirty Pipe를 통한 바이너리 변조는 디스크의 실제 파일을 직접 수정하는 것이 아니라 커널의 페이지 캐시 내에서 발생합니다. - 따라서 공격으로 인한 변조는 시스템이 재부팅되거나 커널 캐시가 드롭(drop)되기 전까지만 유지되는 비영구적 특성을 가집니다. - 하지만 단 한 번의 실행만으로도 호스트에 백도어를 설치하거나 권한을 상승시키기에 충분하므로 그 위험성은 매우 높습니다. Dirty Pipe 취약점은 리눅스 커널 수준의 결함이므로 이를 근본적으로 해결하기 위해서는 최신 보안 패치가 적용된 커널로 신속히 업데이트해야 합니다. 또한 컨테이너 환경에서는 최소 권한 원칙을 철저히 준수하고, 런타임 보안 모니터링 도구를 도입하여 `/proc` 파일 시스템에 대한 의심스러운 접근이나 시스템 이진 파일의 비정상적인 동작을 실시간으로 감지하고 차단하는 방어 전략이 필요합니다.

2023-03-08 incident: A deep dive into our incident response | Datadog (새 탭에서 열림)

Datadog은 2023년 3월 발생한 사상 첫 글로벌 서비스 장애를 겪으며 자사의 장애 대응(Incident Response) 프로세스와 문화를 실전에서 검증했습니다. 수백 명의 엔지니어가 투입된 이번 사태를 통해 Datadog은 "직접 만든 사람이 직접 운영한다(You build it, you own it)"는 원칙과 비난 없는 사후 분석(Blameless Postmortem)의 중요성을 다시 한번 확인했습니다. 이 글은 전례 없는 대규모 장애 상황에서 유연한 의사결정과 체계적인 협업 시스템이 어떻게 복구를 견인했는지에 대한 기술적 기록을 담고 있습니다. **Datadog의 장애 모니터링 및 대응 체계** * **소유권 기반 모델:** 모든 엔지니어링 팀은 자신이 구축한 서비스의 운영을 직접 책임지며, 24시간 모니터링 경보에 몇 분 내로 응답해야 하는 "You build it, you own it" 모델을 따릅니다. * **대역 외(Out-of-band) 모니터링:** 플랫폼 자체가 중단될 경우를 대비해 인프라 외부에서 API를 호출하여 사용자 관점에서 상태를 체크하는 별도의 독립적인 모니터링 시스템을 운영합니다. * **Slack 기반 협업:** 장애 발생 시 전용 앱이 Slack 채널을 자동으로 생성하며, 관련 없는 엔지니어도 자유롭게 참여하여 도움을 줄 수 있는 개방적인 환경을 조성합니다. **고심도 장애(High-Severity) 관리 및 역할 분담** * **장애 지휘관(Incident Commander):** 대규모 장애 시 숙련된 시니어 엔지니어가 투입되어 전체 대응을 진두지휘하며, 복구 전략과 커뮤니케이션을 총괄합니다. * **전담 커뮤니케이션 팀:** 고객 지원 매니저와 경영진이 포함된 별도 팀이 구성되어 외부 고객 및 비즈니스 이해관계자에게 정확한 상태 정보를 전달합니다. * **지속적인 훈련:** 장애 선언 문턱을 낮게 설정하여 일상적으로 장애 대응 프로세스를 연습하며, 모든 엔지니어는 6개월마다 필수 리프레시 교육을 이수해야 합니다. **자율성과 비난 없는 조직 문화** * **절차보다 사람 우선:** 고정된 복구 매뉴얼은 복잡한 시스템의 변화 속도를 따라갈 수 없으므로, 엔지니어가 현장에서 상황에 맞는 최선의 판단을 내릴 수 있도록 자율권을 부여합니다. * **비난 없는 문화(Blameless Culture):** 장애의 원인을 개인의 실수가 아닌 시스템의 결함으로 간주하여, 엔지니어가 압박감 속에서도 창의적인 해결책을 찾을 수 있도록 지원합니다. * **강화된 사후 분석:** 모든 고심도 장애 이후에는 자동화된 알림을 통해 상세한 포스트모템 작성을 독려하며, 이를 통해 유사 장애의 재발을 방지합니다. **3월 8일 글로벌 장애 타임라인 및 초기 진단** * **장애 트리거(06:00 UTC):** systemd 업데이트가 시작되면서 예상치 못한 인프라 연쇄 반응이 발생했습니다. * **신속한 감지(06:03~06:18 UTC):** 장애 발생 3분 만에 모니터링 시스템이 문제를 감지했고, 15분 이내에 고심도 장애로 격상되었습니다. * **원인 파악(07:20~11:36 UTC):** 쿠버네티스(Kubernetes) 노드 실패가 글로벌 장애의 핵심 원인임을 식별했으며, 최종적으로 '무인 업데이트(Unattended upgrades)'가 트리거였음을 밝혀냈습니다. * **인프라 복구(12:05~19:00 UTC):** EU1 및 US1 리전의 컴퓨팅 용량을 순차적으로 복구하고 재발 방지를 위한 완화 조치를 적용하여 전체 인프라를 정상화했습니다. 대규모 시스템을 운영하는 조직이라면 고정된 대응 매뉴얼에 의존하기보다 엔지니어의 자율성을 존중하고, 장애를 학습의 기회로 삼는 비난 없는 문화를 구축하는 것이 중요합니다. 특히 플랫폼 전체가 마비되는 최악의 상황을 대비해 인프라 외부에서 독립적으로 작동하는 '대역 외 모니터링' 체계를 반드시 갖출 것을 추천합니다.