Cloudflare 장애는 다음과 같은 일련의 사건으로 전개되었습니다.
장애 발생 과정
-
권한 변경: Cloudflare는 ClickHouse 데이터베이스 클러스터의 권한 및 메타데이터 가시성을 변경했습니다. 이로 인해 시스템 메타데이터 쿼리 결과에 이전보다 더 많은 행(다른 스키마의 테이블 포함)이 반환되었습니다.
-
설정 파일 생성: Bot Management 기능 파일 생성기는
system.columns를 쿼리하여 봇 점수 모델에 사용되는 기능 목록을 생성합니다. 변경 후 이 쿼리는 약 두 배의 컬럼을 반환하여 훨씬 더 큰 기능 파일을 생성했습니다. -
프록시 패닉: 이 기능 파일은 Cloudflare의 엣지 네트워크로 전송됩니다. 코어 프록시의 봇 모듈은 기능 수가 하드 리미트(200개) 미만일 것으로 예상하고 메모리를 사전 할당합니다. 새로운 대형 파일은 이 제한을 초과했고, Rust 코드는 패닉 상태에 빠져 5xx 오류를 유발했습니다.
-
파급 효과: 코어 프록시에 의존하는 Workers KV 및 Access와 같은 다운스트림 시스템도 영향을 받았습니다.
지속적 배포(CD)의 중요성
생산 환경 장애의 주요 원인은 ‘변경’입니다. 지속적 배포는 이러한 변경을 안전하고 예측 가능하게 만드는 것을 목표로 합니다.
1. 설정 파일(Config)은 코드이다
장애를 일으킨 기능 파일은 단순한 데이터가 아니라 실행 가능한 동작을 정의합니다. 이는 애플리케이션 코드와 동일한 규율로 다루어져야 합니다.
-
소스 제어 시스템에 저장 및 버전 관리
-
파이프라인에서 유효성 검사
-
소비자(프록시 모듈)와의 계약 테스트 적용
2. 시스템 간의 계약
생산자(기능 파일 생성기)와 소비자(프록시 모듈) 사이에는 “200개 이하의 기능을 안전하게 처리할 수 있다”는 암묵적인 계약이 존재했습니다. 이 계약은 명시적으로 강제되지 않았고, 위반 시 소비자는 단순히 패닉 상태에 빠졌습니다.
- CD 환경에서는 이러한 계약을 테스트로 인코딩해야 합니다. 예: “기능 파일이 200개를 초과하면 파이프라인 실패” 또는 “실행 시 너무 크면 로깅하고 기능을 삭제하여 우아하게 저하(degrade gracefully)”.
3. 변경 이벤트와 연동된 빠른 피드백
변경 배포 직후 5xx 오류가 급증한다면, 첫 번째 가설은 “우리가 문제를 일으켰다”여야 합니다. 강력한 CD/운영 체계는 모니터링을 배포와 직접 연결하여, 문제가 발생하면 즉시 변경 사항을 롤백하고 조사를 계속하도록 지시해야 합니다.
CI/CD가 더 도움이 될 수 있었던 지점
1. 프로덕션 코드처럼 설정 생성기 테스트
-
쿼리 동작에 대한 자동화된 테스트
-
안전하다고 간주되는 출력 크기 범위에 대한 테스트
-
실제와 유사한 ClickHouse 클러스터(권한 변경 포함)를 프로덕션에 적용하기 전에 테스트 환경에서 검증
2. 모든 것에 대한 점진적 배포(Progressive Delivery)
-
새로운 동작을 트래픽의 작은 부분이나 일부 지역에 먼저 배포
-
5xx 오류, 지연 시간, 리소스 사용량 급증 여부 관찰
-
자동화된 시스템이 문제 감지 시 롤백 및 추가 배포 차단
3. 패닉이 아닌 우아한 성능 저하 설계
-
제한을 초과하는 기능은 삭제하고 로그를 남김
-
Bot Management 모듈을 일시적으로 비활성화하고 트래픽을 계속 전달
-
글로벌 킬 스위치를 통해 Bot Management 기능을 끄고 핵심 CDN 및 프록시 경로는 유지
4. “플랫폼성” 변경 사항에 대한 CI 안전망
-
플랫폼 변경 사항도 종속 서비스에 대한 대표 워크로드 및 통합 테스트를 실행하는 파이프라인을 거쳐야 함.
-
ClickHouse 권한 변경은
system.columns를 쿼리하는 모든 소비자에 대한 호환성 테스트 스위트를 실행해야 했습니다.