사례2건

2건 중 1~2번째

1. IL-0240 인증 데이터베이스가 과부하에 걸려 Cloudflare API 와 대시보드가 6시간 33분 동안 실패하고 느려졌다

   Cloudflare2020

   증상

   14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.

   오류율 상승지연 시간 증가데이터베이스 과부하쓰기 거부패킷 손실

   촉발

   14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.

   원인

   DNS·네트워크 장애

   구성 요소

   NIC·케이블·스위치 포트 링크코디네이션 키-값 저장소데이터베이스 장애 조치 관리자데이터베이스데이터베이스 복제

   기여 요인

   자동화 증폭여유 용량 부재수동 조치 악화

   감지

   14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.

   조치

   • SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 주 인증 데이터베이스가 늘어난 부하를 감당할 여유를 만들었다.
   • 읽기 복제본으로 처리할 수 있는 API 트래픽을 손으로 보조 데이터 센터로 돌렸다. API 가용성이 크게 나아졌다.
   • 대시보드 사용자의 불편이 커지자 인증 호출을 모두 주 데이터 센터로 되돌렸고, 성능이 떨어진 상태에서도 최대한 버티도록 주 데이터베이스를 계속 손봤다.
   • 21:20 UTC 에 첫 데이터베이스 복제본이 다시 만들어지자마자 자동으로 서비스에 투입됐고, 성능이 정상으로 돌아왔다.
   • 줄였던 서비스를 모두 다시 올려 밀린 비동기 처리가 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다.

   후속 조치

   • 새 primary 를 승격하면 데이터베이스 복제본을 모두 다시 만들어야 하는 클러스터 관리 시스템의 제약을 고친다. Cloudflare 는 글을 쓸 무렵 이 결함을 이미 고쳤다고 밝혔다.
   • 트래픽을 다른 데이터 센터로 돌려야 할 때 유연하게 대응하지 못하는 사용자 세션 시스템을 다시 설계한다.
   • 자동 복구 조치의 설정 값을 다시 검토한다. 적어도 데이터베이스 하나에서는 복제본을 primary 로 승격하는 절차를 그렇게 빨리 시작하지 않도록 장애 직후 설정을 바꿨다.
   • 이 장애에 얽힌 시스템마다 자기가 의존하는 시스템의 고장을 더 잘 견디도록 계속 조정한다.

   교훈

   모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.

   사례 보기
2. IL-0590 Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다

   Mailgun2014

   증상

   2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.

   간헐적 연결 실패간헐적 타임아웃패킷 손실

   촉발

   Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다.

   원인

   DNS·네트워크 장애

   구성 요소

   클라우드 로드 밸런서데이터베이스 복제

   기여 요인

   –

   감지

   9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다.

   조치

   • Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다.
   • Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다.
   • Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다.

   후속 조치

   • Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다.
   • 근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다.

   사례 보기

원인별1