Incident Library

IL-0515 Python Software Foundation · 2026-08-15networking

files.pythonhosted.org 에서 파일을 받을 때 2주 가까이 502 와 503 이 간헐적으로 나서 PyPI 설치가 실패했다

files.pythonhosted.org 는 세 오리진 앞에 둔 Fastly CDN 서비스다. 패키지 파일 요청은 먼저 Backblaze B2 로 가고, B2 가 답하지 않거나 예상 밖의 답을 하면 S3 로 넘어간다. 패키지 파일이 아닌 요청은 Conveyor 가 맡는다. Fastly 의 카나리 집단은 전체 배포 전에 캐시와 라우팅 소프트웨어를 먼저 받는 일부 장비이고, PyPI 트래픽은 몇 년째 여기에 들어 있었다. 카나리 배포 중 부분 롤백으로 시애틀 근처 POP 하나의 캐시 설정만 되돌아가고 라우팅 설정은 그대로 남아, 그 라우팅 계층이 캐시 노드로 가는 트래픽에 502 를 냈다. Fastly 는 이 문제가 8월 15일에 시작됐다고 봤다.

8월 17일부터 사용자 보고가 쌓였고, 8월 19일의 보고가 문제를 캐시 노드 cache-pae2080020 하나로 좁혔다. 같은 날 Fastly 네트워크 운영팀이 PyPI 트래픽 일부를 그 POP 로 보내던 라우팅 재정의를 없앴고, 8월 20일에 그 POP 의 회복을 확인했다. 8월 28일 Fastly 는 카나리 설정 버그를 고치고 PyPI 를 포함한 PSF 트래픽 전부를 카나리 집단에서 뺐다.

조사 중에 PyPI 자체 Fastly 설정에서 오래된 버그 셋이 같은 증상을 만들고 있었다는 것이 드러났다. 첫째, S3 로 넘기는 대체 경로는 B2 가 오류 상태 코드로 답할 때만 돌았고, B2 가 타임아웃, 연결 거부, TLS 실패로 아예 답하지 않으면 Fastly 가 스스로 503 을 만들었다. 이는 8월 18일 infra#237 로 고쳤다. 둘째, 큰 wheel 파일을 통째로 캐시에 올리지 않으려고 쓰는 segmented caching 이 bytes=-1024 같은 끝에서부터의 범위와 시작이 파일 끝을 넘는 범위를 처리하지 못하고 501 을 냈다. 일부 설치 도구는 wheel 메타데이터를 이런 범위로 읽으므로 그 읽기가 실패했다. 이는 infra#241 과 infra#243 으로 고쳤다. 셋째, segmented caching 예외 검사가 URL 정규화 전에 돌아 쿼리 문자열이 붙은 .metadata 요청에서 예외가 맞지 않았고, 잘못된 501 응답이 캐시되어 같은 파일의 뒤 요청에 모두 나갔다. 이는 8월 28일 infra#245 로 고쳤다. 8월 28일부터 다운로드는 완전히 정상으로 돌아왔다. infra#241 뒤의 오류 양은 장애 전 기준선보다 두세 자릿수 낮아서, 배경 소음으로 여기던 오류 가운데 일부가 내내 이 버그였다.

심각도
–
영향 범위
Downloads from files.pythonhosted.org and therefore installations from PyPI
영향 사용자
some PyPI users
지역
Seattle-area Fastly point of presence for the Fastly fault
감지까지
2d
복구까지
13d

증상

2026년 8월에 약 2주 동안 일부 PyPI 사용자가 files.pythonhosted.org 에서 파일을 받다가 간헐적으로 502 와 503 을 받았고, PyPI 에서 패키지를 설치하는 일이 실패했다. 사용자들이 지원 트래커에 보고를 올렸다.

8월 17일에 files.pythonhosted.org 에서 502 가 계속 난다는 첫 보고 두 건이 열렸다. 8월 18일의 보고는 6시간 동안 서로 관계없는 패키지 32개에서 502 를 88번 기록했고, 설치 도구가 PEP 658 메타데이터를 읽으려고 보내는 작은 .whl.metadata 범위 요청도 그 안에 있었다.

PyPI 인프라 엔지니어가 Datadog Logs 에서 이 보고에 맞는 PyPI Files 오류를 뒤졌지만 의미 있는 것은 나오지 않았다. 장애 전부터 5xx 가 수천에서 수만 건씩 나는 배경 소음이 있어서, 8월 15일부터 늘어난 양은 알아채기 어려웠다. Fastly 의 실시간 분석에서는 8월 15일부터 B2 오류가 늘었지만 S3 백엔드는 0 에 머물렀다. 실패를 S3 로 넘겨야 할 대체 경로가 작동하지 않았기 때문이다.

8월 19일의 보고가 문제를 Fastly 캐시 노드 cache-pae2080020 하나로 좁혔다. 이 노드로 간 요청은 19시간 넘게 모두 502 를 받았고, 실패한 응답의 x-served-by 헤더가 이를 확인해 줬다.

PyPI 자체 Fastly 설정의 버그도 같은 증상을 만들고 있었다. 502 가 늘었고, 몇몇 경우에는 밖에서 502 처럼 보이는 501 이 났다. 8월 21일 아침에는 논리적으로 잘못된 범위를 보내는 클라이언트 하나 때문에 5xx 가 백만 건 가까이 치솟았다. 8월 24일에는 고장 난 병렬 다운로더 두 개가 하루에 같은 종류의 오류를 41,315건 더 만들었다.

증상 오류율 상승

원인

원인 의존성 장애

구성 요소 CDN 과 엣지 네트워크오브젝트 스토리지
기여 요인 부분 배포장애 중첩잡음에 묻힌 신호
촉발
Fastly 네트워크 안의 카나리 배포가 부분 롤백되면서 시애틀 근처 POP 한 곳의 캐시 설정은 되돌아갔고 그 앞의 라우팅 설정은 되돌아가지 않았다. PyPI 트래픽은 몇 년째 Fastly 의 카나리 집단에 들어 있었다.

감지

사용자들이 PyPI 지원 트래커에 보고를 올렸다. 8월 17일에 502 가 계속 난다는 첫 보고 두 건이 열렸고, 8월 19일의 보고가 실패한 응답의 x-served-by 헤더로 문제를 캐시 노드 하나로 좁혔다. 장애 전부터 5xx 소음이 많아 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 가 흔들릴 때 빌드가 깨질 일이 하나 줄어든다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: CDN 과 엣지 네트워크, 오브젝트 스토리지. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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