사례9건

9건 중 2~6번째

1. IL-0374 DigitalOcean 내부 서비스 디스커버리가 전 리전에서 멈춰 생성, 이벤트 처리, 제어판과 API 관리가 실패했다

   DigitalOcean2024

   증상

   2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.

   서비스 중단클러스터·노드 생성 정체

   촉발

   새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다.

   원인

   설정 변경

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리데이터베이스 복제

   기여 요인

   과도한 영향 범위

   감지

   16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다.

   조치

   • 17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다.
   • 18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다.
   • 남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다.

   후속 조치

   • 이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다.
   • 이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다.
   • 이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다.
   • 여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다.

   사례 보기
2. IL-0514 클라우드 사업자의 노드 교체 뒤 Consul 이 리더를 뽑지 못하고 Vault 가 봉인된 채 남아 PyPI 백엔드가 7분 동안 응답하지 않았다

   Python Software Foundation2022

   증상

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 다시 올라오려면 봉인 해제가 필요하다는 첫 알림이 왔다. 살펴보니 클러스터의 Vault 컨테이너는 모두 쓸 수 없었고 Consul 컨테이너는 새 리더를 뽑지 못하고 있었다.

   서비스 중단파드 Terminating 정체

   촉발

   2022-07-28 17:24 UTC 부터 클라우드 사업자가 알 수 없는 장애를 이유로 PyPI 가 도는 쿠버네티스 클러스터의 클라우드 인스턴스 여러 대를 자동으로 교체했다.

   원인

   클라우드 제공자 장애

   구성 요소

   코디네이션 키-값 저장소시크릿 저장소

   기여 요인

   자동화 증폭

   감지

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 봉인 해제가 필요하다는 알림이 왔다.

   조치

   • Terminating 상태에 멈춘 Consul 파드를 강제로 지우고 다시 만들어지게 했다. 그 뒤 Consul 회복이 시작됐다.
   • Consul 을 되살린 뒤 새 Vault 컨테이너의 봉인을 풀었다.

   사례 보기
3. IL-0213 Consul 클러스터의 KV 쓰기가 느려지고 리더가 뒤처지며 Roblox 전체가 73시간 동안 멈췄다

   Roblox2021

   증상

   2021년 10월 28일 13:37 PST 에 Vault 성능이 떨어지고 Consul 서버 한 대의 CPU 부하가 높아졌다. 이때는 플레이어에게 영향이 없었다.

   지연 시간 증가노드 CPU 고부하서비스 중단모니터링 중단

   촉발

   10월 27일 14:00 PST 에 트래픽 라우팅을 맡는 백엔드 서비스에 Consul 의 새 streaming 기능을 켰다. 같은 롤아웃에서 연말 트래픽에 대비해 트래픽 라우팅 노드 수를 50% 늘렸고, 하루 뒤 Consul 성능이 떨어지기 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리인메모리 캐시

   기여 요인

   단일 장애점장애 중첩모니터링 사각지대수동 조치 악화늦게 드러난 변경

   감지

   10월 28일 13:37 PST 에 Vault 성능 저하와 Consul 서버 한 대의 높은 CPU 부하를 보고 Roblox 엔지니어들이 조사를 시작했다. Consul 클러스터 지표에서 KV 쓰기 지연이 올라간 것을 확인했다.

   조치

   • 하드웨어 성능 저하를 의심해 Consul 클러스터 노드 한 대를 교체했다.
   • 트래픽 증가를 의심해 Consul 클러스터의 모든 노드를 128코어와 더 빠른 NVME SSD 를 단 서버로 바꿨다.
   • Consul 클러스터 전체를 내리고 장애 시작 무렵인 몇 시간 전 스냅샷으로 상태를 되돌렸으며, iptables 로 접근을 막았다가 천천히 풀었다.
   • 외부 트래픽을 막고, Consul 을 쓰는 서비스 목록을 모아 꼭 필요하지 않은 사용을 끄는 설정을 배포했으며, 서비스 인스턴스를 한 자릿수로 줄이고 헬스 체크 간격을 60초에서 10분으로 늘렸다.
   • 경합이 128코어 서버로 옮긴 탓일 수 있다고 보고 Consul 클러스터를 다시 64코어 서버로 옮겼다.
   • 트래픽 라우팅 노드를 포함한 모든 Consul 시스템에서 streaming 기능을 껐고, 설정이 15:51 PST 에 다 퍼지자 KV 쓰기의 p50 지연이 300ms 로 내려갔다.
   • 느린 리더 문제의 원인을 모르는 채로, 문제가 있는 서버가 리더로 뽑힌 채 남지 않게 막았다.
   • 캐시 시스템을 다시 배포했고, 틀어진 스케줄링 데이터와 끝나지 않는 배포 같은 문제를 밤새 찾아 고쳤다.
   • 장애와 문제 분석 중에 내렸던 서비스들을 알맞은 용량으로 다시 띄우고 제대로 도는지 확인했다.
   • DNS 조정으로 무작위로 고른 일정 비율의 플레이어만 들이고 나머지는 정적 점검 페이지로 보냈으며, 데이터베이스 부하와 캐시 성능을 보며 약 10% 씩 늘렸다.

   후속 조치

   • HashiCorp 는 시험 환경에서 이 경합 문제를 재현하는 새 벤치마크를 만들고 대규모 시험을 늘린다.
   • HashiCorp 는 극한 부하에서도 경합이 생기지 않도록 streaming 시스템의 설계를 고친다.
   • 기존 BoltDB 도구로 데이터베이스를 압축하는 절차를 만들어 배포했고, 이것으로 성능 문제가 풀렸다.
   • 텔레메트리 시스템과 Consul 사이의 순환 의존을 없애, 텔레메트리 시스템이 감시 대상 시스템에 기대지 않게 했다.
   • Consul 과 BoltDB 성능, Roblox 서비스와 Consul 사이의 트래픽 패턴을 더 잘 보이게 텔레메트리를 넓혔고, 이번 장애 상태에 가까워지는 신호에 정밀한 알림을 건다.
   • 백엔드 서비스를 둘 지리적으로 떨어진 데이터센터를 하나 더 세웠고, 데이터센터 안에서 여러 가용 영역으로 옮긴다.
   • 서비스들의 Consul KV 와 헬스 체크 사용을 검토해 일부 핵심 서비스를 전용 클러스터로 나눠 중앙 Consul 클러스터의 부하를 줄였다.
   • Consul KV 를 데이터 저장소로 쓰던 핵심 서비스의 데이터를 더 알맞은 저장 시스템으로 옮긴다.
   • 쓰지 않는 KV 데이터를 대량으로 찾아 지웠고, Consul 성능이 좋아졌다.
   • HashiCorp 와 함께 BoltDB 대신 freelist 가 끝없이 커지는 문제가 없는 후속 라이브러리 bbolt 를 쓰는 새 Consul 버전을 배포한다. 연말 최대 트래픽을 피해 새해로 미뤘고 1분기에 끝낸다.
   • 캐시 배포 방식을 다시 설계해 아무것도 없는 상태에서도 캐시 시스템을 빨리 올릴 수 있게 한다.
   • 오래 멈춘 뒤 큰 작업을 다시 올리기 쉽게 하는 Nomad 개선 몇 가지를 HashiCorp 와 찾았고, 다음 Nomad 업그레이드에서 배포한다.
   • 서버 설정을 더 빨리 바꾸는 방법을 만들어 배포했다.
   • 새 streaming 구현을 Roblox 규모와 부하로 시험한 뒤에 조심스럽게 다시 들인다.

   교훈

   Roblox 는 원인 두 가지가 Consul 구현 깊숙이 묻혀 있어 진단이 어려웠던 것이 장애를 길게 만든 주된 이유라고 봤다. 원인을 보여 줄 모니터링 시스템이 장애가 난 Consul 에 기대고 있어 분석이 크게 막혔다. 모든 백엔드 서비스를 Consul 클러스터 하나에 올린 구성이 이런 장애에 취약했다. HashiCorp 는 Roblox 와 비슷한 규모에서 streaming 을 벤치마크했지만, 이 경합은 스트림 수가 많고 교체가 잦은 조건이 겹칠 때만 나타나 전에는 보지 못했다. 더 빠른 하드웨어는 도움이 되지 않았고 오히려 안정성을 해쳤을 수 있다. 오래 완전히 멈춘 상태에서 서비스를 올리는 데도 캐시 배포와 데우기 때문에 시간이 많이 걸렸다.

   사례 보기
