사례6건

6건 중 3~6번째

1. IL-0277 Elastic Cloud us-east-1 의 ZooKeeper 조정 계층이 쿼럼을 잃어 Elasticsearch 배포에 6시간 넘게 접속하지 못하고 Kibana 는 18:44 UTC 까지 불안정했다

   Elastic2019

   증상

   2019년 2월 4일 02:50 UTC 무렵부터 AWS us-east-1 의 Elastic Cloud 고객이 클러스터에 접속하기 어려워졌고, 로드 밸런서에서 HTTP 5xx 오류가 늘었다. 고객 대부분은 Kibana 에도 접속하지 못했고, Elastic Cloud User Console 은 배포 목록을 볼 때 타임아웃이 늘었다.

   오류율 상승서비스 중단간헐적 타임아웃노드 커널 패닉

   촉발

   2019년 2월 4일 AWS us-east-1 리전에서 조정 계층의 ZooKeeper 를 정기 패치하면서 02:25~02:45 에 앙상블 멤버 두 대를 패치한 호스트로 바꿨다.

   원인

   소프트웨어 결함

   구성 요소

   코디네이션 키-값 저장소컨테이너 런타임리눅스 커널Elasticsearch 와 OpenSearchconntrack 테이블

   기여 요인

   모니터링 사각지대재시도 폭주의존성에 묶인 헬스 체크장애 중첩수동 조치 악화

   감지

   Elastic 은 02:50 UTC 에 로드 밸런서에서 HTTP 5xx 오류가 늘어난 것을 확인했다.

   조치

   • 03:22 와 06:00 에 클라이언트 연결 문제를 줄이려고 내부 서비스를 일괄 재시작했다.
   • 04:39 에 클라이언트 연결을 끊어 앙상블을 떼어 놓고 시스템을 안정시켰다.
   • 04:46 에 호스트가 불안정해지자 남은 앙상블 멤버의 롤백을 시작했다.
   • 05:25 에 호스트가 불안정해 두 번째 앙상블 멤버도 롤백하기 시작했다.
   • runc 버그로 응답하지 않게 된 ZooKeeper 앙상블 멤버 두 대를 재부팅했다.
   • 가능한 곳에서 클라이언트 부하를 걷어 내 앙상블이 안정될 시간을 준 뒤, 클라이언트 부하를 조금씩 다시 들여 쿼럼을 다시 세웠다.
   • 프록시가 쓰는 ZooKeeper observer 계층의 initLimit 설정을 늘려 observer 계층을 안정시켰다.
   • 늘어난 Elasticsearch 클러스터 트래픽을 받도록 프록시를 키우고 대수를 늘렸다.
   • 내부 프록시 컨테이너와 Kibana 인스턴스를 재시작하고 sysctl 한도를 거는 런북을 만들어 적용했다.

   후속 조치

   • ZooKeeper 앙상블이 담는 데이터셋을 60% 넘게 줄였다.
   • 정상으로 표시된 프록시 노드가 로드 밸런싱 대상에 들어가는 데 필요한 헬스 체크 횟수와 간격을 줄였다.
   • 프록시 헬스 체크에서 ZooKeeper 연결 여부를 빼, 초기화를 마친 프록시가 ZooKeeper 상태 때문에 비정상이 되지 않게 한다.
   • 프록시 서비스를 ZooKeeper 상태에서 떼어 낸 v2 구조의 프록시 계층을 운영 리전에서 카나리로 시험한다.
   • 내부 로깅을 늘리고 ZooKeeper 프로세스, JVM, 컨테이너와 호스트 시스템의 지표를 더해 ZooKeeper 의 관측성을 높인다.
   • Kibana 의 경로 탐색 방식을 더 튼튼하게 만든다.
   • 가용성 사고 중에 Kibana 가 내부 HTTP 요청을 몇 배로 늘려 보내는 문제를 찾아 고친다.
   • Kibana 의 연결 누수 문제를 찾아 고친다.
   • 내부 모니터링 에이전트가 지터를 넣은 백오프를 제대로 쓰지 않던 문제를 찾아 완화했다.
   • 문제가 생겨도 덜 중요한 시간대에 드러나도록, 유지보수 일정표를 정식으로 만들어 리전마다 정한 시간대에만 작업하게 했다.
   • 조정 계층의 정기 유지보수를 다루는 런북에 더 나은 판단 기준표를 넣는다.
   • 지원 창구와 상태 페이지로 나가는 안내를 두고 지원 리더십 팀과 피드백 루프를 만들었다.

   교훈

   서비스 지표가 호스트를 정상으로 보고해 유지보수를 이어 가도 된다는 신호를 줬지만, 그 지표로는 개별 호스트와 조정 계층 전체의 상태를 충분히 알 수 없었다. 다른 플랫폼 구성 요소가 조정 계층에 의존해서 조정 계층의 불안정과 쿼럼 상실이 큰 서비스 중단으로 번졌다. 원인을 찾는 동안 관련 없는 문제들을 만나 해결이 더 늦어졌고, 하나하나는 성공한 완화 조치도 장애의 규모 때문에 한동안 효과가 없었다.

   사례 보기
2. 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 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

   사례 보기
3. 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 오류로 이어졌다. 노드는 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도했어야 했다.

   사례 보기
4. 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 에 밝지도 않았다.

   사례 보기

원인별3