systemd

ecdysis를 통한 오래된 코드 탈 (새 탭에서 열림)

Cloudflare는 수년간 자사 인프라에서 수백만 건의 요청을 중단 없이 처리하며 검증한 Rust 라이브러리 'ecdysis'를 오픈소스로 공개했습니다. 이 라이브러리는 네트워크 서비스 업데이트 시 연결 끊김이나 새로운 연결 거부 없이 프로세스를 재시작할 수 있는 '우아한 재시작(Graceful Restart)' 기능을 제공합니다. 이를 통해 보안 패치나 기능 업데이트 시에도 실시간 트래픽에 영향을 주지 않고 안전하게 최신 코드로 교체할 수 있습니다. ### 기존 재시작 방식의 한계와 문제점 * 단순한 재시작 방식(이전 프로세스 종료 후 새 프로세스 시작)은 소켓을 닫는 순간부터 새 프로세스가 리스닝을 시작할 때까지 공백이 발생하며, 이 기간에 들어오는 연결은 커널에 의해 `ECONNREFUSED`로 거부됩니다. * 이미 연결된 세션(대용량 업로드, 비디오 스트리밍, WebSocket 등)이 프로세스 종료와 함께 강제로 끊기며 사용자 경험에 악영향을 미칩니다. * `SO_REUSEPORT` 옵션은 여러 프로세스가 동일한 포트를 바인딩하게 해주지만, 새 프로세스가 연결을 수락(`accept`)하기 전에 이전 프로세스가 종료되면 커널 큐에서 대기 중이던 연결들이 고아 상태가 되어 폐기되는 고유의 결함이 있습니다. ### ecdysis의 작동 원리와 포크 모델 * NGINX의 설계 방식을 차용하여, 실행 중인 부모 프로세스가 `fork()`를 통해 자식 프로세스를 생성하고, 자식은 `execve()`를 실행하여 새 버전의 코드로 자신을 교체합니다. * 이 과정에서 부모 프로세스는 명명된 파이프(named pipe)를 통해 소켓 파일 디스크립터(FD)를 자식에게 상속하며, 두 프로세스가 잠시 소켓을 공유하여 공백 없는 트래픽 처리를 보장합니다. * 자식 프로세스가 초기화를 완료했다는 신호를 보내면 부모는 그제야 소켓을 닫고 기존 연결만 처리한 뒤 종료(Draining)되며, 만약 자식이 초기화 중 충돌하더라도 부모가 여전히 동작 중이므로 서비스 중단이 발생하지 않습니다. ### 주요 기능 및 시스템 통합 * **Tokio 비동기 런타임 지원**: 고성능 Rust 서비스를 위해 Tokio용 비동기 스트림 래퍼를 기본 제공하므로, 상속받은 소켓을 별도의 복잡한 연동 없이 즉시 리스너로 사용할 수 있습니다. * **systemd 통합**: `systemd-notify` 기능을 내장하여 서비스 유닛 설정의 `Type=notify-reload`와 연동될 수 있으며, 시스템 레벨에서 프로세스 수명 주기를 정확히 추적할 수 있습니다. * **검증된 신뢰성**: Cloudflare의 글로벌 네트워크에서 트래픽 라우팅, TLS 수명 주기 관리, 방화벽 규칙 적용 등 가장 핵심적인 서비스들에 5년 넘게 사용되며 안정성을 입증했습니다. 가용성이 극도로 중요한 Rust 기반 네트워크 서비스를 운영한다면, `ecdysis`는 복잡한 소켓 공유 로직을 직접 구현할 필요 없이 제로 다운타임 업데이트를 구현할 수 있는 가장 실무적인 해결책이 될 것입니다.

2023-03-08 사건: 플랫폼 수준 복구에 대한 심층 분석 | 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) 설계가 필수적입니다.

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

