사례4건

4건 중 1~4번째

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-0257 한꺼번에 몰린 요청에 API Gateway 태스크가 모두 OOM 으로 종료돼 canva.com 이 약 50분 동안 열리지 않았다

   Canva2024

   증상

   2024년 11월 12일 8:47 AM UTC 에 편집기 새 버전을 배포한 뒤, 아시아의 많은 사용자에게 편집기의 객체 패널이 끝없이 로딩 상태로 남았다. 9:08 AM UTC 부터는 canva.com 자체가 열리지 않았다.

   서비스 중단OOMKilled지연 시간 증가패킷 손실

   촉발

   2024년 11월 12일 8:47 AM UTC 에 Canva 편집기 새 버전이 배포돼 클라이언트들이 새 정적 자산을 받기 시작했다. 같은 시각 Cloudflare 의 싱가포르와 애슈번 사이 경로에서 패킷이 손실돼 JavaScript 파일 하나의 전송이 20분 동안 끝나지 않았다.

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크API 게이트웨이Amazon ECS

   기여 요인

   장애 중첩모니터링 사각지대재시도 폭주자동화 증폭미패치 알려진 버그

   조치

   • 임시 Cloudflare 방화벽 규칙을 넣어 CDN 에서 모든 트래픽을 막고, 새 API Gateway 태스크가 요청을 받지 않은 상태에서 뜨게 했다.
   • canva.com 을 상태 페이지로 돌려 사용자에게 장애 중임을 알렸다.
   • 엄격한 속도 제한을 건 오스트레일리아 사용자부터 시작해 canva.com 트래픽을 조금씩 되살렸다.

   후속 조치

   • 트래픽을 세밀하게 돌리고 막은 뒤 단계적으로 다시 늘리는 내부 런북을 만든다.
   • canva.com 을 쓸 수 없을 때 사용자에게 더 자세한 오류 페이지를 보여 준다.
   • API Gateway 의 기본 태스크 수와 태스크 하나에 주는 메모리를 늘린다.
   • 비슷한 트래픽 패턴에서 실패할 위험을 줄이는 부하 차단 규칙을 API Gateway 에 더한다.
   • API Gateway 에 정기 부하 테스트를 들인다.
   • 텔레메트리 라이브러리의 스레드 잠금 버그를 고치는 패치를 배포한다.
   • 텔레메트리 라이브러리의 마이크로벤치마크 테스트에 스레드 경합을 일으킨 코드 경로의 멀티스레드 테스트를 더한다.
   • 페이지 자산 카나리 릴리스에서 JavaScript 오류율에 더해 페이지 로드 완료 이벤트를 보조 지표로 본다.
   • 카나리에 롤아웃 단계를 하나 더 두어 단계적 배포 중 문제를 찾을 시간을 늘리는 실험을 한다.
   • 사용자 요청이 자산을 너무 오래 기다리지 않도록 자산 받기에 타임아웃을 둔다.
   • Cloudflare 와 함께 이번 사고에서 여러 시스템이 어떻게 얽혀 작용했는지 자세히 파악한다.

   사례 보기
