사례4건

4건 중 1~4번째

1. IL-0342 DigitalOcean 의 AMS3, LON1, SFO2 데이터 센터가 에지 라우터 고장으로 인터넷 연결을 되풀이해 잃었다

   DigitalOcean2023

   증상

   2023년 8월 9일 09:55 UTC 부터 DigitalOcean 의 AMS3, LON1, SFO2 데이터 센터가 인터넷 연결을 잃었다. 끊김은 세 차례 일어났다. 한 번에 10~15분씩 이어졌고, 끊김 사이의 간격은 한 시간쯤이었다.

   네트워크 도달 불가간헐적 타임아웃지연 시간 증가

   촉발

   에지 라우터가 RPKI 관련 라우팅 갱신을 받으면서, 일부 에지 라우터에서 돌던 운영체제 소프트웨어 버전의 버그가 라우팅 프로세스를 죽였다.

   원인

   소프트웨어 결함

   구성 요소

   BGP 라우팅

   기여 요인

   과도한 영향 범위수동 조치 악화

   조치

   • 장비 업체의 조사 뒤 문제의 운영체제 버전을 쓰는 에지 라우터에 소프트웨어 업데이트를 긴급히 내보냈다. 회선에서 트래픽을 빼고 라우터가 인터넷에 다시 붙는 동안 연결 문제가 더 났다.
   • AMS3 와 FRA1 사이 경로의 혼잡을 줄이려고 트래픽을 다시 나눴다.
   • 장애 전환이 일어나도 같은 문제를 겪지 않도록 이중화된 네트워크 장비에도 수정을 내보냈다. 14:58 UTC 공지에서 AMS3, LON1, SFO2 의 모든 네트워크 장비를 패치했다고 알렸다.

   후속 조치

   • 전 세계 모든 에지 라우터를 버그를 피하는 버전으로 업그레이드했다.
   • 네트워크의 안정성과 보안을 높이는 네트워크 업그레이드를 진행한다. 아시아는 이미 업그레이드를 마쳤고, 유럽과 북미는 올해 말과 2024년 초에 업그레이드한다.

   사례 보기
2. 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 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기
3. 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 의 연결 누수 문제를 찾아 고친다.
   • 내부 모니터링 에이전트가 지터를 넣은 백오프를 제대로 쓰지 않던 문제를 찾아 완화했다.
   • 문제가 생겨도 덜 중요한 시간대에 드러나도록, 유지보수 일정표를 정식으로 만들어 리전마다 정한 시간대에만 작업하게 했다.
   • 조정 계층의 정기 유지보수를 다루는 런북에 더 나은 판단 기준표를 넣는다.
   • 지원 창구와 상태 페이지로 나가는 안내를 두고 지원 리더십 팀과 피드백 루프를 만들었다.

   교훈

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

   사례 보기
4. IL-0274 GitHub 코드 검색의 elasticsearch 클러스터에서 일부 노드 CPU 가 100% 에 가깝게 차고 마스터가 계속 바뀌면서 검색과 색인이 타임아웃되고 샤드 데이터가 사라졌다

   GitHub2013

   증상

   2013년 1월 24일 목요일 예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다. 예외 대부분은 코드 검색 질의의 타임아웃과, 새 push 의 데이터로 코드 검색 색인을 갱신하는 백그라운드 작업의 타임아웃이었다.

   간헐적 타임아웃노드 CPU 고부하스플릿 브레인데이터 유실

   촉발

   2013년 1월 17일 코드 검색 클러스터를 elasticsearch 0.19.9 에서 0.20.2 로 업그레이드했다. 그 뒤 코드 검색을 공개하자 클러스터에 높은 부하가 걸렸고 메모리 할당이 계속 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   Elasticsearch 와 OpenSearch언어 런타임 설정

   기여 요인

   기본 설정 방치미뤄 둔 업그레이드시험하지 않은 변경초기 신호 무시수동 조치 악화

   감지

   예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다.

   조치

   • 클러스터를 완전히 멈추고, 샤드 할당과 재균형을 끄는 "maintenance mode" 로 다시 올렸다.
   • elasticsearch 를 개발하고 지원하는 회사의 엔지니어 두 명에게 도움을 청했다.
   • 두 엔지니어의 권고대로 Java 와 elasticsearch 를 곧바로 업그레이드하고 설정을 바꿨다. Puppetmaster 에 이 변경 전용 토픽 브랜치와 환경을 만들고 각 노드에서 Puppet 을 돌렸다.

   후속 조치

   • 코드 검색 클러스터의 스테이징 환경을 만들어 인프라 변경을 더 잘 시험한다.
   • elasticsearch 팀이 앞으로도 코드 검색 클러스터 설정을 다시 점검해, 쓰임새에 맞게 유지되도록 한다.

   교훈

   GitHub 는 elasticsearch 0.20.2 를 코드 검색 클러스터에 내보내기 전에 자기 인프라에서 충분히 시험하지 않았고 다른 클러스터에서도 시험하지 않았다. 코드 검색 클러스터에 제대로 된 스테이징 환경이 없던 것이 한 요인이었다. elasticsearch 팀은 큰 클러스터에 이렇게 권했다. ES_HEAP_SIZE 환경 변수로 JVM 의 최소·최대 메모리를 같게 하고 시스템 RAM 의 50% 로 둔다. recover_after_time 을 30분으로 두지 말고 복구가 바로 시작되게 한다. minimum_master_nodes 를 설정해 노드가 오래 멈출 때 노드 일부가 따로 클러스터를 이루지 않게 한다.

   사례 보기

원인별1