2023년 3월 발생한 Datadog의 사상 첫 글로벌 장애는 대규모 복합 시스템을 운영하는 조직에 있어 장애는 '발생 여부'가 아닌 '발생 시기'의 문제임을 다시 한번 각인시켰습니다. Datadog은 수백 명의 엔지니어가 투입된 이 전례 없는 위기 상황에서 '직접 만든 사람이 직접 운영한다(You build it, you own it)'는 원칙과 체계적인 사고 대응(Incident Response) 프로세스를 통해 시스템을 복구할 수 있었습니다. 이번 장애 대응 과정은 기술적 해결을 넘어, 유연한 조직 구조와 비난 없는 문화(Blameless Culture)가 복잡한 시스템의 장애를 해결하는 데 얼마나 결정적인 역할을 하는지 증명했습니다. ### 데이터독의 상시 모니터링 및 대응 체계 * **다중 모니터링 전략:** 서비스 내부 모니터링뿐만 아니라, 플랫폼 전체가 중단된 상황에서도 작동할 수 있도록 외부 인프라에서 독립적으로 구동되는 '아웃 오브 밴드(Out-of-band)' 모니터링을 운영합니다. * **소유권 중심 모델:** 엔지니어가 자신이 구축한 서비스의 온콜(On-call) 업무를 직접 담당하며, 장애 발생 시 수 분 이내에 응답하는 것을 원칙으로 합니다. * **자동화된 협업 환경:** 장애가 선포되면 Slack 앱이 자동으로 전용 채널을 생성하고 상황을 공유하여, 직접 호출되지 않은 엔지니어도 자발적으로 참여할 수 있는 환경을 제공합니다. ### 고난도 장애를 위한 지휘 체계와 역할 분담 * **인시던트 커맨더(Incident Commander, IC):** 고객 영향도가 크거나 여러 팀의 협력이 필요한 고차원 장애 시, 숙련된 시니어 엔지니어가 IC 역할을 맡아 전체 대응을 진두지휘합니다. * **전담 커뮤니케이션 관리:** IC는 복구 작업에 집중하고, 별도의 커뮤니케이션 리드와 고객 연락 담당자(Customer Liaison)가 내부 상황 전파 및 대외 공지를 전담하여 혼선을 방지합니다. * **경영진의 참여:** 심각한 장애 시에는 엔지니어링 임원이 참여하여 비즈니스 맥락에 따른 의사결정을 지원하고 필요한 자원을 즉각 투입합니다. ### 훈련을 통한 숙련도 향상과 자율성 보장 * **낮은 장애 선포 장벽:** 평소 아주 작은 문제라도 장애로 규정하고 대응 프로세스를 가동함으로써, 엔지니어들이 도구와 절차에 익숙해지도록 유도합니다. * **정기적인 온콜 교육:** 모든 엔지니어는 6개월마다 온콜 교육을 이수해야 하며, 여기에는 기술적 절차뿐만 아니라 비난 없는 조사 방식에 대한 교육이 포함됩니다. * **사람 중심의 프로세스:** 미리 정의된 딱딱한 복구 절차(Runbook)에 의존하기보다, 시스템을 가장 잘 아는 엔지니어가 현장에서 최선의 판단을 내릴 수 있도록 자율성을 부여합니다. ### 3월 8일 글로벌 장애의 기술적 분석 및 교훈 * **장애 원인:** `systemd` 업그레이드 과정에서 발생한 예기치 못한 문제가 '무인 업그레이드(Unattended upgrades)'를 통해 확산되며 쿠버네티스 클러스터 실패를 유발했습니다. * **신속한 초기 대응:** 장애 발생 3분 만에 이상이 감지되었고, 30분 이내에 글로벌 장애로 진단되어 대응 체계가 가동되었습니다. * **심리적 안전감의 중요성:** 극심한 스트레스가 동반되는 글로벌 장애 상황에서 비난 없는 문화는 엔지니어들이 위축되지 않고 창의적인 해결책을 찾는 토대가 되었습니다. **실용적인 결론** 대규모 시스템의 장애는 완벽히 막을 수 없으므로, 조직은 **'사람과 문화'**에 투자해야 합니다. 기술적 자동화도 중요하지만, 장애 상황에서 유연하게 대처할 수 있는 숙련된 엔지니어를 양성하고 이들이 비난받을 두려움 없이 복구에 전념할 수 있는 환경을 조성하는 것이 가장 효과적인 재난 대비책입니다. 또한, 평상시 아주 작은 장애라도 공식 프로세스를 거쳐 대응하고 사후 분석(Postmortem)을 작성하는 습관을 통해 조직 전체의 복원력을 높여야 합니다.

2023-03-08 사건: 우리의 사건 대응에 대한 심층 분석 | 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 리전의 컴퓨팅 용량을 순차적으로 복구하고 재발 방지를 위한 완화 조치를 적용하여 전체 인프라를 정상화했습니다. 대규모 시스템을 운영하는 조직이라면 고정된 대응 매뉴얼에 의존하기보다 엔지니어의 자율성을 존중하고, 장애를 학습의 기회로 삼는 비난 없는 문화를 구축하는 것이 중요합니다. 특히 플랫폼 전체가 마비되는 최악의 상황을 대비해 인프라 외부에서 독립적으로 작동하는 '대역 외 모니터링' 체계를 반드시 갖출 것을 추천합니다.

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

