사례7건

7건 중 1~5번째

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

   Python Software Foundation2026

   증상

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

   오류율 상승

   촉발

   Fastly 네트워크 안의 카나리 배포가 부분 롤백되면서 시애틀 근처 POP 한 곳의 캐시 설정은 되돌아갔고 그 앞의 라우팅 설정은 되돌아가지 않았다. PyPI 트래픽은 몇 년째 Fastly 의 카나리 집단에 들어 있었다.

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   부분 배포장애 중첩잡음에 묻힌 신호

   감지

   사용자들이 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 가 흔들릴 때 빌드가 깨질 일이 하나 줄어든다.

   사례 보기
2. IL-0438 CloudFront VPC Origins 장애로 Builder Work 가 504 오류를 내며 거의 모든 접속이 막혔다

   ANDPAD2026

   증상

   2026년 7월 16일 17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 CloudFront 에서 VPC Origins 연결을 쓰는 배포에 5xx 오류가 늘기 시작했다. CloudFront 자체는 정상으로 돌았지만 VPC Origins 기능에만 장애가 나서 504 Gateway Time-out 이 잇따랐다.

   서비스 중단오류율 상승

   촉발

   CloudFront 의 VPC Origins 연결을 관리하는 AWS 내부 공유 서브시스템에서 용량 제약이 생겼다.

   원인

   클라우드 제공자 장애

   구성 요소

   CDN 과 엣지 네트워크클라우드 로드 밸런서인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   단일 장애점

   감지

   17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 VPC Origins 연결을 쓰는 CloudFront 배포에서 5xx 오류가 늘고 있는 것을 알았다.

   조치

   • CloudFront 의 오리진이 VPC Origins 하나뿐이었으므로, CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하도록 임시로 바꾸기로 했다.
   • VPC Origins 도입 때 지운 Internet-facing Ingress 를 다시 만들고, Argo Rollouts 의 Rollout 리소스에 묶은 뒤 promote 했다.
   • 기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 ALB 용 리전 WAF 를 따로 만들었다.
   • ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 를 새로 만들었다.
   • 일반 트래픽용, Cognito 인증과 VPN 접근 제한을 건 관리 화면용, 리다이렉트용 Ingress 를 더해 라우팅을 되살렸다.

   후속 조치

   • VPC Origins 와 CloudFront 구성으로 돌아가면서, 다음 장애에 대비해 Internet-facing 으로 바꾸는 수단을 코드에 넣어 둔다.
   • 복구 때 만든 Internet-facing ALB 를 남기고, AWS Load Balancer Controller 의 IngressClassParams spec.inboundCIDRs 로 Security Group 인바운드를 사내 CIDR 과 제한 공개용 CIDR 에만 허용한다. values.yaml 의 securityGroupInboundCidrs 를 주석 처리하면 inboundCIDRs 가 빠져 0.0.0.0/0 으로 열리게 했다.
   • Terraform 으로 관리하는 Route53 A 레코드를 CloudFront 로 되돌렸다. ALB 로 가는 별칭 설정 route53_alias_name 은 주석 처리한 채 코드에 남겨, 주석을 풀고 apply 하면 Route53 을 ALB 로 돌릴 수 있게 했다.

   교훈

   VPC Origins 는 ALB 를 Private 서브넷에 두어 인터넷에서 오는 직접 접근을 막고 통신 경로를 단순하게 해 운영 부담을 줄인다. 그 대신 CloudFront 와 오리진 사이의 통신이 AWS 가 관리하는 공유 서브시스템을 거치므로, 그 서브시스템이 망가지면 CloudFront 전체가 정상이어도 통신이 끊긴다. ANDPAD 는 VPC Origins 의 이점을 버리지 않고 장애 때 쓸 우회 경로를 미리 마련해, 다음에 같은 위험이 드러날 때의 대응 비용을 낮추기로 했다. 상시 켜 둔 ALB 의 유지 비용은 치르지만, 이번에 Ingress 재생성과 Rollout 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다.

   사례 보기
