사례9건

9건 중 6~9번째

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-0587 Elastic Cloud AWS eu-west-1 리전의 클러스터 접속이 약 3시간 심하게 저하되고 20분 동안 완전히 끊겼다

   Elastic2019

   증상

   2019년 1월 18일 09:35 UTC 에 Elastic Cloud 의 당번 SRE 들이 AWS eu-west-1 리전 조정 계층의 서비스 저하 알림을 받았다. 10:08 UTC 무렵부터 이 리전에 배포를 둔 고객은 약 3시간 동안 자기 클러스터에 접속하기가 매우 어려워졌다.

   데이터베이스 과부하서비스 중단OOMKilled

   촉발

   09:09 UTC 에 ZooKeeper 앙상블 리더 서버의 CPU 사용량이 높은 임계치에 닿으면서 클라이언트 연결이 끊긴 것이 시작이었다.

   원인

   소프트웨어 결함

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리

   기여 요인

   재시도 폭주미패치 알려진 버그

   감지

   09:35 UTC 에 당번 SRE 들이 조정 계층의 서비스 저하 알림을 받았고, 내부 절차에 따라 운영 장애를 열었다.

   조치

   • 급증한 클라이언트 트래픽을 받도록 프록시 계층을 수직과 수평으로 늘렸다.
   • 리더 선출을 일으켜 조정 계층의 ZooKeeper 앙상블을 안정시켰다.

   후속 조치

   • 모든 Elasticsearch Service 제공자와 리전 거점에서 TreeCache 를 TreeWatcher 로 바꾼다. 2019년 1월 24일에 교체를 마쳤다.
   • 운영에서 검증된 TreeWatcher 를 Apache Curator 프로젝트에 기여할 계획이다.
   • 다음 버전의 프록시 계층은 ZooKeeper 에 덜 의존하고, 라우팅 테이블을 버전을 매긴 로컬 파일에 캐시해 ZooKeeper 연결이 끊기거나 불안정해도 트래픽을 보낼 수 있게 한다. 앞으로 몇 달에 걸쳐 모든 리전에 차례로 배포한다.

   사례 보기
3. 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 가 노드 하나의 장애를 견디도록 설계됐어도 여러 노드가 함께 죽는 일이 불가능하다고 여기면 안 된다. 큰 분산 시스템에서는 무엇이든 일어날 수 있으므로 시스템과 절차에 빠르게 복구할 대안을 늘 준비해 둬야 한다.

   사례 보기
4. 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