Cloudflare, BGP 라우팅 오류로 6시간 서비스 장애...전 세계 BYOIP 고객 직격

클라우드플레어가 자체 소프트웨어 버그로 인해 2월 20일 6시간 이상 서비스 중단 사태를 빚었다.

[한국정보기술신문] 세계 최대 콘텐츠 전송 네트워크 및 인터넷 보안 기업 클라우드플레어(Cloudflare)가 지난 2월 20일(UTC 기준) 오후 5시 48분부터 약 6시간 7분에 걸쳐 대규모 서비스 장애를 겪었다. 이번 사태는 외부 해킹이나 사이버 공격이 아닌 클라우드플레어 내부 코드의 버그로 인해 발생한 것으로 확인됐다. 자사의 자체 IP 주소 관리 시스템에서 오작동이 발생해 고객들이 직접 가져온 IP 주소(BYOIP, Bring Your Own IP)를 통해 운영하던 서비스가 인터넷에서 갑자기 사라지는 사태가 벌어진 것이다.

코드 한 줄이 부른 대규모 장애

클라우드플레어 측 공식 발표에 따르면, 이번 장애의 원인은 BYOIP 서비스에서 고객의 IP 접두사를 정리하는 자동화 작업을 구현하는 과정에서 발생한 API 쿼리 버그였다. 해당 작업은 삭제 대기 중인 IP 접두사만을 조회해 처리해야 했으나, 버그로 인해 API 서버가 삭제 대기 목록이 아닌 전체 BYOIP 접두사 목록을 반환했고, 시스템은 이 모든 항목을 삭제 대상으로 인식해 순차적으로 제거하기 시작했다.

구체적으로는 정리 서브태스크가 API를 호출할 때 쿼리 파라미터 pending_delete에 아무 값도 지정하지 않은 상태로 요청을 보냈고, API 서버는 해당 파라미터 값이 빈 문자열("")이면 전체 BYOIP 접두사를 반환하도록 구현되어 있었다. 결과적으로 시스템은 전체 목록을 삭제 대상으로 판단하고 처리를 시작했다. 이 버그를 담은 코드는 2월 5일 코드베이스에 병합되었으며, 2월 20일 배포 이후 약 10분 만에 피해가 시작됐다.

BYOIP 접두사 25% 철회, 1.1.1.1도 영향

클라우드플레어가 글로벌 BGP(Border Gateway Protocol) 피어에 광고하는 전체 6,500개 접두사 중 4,306개가 BYOIP 접두사였다. 사고가 진행되는 동안 1,100개의 접두사가 17시 56분부터 18시 46분 (UTC) 사이에 인터넷에서 철회됐으며, 이는 전체 BYOIP 접두사의 약 25%에 해당한다. 이로 인해 해당 IP 주소로 운영되던 고객의 웹사이트와 애플리케이션이 인터넷에서 접근 불가 상태에 빠졌다.

클라우드플레어의 공개 DNS 리졸버인 1.1.1.1의 일부 구간인 one.one.one.one 역시 BYOIP 방식으로 운영되고 있어 이번 사고의 영향을 받았다. 다만 이 서비스가 조기에 장애를 감지하는 계기가 됐으며, 클라우드플레어 엔지니어들은 이를 통해 사고를 빠르게 인지하고 대응에 착수할 수 있었다고 설명했다.

피해를 받은 서비스를 구체적으로 살펴보면, CDN 및 보안 서비스는 해당 IP 대역으로의 트래픽 유입 자체가 차단되어 사용자들이 연결 실패를 경험했고, 스펙트럼 애플리케이션은 BYOIP 기반 앱에서 트래픽 프록시가 작동하지 않았다. 또한 데디케이티드 이그레스(Dedicated Egress)를 통해 아웃바운드 트래픽을 보내던 고객들도 목적지로 트래픽을 전송할 수 없었으며, 매직 트랜짓(Magic Transit)으로 보호받던 서비스들 역시 인터넷 경로 자체가 사라지는 피해를 입었다.

상태별 대응으로 6시간 이상 소요

