사례11건

11건 중 6~10번째

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-0486 Figma의 PostgreSQL 데이터베이스에서 쓰기 IOPS와 락 경합이 치솟아 서비스가 하루 동안 여러 번 내려갔다

   Figma2020

   증상

   2020-01-22 오전 9시 45분 PST부터 데이터베이스 지표에서 쓰기 IOPS와 락 경합이 늘었다. 전날 사고와 달리 데이터베이스 CPU는 평소보다 낮았다. 오전 10시에 자동 알림이 왔고, 일부 사용자는 Figma를 불러오지 못했다.

   잠금 경합과 교착데이터베이스 과부하서비스 중단

   촉발

   사고가 시작된 바로 그 시각에 테이블 하나의 자동 ANALYZE가 끝나 통계가 바뀌었고, PostgreSQL 9 쿼리 플래너가 ORM이 만든 질의 하나의 행 수를 크게 잘못 추정했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   장애 중첩수동 조치 악화

   감지

   2020-01-22 오전 10시 PST에 자동 알림을 받고 조사를 시작했다. 데이터베이스 지표의 변화는 9시 45분부터 보였다. 전날 사고도 오전 6시 11분 PST의 오류율 상승 자동 알림으로 알아챘다.

   조치

   • 데이터베이스 부하를 줄이려고 꼭 필요하지 않은 질의 몇 개를 취소하고 할당 IOPS를 늘렸다.
   • 가장 큰 테이블들에서 돌던 autovacuum 문을 취소했다. 지표가 잠시 나아졌지만 autovacuum이 다시 시작됐다.
   • 공격적인 autovacuum을 완전히 막으려고 autovacuum_freeze_max_age 파라미터를 바꾸고 데이터베이스를 재부팅했다.
   • 오후 7시 PST에 서비스를 내려 긴급 유지보수를 하고, 스테이징에서 미리 시험한 PostgreSQL 11로 데이터베이스를 올렸다. 오후 8시 15분 PST에 사이트를 다시 열었다.

   후속 조치

   • 장시간 도는 비싼 질의가 끊기도록 트랜잭션 타임아웃과 한도를 다시 정한다.
   • autovacuum, 락, 질의 성능과 관련된 지표, 모니터링, 데이터베이스 설정을 개선한다.
   • 쿼리 플래너를 헷갈리게 할 수 있는 불필요하거나 지나친 조인과 하위 질의가 있는지 질의를 점검한다.
   • 업그레이드한 PostgreSQL에서 쓸 수 있는 새 성능 분석 도구를 장애 대응 계획에 넣어 문제 질의를 더 빨리 가려낸다.
   • PostgreSQL에 들어 있는 데이터 종류별 구조와 접근 방식을 점검하고, 일부 데이터는 접근 방식에 맞는 저장소로 옮기는 것을 검토한다.
   • 예정에 없던 유지보수 시간을 앱 안에서 알리는 방식을 개선한다.
   • 앞으로 중단 시간이 필요 없는 온라인 데이터베이스 업그레이드로 옮겨 간다.
   • 오프라인이 된 뒤 다시 연결되기 전에 브라우저를 닫아도, 이미 열어 둔 파일에서 계속 안전하게 작업할 수 있게 하는 일을 시작한다.

   교훈

   스테이징 데이터베이스를 미리 PostgreSQL 11로 올려 몇 달 시험하고 운영 업그레이드 계획을 써 둔 덕분에 좋지 않은 상황에서도 업그레이드를 결정할 수 있었다. autovacuum을 막은 뒤에도 성능 문제가 남았으므로 autovacuum은 기여 요인이었을 뿐 유일한 원인이 아니었다. 같은 질의의 행 추정이 시점마다 크게 달랐다는 것은 통계 문제의 신호였다.

   사례 보기
3. IL-0387 Mailgun 한 리전의 MongoDB 서버가 연결 증가로 과부하돼 트래킹, API, SMTP, 웹사이트에서 간헐적 타임아웃과 오류가 났다

   Mailgun2017

   증상

   2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.

   데이터베이스 과부하간헐적 타임아웃오류율 상승

   촉발

   전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다.

   원인

   unknown

   구성 요소

   데이터베이스

   기여 요인

   수동 조치 악화단일 장애점

   감지

   14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다.

   조치

   • 전날 낸 MongoDB 설정 변경을 15:15 UTC 부터 새 pull request 여러 개로 롤백했다. 이 과정에서 사람의 실수로 API 와 SMTP 서비스의 읽기를 primary 로 옮기는 변경이 함께 들어갔다.
   • 더 많은 연결을 감당하도록 MongoDB 서버 크기를 키웠다.
   • 근본 원인을 찾는 동안 서버를 안정시키려고 서버 단에 연결 한도를 넣었다. 서버 크기 조정과 함께 이 조치로 이 리전 API 가 평소 처리량의 약 75% 를 처리했다.
   • 20:28 UTC 부터 서비스가 MongoDB primary 서버에 열 수 있는 연결 수에 한도를 두는 변경을 배포했다.
   • 읽기에 secondary 서버를 우선하는 설정을 다시 배포했다. 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다.

   후속 조치

   • 그동안 한 리전에서만 돌던 트래킹 인프라를 독립된 두 리전에서 운영한다.
   • 이 데이터베이스를 쓰는 모든 서비스에 열 수 있는 연결 수의 한도를 둬서, 서비스 하나가 다른 서비스에 주는 피해를 줄인다.
   • 주 MongoDB 클러스터 크기를 영구히 키우고, 같은 변경을 다른 데이터센터에도 적용한다.
   • 하위 서비스가 실패해도 클릭 리디렉션은 제대로 동작하도록 트래킹 서비스를 고친다.

   사례 보기
