Incident Library

IL-0240 Cloudflare · 2020-11-02databasenetworking

인증 데이터베이스가 과부하에 걸려 Cloudflare API 와 대시보드가 6시간 33분 동안 실패하고 느려졌다

2020년 11월 2일 Cloudflare 의 API 와 대시보드가 6시간 33분 동안 제대로 동작하지 않았다. API 와 대시보드는 Cloudflare 의 제어 플레인이고, 두 지역에 이중화한 많은 마이크로서비스로 이루어져 있다. 대부분 서비스의 데이터베이스는 한 번에 한 지역에서만 쓰기를 받을 수 있다. 전 세계에 퍼진 엣지는 영향 없이 동작했다. 14:43 UTC 에 한 랙의 스위치가 LACP 와 BGP 는 유지한 채 vPC 와 패킷 전달 일부를 잃었다. 스위치가 완전히 죽었다면 트래픽이 같은 쌍의 다른 스위치로 넘어갔겠지만, 일부만 망가져서 그런 전환이 일어나지 않았다. 이 랙에 있던 etcd 노드 하나는 리더와 연결이 끊겼지만 다른 노드와는 연결돼 있었다. 그래서 노드마다 클러스터 상태를 다르게 보게 됐고, 분산 시스템 이론에서는 이런 상태를 비잔틴 장애라고 부른다. RAFT 리더 선출에서 표가 갈려 리더가 뽑히지 않는 일이 거듭됐다. 선출 중에는 쓰기가 막히므로 etcd 는 스위치가 회복할 때까지 읽기 전용이 됐다. 스위치는 6분 뒤 스스로 회복했다.

데이터베이스 클러스터 관리 시스템은 etcd 로 구성원을 찾고 서로 조율한다. 각 클러스터는 primary, 동기 복제본, 하나 이상의 비동기 복제본으로 이루어진다. etcd 가 읽기 전용이 되자 클러스터 두 개가 primary 가 정상이라고 알리지 못했고, 동기 복제본이 자동으로 새 primary 로 승격됐다. 승격은 오류나 데이터 손실 없이 끝났다. 하지만 클러스터 관리 시스템에는 새 primary 를 승격하면 복제본을 모두 다시 만들어야 하는 결함이 있었다. 한 클러스터는 복제본이 금방 다시 만들어져 영향이 작았다. 다른 클러스터는 API 호출과 대시보드의 인증을 맡은 데이터베이스였고, 읽기가 많아 복제본 하나가 부하를 나눠 받고 있었다. 복제본이 없어지자 primary 가 모든 부하를 받아 과부하에 걸렸다. 이 데이터베이스는 커서 복제본을 다시 만드는 데 몇 시간이 걸릴 것으로 보였다.

Cloudflare 는 SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 primary 의 부하를 덜었다. 주 데이터 센터의 모든 데이터베이스 클러스터는 보조 데이터 센터에도 복제본이 있었고, 이 복제본은 장애 내내 살아 있었다. 읽기 쿼리를 그쪽으로 보내는 일은 아직 자동화되지 않아 손으로 API 트래픽을 돌렸고, API 가용성이 크게 나아졌다. 하지만 대시보드의 사용자 세션은 데이터 센터를 넘나들면 끊겨서 대시보드는 더 나빠졌다. 결국 인증 호출을 모두 주 데이터 센터로 되돌렸다. 21:20 UTC 에 첫 복제본이 다시 만들어져 자동으로 서비스에 투입되자 성능이 정상으로 돌아왔다. 줄였던 서비스를 다시 올려 밀린 비동기 처리를 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다. 글 끝에 덧붙인 글에서 Cloudflare 는 분산 시스템 커뮤니티의 지적을 받아들여, 이 고장은 비잔틴 장애보다 omission fault 로 보는 편이 맞다고 밝혔다. omission fault 는 비잔틴 장애보다 훨씬 좁은 장애 유형이고, 비잔틴 장애를 견디는 프로토콜 없이도 견딜 수 있다.

심각도
–
영향 범위
Cloudflare control plane: the API, whose query success rate dipped as low as 75%, and the dashboard, up to 80 times slower than normal; the edge kept working
영향 사용자
–
지역
–
감지까지
0m
복구까지
6h 33m

증상

14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.

스위치는 일부만 동작하는 상태였다. LACP 와 BGP 같은 제어 프로토콜은 살아 있었지만 vPC 는 동작하지 않았고, 데이터 플레인은 받은 패킷을 전부 전달하지 못했다. LACP 가 트래픽을 여러 링크에 나눠 보내기 때문에 연결된 서버는 트래픽 일부에서만 문제를 겪었고, 서버 쪽에서는 이 고장이 보이지 않았다. 스위치는 6분 뒤 사람이 손대지 않았는데도 회복했다.

14:44 에 etcd 오류가 시작됐다. 고장 난 랙에 있던 etcd 노드 1은 리더인 노드 3에 닿지 못했지만, 노드 2는 노드 1과 노드 3 모두에 닿았다. 노드 1은 자기에게 투표하며 리더 선출을 거듭 시작했고 노드 2는 계속 노드 3에 투표해 표가 갈렸다. 선출이 끝나지 않는 동안 모든 쓰기가 막혀 etcd 클러스터가 읽기 전용이 됐다.

14:45 에 데이터베이스 클러스터 두 개가 etcd 를 통해 primary 가 정상이라고 알리지 못했고, 동기 복제본이 자동으로 새 primary 로 승격됐다. 승격 뒤에는 복제본을 모두 다시 만들어야 했다. API 호출과 대시보드의 인증을 맡은 데이터베이스는 읽기가 많아 복제본 하나가 부하를 덜어 주고 있었는데, 그 복제본이 사라지자 primary 가 모든 부하를 받아 과부하에 걸렸다. 본격적인 영향은 이때 시작됐다.

API 가용성을 높이려고 읽기 트래픽을 보조 데이터 센터로 돌리자 대시보드 사용 경험은 오히려 나빠졌다. 대시보드의 사용자 세션은 바다 건너 데이터 센터로 옮기면 끊기기 때문이었다.

증상 오류율 상승지연 시간 증가데이터베이스 과부하쓰기 거부패킷 손실

원인

원인 DNS·네트워크 장애

구성 요소 NIC·케이블·스위치 포트 링크코디네이션 키-값 저장소데이터베이스 장애 조치 관리자데이터베이스데이터베이스 복제
기여 요인 자동화 증폭여유 용량 부재수동 조치 악화
촉발
14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.

감지

14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.

조치

후속 조치

교훈

모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: NIC·케이블·스위치 포트 링크, 코디네이션 키-값 저장소, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.