사례16건

16건 중 6~10번째

1. IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

   Stripe2019

   증상

   2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

   오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

   촉발

   16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩

   감지

   첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

   조치

   • 17:00 UTC 에 데이터베이스 클러스터의 모든 노드를 재시작해 새 primary 선출을 성공시켰다. 17:02 에 Stripe API 가 완전히 복구됐다.
   • 22:34 UTC 에 운영 설정을 고쳐 새로 배포하고 데이터베이스 클러스터의 노드를 재시작해 영향받은 shard 를 되살렸다.
   • 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸다. 22:47 UTC 에 완전히 복구됐다.

   후속 조치

   • 노드가 복제 지연 지표를 보내지 않으면 알리는 모니터링을 더했다.
   • shard 가 데이터베이스 장애 조치 시스템의 이 선출 결함을 일으킬 수 있는 상태에 들어가면 알리는 모니터링을 더했다.
   • 이 결함을 고치는 수정을 데이터베이스 메인테이너와 함께 만든다.
   • 특정 클러스터로 가는 작업이 실패하면 끊어 내는 서킷 브레이커를 더 넣는다. 이번 사고의 클러스터도 대상이다.
   • shard 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기
2. IL-0289 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다

   updown.io2019

   증상

   2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.

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

   촉발

   주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   –

   감지

   MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다.

   조치

   • 보조 서버가 넘겨받을 준비가 됐는지 확인한 뒤 주 서버를 강제로 step down 시켰다. 8:56 am CEST 에 웹과 데몬 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다.
   • I/O 문제를 일으킨 SSD 를 RAID 어레이에서 빼자 서버가 원래 성능으로 돌아왔다.
   • 호스팅 업체에 SSD 교체 일정을 잡는 티켓을 열었다.
   • 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿨고, 그 뒤 응답 시간이 정상으로 돌아왔다.

   후속 조치

   • MongoDB 팀이 이 문제를 곧 고칠 것 같지 않아, MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만든다.
   • 더 조사할 것이 없다고 확인되면 옛 보조 서버를 내리고 지운다.
   • 새 보조 서버가 며칠 동안 주 서버 역할을 버틸 수 있는지, clamscan 이 도는 밤까지 포함해 확인한다.
   • 주 서버가 정상으로 돌아오면 자동 step down 스크립트를 시험한다.
   • updown.io 의 제대로 된 상태 페이지를 만든다.
   • MongoDB 가 Storage Node Watchdog 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다.

   사례 보기
