그래프
사례5건
5건 중 1~5번째
- 증상
미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 반복해서 흔들렸다. 로그와 지표에서는 fly-proxy 가 처리 중인 요청에 필요한 항목만 읽어 오는 lazy loader 의 지연이 500 ms 에서 몇 초까지 높게 나왔다. 새 요청도 그만큼 더 기다린 뒤에야 처리됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Fly.io 는 미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 흔들리는 것을 알아챘다. 로그와 지표에서 lazy loader 지연이 500 ms 에서 몇 초까지 높게 나왔다.
- 조치
- Corrosion 에 상태가 아주 큰 앱을 원인으로 보고 임시 완화책을 넣은 뒤 SJC 에 프록시를 배포했다. 잠시 나아졌지만 새 프로세스가 워밍업을 마치자 지연이 다시 치솟았다.
- 서버 몇 대가 빠져 용량이 모자란 SJC 에서 Anycast 트래픽을 LAX 로 옮겼다. 처음에는 나아졌지만 얼마 뒤 LAX 도 버거워했다.
- Airtime 의 대역폭 한도를 낮췄다. softirq CPU 사용률과 호스트 load average 는 내려갔지만 lazy loader 질의는 계속 느렸다.
- 프록시를 재시작하면서 종료를 기다리던 프록시 프로세스를 모두 강제로 죽여 lazy loader 문제를 풀었다. 이것으로 첫 고비가 끝났다.
- 후속 조치
- 앞으로 몇 주에서 몇 달 사이에 에지 용량을 크게 늘린다.
- 프록시 인스턴스가 여럿 함께 떠 있게 만든 버그를 고쳤다.
- Airtime 이 돌고 있는 프록시가 기대한 활성 인스턴스가 아닐 때는 당분간 훨씬 엄격한 한도를 쓰도록 바꿨다.
- lazy loader 의 로드 셰딩 동작을 고쳐 요청 처리 지연의 최대값에 합리적인 상한이 생기게 했다.
- 프록시 메모리 안 서비스 카탈로그를 샤드로 나누고 더 잘게 나눈 락으로 바꾼다. 이 전환이 장애를 더 내지 않도록 Antithesis 같은 테스트를 함께 쓴다.
- Airtime 이 프록시만이 아니라 시스템 전체 부하에 맞춰 반응하도록 다시 만든다. 프록시 프로세스가 여럿 떠 있거나 같은 호스트의 다른 프로세스가 대역폭 여유를 쓸 때도 안전장치가 되게 한다.
- 프록시가 기대한 구성으로 돌지 않을 때를 더 잘 감시하는 방법을 찾는다.
IL-0283Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다Cloudflare2025- 증상
11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.
- 촉발
11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
11:31 UTC 에 첫 자동 테스트가 문제를 감지했고, 11:32 에 수동 조사가 시작됐으며, 11:35 에 장애 대응 통화가 열렸다.
- 조치
- 13:05 UTC 에 Workers KV 와 Cloudflare Access 를 내부 우회 경로로 돌려 이전 버전의 코어 프록시를 쓰게 했다. 이전 버전에도 같은 문제가 있었지만 영향이 작았다.
- 14:24 UTC 에 새 Bot Management 설정 파일의 자동 배포를 멈췄다.
- 알려진 정상 피처 파일을 피처 파일 배포 큐에 손으로 넣었다.
- 코어 프록시를 강제로 재시작했다. 14:30 UTC 에 주된 영향이 풀렸다.
- 쌓인 로그인 시도와 재시도로 느려진 대시보드를 컨트롤 플레인 동시성을 늘려 15:30 UTC 무렵 되살렸다.
- 나쁜 상태에 빠진 나머지 서비스들을 재시작했고, 17:06 UTC 에 5xx 오류량이 평소로 돌아왔다.
- 후속 조치
- Cloudflare 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
- 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
- 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
- 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.
- 증상
2024년 11월 12일 8:47 AM UTC 에 편집기 새 버전을 배포한 뒤, 아시아의 많은 사용자에게 편집기의 객체 패널이 끝없이 로딩 상태로 남았다. 9:08 AM UTC 부터는 canva.com 자체가 열리지 않았다.
- 촉발
2024년 11월 12일 8:47 AM UTC 에 Canva 편집기 새 버전이 배포돼 클라이언트들이 새 정적 자산을 받기 시작했다. 같은 시각 Cloudflare 의 싱가포르와 애슈번 사이 경로에서 패킷이 손실돼 JavaScript 파일 하나의 전송이 20분 동안 끝나지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 임시 Cloudflare 방화벽 규칙을 넣어 CDN 에서 모든 트래픽을 막고, 새 API Gateway 태스크가 요청을 받지 않은 상태에서 뜨게 했다.
- canva.com 을 상태 페이지로 돌려 사용자에게 장애 중임을 알렸다.
- 엄격한 속도 제한을 건 오스트레일리아 사용자부터 시작해 canva.com 트래픽을 조금씩 되살렸다.
- 후속 조치
- 트래픽을 세밀하게 돌리고 막은 뒤 단계적으로 다시 늘리는 내부 런북을 만든다.
- canva.com 을 쓸 수 없을 때 사용자에게 더 자세한 오류 페이지를 보여 준다.
- API Gateway 의 기본 태스크 수와 태스크 하나에 주는 메모리를 늘린다.
- 비슷한 트래픽 패턴에서 실패할 위험을 줄이는 부하 차단 규칙을 API Gateway 에 더한다.
- API Gateway 에 정기 부하 테스트를 들인다.
- 텔레메트리 라이브러리의 스레드 잠금 버그를 고치는 패치를 배포한다.
- 텔레메트리 라이브러리의 마이크로벤치마크 테스트에 스레드 경합을 일으킨 코드 경로의 멀티스레드 테스트를 더한다.
- 페이지 자산 카나리 릴리스에서 JavaScript 오류율에 더해 페이지 로드 완료 이벤트를 보조 지표로 본다.
- 카나리에 롤아웃 단계를 하나 더 두어 단계적 배포 중 문제를 찾을 시간을 늘리는 실험을 한다.
- 사용자 요청이 자산을 너무 오래 기다리지 않도록 자산 받기에 타임아웃을 둔다.
- Cloudflare 와 함께 이번 사고에서 여러 시스템이 어떻게 얽혀 작용했는지 자세히 파악한다.
IL-0339Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다Microsoft Azure2024- 증상
2024년 7월 30일 11시 45분 UTC 부터 Azure Front Door 와 Azure CDN 을 거치는 Microsoft 서비스에 접속하던 일부 고객이 간헐적인 연결 오류, 타임아웃, 지연 급증을 겪었다. 11시 47분에 Azure Portal 팀이 먼저 서비스 성능 저하를 알아챘다.
- 촉발
Azure 네트워크 DDoS 보호 서비스가 TCP SYN flood DDoS 공격을 자동으로 막은 뒤 트래픽을 Azure Front Door 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 2분 뒤인 11시 47분 UTC 에 Azure Portal 팀이 서비스 성능 저하를 알아채고 조사를 시작했다. 12시 10분에 네트워크 모니터링이 이 포털 장애를 유럽의 한 사이트에서 난 네트워크 문제와 연결 지었다.
- 조치
- 12시 55분 UTC 에 국지적인 혼잡을 확인하고, 트래픽 경로 변경을 포함한 혼잡 완화용 표준 플레이북을 실행했다. 13시 58분에 영향 대부분이 사라졌다.
- 16시 58분, 네트워크 컨트롤 플레인이 명령을 다시 내리게 했지만 문제의 장비에는 명령이 닿지 않았다.
- 17시 50분부터 문제의 장비를 네트워크에서 안전하게 빼면서 다른 문제가 없는지 네트워크를 훑었다. 장비는 19시 32분에 다 뺐다.
- 후속 조치
- 한 지역의 DDoS 완화 문제가 다른 지역으로 번지지 않도록, 네트워크 장비에 빠져 있던 설정을 넣었다. 이 일은 끝났다.
- 잘못된 설정을 찾아내도록 Azure 네트워크의 기존 검증과 모니터링을 강화한다. 2024년 11월에 끝낼 예정이다.
- DDoS 보호 서비스가 컨트롤 플레인에서 닿지 않는데도 트래픽을 계속 받는 상황을 잡아내도록 모니터링을 개선한다. 2024년 11월에 끝낼 예정이다.
- 증상
2017년 10월 13일 14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. API 서비스가 쓰는 Redis 고가용 클러스터에서 primary 노드가 완전히 사라졌다. 클러스터는 secondary 노드로 제대로 failover 했지만, 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다.
- 촉발
14:01 PDT 쯤 Google Cloud Platform 이 API 서비스용 Redis 고가용 클러스터의 primary 인스턴스를 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 되면서 클러스터가 재조정됐고, API 인스턴스의 Redis failover 처리에 있던 알려진 문제가 드러났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. 15:41 에 모니터링에서 다시 이상이 보였고, 15:42 에 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다.
- 조치
- Redis 연결 문제를 풀려고 14:11 PDT 에 모든 API 인스턴스를 롤링 재시작했다. 재시작은 14:15 에 끝났지만 API 지연은 계속 높았다.
- 비용이 큰 API 경로에 잘못 걸린 엣지 캐시 규칙을 고쳤다.
- 엔드포인트를 쓸 수 없는 동안에는 응답을 캐시할 수 없어서, 문제를 일으킨 API 엔드포인트를 상위 엣지 네트워크에서 막았다.
- 부하로 쓰러진 Cassandra 클러스터를 되살려 정상 서비스로 돌렸다.
- Cassandra 클러스터 문제로 생긴 지연을 풀려고 모든 API 인스턴스를 다시 롤링 재시작했다. 14:57 에 API 가 정상으로 돌아왔다.
- 15:50 PDT 에 이상하게 동작하는 "guilds" 노드를 서비스 해시링에서 강제로 빼서, 그 서버가 스스로 제대로 내려가기를 기대했다.
- 15:52 PDT 에 그 guilds 노드를 강제로 재시작했고, 재시작은 성공했다.
- 16:07 PDT 에 전체 서비스를 재시작하기로 하고, 모든 사용자를 다시 접속시켜 여러 서비스의 잘못된 상태를 초기화했다.
- "push" 구성 요소의 부하를 줄이려고 이 구성 요소에 기대는 트래픽 여러 갈래를 차단 목록에 넣었다.
- 사용자가 빠르고 안전하게 다시 접속하게 해 주는 API 설정이 사람의 실수로 잘못 들어가 있던 것을 고쳤다. 16:33 부터 서비스가 천천히 회복했다.
- 후속 조치
- Redis failover 의 알려진 문제를 고치는 일의 우선순위를 올려, 앞으로 몇 주 안에 끝내려 한다. 노드 하나의 장애로 문제가 더 생기지 않게 하려는 것이다.
- 캐시가 잘못 걸렸던 경로의 동작을 바꿔, 앞으로 이런 오류가 나도 다른 서비스를 망가뜨리지 않고 제대로 처리하게 했다.
- 연쇄 장애를 미리 알려 줄 수 있었던 신호 일부에 모니터링을 더했다. 엔지니어가 조사하고 대비할 시간을 벌려는 것이다.
- 이번 장애에 영향을 받은 서비스들의 전반적인 신뢰성과 장애 처리를 개선할 계획을 이어 간다.
- 문제가 된 서비스가 쓰는 라이브러리에서 결함으로 보이는 것을 찾았고, 이를 고칠 것으로 보는 업데이트를 배포하고 있다.
이 5건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.