사례13건

13건 중 11~13번째

1. IL-0276 Chef 가 ZooKeeper 세 노드 가운데 두 대를 동시에 재시작해 쿼럼이 깨지면서 Parse.ly 의 실시간 데이터 전달이 약 3시간 멈췄다

   Parse.ly2016

   증상

   2016년 6월 9일 목요일 11:30am ET 에 대시보드로 가는 데이터 전달이 갑자기 멈췄다. 데이터 전달 모니터 말고는 어떤 시스템도 장애를 알리지 않았다.

   서비스 중단

   촉발

   2016년 6월 9일 정기적으로 도는 Chef 가 설정 변경에 따라 서비스를 재시작하면서, 세 노드로 된 ZooKeeper 클러스터의 두 노드를 정확히 같은 시각에 재시작했다.

   원인

   배포 결함

   구성 요소

   코디네이션 키-값 저장소

   기여 요인

   미검증 가정단계적 배포 부재

   감지

   데이터 전달 모니터가 대시보드로 가는 데이터 전달이 멈춘 것을 알렸다. 다른 시스템은 장애를 알리지 않았다.

   조치

   • 실시간 시스템에서 몇 시간치 데이터를 비우고, 클러스터를 내렸다가 처음부터 다시 올리는 콜드 스타트를 했다.
   • 멈춘 3시간치 데이터를 이력 재구축 과정으로 대시보드에 다시 넣었다.

   후속 조치

   • 운영 환경의 설정 변경과 노드 재시작을 분리한다.
   • 시스템과 절차에 빠르게 복구할 대안을 늘 준비해 둔다.

   교훈

   Parse.ly 는 자동 서비스 재시작을 다시 생각하게 됐다. Chef 가 설정 변경은 자동으로 내보내되 서비스 재시작은 엔지니어가 손으로 하거나 승인하도록 대기시켜 두었다면, 이 작업의 위험이 바로 드러났을 것이다. ZooKeeper 가 노드 하나의 장애를 견디도록 설계됐어도 여러 노드가 함께 죽는 일이 불가능하다고 여기면 안 된다. 큰 분산 시스템에서는 무엇이든 일어날 수 있으므로 시스템과 절차에 빠르게 복구할 대안을 늘 준비해 둬야 한다.

   사례 보기
2. IL-0536 US East 의 Amazon SimpleDB 가 두 시간 동안 거의 모든 API 호출에 실패했다

   Amazon Web Services2014

   증상

   US East 리전의 SimpleDB 가 PDT 오후 9:16 부터 11:16 까지 거의 모든 API 호출에 실패했다. 최종 일관성 읽기 호출 일부만 성공했다. API 요청은 서버 쪽 오류인 http response code 500 을 받았다.

   서비스 중단오류율 상승

   촉발

   한 데이터센터에서 서버에 전원이 끊겨 SimpleDB 스토리지 노드 여러 대가 한꺼번에 내려갔다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스코디네이션 키-값 저장소데이터센터 전력·냉각

   기여 요인

   자동화 증폭

   조치

   • 핸드셰이크 타임아웃 값을 손으로 늘렸다.
   • 메타데이터 노드 일부를 재시작해 스토리지 노드를 승인하게 했다. 스토리지 노드는 클러스터에 다시 들어가 고객 데이터 요청을 처리했다.
   • 나머지 메타데이터 노드가 안전하게 회복하도록 메타데이터 노드가 처리하는 CreateDomain 과 DeleteDomain API 호출을 PDT 오전 1:30 까지 스로틀링했다.

   후속 조치

   • 락 서비스의 핸드셰이크 타임아웃을 더 길게 잡는다. 이 수정을 모든 SimpleDB 리전에 배포한다.
   • 핸드셰이크 타임아웃을 여러 번 겪은 노드가 곧바로 클러스터에서 빠지지 않고, 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도하게 한다. 이 수정을 모든 SimpleDB 리전에 배포한다.

   교훈

   핸드셰이크 타임아웃 값을 낮게 잡은 것은 복제본 실패를 빨리 알아채기 위해서였지만, 지나고 보니 너무 낮았다. 핸드셰이크 타임아웃을 여러 번 겪은 노드가 곧바로 클러스터에서 빠지는 동작이 장애의 범위를 넓혔고 API 오류로 이어졌다. 노드는 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도했어야 했다.

   사례 보기
3. IL-0362 PagerDuty 의 알림 발송이 18분 동안 멈추고 API 가 500 을 냈다

   PagerDuty2013sev1

   증상

   2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.

   지연 시간 증가오류율 상승간헐적 연결 실패

   촉발

   PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비코디네이션 키-값 저장소

   기여 요인

   단일 장애점미검증 가정모니터링 사각지대

   감지

   8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다.

   조치

   • 장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했다.
   • 8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓여 있던 알림을 모두 처리하기 시작했다.

   후속 조치

   • 일부 시스템의 문제를 디버깅할 로그가 부족했으므로, 로그를 더 남기고 검색하기 쉽게 한곳으로 모으기 시작했다.
   • 실패한 coordinator 같은 프로세스를 자동으로 재시작하는 프로세스 감시자를 둔다.
   • 호스트 사이 연결 상태를 보여 주는 대시보드를 만든다.
   • 모든 엔지니어가 Cassandra 와 ZooKeeper 를 잘 알지는 못하므로, 두 기술을 교육하는 데 시간을 들인다.
   • AWS 리전 하나에서 옮겨 가는 방안을 조사한다. 새 호스팅 사업자와 데이터센터를 고를 때 단일 장애 지점이 생기지 않도록 미리 따져 본다.

   교훈

   서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다.

   사례 보기

원인별6