3. IL-0210 43초 네트워크 단절 뒤 MySQL 프라이머리가 미국 서부로 넘어가 GitHub.com 이 24시간 11분 동안 느려지고 오래된 데이터를 보여 줬다

   GitHub2018

   증상

   2018년 10월 21일 22:54 UTC 에 내부 모니터링 시스템이 여러 시스템에서 장애가 났다는 알림을 쏟아내기 시작했다. 23:02 UTC 에 첫 대응 팀은 여러 데이터베이스 클러스터의 토폴로지가 예상하지 못한 상태라는 것을 확인했다.

   스플릿 브레인장애 조치 실패복제 지연지연 시간 증가

   촉발

   10월 21일 22:52 UTC 에 고장 난 100G 광 장비를 교체하는 정기 유지보수 작업 중 미국 동부 네트워크 허브와 동부 주 데이터센터 사이의 연결이 끊겼다. 연결은 43초 만에 돌아왔다.

   원인

   DNS·네트워크 장애

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자데이터베이스 복제데이터베이스 백업과 스냅숏NIC·케이블·스위치 포트 링크

   기여 요인

   자동화 증폭미검증 가정

   감지

   22:54 UTC 에 내부 모니터링 시스템이 알림을 내기 시작해 여러 엔지니어가 알림을 분류했다. 23:02 UTC 에 첫 대응 팀이 Orchestrator API 를 조회해 복제 토폴로지에 서부 데이터센터 서버만 남은 것을 확인했다.

   조치

   • 23:07 UTC 에 내부 배포 도구를 수동으로 잠가 더는 변경이 들어오지 않게 했다.
   • 푸시 같은 메타데이터를 쓰는 작업을 멈추려고 웹훅 전송과 GitHub Pages 빌드를 일시 중지했다.
   • 10월 22일 06:51 UTC 까지 여러 클러스터를 미국 동부 데이터센터에서 백업으로 복원했고, 복원된 서버는 서부에서 새 데이터를 복제받기 시작했다.
   • 외부 저장소에서 내려받는 처리량 한계를 피하려고 서부 데이터센터에서 직접 복원하는 방법을 찾았다.
   • 11:12 UTC 에 모든 데이터베이스 프라이머리를 다시 미국 동부에 세웠다.
   • 미국 동부 퍼블릭 클라우드에 MySQL 읽기 복제본을 추가로 띄워 읽기 요청을 더 많은 서버로 나눴고, 복제본 전체의 사용률이 내려가 복제가 따라잡았다.
   • 복제본이 맞춰진 뒤 16:24 UTC 에 원래 토폴로지로 페일오버했다.
   • 밀린 웹훅 이벤트와 Pages 빌드를 처리했다. 웹훅 페이로드 약 200,000건이 내부 TTL 을 넘겨 버려진 것을 발견하자 처리를 멈추고 TTL 을 당분간 늘리는 변경을 배포했다.

   후속 조치

   • 각 클러스터에서 서부로 복제되지 않은 쓰기를 담은 MySQL 바이너리 로그를 분석해, 자동으로 맞출 수 있는 쓰기와 사용자에게 연락해야 하는 쓰기를 가린다.
   • GitHub Pages 빌드가 멈춘 상황에서도 공지 글을 낼 수 있게 한다.
   • 장애 중 복구 예상 시간을 더 정확하게 알린다.
   • Orchestrator 설정을 고쳐 데이터베이스 프라이머리가 리전 경계를 넘어 승격되지 않게 한다.
   • 녹색, 노란색, 빨간색 세 단계만 있던 상태 표시를 새 상태 보고 방식으로 옮겨 플랫폼 구성 요소마다 상태를 보여 준다.
   • 여러 데이터센터에서 트래픽을 받는 active/active/active 구성으로 옮기는 일을 앞당겨, 시설 단위 N+1 이중화로 데이터센터 하나가 통째로 망가져도 사용자에게 영향이 없게 한다.
   • 시스템이 기대는 가정을 더 적극적으로 시험한다.
   • 장애 시나리오를 사용자에게 닿기 전에 검증하는 관행을 들이고, 장애 주입과 카오스 엔지니어링 도구에 투자한다.

   교훈

   GitHub 은 Orchestrator 가 설정대로 움직였지만 애플리케이션 계층은 그 토폴로지 변경을 견디지 못했다고 봤다. 리전 안의 리더 선출은 대체로 안전하지만, 갑자기 생긴 대륙 간 지연이 이번 장애를 키운 큰 요인이었다. 자동 페일오버 설정은 애플리케이션이 기대하는 것과 맞춰야 한다. GitHub 은 이만큼 복잡한 서비스 체계에서는 운영 통제를 조이거나 대응을 빠르게 하는 것만으로는 안정성을 지킬 수 없다고 판단했다. 그래서 가정을 더 적극적으로 시험하고, 장애 시나리오를 사용자에게 닿기 전에 검증하기로 했다. 복구 예상 시간은 모든 변수를 고려하지 못해 틀렸다.

   사례 보기
4. IL-0588 AppOptics 와 Librato 의 메트릭 API 가 대부분의 데이터에 5xx 를 내고 Kafka 파티션이 리더 없이 오프라인으로 남았다

   AppOptics2018

   증상

   2018년 5월 31일 21:53 UTC 부터 AppOptics 와 Librato 의 메트릭 API 가 들어오는 메트릭 데이터 대부분에 5xx 를 냈다. AppOptics APM 이 보낸 APM 메트릭과 트레이스도 영향을 받았고, 알림 상당수가 늦게 나갔다.

   오류율 상승장애 조치 실패모니터링 중단

   촉발

   AWS US-East-1 리전의 가용 영역 하나에 난 전력 장애로 ZooKeeper 리더 노드를 잃었고, 그 가용 영역의 Kafka 브로커 여럿도 영향을 받았다.

   원인

   클라우드 제공자 장애

   구성 요소

   메시지 브로커코디네이션 키-값 저장소

   기여 요인

   단일 장애점과도한 영향 범위모니터링 사각지대

   조치

   • ZooKeeper 클러스터의 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 앙상블이 쿼럼을 되찾았다.
   • Kafka 브로커를 하나씩 차례로 재시작해 리더 없이 오프라인이던 파티션을 다시 온라인으로 올렸다.
   • 밀린 작업과 알림을 모두 처리하고 정상 운영으로 돌아갔다.

   후속 조치

   • Kafka 클러스터를 가용 영역 사이, 나아가 리전 사이에 더 잘 격리한다.
   • Kafka 클러스터끼리 ZooKeeper 앙상블을 같이 쓰지 않게 한다.
   • ZooKeeper 쿼럼이 돌아온 뒤 Kafka 가 사람 손 없이 파티션 리더를 되찾는지 게임데이에서 이 상황을 더 재현해 본다. 새 Kafka 버전에서 이 문제가 고쳐졌는지도 확인한다.
   • 복구에 따로 손이 필요한 하위 시스템을 더 일찍 알려 주는 점검을 더 넣었다.

   교훈

   여러 가용 영역에 서비스를 나눠 뒀지만 Kafka 와 ZooKeeper 가 이번처럼 실패하자 격리가 충분하지 않았다. Kafka 클러스터를 가용 영역과 리전 사이에 더 잘 격리하고 Kafka 클러스터마다 ZooKeeper 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

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

   사례 보기

원인별9