사례6건

6건 중 3~6번째

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

   사례 보기
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-0339 Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다

   Microsoft Azure2024

   증상

   2024년 7월 30일 11시 45분 UTC 부터 Azure Front Door 와 Azure CDN 을 거치는 Microsoft 서비스에 접속하던 일부 고객이 간헐적인 연결 오류, 타임아웃, 지연 급증을 겪었다. 11시 47분에 Azure Portal 팀이 먼저 서비스 성능 저하를 알아챘다.

   간헐적 연결 실패간헐적 타임아웃지연 시간 증가패킷 손실

   촉발

   Azure 네트워크 DDoS 보호 서비스가 TCP SYN flood DDoS 공격을 자동으로 막은 뒤 트래픽을 Azure Front Door 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.

   원인

   설정 변경

   구성 요소

   CDN 과 엣지 네트워크DDoS 방어 서비스네트워크 컨트롤 플레인데이터센터 전력·냉각

   기여 요인

   장애 중첩과도한 영향 범위모니터링 사각지대

   감지

   장애가 시작되고 2분 뒤인 11시 47분 UTC 에 Azure Portal 팀이 서비스 성능 저하를 알아채고 조사를 시작했다. 12시 10분에 네트워크 모니터링이 이 포털 장애를 유럽의 한 사이트에서 난 네트워크 문제와 연결 지었다.

   조치

   • 12시 55분 UTC 에 국지적인 혼잡을 확인하고, 트래픽 경로 변경을 포함한 혼잡 완화용 표준 플레이북을 실행했다. 13시 58분에 영향 대부분이 사라졌다.
   • 16시 58분, 네트워크 컨트롤 플레인이 명령을 다시 내리게 했지만 문제의 장비에는 명령이 닿지 않았다.
   • 17시 50분부터 문제의 장비를 네트워크에서 안전하게 빼면서 다른 문제가 없는지 네트워크를 훑었다. 장비는 19시 32분에 다 뺐다.

   후속 조치

   • 한 지역의 DDoS 완화 문제가 다른 지역으로 번지지 않도록, 네트워크 장비에 빠져 있던 설정을 넣었다. 이 일은 끝났다.
   • 잘못된 설정을 찾아내도록 Azure 네트워크의 기존 검증과 모니터링을 강화한다. 2024년 11월에 끝낼 예정이다.
   • DDoS 보호 서비스가 컨트롤 플레인에서 닿지 않는데도 트래픽을 계속 받는 상황을 잡아내도록 모니터링을 개선한다. 2024년 11월에 끝낼 예정이다.

   사례 보기
4. IL-0388 Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다

   Discord2017

   증상

   2017년 10월 13일 14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. API 서비스가 쓰는 Redis 고가용 클러스터에서 primary 노드가 완전히 사라졌다. 클러스터는 secondary 노드로 제대로 failover 했지만, 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다.

   장애 조치 실패지연 시간 증가서비스 중단

   촉발

   14:01 PDT 쯤 Google Cloud Platform 이 API 서비스용 Redis 고가용 클러스터의 primary 인스턴스를 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 되면서 클러스터가 재조정됐고, API 인스턴스의 Redis failover 처리에 있던 알려진 문제가 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   인메모리 캐시데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미패치 알려진 버그장애 중첩모니터링 사각지대

   감지

   14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. 15:41 에 모니터링에서 다시 이상이 보였고, 15:42 에 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다.

   조치

   • Redis 연결 문제를 풀려고 14:11 PDT 에 모든 API 인스턴스를 롤링 재시작했다. 재시작은 14:15 에 끝났지만 API 지연은 계속 높았다.
   • 비용이 큰 API 경로에 잘못 걸린 엣지 캐시 규칙을 고쳤다.
   • 엔드포인트를 쓸 수 없는 동안에는 응답을 캐시할 수 없어서, 문제를 일으킨 API 엔드포인트를 상위 엣지 네트워크에서 막았다.
   • 부하로 쓰러진 Cassandra 클러스터를 되살려 정상 서비스로 돌렸다.
   • Cassandra 클러스터 문제로 생긴 지연을 풀려고 모든 API 인스턴스를 다시 롤링 재시작했다. 14:57 에 API 가 정상으로 돌아왔다.
   • 15:50 PDT 에 이상하게 동작하는 "guilds" 노드를 서비스 해시링에서 강제로 빼서, 그 서버가 스스로 제대로 내려가기를 기대했다.
   • 15:52 PDT 에 그 guilds 노드를 강제로 재시작했고, 재시작은 성공했다.
   • 16:07 PDT 에 전체 서비스를 재시작하기로 하고, 모든 사용자를 다시 접속시켜 여러 서비스의 잘못된 상태를 초기화했다.
   • "push" 구성 요소의 부하를 줄이려고 이 구성 요소에 기대는 트래픽 여러 갈래를 차단 목록에 넣었다.
   • 사용자가 빠르고 안전하게 다시 접속하게 해 주는 API 설정이 사람의 실수로 잘못 들어가 있던 것을 고쳤다. 16:33 부터 서비스가 천천히 회복했다.

   후속 조치

   • Redis failover 의 알려진 문제를 고치는 일의 우선순위를 올려, 앞으로 몇 주 안에 끝내려 한다. 노드 하나의 장애로 문제가 더 생기지 않게 하려는 것이다.
   • 캐시가 잘못 걸렸던 경로의 동작을 바꿔, 앞으로 이런 오류가 나도 다른 서비스를 망가뜨리지 않고 제대로 처리하게 했다.
   • 연쇄 장애를 미리 알려 줄 수 있었던 신호 일부에 모니터링을 더했다. 엔지니어가 조사하고 대비할 시간을 벌려는 것이다.
   • 이번 장애에 영향을 받은 서비스들의 전반적인 신뢰성과 장애 처리를 개선할 계획을 이어 간다.
   • 문제가 된 서비스가 쓰는 라이브러리에서 결함으로 보이는 것을 찾았고, 이를 고칠 것으로 보는 업데이트를 배포하고 있다.

   사례 보기

원인별4