3. IL-0267 싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다

   Wikimedia Foundation2023

   증상

   16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태가 CRITICAL 이라고 알렸고, 몇 분 뒤 eqsin 의 호스트들이 한꺼번에 DOWN 으로 떴다. 호출 알림 세 건이 동시에 울렸고 그중 두 건은 batphone 으로 올라갔다.

   네트워크 도달 불가

   촉발

   eqsin 을 코어 데이터센터에 잇는 전송 회선 두 개 중 하나는 오래 이어진 광케이블 절단으로 끊겨 있었다. 남은 하나가 전송 회선 공급사 Arelion 의 계획 작업 PWIC225900 으로 내려갔다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   단일 장애점초기 신호 무시

   감지

   자동 모니터링이 먼저 잡았다. 16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태 CRITICAL 을 알렸고, 이어서 cr2-eqsin 의 BGP 상태와 eqsin 호스트들의 DOWN 알림이 울렸다. 호출 알림 세 건이 동시에 울렸고 그중 두 건이 batphone 으로 올라갔다.

   조치

   • 16시 48분 UTC 에 eqsin 을 DNS 에서 뺐다.
   • 나중에 eqsin 을 다시 DNS 에 넣었다.

   후속 조치

   • 백업 GRE 터널을 만든다. 작업은 T327265 이다.
   • 오래 끊겨 있던 전송 회선이 수리된 뒤 제대로 다시 올라오는지 확인한다. 작업은 T322529 이다.
   • 공급사의 점검 알림을 자동으로 읽어 들여 점검 일정이 서로 겹치면 알린다. 작업은 T230835 이다.

   교훈

   eqsin 을 DNS 에서 빨리 뺀 것이 잘됐고, 먼저 빼고 나중에 조사한다는 태도가 맞았다. 잘못된 것은 세 가지였다. eqsin 이 너무 오래 전송 회선 하나로만 버텼다. 두 전송 회선이 겹쳐서 내려가는 것을 SRE 들이 잡지 못했다. 공급사의 계획 작업이 작업 티켓이나 알림으로 남지 않았다. 알림은 맞게 울렸지만 IRC 에서 감당하기 어려울 만큼 많았다.

   사례 보기
4. IL-0398 GOV.UK 가 쓰는 주 CDN 에 전 세계 장애가 나서, 1시간이 안 되는 동안 GOV.UK 방문자가 오류 페이지만 봤다

   Government Digital Service2021

   증상

   2021년 6월 8일 1시간이 안 되는 동안 GOV.UK 방문자가 정보와 서비스에 접근하지 못하고 오류 페이지를 봤다. 팀은 장애가 시작되고 4분 뒤에 알아챘다.

   서비스 중단

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   –

   감지

   장애는 시작되고 4분 뒤에 감지됐다. 팀은 장애 책임자를 정했고, 장애 책임자는 커뮤니케이션 책임자와 함께 공식 장애 대응 절차를 시작했다.

   조치

   • 감지하고 15분이 지나도 상태가 바뀌지 않자 보조 CDN 으로 페일오버하기로 했다.
   • 30분 안에 DNS 레코드 변경을 배포했고, 트래픽이 보조 CDN 으로 가기 시작했다.
   • 주 CDN 이 회복되는 것을 몇 분 지켜본 뒤 주 CDN 으로 되돌렸고, 1시간을 더 지켜본 뒤 장애 종료를 선언했다.

   후속 조치

   • 공식 장애 리뷰를 열어 무슨 일이 있었는지, 대응이 어땠는지, 다음에 더 잘하려면 무엇을 해야 하는지 논의한다.
   • 장애 중에 더 빠르고 투명하게 소통할 방법을 검토한다.
   • 이미 계획한 플랫폼 기술과 절차의 변경으로 앞으로 장애가 났을 때 더 빨리 복구할 수 있는 방법을 검토한다.

   교훈

   어떤 인프라도 100% 믿을 수는 없고, 네트워크 엣지에 있는 CDN 이 망가지면 사이트 전체가 내려가므로 예비 계획이 있어야 한다고 팀은 말했다. 보조 CDN 으로는 기능이 줄어든 서비스만 할 수 있어서 페일오버는 큰 결정이고, 주 CDN 장애가 빨리 끝나면 너무 이른 페일오버가 오히려 장애를 키울 수 있다고 했다. 이런 장애에서는 침착하게, 목적을 분명히 하고 움직이는 것이 중요하다고 했다. 방문자가 본 오류 페이지는 GOV.UK 가 손댈 수 없는 페이지였고, 아무 정보도 주지 못해 GOV.UK 의 콘텐츠 기준에 크게 못 미쳤다고 했다.

   사례 보기

원인별1