Incident Library

IL-0388 Discord · 2017-10-13databasegcp

Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다

2017년 10월 13일 14:01 PDT 쯤 Discord API 서비스가 쓰는 Redis 고가용 클러스터의 primary 인스턴스를 Google Cloud Platform 이 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 됐고, 클러스터는 secondary 노드로 failover 했다. 그러나 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다. 이 버그는 Discord 가 전부터 알고 있었고 몇 주 안에 고치기로 일정을 잡아 둔 것이었다. 엔지니어들은 GCP 지원에 P1 티켓을 올리고, 14:11 에 모든 API 인스턴스를 롤링 재시작했다.

재시작 뒤에도 API 지연이 계속 높았다. 14:18 부터 14:57 사이에 비용이 큰 API 경로 하나에 엣지 캐시 규칙이 잘못 걸려 클라이언트가 그 경로를 공격적으로 호출한다는 것을 찾아 고쳤다. 그 요청량으로 중요하지 않은 Cassandra 클러스터 하나가 쓰러졌다. 엔드포인트를 쓸 수 없는 동안에는 응답을 캐시할 수 없어서, 상위 엣지 네트워크에서 그 엔드포인트를 막았다. Cassandra 클러스터를 되살린 뒤 API 인스턴스를 다시 롤링 재시작했고, 14:57 에 API 가 정상으로 돌아왔다.

15:41 에 다시 이상이 보였다. "guilds" 클러스터의 노드 하나가 잘못 동작해 길드 일부가 오프라인으로 보였고, 엔지니어들은 그 노드를 해시링에서 강제로 빼고 강제로 재시작했다. 이어 "sessions" 클러스터의 노드 몇 개도 이상하게 동작하자, 16:07 에 모든 사용자를 다시 접속시켜 여러 서비스의 잘못된 상태를 초기화하는 전체 재시작을 하기로 했다. 재시작 중 16:19 에 "push" 구성 요소가 또 실패해, 한 엔지니어는 이를 고치고 다른 엔지니어는 이 구성 요소에 기대는 트래픽 일부를 막아 부하를 줄였다. 사용자가 빠르고 안전하게 다시 접속하게 해 주는 중요한 API 설정이 사람의 실수로 잘못 들어가 있던 것도 찾아 고쳤다. 16:33 부터 서비스가 천천히 회복했고 16:52 에 완전히 복구됐다. 수백만 클라이언트가 20분에 걸쳐 다시 접속했다.

처음의 API 부분 장애가 왜 전체 장애로 번졌는지는 사후 분석을 쓴 시점까지 밝혀지지 않았다. 처음 장애가 다른 서비스의 노드 일부를 잘못 동작하게 했고, 그 노드들이 결국 메모리가 바닥나 죽으면서 여러 안전장치가 있는데도 연쇄 장애를 일으켰다. 그 뒤 토요일에는 이 사후 분석의 결과로 더한 알림이 같은 증상을 잡았다. 엔지니어들은 해당 노드를 안전하게 빼서 조사했고, 그 서비스가 쓰는 라이브러리에서 결함으로 보이는 것을 찾았다.

심각도
–
영향 범위
API latency and errors, then guilds appearing offline and connection failures, ending in a full restart of Discord that reconnected all clients
영향 사용자
Discord users; millions of clients reconnected over about 20 minutes
지역
–
감지까지
0m
복구까지
2h 51m

증상

2017년 10월 13일 14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. API 서비스가 쓰는 Redis 고가용 클러스터에서 primary 노드가 완전히 사라졌다. 클러스터는 secondary 노드로 제대로 failover 했지만, 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다.

API 인스턴스를 롤링 재시작한 뒤에도 API 엔드포인트의 지연이 비정상으로 높았다. 비용이 큰 API 경로 하나에 엣지 캐시 규칙이 잘못 걸려 있어 클라이언트가 그 경로를 공격적으로 호출했다. 이 요청량 때문에 중요하지 않은 Cassandra 클러스터 하나가 부하를 못 이기고 쓰러졌다.

15:41 PDT 에 모니터링에서 다시 이상이 보였고, 15:42 에는 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다. "guilds" 클러스터의 노드 하나가 이상하게 동작해 Discord 길드 일부가 사용자에게 오프라인으로 보였다. 상태 페이지에는 15:54 PDT 에 길드를 쓸 수 없고 접속에 문제가 있다는 공지가 올라왔다.

15:55 PDT 에는 "sessions" 클러스터의 노드 몇 개도 이상하게 동작했다. 처음 장애가 다른 서비스의 노드 일부를 잘못 동작하게 했고, 그 노드들은 결국 메모리가 바닥나 죽으면서 연쇄 장애를 일으켰다. 16:19 PDT 에는 전체 재시작 도중 "push" 라는 구성 요소에서 또 장애 알림이 왔다.

처음에는 Redis 연결 문제를 풀려고 14:11 PDT 에 모든 API 인스턴스를 롤링 재시작했고, 14:15 에 끝났다. guilds 노드는 서비스 해시링에서 강제로 빼 스스로 내려가게 하려 했고, 이어 강제로 재시작했다.

증상 장애 조치 실패지연 시간 증가서비스 중단

원인

원인 소프트웨어 결함

구성 요소 인메모리 캐시데이터베이스CDN 과 엣지 네트워크
기여 요인 미패치 알려진 버그장애 중첩모니터링 사각지대
촉발
14:01 PDT 쯤 Google Cloud Platform 이 API 서비스용 Redis 고가용 클러스터의 primary 인스턴스를 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 되면서 클러스터가 재조정됐고, API 인스턴스의 Redis failover 처리에 있던 알려진 문제가 드러났다.

감지

14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. 15:41 에 모니터링에서 다시 이상이 보였고, 15:42 에 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다.

조치

후속 조치

교훈

–

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인메모리 캐시, 데이터베이스, CDN 과 엣지 네트워크. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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