이 글은 2023년 3월 8일 발생한 Datadog의 대규모 서비스 장애 원인을 분석하고 있습니다. 장애의 근본 원인은 Ubuntu 22.04에 포함된 **systemd-networkd의 기본 동작 변경**과 **자동 보안 업데이트(unattended-upgrades)**가 결합되어, 전 세계 모든 리전의 호스트에서 네트워크 라우팅 규칙이 동시에 삭제되었기 때문입니다. 결과적으로 리전 간 격리 원칙에도 불구하고 클라우드 제공업체와 무관하게 전사적인 네트워크 마비가 발생했습니다. ### systemd-networkd의 동작 변경과 잠복된 위험 * **새로운 기본값 도입:** systemd v248부터 `systemd-networkd`가 시작될 때 자신이 인식하지 못하는 모든 IP 규칙(IP rules)을 삭제(flush)하는 동작이 추가되었습니다. * **버전별 차이:** 이전 LTS 버전인 Ubuntu 20.04(systemd v245)에서는 이 문제가 없었으나, Datadog이 도입한 **Ubuntu 22.04(systemd v249)**는 이 새로운 동작이 기본값으로 설정되어 있었습니다. * **발견 지연의 이유:** 이 현상은 호스트가 처음 생성될 때가 아니라, 실행 중인 상태에서 `systemd-networkd`가 **재시작**될 때만 발생합니다. 평상시에는 재시작할 일이 거의 없었기 때문에 대규모 배포 과정에서도 위험이 감지되지 않았습니다. ### 자동 업데이트(Unattended Upgrades)와 트리거 * **보안 패치의 배포:** 2023년 3월 7일, systemd의 CVE 취약점 해결을 위한 패치가 Ubuntu 저장소에 배포되었습니다. * **자동 업데이트의 동작:** Datadog 서버들은 Ubuntu 기본 설정에 따라 `unattended-upgrades`가 활성화되어 있었으며, 매일 정해진 시간(06:00~07:00 UTC 사이)에 보안 업데이트를 수행하도록 설정되어 있었습니다. * **네트워크 규칙 삭제:** 보안 패치가 설치되면서 `systemd-networkd` 서비스가 재시작되었고, 이 과정에서 Kubernetes 네트워킹 등에 필요한 커스텀 IP 라우팅 규칙들이 "알 수 없는 규칙"으로 간주되어 모두 삭제되었습니다. ### 전 리전 동시 장애 발생 원인 * **일관된 구성의 역설:** 모든 리전이 동일하게 Ubuntu 22.04를 사용하고 동일한 업데이트 타이머 설정을 가지고 있었기 때문에, 리전 간의 물리적 격리에도 불구하고 업데이트와 그에 따른 네트워크 마비가 전 세계적으로 거의 동시에 일어났습니다. * **점진적 배포의 한계:** Datadog은 평소 인프라 변경 시 리전별로 단계적 배포를 수행하지만, OS 패키지 저장소에서 직접 내려받는 자동 보안 업데이트는 이러한 통제된 배포 프로세스를 우회하여 직접 호스트에 적용되었습니다. 이 사건은 인프라의 안정성을 위해 도입한 **자동 보안 패치**가 오히려 시스템의 기저 동작(low-level behavior) 변경과 맞물려 거대한 단일 장애점(Single Point of Failure)이 될 수 있음을 시사합니다. 운영 환경에서는 OS 패키지 업데이트를 포함한 모든 변경 사항이 통제된 파이프라인과 단계적 배포 전략을 거치도록 관리하는 것이 중요합니다.

2023-03-08 사건: 플랫폼 수준의 영향 깊이 살펴보기 | 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와 같은 핵심 데몬)의 기본 동작 변경 사항을 상세히 검토해야 합니다. 또한, 보안을 위한 자동 업데이트라 할지라도 인프라 전체에 동시에 적용되는 방식은 위험할 수 있으므로, 업데이트 주기를 리전별로 분산하거나 자체적인 패키지 미러를 통해 보안 패치 역시 점진적 배포 파이프라인의 통제하에 두는 것이 권장됩니다.