observability-tools

Code Orange: Fail Small is complete. The result is a stronger Cloudflare network (새 탭에서 열림)

Cloudflare는 2025년 말 발생했던 두 차례의 대규모 장애를 계기로 추진한 인프라 회복 탄력성 강화 프로젝트인 'Code Orange: Fail Small'을 성공적으로 마무리했습니다. 이번 프로젝트를 통해 설정 변경의 안정성을 확보하고, 장애 발생 시 영향을 최소화하며, 비상 상황에서의 대응 체계를 전면 개편했습니다. 결과적으로 Cloudflare 네트워크는 잠재적인 문제를 조기에 감지하고 격리함으로써 전 세계 사용자에게 더욱 신뢰할 수 있는 서비스를 제공할 수 있게 되었습니다. ### 안전한 설정 변경을 위한 Snapstone 도입 설정 변경이 네트워크 전체에 즉각적으로 반영되어 발생하던 대규모 장애를 방지하기 위해 새로운 배포 매커니즘을 구축했습니다. * **Snapstone 시스템 개발**: 설정을 패키지화하여 단계적으로 배포하고, 실시간 상태 모니터링을 통해 문제가 감지되면 자동으로 롤백하는 통합 관리 도구를 도입했습니다. * **점진적 배포의 표준화**: 과거에는 팀별로 달랐던 배포 방식을 Snapstone으로 통일하여, 데이터 파일이나 글로벌 제어 플래그 등 모든 유형의 설정 변경에 '상태 기반 점진적 배포(Health-mediated deployment)'를 적용합니다. * **리스크 관리 자동화**: 위험한 설정 패턴이 발견되면 이를 Snapstone 관리 대상으로 즉시 편입시켜, 별도의 추가 작업 없이도 안전한 배포 사이클을 보장받을 수 있습니다. ### 장애 영향력 최소화 및 서비스 세분화 장애가 발생하더라도 서비스 전체가 중단되지 않도록 시스템의 구조적 유연성을 높였습니다. * **Fail Open 및 Fail Stale 구현**: 최신 설정을 읽지 못할 경우 마지막으로 정상 작동했던 설정을 사용(Fail Stale)하거나, 일부 기능을 제한하더라도 트래픽 흐름은 유지(Fail Open)하도록 프로그래밍 모델을 개선했습니다. * **고객 코호트별 세분화**: 서비스 실행 환경을 여러 독립적인 세그먼트로 나누어, 무료 사용자 그룹에 먼저 업데이트를 적용하고 점진적으로 확대하는 방식을 도입했습니다. * **폭발 반경(Blast Radius) 제한**: 특정 서비스(예: Workers 런타임)에서 문제가 발생하더라도 전체 네트워크가 아닌 소수의 특정 세그먼트에만 영향이 국한되도록 설계하여 대규모 장애로 확산되는 것을 차단합니다. ### 비상 접근 권한(Break Glass) 및 사고 관리 체계 개편 인프라 장애로 인해 관리 도구 자체가 마비되는 '자기 의존성' 문제를 해결하기 위해 비상 대응 절차를 강화했습니다. * **백업 인증 경로 확보**: 핵심 Zero Trust 보안 툴이 작동하지 않는 극한 상황에서도 시스템에 접근할 수 있도록 18개 주요 서비스에 대한 별도의 비상 인증 경로와 스크립트를 마련했습니다. * **실전 중심의 대응 훈련**: 200명 이상의 엔지니어가 참여하는 대규모 드릴(Drill)을 통해 비상 상황에서의 대응 속도와 숙련도를 높였습니다. * **고객 소통 강화**: 내부 모니터링 데이터가 외부 공지 시스템으로 신속하고 명확하게 전달될 수 있도록 소통 프로세스를 개선하여 장애 시 고객의 불확실성을 해소합니다. Cloudflare의 이번 개선 작업은 단순한 기술적 수정을 넘어, '작게 실패(Fail Small)'함으로써 더 큰 가용성을 보장하는 구조적 변화를 의미합니다. 사용자는 이제 더욱 견고해진 인프라 위에서 예상치 못한 설정 오류나 시스템 장애로부터 보호받으며 서비스를 이용할 수 있습니다.

디스코드의 엘릭 (새 탭에서 열림)

Discord는 Elixir의 강력한 동시성 메커니즘을 활용하여 각 서버(길드)를 독립적으로 운영함으로써 수억 명의 사용자에게 실시간에 가까운 채팅 경험을 제공합니다. 그러나 급격한 트래픽 증가로 시스템 자정 능력이 한계에 도달할 때, 기존의 메트릭이나 자체 개발한 메모리 기반 분석 도구만으로는 복잡한 성능 병목 현상과 사용자 경험의 실질적인 저하 원인을 파악하는 데 한계가 있었습니다. 이를 해결하기 위해 Discord는 Elixir 환경에 맞춤화된 분산 추적(Distributed Tracing) 시스템을 직접 구축하여 서비스 중단 없이 시스템 전반의 가시성을 확보하는 데 성공했습니다. **기존 관측 도구의 한계와 실무적 어려움** * **지표와 로그의 한계:** 대시보드는 엔진 온도계처럼 시스템의 상태를 보여주지만, 온도가 높을 때 사용자가 느끼는 실제 주행 경험(지연 시간의 체감 등)이나 구체적인 결과까지는 설명해주지 못합니다. * **길드 타이밍(Guild Timings) 도구:** 길드별 작업 소요 시간을 분 단위로 메모리에 기록하는 커스텀 도구를 사용해왔으나, 데이터 양이 너무 방대하여 대형 길드를 제외하고는 데이터를 빠르게 순환(Rotation)시켜야 하므로 과거 이력 분석이 어렵습니다. * **다운스트림 효과 파악 불가:** 기존 도구들은 개별 작업의 소요 시간은 보여주지만, 해당 작업이 연쇄적으로 일으키는 다운스트림 서비스의 영향과 전체적인 실행 흐름을 시각화하지 못하는 단점이 있었습니다. **Elixir 환경에서의 분산 추적 도입 과정** * **분산 추적(APM)의 필요성:** 작업의 구성 요소별 소요 시간을 한눈에 파악할 수 있는 분산 추적 기술을 통해 시스템 내부의 복잡한 상호작용을 투명하게 확인하고자 했습니다. * **기술적 난관:** 일반적인 추적 도구는 HTTP 헤더와 같은 메타데이터 레이어를 통해 추적 정보를 전달하지만, Elixir의 기본 통신 도구들에는 이러한 메타데이터 레이어가 내장되어 있지 않았습니다. * **커스텀 메타데이터 레이어 구축:** 서비스 간 통신 방식에 추적 정보를 함께 전달할 수 있는 자체 메타데이터 전달 메커니즘을 설계하여 문제를 해결했습니다. * **무중단 통합:** 서비스 간의 통신 방식을 근본적으로 변경하는 작업임에도 불구하고, 철저한 설계를 통해 시스템 가동 중단(Downtime) 없이 새로운 추적 시스템을 성공적으로 통합했습니다. 복잡한 분산 시스템에서 단순한 성능 지표만으로는 문제의 근본 원인을 파악하기 어렵습니다. 특히 Elixir와 같이 특수한 통신 구조를 가진 환경에서는 표준적인 APM 도구를 그대로 적용하기보다, 시스템의 특성에 맞춰 메타데이터 전달 계층을 직접 구현함으로써 인프라 전반의 흐름을 명확히 파악할 수 있는 분석 환경을 구축하는 것이 중요합니다.