Incident Library

IL-0270 Discord · 2023-11-06database

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

Discord 의 scylla-authentication 클러스터는 사용자 세션 정보를 담고, Rust 로 만든 인증 서비스가 그 앞에서 모든 API 요청의 인증을 확인한다. 이 클러스터는 표준 구성대로, 빠르지만 재부팅하면 지워지는 NVMe 로컬 SSD 와 느리지만 지워지지 않는 영구 디스크를 RAID 로 미러링한다. 데이터는 세 존에 복제하고 쿼럼 읽기를 써서, 존 하나를 잃어도 요청을 처리하도록 설계됐다. 인스턴스가 뜰 때 영구 디스크의 데이터를 NVMe 로 복사하는 RAID 동기화가 40분쯤 걸리고, 이것이 끝나야 Scylla 가 시작한다.

11월 3일부터 영속성 인프라 팀은 존을 하나씩 내려 디스크를 떼고 인스턴스를 종료한 뒤, 새 운영체제의 인스턴스에 디스크를 다시 붙이는 방식으로 Scylla 클러스터들의 운영체제를 업그레이드했다. 존 하나를 내리면 연산 용량이 3분의 1 줄고 여유가 없어져서, 다른 존에 문제가 하나만 더 생겨도 쿼럼을 잃는다. 디스크를 뗀 뒤에는 RAID 재구축 때문에 적어도 45분 동안 용량을 되돌릴 수 없다. 팀은 인증 클러스터를 업그레이드하기 전에 존 b 를 10분 동안 내려 성능을 시험했고 문제가 없었다. 9:16 AM 에 업그레이드를 시작해 10:42 AM 에 존 b 를 마쳤다. 이때 scylla-authentication-b-2 의 RAID 재구축이 유난히 느렸지만 팀은 이상한 점으로만 보고 넘겼다. 운영자는 클러스터가 정상인 것을 확인하고 다음 존으로 넘겼고, 10:52 AM 에 존 c 의 연결이 모두 비워지면서 장애가 시작됐다.

원인은 여러 가지가 겹친 것이었다. 클러스터는 용량이 부족했다. scylla-authentication-b-2 의 NVMe 로컬 SSD 하나가 성능이 떨어져 디스크 I/O 가 나빴다. 이 클러스터는 행 캐시 적중률이 일정 수준이 돼야 노드를 안전하게 재시작할 수 있다. 그런데 팀은 앞선 시험으로 잘못된 확신을 얻어, 방금 재시작한 존 b 노드의 캐시 적중률을 확인하지 않았다. 애플리케이션의 재시도 폭주가 부하를 더 키웠다. 존 c 는 디스크가 이미 떼어져 다시 올리려면 45분쯤 기다려야 했다. 팀은 11:05 AM 에 입력 중 표시와 읽음 표시를 꺼 부하를 덜었고 사용자의 약 50% 가 회복됐다. 노드를 재시작하면 쿼럼이 확실히 깨질 수 있어서, 팀은 재시작하지 않고 원인을 찾았다. 존 b 노드들이 과부하라는 것을 알아낸 11:35 AM 에는 RAID 재구축이 5분 남아 있어 기다리기로 했다. 11:41 AM 에 존 c 의 두 노드가 올라오자 존 b 노드를 한 대씩 재시작했고 11:43 AM 에 사용자 활동이 정상으로 돌아왔다. 장애는 서비스 가용성에만 영향을 줬고, 인증 서비스가 내놓은 결과의 정확성에는 영향이 없었다. 외부 공격이나 무단 접근 때문도 아니었다.

심각도
–
영향 범위
Discord authentication: users could not connect, log in, read or send messages; availability fell to about 25%, then about 50% of users could use Discord until 11:43 AM PST
영향 사용자
Discord users; about 50% could use the service from 11:05 AM until recovery
지역
–
감지까지
4m
복구까지
51m

증상

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

하위 서비스별 소요 시간 그래프에서 인증 서비스가 사용자 요청을 처리하는 데 평소보다 훨씬 오래 걸리는 것이 보였다. 시점이 겹쳐 팀은 진행 중이던 인증 클러스터 업그레이드를 곧바로 의심했고, 잠시 뒤 인증 알림이 울려 의심이 맞았음을 확인했다.

인증 클러스터는 쿼리로 포화돼 지연이 높았다. 11:05 AM 에 입력 중 표시 이벤트와 메시지 읽음 표시를 끄자 사용자의 약 50% 가 다시 인증됐지만 완전히 회복되지는 않았다. 노드 네 대가 모두 과부하였고, 노드마다 일부 샤드의 부하가 100% 였다.

서버 오류가 나면 애플리케이션이 인증 엔드포인트 요청을 다시 보냈다. 요청이 타임아웃되기 시작하자 재시도가 폭주해 Scylla 클러스터의 부하가 더 커졌다.

인증 서비스의 오류 메시지가 엉뚱한 쪽을 가리켜 조사가 한 번 빗나갔다. 그 뒤 Scylla 로그에서 존 b 의 두 노드 scylla-authentication-b-1 과 scylla-authentication-b-2 에 연결하는 오류가 나오는 것을 보고 두 노드가 과부하임을 알았다.

업그레이드 중 존 b 를 내렸을 때 클러스터의 지연과 오류율은 정상이었다. 다만 scylla-authentication-b-2 는 짝 노드보다 RAID 배열을 훨씬 느리게 다시 만들었다. 팀은 이를 이상한 점 정도로만 보고 넘겼다. 이 노드에 붙은 NVMe 로컬 SSD 하나가 성능이 떨어져 있었다.

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

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 여유 용량 부재장애 중첩데워진 캐시에 기댄 구조미검증 가정초기 신호 무시재시도 폭주
촉발
2023년 11월 6일 운영체제 업그레이드 절차가 scylla-authentication 클러스터의 존 b 를 마친 뒤, 10:52 AM 에 스크립트가 존 c 의 연결을 모두 비우고 업그레이드를 시작했다. 존 b 에는 디스크 성능이 떨어진 노드가 있었다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.