사례2건
2건 중 1~2번째
- 증상
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 가 흔들릴 때 빌드가 깨질 일이 하나 줄어든다.
IL-0343digitaloceanspaces.com 도메인의 DNS 해석이 멈춰 DigitalOcean 의 Spaces, 컨테이너 레지스트리, App Platform, 로드 밸런서가 실패했다DigitalOcean2024- 증상
2024년 11월 28일 22:38 UTC 부터 DigitalOcean 의 Cloud Control Panel 이 열리지 않았고, 고객은 가입하거나 로그인하지 못했다. 모니터링과 고객 신고로 장애가 선언됐고, 22:44 에 내부 알림이 문제를 잡았다.
- 촉발
도메인 등록 대행자 Network Solutions 가 11월 28일 22:38 UTC 에 digitaloceanspaces.com 도메인에 Extensible Provisioning Protocol, 곧 EPP 의 clientHold 상태 코드를 잘못 걸었다. 이 코드는 고객이 Network Solutions 에 연락해 풀기 전까지 DNS 해석을 막는다.
- 원인
- 구성 요소
- 기여 요인
- 감지
22:38 UTC 에 Cloud Control Panel 이 열리지 않는다는 모니터링과 고객 신고로 장애가 선언됐다. 22:44 에 내부 알림이 문제를 잡았고, 22:57 에 Cloud Control Panel 영향을 알리는 첫 고객 연락이 들어왔다.
- 조치
- Cloud Control Panel 을 다시 살리는 조치를 배포해 01:42 UTC 에 기능을 되살렸다. 사용자에게는 페이지를 몇 번 새로 고쳐 캐시를 비우라고 안내했다.
- 01:08 UTC 에 Network Solutions 에 연락해 clientHold 를 풀어 달라고 요청했다.
- 02:44 부터 04:03 UTC 까지 Verisign 임원진에게 여러 차례 에스컬레이션했고, 04:03 에 도메인의 clientHold 가 풀렸다.
- 후속 조치
- Network Solutions 와 함께 그쪽에서 무슨 일이 있었기에 도메인에 clientHold 가 잘못 걸렸는지 알아낸다.
- DigitalOcean 도메인을 옮길 곳으로 다른 도메인 등록 대행자들을 검토한다.
- 등록 대행자가 건 변경과 DNS 해석 문제로 생기는 장애를 더 빨리 알아채도록 모니터링과 알림을 검토한다.
이 2건에서 가장 많이 나오는 구성 요소: 오브젝트 스토리지, CDN 과 엣지 네트워크. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.