4. IL-0271 서비스 디스커버리에 잘못된 항목이 들어가 Elixir 서비스들이 한꺼번에 죽으면서 Discord 가 대부분의 사용자에게 한 시간 동안 열리지 않았다

   Discord2020sev1

   증상

   2020년 3월 16일 14:19 PDT 에 실시간 연결과 채팅 메시지를 처리하는 Elixir 서비스 대부분이 죽어 용량이 한순간에 사라졌고, 여기에 의존하는 다른 시스템으로 장애가 번졌다. 14:21 에 핵심 지표가 떨어졌다는 알림과 클러스터 사용률 이상 알림이 여럿 울렸고 SEV1 이 선언됐다. 대부분의 사용자가 Discord 에 접속하지 못했다.

   서비스 중단오류율 상승

   촉발

   2020년 3월 16일 14:18 PDT 에 Google Cloud 관리형 인스턴스 그룹 오토스케일러가 API 클러스터에 새 노드를 넣었고, 이 노드가 etcd 에 자신을 등록하는 도중 연결이 끊겨 값이 빈 키가 서비스 디스커버리에 쓰였다.

   원인

   소프트웨어 결함

   구성 요소

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

   기여 요인

   자동화 증폭

   감지

   14:21 PDT 에 핵심 지표가 떨어졌다는 알림과 클러스터 사용률 이상 알림이 여럿 울렸고, SEV1 이 선언됐다.

   조치

   • 잃은 실시간 용량을 다시 띄우고 장애가 난 노드를 고쳤다.
   • 서비스 복구를 돕기 위해 Discord 로 들어오는 접속을 조절하기 시작했다.
   • 모두가 다시 접속하는 동안 자원이 바닥나지 않도록 ScyllaDB 클러스터 두 곳의 데이터베이스 유지 작업인 anti-entropy repair 를 멈췄다.
   • 서비스가 회복되는 대로 접속 허용량을 계속 늘려 더 많은 사용자가 다시 접속하게 했다.

   후속 조치

   • 값이 잘못된 키가 쓰일 가능성을 줄이려고, etcd 클라이언트가 자신을 등록하는 요청을 TCP 패킷 두 개가 아니라 하나로 보내게 바꿨다.
   • 키 값이 깨진 서비스는 무시하도록 오류 처리를 더해, 같은 일이 다시 나도 그 서비스가 발견되지 않을 뿐 크래시 루프에 빠지지 않게 했다.
   • Go 프로젝트에 이 문제를 버그로 보고한다.

   교훈

   서비스 디스커버리 시스템은 etcd 안의 여러 장애에는 견디도록 만들었지만, 일시적인 네트워크 오류로 값 없는 키가 쓰일 수 있다는 것은 예상하지 못했다. 이 경우 Go 의 net/http 는 HTTP 1.1 규격을 어겨, Content-Length 헤더가 있고 본문이 불완전한 요청을 거부하지 않는다. 이 때문에 예상하지 못한 장애 상황이 하나 더 생겼다.

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