사례8건

8건 중 5~8번째

1. IL-0378 Cloudflare R2 객체 스토리지에서 1시간 7분 동안 쓰기가 모두 실패하고 읽기가 전 세계에서 약 35% 실패했다

   Cloudflare2025

   증상

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 의 읽기와 쓰기 가용성 지표가 조금씩 계속 내려가고 있었다.

   자격 증명 획득 실패오류율 상승

   촉발

   R2 엔지니어링 팀이 R2 Gateway 서비스의 스토리지 인프라 자격 증명을 교체하면서 wrangler secret put 과 wrangler deploy 에 --env 인자를 빠뜨렸다. 새 자격 증명은 운영 Worker 가 아니라 기본 환경 Worker 에 들어갔고, 그 뒤 스토리지 인프라에서 옛 자격 증명을 지웠다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지

   기여 요인

   미검증 가정모니터링 사각지대늦게 드러난 변경

   감지

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 엔지니어링 팀은 운영 대시보드와 로그를 보기 시작했다.

   조치

   • 22:45 UTC 에 올바른 운영 R2 Gateway Worker 에 자격 증명을 배포했고, R2 가용성이 돌아왔다.

   후속 조치

   • R2 Gateway Worker 가 스토리지 인프라 인증에 쓰는 자격 증명 ID 의 끝자리를 로그 태그에 넣어, 어떤 자격 증명을 쓰는지 바로 확인할 수 있게 했다.
   • 옛 토큰을 지우기 전에 새 토큰 ID 의 끝자리가 스토리지 인프라 로그와 맞는지 반드시 확인하도록 내부 절차를 바꿨다.
   • 키 교체를 wrangler 명령을 손으로 치는 대신 핫픽스 배포 도구로만 하도록 했다. 이 도구는 환경 설정을 강제하고 다른 안전 검사도 한다.
   • 변경을 적어도 두 사람이 확인한다는 관행을 관련 표준 운영 절차에 명시했다.
   • 엔드포인트를 감시하는 기존 폐루프 상태 검사 시스템을 넓힌다. 이 시스템이 새 키를 시험하고, 그 상태를 알림 플랫폼으로 자동 보고하고, 게이트웨이 Worker 를 배포하기 전에 새 키가 전역으로 퍼졌는지 확인하게 한다.
   • 분산 스토리지 엔드포인트의 문제를 빨리 가려내도록, 관측 플랫폼에 캐시를 거치지 않은 업스트림 성공률 화면을 더한다.

   교훈

   이번 장애는 사람의 실수로 일어났고, R2 Gateway Worker 가 어떤 자격 증명으로 스토리지 인프라에 인증하는지 볼 수 없어서 더 길어졌다. Cloudflare 는 옛 자격 증명을 지운 뒤 가용성 지표에 기대지 말고, R2 Gateway 서비스가 실제로 어떤 토큰을 쓰는지 직접 확인했어야 했다고 적었다.

   사례 보기
2. IL-0343 digitaloceanspaces.com 도메인의 DNS 해석이 멈춰 DigitalOcean 의 Spaces, 컨테이너 레지스트리, App Platform, 로드 밸런서가 실패했다

   DigitalOcean2024

   증상

   2024년 11월 28일 22:38 UTC 부터 DigitalOcean 의 Cloud Control Panel 이 열리지 않았고, 고객은 가입하거나 로그인하지 못했다. 모니터링과 고객 신고로 장애가 선언됐고, 22:44 에 내부 알림이 문제를 잡았다.

   DNS 조회 실패오류율 상승이미지 풀 실패

   촉발

   도메인 등록 대행자 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 해석 문제로 생기는 장애를 더 빨리 알아채도록 모니터링과 알림을 검토한다.

   사례 보기
