어젯밤 Cloudflare 서비스 중단은 다음 SQL 명령문으로 인해 발생했습니다. 이전에는 이 SQL 쿼리가 완벽하게 작동했으며, 기본 데이터베이스의 열 정보만 쿼리했습니다. 하지만 어제 일부 사용자의 권한을 업그레이드하면서 이 SQL이 기본 데이터베이스와 기본 r0 데이터베이스 모두에서 솔루션 정보를 반환하는 문제가 발생했습니다. 권한을 조정했을 때 아무도 이 SQL을 적절하게 수정해야 한다고 생각하지 않았습니다. 결과적으로 쿼리 결과 수가 두 배로 늘어나 결과 파일 크기도 두 배로 늘어났습니다. 원래 약 60개의 피처를 포함하던 파일이 약 120개의 피처로 늘어났습니다. 여기서 핵심 설계 특징이 있습니다. 성능 최적화를 위해 Cloudflare의 크롤러 방지 모듈은 고정된 양의 메모리를 미리 할당하고 최대 200개의 기능만 지원한다는 상한선을 하드코딩합니다. 원래 한도는 매우 관대하게 설정되었는데, 실제로 사용된 것이 60개에 불과해 마진이 3배 이상 남았기 때문이다. 그러나 중복 데이터로 인해 피처 파일이 200개라는 제한을 초과하면 문제가 발생합니다. Rust 코드에는 피처 수가 제한을 초과하면 패닉을 일으키고 500 오류를 반환하는 검사 코드가 있습니다. 더 심각한 점은 이 기능 파일이 5분마다 자동으로 생성되어 전 세계 모든 서버에 빠르게 푸시된다는 것입니다. 권한 조정은 쿼리가 어느 노드에 도달하는지에 따라 5분마다 각 데이터베이스 노드에 점진적으로 푸시되므로, 정상적인 파일이 생성될 수도 있고, 그렇지 않을 수도 있습니다. 이로 인해 매우 이상한 현상이 발생했습니다. 시스템이 작동하다가 간헐적으로 고장이 나기도 하고, 때로는 정상으로 돌아오기도 하고 때로는 완전히 다운되기도 했습니다. 이 증상을 보고 엔지니어들은 DDoS 공격을 받고 있을 가능성을 의심했습니다. 우연히도, 클라우드플레어의 상태 페이지(제3자가 호스팅하고 클라우드플레어 인프라와 완전히 독립되어 있음)도 이때 다운되어 "공격"에 대한 의심이 더욱 커졌습니다. 이로 인해 문제를 식별할 때 잘못된 방향으로 생각하게 되어 시간을 낭비하게 되었습니다. 권한 조정이 모든 노드에 점진적으로 적용되고 각 노드에서 손상된 파일이 생성되기 시작한 후에야 시스템은 안정적인 장애 상태에 진입했습니다. 그제서야 엔지니어들은 실제 문제를 정확히 파악하고 장애를 해결할 수 있었습니다. 이번 서비스 중단은 11월 18일 오후 7시 28분경 베이징에서 시작되어 오후 10시 30분에 복구되었고, 19일 오전 1시 6분에 완전히 복구되어 총 5시간 30분 동안 지속되었습니다. 이는 2019년 이후 클라우드플레어 역사상 가장 큰 서비스 중단이었습니다.
스레드를 불러오는 중
깔끔한 읽기 화면을 위해 X에서 원본 트윗을 가져오고 있어요.
보통 몇 초면 완료되니 잠시만 기다려 주세요.
