사례2건

2건 중 1~2번째

1. IL-0255 데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다

   37signals2020

   증상

   2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.

   링크 플래핑지연 시간 증가복제 지연

   촉발

   2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅인메모리 캐시데이터베이스 복제

   기여 요인

   단일 장애점재시도 폭주잡음에 묻힌 신호

   감지

   PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.

   조치

   • 로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다.
   • 레플리카의 Redis 를 재시작했다.

   후속 조치

   • 알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다.
   • 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다.
   • 장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다.
   • 사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다.

   교훈

   이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.

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

   사례 보기

원인별2