3. IL-0535 US-EAST-1 에서 AWS 내부용 Kinesis Data Streams 셀 하나가 느려져 CloudWatch Logs 와 이를 쓰는 여러 서비스의 지연과 오류가 늘었다

   Amazon Web Services2024

   증상

   2024-07-30 PDT 오후 2:45 부터 US-EAST-1 리전의 여러 AWS 서비스에서 지연과 오류율이 올랐다. CloudWatch Logs, Amazon Data Firehose, Amazon S3 이벤트를 게시하는 이벤트 프레임워크, Amazon ECS, AWS Lambda, Amazon Redshift, AWS Glue 가 영향을 받았다. 같은 리전의 다른 Kinesis Data Streams 셀로 가는 요청은 정상이었다.

   지연 시간 증가오류율 상승모니터링 중단프로브 실패

   촉발

   2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다.

   원인

   소프트웨어 결함

   구성 요소

   메시지 브로커서버리스 함수 플랫폼오브젝트 스토리지

   기여 요인

   스테이징 불일치자동화 증폭

   조치

   • PDT 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했다. 셀 관리 시스템이 처리할 데이터가 줄어 오후 5:39 에 오류율과 지연이 나아지기 시작했다.
   • 보안 연결을 만드는 하위 시스템에 용량을 더해 셀 관리 시스템의 상태를 되살렸다. 오후 5:55 에 셀 관리 시스템이 Kinesis 요청 처리에 쓰는 보안 연결을 제대로 맺었다.
   • 오후 6:32 에 연결 프로비저닝을 더 나아지게 하려고 용량을 더 늘렸고, 오류율이 더 내려갔다.

   후속 조치

   • 장애 중에 한 변경을 US-EAST-1 에 그대로 남긴다. 데이터 플레인 연결을 만드는 용량을 늘리고, 부하를 덜어 내는 도구를 운영에 넣고, 연결 한도를 바꾼 것이 여기에 든다.
   • 새 Kinesis Data Streams 아키텍처의 셀이 있는 다른 모든 AWS 리전에도 같은 변경을 이미 적용했다.
   • 이번 장애를 일으킨 워크로드를 더 잘 다루도록 셀 관리 시스템을 더 고친다.

   사례 보기
4. IL-0382 Newark 와 Atlanta 의 Linode Object Storage 가 느려지고 모든 클라이언트에 503 - Slow Down 으로 응답했다

   Linode2022

   증상

   10월 19일과 20일 Newark 와 Atlanta 데이터 센터의 Linode Object Storage 에서 성능과 가용성이 떨어졌다. 고객은 “503 - Slow Down” HTTP 응답 코드로 나타나는 속도 제한을 더 많이 받았다.

   오류율 상승메모리 압박

   촉발

   10월 19일과 20일 Newark 와 Atlanta 의 Object Storage 클러스터로 요청 수와 처리량이 모두 아주 높은 트래픽이 들어왔다.

   원인

   용량 한계

   구성 요소

   오브젝트 스토리지

   기여 요인

   미패치 알려진 버그과도한 영향 범위

   조치

   • Object Storage 클러스터 경계의 속도 제한을 고쳐 공개한 한도인 버킷당 초당 750 요청을 정확히 지키게 했다. 이전에는 클라이언트가 이 값보다 훨씬 많은 I/O 를 할 수 있었다.
   • 일부 내부 Object Storage 인프라에서 메모리를 지나치게 쓰게 하던 Ceph 버그를 해결하고, 하드웨어나 네트워크 고장 뒤 클러스터 복구 같은 스토리지 압박 상황에서 메모리가 폭주하지 않게 설정 값을 조정했다.
   • 자원 경합을 겪던 내부 Object Storage 구성 요소를 덜 붐비고 더 안정적이며 성능이 더 높은 인프라로 옮겼다.
   • 내부 Object Storage 구성 요소와 백엔드 클러스터의 성능 설정 값 몇 개를 조정해 고객을 너무 일찍 속도 제한하지 않게 했다.

   후속 조치

   • 처리량 제한을 더 세밀하게 만든다.
   • 부하를 더 효율적으로 나누도록 내부 Object Storage 인프라를 키운다.
   • 내부 Object Storage 인프라의 하드웨어 성능을 더 높일 방법을 찾는다.
   • 클러스터에 부하가 한곳에 몰리지 않도록 부하 분산 알고리즘을 다듬는다.

   교훈

   백엔드 속도 제한은 한번 걸리면 공개한 한도를 넘지 않은 클라이언트까지 모든 클라이언트에 영향을 준다. Linode 는 버킷당 프런트엔드 속도 제한이 뜻한 대로 동작한다면 클라이언트를 가리지 않는 이런 백엔드 제한은 아예 걸리지 않아야 한다고 봤고, 그래서 백엔드 설정 값을 바꿨다.

   사례 보기

원인별6