복구가 즉각적으로 이루어지지 못한 이유는 피해를 입은 BYOIP 접두사가 모두 동일한 상태가 아니었기 때문이다. 일부 고객은 단순히 접두사 광고만 철회된 상태였으며, 이 경우 클라우드플레어 대시보드에서 직접 재광고를 설정해 자가 복구가 가능했다. 또 다른 고객들은 접두사 철회와 함께 일부 서비스 바인딩도 삭제된 상태여서 부분적으로만 복구가 가능했다. 가장 심각한 경우는 접두사 철회와 함께 모든 서비스 바인딩이 함께 삭제된 고객들로, 이들은 대시보드 조작만으로는 복구가 불가능했으며 클라우드플레어 엔지니어들이 전 세계 엣지 서버에 설정을 수동으로 재적용해야 했다.

주요 복구 타임라인을 정리하면 다음과 같다. 18시 46분 (UTC)에 버그가 발생한 서브태스크가 종료되고 복구가 시작됐으며, 19시 19분 (UTC)에는 일부 고객이 대시보드를 통한 자가 복구가 가능해졌다. 20시 30분 (UTC)에는 서비스 바인딩이 남아 있던 접두사들의 대량 복구가 완료됐고, 최종적으로 23시 03분 (UTC)에 나머지 접두사에 대한 전체 엣지 구성 배포가 완료되면서 사고가 완전히 종결됐다.

테스트 및 스테이징 환경의 한계

클라우드플레어는 스테이징 환경이 프로덕션과 최대한 유사하게 유지되고 있었지만, 이번 사고를 사전에 감지하기에는 모의 데이터가 충분하지 않았다고 인정했다. 또한 테스트는 고객이 직접 API를 호출하는 시나리오에 초점을 맞추고 있었으며, 내부 태스크 러너 서비스가 독립적으로 사용자 데이터를 변경하는 시나리오는 커버하지 못했다. 코드 리뷰도 통과했으나 이 특수한 케이스는 발견되지 않았던 것이다.

API 표준화, 롤백 체계, 서킷 브레이커 도입

클라우드플레어는 이번 사고를 계기로 세 가지 핵심 개선 방안을 발표했다. 첫째, API 스키마를 표준화해 파라미터 처리 방식을 명확히 하고 잘못된 API 호출을 시스템이 자동으로 감지할 수 있도록 할 계획이다. pending_delete와 같은 플래그를 문자열이 아닌 명확한 타입으로 처리하도록 개선한다.

둘째, 운영 상태와 설정 데이터베이스 간의 분리를 강화해 빠른 롤백이 가능한 구조를 구축한다. 현재는 고객이 설정한 주소 정보와 실제 운영에 사용되는 데이터가 동일한 데이터베이스에 저장되어 있어, 문제 발생 시 즉각적인 롤백이 어려웠다. 앞으로는 데이터베이스 상태의 스냅샷을 생성하고, 이를 다른 소프트웨어 배포와 동일하게 헬스 메트릭 기반의 점진적 배포 방식으로 적용할 예정이다. 이를 통해 데이터베이스가 비정상 상태로 변경되더라도, 트래픽 서비스를 유지하면서 데이터베이스를 복구하는 것이 가능해진다.

셋째, BGP 접두사의 대규모 철회나 삭제가 비정상적으로 빠른 속도로 일어날 때 이를 자동으로 감지하고 중단하는 서킷 브레이커 메커니즘을 도입한다. 이는 이번처럼 제어되지 않은 프로세스가 대규모 피해를 일으키는 것을 사전에 차단하기 위한 조치다.

이번 사고는 클라우드플레어가 지난해 말 선언한 "Code Orange: Fail Small" 이니셔티브의 일환으로 수행된 작업 도중 발생한 것이라는 점에서 아이러니한 측면이 있다. 해당 이니셔티브는 네트워크에 가해지는 모든 변경을 점진적이고 안전하게 배포하기 위한 복원력 강화 계획으로, 이번 사고의 원인이 된 자동화 작업도 그 일환이었다. 클라우드플레어는 이번 사고로 인해 해당 이니셔티브의 중요성이 더욱 부각됐다며, 완전한 복원력 확보까지 이 계획을 최우선 과제로 유지하겠다고 밝혔다.

한국정보기술신문 클라우드분과 이준호 기자 news@kitpa.org