사례2건

2건 중 1~2번째

1. IL-0270 인증용 ScyllaDB 클러스터가 과부하로 조회를 처리하지 못해 Discord 에서 약 50분 동안 접속과 로그인이 되지 않았다

   Discord2023

   증상

   2023년 11월 6일 10:52 AM PST 에 업그레이드 스크립트가 scylla-authentication 클러스터의 존 c 연결을 모두 비우자, 2xx 응답 비율로 재는 Discord 의 가용성이 곧바로 약 25% 로 떨어졌다. 사용자는 접속, 로그인, 메시지 읽기와 보내기를 거의 할 수 없었다. 첫 알림은 4분쯤 뒤인 10:56 AM 에 울렸다.

   서비스 중단데이터베이스 과부하지연 시간 증가

   촉발

   2023년 11월 6일 운영체제 업그레이드 절차가 scylla-authentication 클러스터의 존 b 를 마친 뒤, 10:52 AM 에 스크립트가 존 c 의 연결을 모두 비우고 업그레이드를 시작했다. 존 b 에는 디스크 성능이 떨어진 노드가 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재장애 중첩데워진 캐시에 기댄 구조미검증 가정초기 신호 무시재시도 폭주

   감지

   첫 알림이 장애 시작 4분쯤 뒤인 10:56 AM 에 울렸지만, 팀은 그 전에 이미 사고 대응 통화를 열고 조사하고 있었다. 하위 서비스별 소요 시간 그래프가 인증 서비스를 가리켰고, 잠시 뒤 인증 알림이 울렸다.

   조치

   • 11:05 AM 에 인증 클러스터의 부하를 덜려고 입력 중 표시 이벤트와 메시지 읽음 표시를 껐다.
   • RAID 재구축이 끝나기를 기다려 11:41 AM 에 존 c 의 두 노드를 다시 올렸다.
   • 과부하였던 존 b 의 두 노드를 한 대씩 재시작했다.

   후속 조치

   • 사고 직후 scylla-authentication 클러스터를 두 배로 늘려 용량을 더했다.
   • scylla-authentication-b-2 를 성능이 떨어지지 않은 새 디스크로 다시 만들었다.
   • 전체 지연에는 드러나지 않을 만큼 약하지만 서비스 신뢰성에 위험이 될 수 있는 디스크 성능 저하를 찾아내는 방법을 만든다.
   • Scylla 클러스터의 컨트롤 플레인을 더 자동화하고 업그레이드 작업을 그곳으로 옮겨, 캐시 적중률 같은 클러스터 분석을 업그레이드 절차에 넣는다.
   • 복제 계수를 늘리거나 다른 리전에 핫 스탠바이 클러스터를 두는 방안을 검토해, 이 작고 중요한 클러스터의 이중화를 늘린다.

   교훈

   클러스터는 존 하나를 잃어도 견디게 설계했지만, 존 하나가 내려간 상태에서 다른 존의 노드 하나 성능이 떨어진 것만으로 이 정도 장애가 났다는 것은 클러스터의 용량이 부족했다는 뜻이다. 노드 재시작 전에 캐시 적중률이 일정 수준이 돼야 하는 것도 용량 부족의 신호다. 업그레이드 전 존 중단 시험은 계속 진행해도 안전하다는 잘못된 확신을 줬다. 이 작고 중요한 클러스터는 훨씬 큰 다른 클러스터들과 다르게 운영해야 한다.

   사례 보기
2. IL-0297 Mezmo 의 인증 캐시 Redis 서버가 OOM 으로 죽고 다시 뜨지 못해 로그인이 막히고 로그 색인이 늦어졌다

   Mezmo2019

   증상

   이른 아침에 알림과 고객 신고가 들어와 온콜이 호출됐다. 웹 애플리케이션에서 사용자가 로그인할 수 없었고, 상태 페이지는 2019-05-15 16:59 UTC 에 색인 지연으로 들어오는 로그가 live tail 과 search 에 늦게 나타난다고 알렸다.

   서비스 중단OOMKilled데이터베이스 과부하처리량 저하

   촉발

   로그 배치를 추적하는 도구가 트래픽 급증을 감당할 크기가 아니어서 인증 캐시의 Redis 서버를 무너뜨렸다.

   원인

   용량 한계

   구성 요소

   인메모리 캐시데이터베이스

   기여 요인

   데워진 캐시에 기댄 구조

   감지

   이른 아침에 알림과 고객 신고가 들어와 에스컬레이션 절차가 시작됐고 온콜 담당자가 호출됐다.

   조치

   • 클러스터의 특정 부분을 키워 훨씬 큰 트래픽을 견디게 했다.

   후속 조치

   • 배치 추적 시스템을 다시 만들어 Redis 클러스터에 주는 직접 부담을 줄인다.
   • 배치 추적 기능 전반의 관측용 계측을 늘린다.
   • Redis 모니터링을 강화한다.
   • 이 장애에 얽힌 파이프라인의 병목을 없앤다.

   교훈

   Mezmo 는 기능을 늘려 갈수록 플랫폼 전반에 깊은 계측과 트레이싱, 관측성이 필요하다는 목표를 다시 확인했다.

   사례 보기

원인별1