사례6건
6건 중 1~5번째
- 증상
2026년 8월에 약 2주 동안 일부 PyPI 사용자가 files.pythonhosted.org 에서 파일을 받다가 간헐적으로 502 와 503 을 받았고, PyPI 에서 패키지를 설치하는 일이 실패했다. 사용자들이 지원 트래커에 보고를 올렸다.
- 촉발
Fastly 네트워크 안의 카나리 배포가 부분 롤백되면서 시애틀 근처 POP 한 곳의 캐시 설정은 되돌아갔고 그 앞의 라우팅 설정은 되돌아가지 않았다. PyPI 트래픽은 몇 년째 Fastly 의 카나리 집단에 들어 있었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
사용자들이 PyPI 지원 트래커에 보고를 올렸다. 8월 17일에 502 가 계속 난다는 첫 보고 두 건이 열렸고, 8월 19일의 보고가 실패한 응답의 x-served-by 헤더로 문제를 캐시 노드 하나로 좁혔다. 장애 전부터 5xx 소음이 많아 PyPI 자체 지표에서는 늘어난 양이 잘 드러나지 않았다.
- 조치
- Fastly 네트워크 운영팀이 PyPI 트래픽 일부를 문제의 POP 로 보내던 라우팅 재정의를 없앴다.
- infra#237 을 머지해 B2 가 오류로 답하지 않고 아예 답하지 않을 때도 S3 로 넘어가도록 대체 경로를 고쳤다.
- 한 클라이언트가 논리적으로 잘못된 범위를 보내 아침에 오류가 치솟은 뒤, infra#241 을 머지해 끝에서부터의 범위 요청과 여러 범위 요청을 segmented caching 에서 뺐다. 고장 난 병렬 다운로더 두 개가 같은 종류의 오류를 하루에 41,315건 더 만든 뒤 infra#243 도 머지했다.
- Fastly 가 자기 쪽의 카나리 설정 버그를 고쳤고, PyPI 를 포함한 PSF 트래픽 전부를 카나리 집단에서 뺐다.
- infra#245 를 머지해 segmented caching 예외 검사가 URL 정규화 뒤에 돌도록 순서를 고쳤다. 그 전에는 잘못된 segmented caching 응답이 캐시되어 같은 파일의 뒤 요청에 모두 나갔다.
- 후속 조치
- infra#238 을 머지해 파일 호스팅 서비스의 로그 설정을 개선했다.
- infra#239 를 머지해 파일 호스트에 올 이유가 없는 HTTP 메서드를 거부하게 했다.
- segmented caching 의 범위 처리 문제로 Fastly 에 지원 티켓을 열었다. 잘못된 클라이언트 요청에 501 을 내는 것은 틀린 상태 코드 계열이다. Fastly 가 고치면 PyPI 쪽의 처리 코드는 되돌릴 수 있을 것으로 본다.
- 이 트래픽을 통제하고 알림을 받는 방법이 더 분명해지면 Fastly 의 카나리 프로그램에 다시 참여한다.
- PSF 는 지금의 엔지니어 네 명에 더해 인프라 엔지니어 한 명을 뽑는다. 새 엔지니어는 PyPI 도 맡아 이런 상황을 더 일찍 잡고, 일이 난 뒤에 대응하기보다 미리 막을 수 있게 한다.
- 교훈
PyPI 자체 설정의 버그는 모두 새것이 아니었고 이미 설정 안에 있었다. 범위 요청으로 큰 파일을 받는 실제 트래픽이 생기고 나서야 이 버그들을 조사하고 고쳤다. 장애 전부터 5xx 소음이 많아서 8월 15일부터 늘어난 오류를 놓치기 쉬웠고, 배경 소음으로 여기던 오류 일부가 내내 이 버그였다. 글쓴이는 사용자가 문제를 피해 가지 않고 자세한 내용을 담아 보고해 준 덕분에 문제를 좁힐 수 있었다고 했다. 앞으로도 x-served-by 헤더와 시각을 담아 pypi/support 에 보고하면 더 빨리 대응할 수 있다. files.pythonhosted.org 트래픽의 많은 부분은 지난 실행과 같은 의존성을 다시 설치하는 CI 작업이고, 그중 큰 몫이 GitHub Actions 에서 온다. setup-python 의 pip, pipenv, poetry 캐시는 cache 입력으로 켜야 하고 기본값은 꺼짐이며, setup-uv 의 캐시는 GitHub 호스팅 러너의 대부분 이벤트에서 기본으로 켜져 있지만 확인해 보는 것이 좋다. 캐시된 의존성은 다음 실행에서 PyPI 에 닿지 않으므로 PyPI 나 Fastly 가 흔들릴 때 빌드가 깨질 일이 하나 줄어든다.
- 증상
미국 서부 리전에서, 처음에는 주로 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월에 끝낼 예정이다.
이 6건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.