3. IL-0283 Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다

   Cloudflare2025

   증상

   11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.

   오류율 상승서비스 중단지연 시간 증가응답 품질 저하

   촉발

   11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.

   원인

   설정 변경

   구성 요소

   데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미검증 가정부분 배포단계적 배포 부재설정 테스트 부재장애 중첩재시도 폭주

   감지

   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 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
   • 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
   • 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
   • 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.

   사례 보기
4. IL-0357 Vercel CDN 의 전역 캐시 일부를 잃어 정적 파일 요청이 최대 약 22% 실패했다

   Vercel2025

   증상

   2025-10-20 07:45 UTC 부터 Vercel CDN 의 정적 파일 제공이 실패하기 시작했고, 실패는 최대 트래픽의 약 22% 에 이르렀다. 이 시간대가 그날 사고 전체에서 피해가 가장 컸다.

   오류율 상승

   촉발

   Vercel 이 iad1 이라 부르는 AWS us-east-1 리전에 예상치 못한 장애가 났다. 이 리전을 잃은 뒤 07:45 UTC 에 연쇄 장애가 일어나 Vercel 의 전역 캐시 인프라 일부가 사라졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   –

   감지

   06:55 UTC 에 Vercel 서비스 전반의 오류로 첫 자동 알림이 울렸고, 사고가 자동으로 만들어져 당직 엔지니어가 호출됐다. 이 알림은 us-east-1 장애가 시작될 때 울린 것으로, 캐시 장애가 시작되기 50분 전이었다.

   조치

   • 07:15 UTC 에 iad1 의 트래픽을 이웃 데이터센터로 옮기기로 했고, 07:20 에 단계적으로 옮기기 시작해 07:44 에 마쳤다.
   • 07:25 UTC 부터 백업 리전이나 보조 리전을 설정한 고객의 함수 호출을 다른 리전으로 돌려 그 고객들의 서비스를 모두 되살렸다.
   • 08:18 UTC 에 서비스를 복구했고, 이 연쇄 장애의 근본 원인을 완화했다.

   후속 조치

   • 이번 장애로 드러난 장애 모드를 체계적으로 막을 수 있도록 아주 자세한 기술 포스트모템을 쓴다.
   • 큰 리전 장애를 미리 연습하는 훈련을 이어 가고 더 강화한다.

   사례 보기
5. IL-0555 한 수집 리전에 밀린 트래픽이 다른 엣지 리전으로 번져 Sentry US 의 이벤트 수집이 트래픽을 거부했다

   Sentry2024

   증상

   2024년 10월 4일, 16일, 21일에 Sentry 의 이벤트 수집에서 오류가 늘었다. 수집 리전 하나에 밀린 트래픽이 쌓였고, 그 리전에서 빠져나간 트래픽을 받은 다른 리전에도 트래픽이 밀려 쌓이면서 트래픽이 거부됐다.

   오류율 상승서비스 중단오토스케일러 오동작

   촉발

   세 사고는 계기가 각각 달랐지만, 세 번 모두 수집 리전 하나에서 밀린 트래픽이 늘어나면서 시작했다.

   원인

   용량 한계

   구성 요소

   CDN 과 엣지 네트워크자동 용량 관리 시스템

   기여 요인

   자동화 증폭과도한 영향 범위

   후속 조치

   • 연쇄 장애의 가능성을 줄이려고 엣지 리전을 더 작게 더 많이 만들었다. 남아메리카에 첫 리전을 열고, 북아메리카와 유럽에는 하나씩이던 리전을 둘로 늘려 모두 세 리전을 더했다.
   • 오토스케일링 규칙이 원래의 CPU 부하 지표보다 더 강한 신호를 잡도록 바꿨다.
   • iowait 때문에 요청이 밀릴 때 축소가 일어나지 않도록 축소 속도를 낮췄다.
   • 오토스케일링 규칙과 민감도를 더 다듬을 수 있도록 엣지가 내는 지표를 개선한다.

   사례 보기

원인별6