4. IL-0383 PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다

   PagerDuty2014sev1

   증상

   6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.

   데이터베이스 과부하오류율 상승지연 시간 증가

   촉발

   6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화초기 신호 무시

   조치

   • 6월 3일 Cassandra 클러스터의 부하를 줄였다.
   • 6월 3일 부하를 줄이면서 repair 작업을 멈췄다.
   • 클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다.
   • 6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다.
   • 새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다.

   후속 조치

   • 기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다.
   • Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다.
   • 시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다.
   • 기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다.
   • 높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다.
   • Cassandra 전문 인력을 사내에 더 둔다.

   교훈

   PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다.

   사례 보기
5. IL-0215 Twilio 결제 시스템의 Redis 가 잔액 데이터를 잃고 읽기 전용이 되어 자동 충전 고객의 신용카드가 반복 결제됐다

   Twilio2013

   증상

   2013년 7월 18일 2:42 AM PDT 에 모니터링 시스템이 결제용 Redis 클러스터의 장애를 당번 엔지니어에게 알렸다. redis-master 호스트의 부하가 극도로 높았고, redis-master 에 기대는 서비스들이 실패하고 있었다.

   데이터베이스 과부하데이터 유실쓰기 거부

   촉발

   7월 18일 1:35 AM PDT 에 네트워크 연결이 끊겨 결제용 redis-slave 전부가 동시에 redis-master 와 끊겼고, 다시 붙으면서 한꺼번에 전체 동기화를 요청했다. 부하가 높아진 redis-master 를 당번 엔지니어가 재시작했다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스 복제

   기여 요인

   재시도 폭주수동 조치 악화안전하지 않은 실패 동작

   감지

   2:42 AM PDT 에 모니터링 시스템이 Redis 클러스터 장애를 당번 엔지니어링 팀에 알렸다. 잘못된 결제는 3:28 AM PDT 에 결제 시스템 모니터링이 이상 동작을 보고해 알았고, 12:36 PM PDT 에는 모니터링이 같은 이상의 재발을 찾았다.

   조치

   • 2:42 AM PDT 에 당번 엔지니어가 높은 부하를 해결하려고 redis-master 를 재시작했다.
   • 4:10 AM PDT 에 신용카드 결제가 더 일어나지 않게 결제 시스템을 내렸다.
   • 6:24 AM PDT 에 정지된 계정을 모두 되살렸고, 결제 시스템은 원인을 조사하는 동안 꺼 둔 채로 뒀다.
   • 별도 관계형 데이터 저장소에 따로 적어 둔 잔액 기록으로 redis-master 에서 잃은 계정 잔액을 복원했다.
   • 12:36 PM PDT 에 같은 이상이 다시 나타나자 결제 시스템을 다시 내리고 정지된 계정을 바로 되살렸다.
   • 2:57 PM PDT 부터 잘못된 신용카드 결제를 환불해 7월 19일 3:00 PM PDT 에 모두 마쳤다.
   • 7월 19일 3:30 PM PDT 에 영향받은 모든 계정에 최근 30일 Twilio 사용액의 10% 를 크레딧으로 줬다.
   • 장애를 일으킨 원래 Redis 클러스터를 교체했고, redis-master 의 잘못된 설정을 찾아 고쳤다.
   • 7월 19일 7:10 PM PDT 부터 고객 계정 묶음마다 결제 시스템을 차례로 켰다.

   후속 조치

   • redis-master 의 Redis 재시작을 막고, 앞으로 redis-master 복구는 slave 를 승격해 처리한다.
   • 결제 잔액이 없거나 쓸 수 없으면 계정을 정지하거나 신용카드를 결제하지 않도록 안전장치를 넣는다.
   • 결제 시스템이 잔액을 따로 적어 두는 데이터베이스와 실시간으로 대조하게 바꾼다.

   교훈

   Twilio 는 현재 잔액 데이터와 잔액을 갱신하는 능력을 동시에 잃자 자동 충전 시스템이 위험한 방향으로 실패했다고 봤다. 잔액이 없거나 쓸 수 없을 때 자동 충전 시스템은 계정을 정지하지 않고 카드를 결제하지 않는 쪽으로 멈춰야 했다.

   사례 보기

원인별7