Incident Library

IL-0261 Discord · 2017-11-17gcpnetworking

GCP 네트워크가 잠깐씩 끊기면서 Discord sessions 클러스터 노드가 연달아 망가지고 서비스 전체가 두 번 멈췄다

2017년 11월 17일과 18일 24시간 동안 Discord 는 두 번 약 30분씩 완전히 멈췄고, 사용자 일부가 영향받는 작은 중단이 14번 더 있었다. 근본 원인은 Google Cloud Platform 네트워크 스택에 들어간 버그였다. 이 버그는 네트워크를 많이 쓰는 sessions 클러스터의 노드에서만 16번 네트워크를 끊었다. 네트워크가 끊기면 Erlang VM 의 net_kernel 이 과부하에 걸리고 Erlang distribution port 가 멈춰서, 메시지가 쌓인 프로세스의 메모리가 계속 늘었다.

17일 11시 39분부터 sessions 노드가 하나씩 망가졌다. 엔지니어들은 메모리 부족 알림이 울린 노드를 안전하게 빼려다 실패하면 강제로 종료했고, 처음 두 번은 문제가 없었다. 14시 13분 sessions-1-13 의 강제 종료가 연쇄 장애를 일으켰고, 엔지니어들은 14시 21분에 핵심 서비스 여러 개를 재시작했다. 이 작업을 하면 연결된 클라이언트 수백만 대가 약 20분에 걸쳐 다시 연결된다. 엔지니어들은 15시 7분에 첫 정상화를 알렸다. 그날 밤 Discord 는 강제 종료하고 재부팅한 노드가 다시 망가지지 않는 것을 보고 sessions 클러스터 전체를 종료하고 재부팅하기 시작했다.

18일 11시 38분 sessions-1-11 에서 같은 문제가 나며 시스템이 다시 연쇄적으로 무너졌다. 엔지니어들은 sessions 클러스터를 재시작했다. 12시 4분에는 전 세계에서 메시지 전송을 끈 뒤 클러스터 전체를 재시작했고, 12시 31분에 메시지 전송을 다시 켰다. 서비스 디스커버리 구성 요소의 성능 저하와 내부 HTTP 라이브러리의 불안정이 복구를 늦췄다. 13시 30분에 Google 은 금요일에 네트워크 스택에 넣은 변경을 롤백하기 시작했다고 알렸고, 15시 30분쯤 롤백이 끝났다. 그 뒤 네트워크 문제는 한 번도 다시 나지 않았다.

심각도
–
영향 범위
Discord service completely offline for two periods of about 30 minutes, plus fourteen minor interruptions for portions of the userbase, over 24 hours
영향 사용자
all Discord users during the two full outages; millions of connected clients had to reconnect during the restarts
지역
–
감지까지
13m
복구까지
24h 52m

증상

2017년 11월 17일 PST 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 이어서 sessions 클러스터의 다른 노드들에서 메모리 부족 알림이 차례로 울렸다.

조사해 보니 sessions-1-16 의 서비스가 11시 40분에 재시작됐고 그 노드의 클라이언트가 그 전에 끊겨 있었다. 엔지니어들은 원인을 네트워크 수준의 문제가 애플리케이션 버그를 건드린 것으로 봤다. 11시 50분에는 sessions-1-9 가 비슷한 네트워크 문제로 guilds 클러스터의 멤버들과 연결이 잠깐 끊겼다. 이 노드는 재시작되지 않고 잘못된 상태로 남았다.

12시 1분에 sessions-1-9 의 메모리 부족 알림으로 당번 엔지니어가 호출됐다. 엔지니어들은 노드끼리 통신하는 데 쓰는 "Erlang distribution port" 가 고장 난 것으로 보인다고 판단했다. 이 상태는 이전 장애에서도 본 적이 있었다. 나중에 분석해 보니, 네트워크 불안정 때문에 노드 사이 통신을 맡는 Erlang VM 의 net_kernel 이 과부하에 걸렸다. 그러면서 distribution port 가 "wedged" 상태가 됐고, 메시지가 쌓여 프로세스 메모리가 끝없이 늘었다.

엔지니어들은 처음에 문제 노드를 안전하게 빼려고 했지만 12시 14분에 그 절차가 실패해 노드를 강제로 종료했다. 이 강제 종료는 문제를 일으키지 않았고, 12시 38분 sessions-1-14 에서도 같은 일이 되풀이됐다. 12시 11분에 한 엔지니어가 이 현상이 Google Compute Engine 네트워크에서 예전에 본 network split 과 닮았다고 짚었다.

14시 6분 sessions-1-13 에서 같은 메모리 문제가 났고, 14시 13분의 강제 종료가 이번에는 연쇄 장애를 일으켜 서비스 전체가 무너졌다. 다음 날 11월 18일 11시 38분에는 sessions-1-11 에서 다시 네트워크 문제가 났다. 11시 40분에 고객 경험 팀이 지원 채널의 신고를 올렸고, 11시 46분에 시스템이 연쇄적으로 무너졌다. 상태 페이지에는 오프라인 길드와 연결 문제로 다시 큰 장애를 조사한다는 글이 올라갔다.

18일 복구 때는 회복이 비정상적으로 느렸다. 엔지니어들은 정상 복구를 늦추는 애플리케이션 버그가 하나 더 있다고 봤다. 사후 분석에서는 서비스 디스커버리 내부 구성 요소의 성능 저하와 Erlang 스택이 쓰는 HTTP 라이브러리의 불안정이 복구를 크게 늦춘 것으로 드러났다.

17일 14시 59분에 Discord 엔지니어들은 Google 네트워크 문제라고 확신하고 있었지만, Google 은 17일 내내 자기 쪽에 문제가 있다는 징후를 찾지 못했다. Google 엔지니어들이 원인을 찾아 해결하기까지 24시간 넘게 걸렸다.

증상 네트워크 도달 불가메모리 압박서비스 중단

원인

원인 클라우드 제공자 장애

구성 요소 서비스 디스커버리
기여 요인 디버그 접근 제한수동 조치 악화
촉발
Google 이 Google Cloud Platform 네트워크 스택에 내보낸 업그레이드가 Discord VM 의 네트워크 연결을 짧게 여러 번 끊었다. 네트워크를 많이 쓰는 sessions 클러스터 노드에서만 16번 일어났다.

감지

17일 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 그 뒤로는 sessions 노드의 메모리 부족 알림으로 당번 엔지니어가 호출됐다. 18일에는 11시 38분 네트워크 문제로 당번 엔지니어가 호출됐고, 11시 40분에 고객 경험 팀이 지원 채널의 신고를 올렸다.

조치

후속 조치

교훈

Discord 는 두 번의 큰 장애가 그만큼 커진 데에는 Discord 시스템의 성능과 안정성 문제가 크게 작용했다고 봤다. 이런 형태의 네트워크 장애가 서비스의 연쇄 장애를 일으킬 수 있었기 때문이다. 일부 사용자에게만 머물렀어야 할 문제가 시스템 전체 장애 두 번으로 번진 데에는 여러 문제가 있었고, Discord 는 후속 조치로 그 문제 대부분을 풀 수 있다고 봤다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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