Incident Library

IL-0213 Roblox · 2021-10-28database

Consul 클러스터의 KV 쓰기가 느려지고 리더가 뒤처지며 Roblox 전체가 73시간 동안 멈췄다

Roblox 는 자체 데이터센터의 18,000대가 넘는 서버와 170,000개의 컨테이너를 Nomad, Consul, Vault 로 운영한다. Consul 은 서비스 디스커버리, 헬스 체크, 세션 잠금, KV 저장소를 맡고, 투표권이 있는 voter 5대와 읽기 전용 non-voter 5대로 이루어지며 Raft 로 리더를 뽑는다. 사고 몇 달 전 Roblox 는 CPU 와 네트워크 사용을 줄이는 streaming 기능을 쓰려고 Consul 1.9 에서 1.10 으로 올렸고, 백엔드 서비스에 차례로 켜 왔다. 10월 27일 14:00 PST 에 트래픽 라우팅 서비스에도 streaming 을 켜고 라우팅 노드를 50% 늘렸다.

10월 28일 13:37 PST 에 Vault 성능이 떨어지고 Consul KV 쓰기 지연이 2초로 올랐으며, 16:35 에 플레이어가 절반으로 줄고 시스템 전체가 멈췄다. Consul 이 단일 장애 지점이었기 때문이다. HashiCorp 엔지니어가 합류한 대응 팀은 느린 하드웨어, 트래픽 증가, 재접속하는 컨테이너의 부하를 차례로 의심했다. 노드를 교체하고, 128코어 서버로 옮기고, 스냅샷으로 클러스터를 초기화하고, 외부 트래픽을 막고 꼭 필요하지 않은 Consul 사용을 끄고, 64코어 서버로 되돌렸지만 모두 소용없었다. 텔레메트리 시스템도 Consul 에 기대고 있어 원인을 찾는 데 필요한 데이터가 없었다.

10월 30일 perf report 와 플레임 그래프에서 streaming 코드 경로가 경합을 일으킨다는 증거를 찾았다. streaming 은 롱 폴링보다 동시성 제어 요소인 Go 채널을 적게 써서, 읽기와 쓰기 부하가 모두 매우 높으면 채널 하나에 경합이 몰려 쓰기가 막혔다. NUMA 구조의 2소켓 128코어 서버에서는 경합이 더 심해졌다. 모든 Consul 시스템에서 streaming 을 끄자 15:51 에 KV 쓰기의 p50 지연이 300ms 로 내려갔다. 일부 리더가 여전히 느려 그런 리더가 뽑힌 채로 남지 않게 막았다. 사고 뒤 HashiCorp 는 Raft 로그를 담는 BoltDB 의 freelist 문제가 원인임을 밝혔다. 4.2GB 로그 저장소에 실제 데이터는 489MB 뿐이었고 freelist 가 7.8MB 라서, 16kB 이하를 쓸 때마다 7.8MB freelist 를 디스크에 새로 썼다.

Consul 이 안정된 뒤 대응 팀은 평소 초당 10억 건을 처리하는 캐시 시스템을 다시 배포했다. 스냅샷 초기화로 Consul KV 의 스케줄링 데이터가 틀어져 있었다. 잡 스케줄러는 unhealthy 노드를 비어 있는 노드로 봐서 캐시 작업을 몰아넣었고, 배포 도구는 처음부터 큰 클러스터를 세우는 용도가 아니었다. 10월 31일 05:00 에 Consul 과 캐시가 정상이 됐다. 대응 팀은 서비스들을 알맞은 용량으로 다시 띄운 뒤 DNS 조정으로 무작위로 고른 플레이어를 약 10% 씩 늘려 들였다. 16:45 PST 에 모든 플레이어가 들어와 73시간 만에 완전히 복구됐다. 사용자 데이터 손실이나 무단 접근은 없었다.

심각도
–
영향 범위
Roblox fully down: online players fell to 50% of normal at 16:35 on 28 October and the system then went fully down, until all players were let back in at 16:45 on 31 October; no user data was lost
영향 사용자
Roblox players; fifty million players use Roblox every day
지역
Roblox data centers
감지까지
–
복구까지
73h

증상

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

Consul 클러스터 지표에서 Consul 이 데이터를 담는 KV 저장소의 쓰기 지연이 올라갔다. 이 작업의 p50 지연은 평소 300ms 아래였는데 2초가 됐다. 클러스터는 노드 대부분이 쓰기를 따라가지 못한다고 보고했다.

16:35 에 동시 접속 플레이어 수가 평소의 50% 로 떨어졌고, 이어 시스템 전체가 멈췄다. Roblox 서비스는 서로를 찾을 때 Consul 에 기대고 Nomad 와 Vault 도 Consul 에 기댄다. 그래서 서버끼리 연결이 어려워졌고, 새 컨테이너를 스케줄하거나 인증에 쓰는 운영 시크릿을 가져올 수도 없었다. 원인을 보여 줄 모니터링 시스템도 Consul 에 기대고 있어 대응 팀은 텔레메트리 없이 원인을 찾아야 했다.

대응 팀은 먼저 하드웨어가 느려졌다고 의심해 Consul 노드 한 대를 바꿨지만 나아지지 않았다. 다음에는 트래픽 증가를 의심해 모든 노드를 코어 수가 두 배인 128코어와 더 빠른 NVME SSD 를 단 서버로 바꿨지만 KV 쓰기의 p50 지연은 여전히 2초 안팎이었다.

Consul 리더가 투표권을 가진 다른 서버인 voter 들과 자주 동기화가 어긋나는 증상이 새로 나타났고, 원인을 설명할 수 없었다. 대응 팀은 장애 시작 무렵의 스냅샷으로 클러스터를 되돌리고 iptables 로 접근을 막았다가 풀었다. 그러자 내부 서비스의 서비스 디스커버리와 헬스 체크 부하가 돌아오면서 KV 쓰기 지연이 다시 2초로 올랐고 Consul 에 기대는 서비스들이 스스로를 unhealthy 로 표시했다.

대응 팀은 모든 외부 트래픽을 막고, 꼭 필요하지 않은 Consul 사용을 끄고, 서비스 인스턴스를 한 자릿수로 줄이고, 헬스 체크 간격을 60초에서 10분으로 늘린 뒤 서비스를 다시 올렸다. 그래도 10월 30일 02:00 에 Consul 은 훨씬 적은 부하에서 다시 나빠졌다. 64코어 서버로 되돌려도 나아지지 않았다.

디버그 로그와 운영체제 지표에서 Consul KV 쓰기가 경합 때문에 오랫동안 막혀 있는 것이 보였다. perf report 에서는 대부분의 시간이 Streaming 구독 코드 경로의 커널 스핀락에서 쓰였다. streaming 을 끈 뒤에도 일부 서버가 리더로 뽑히면 같은 지연이 나타났고, 이런 리더에서는 TCP 버퍼가 가득 차 TCP Zero Window 가 생기고 쓰기가 2~3초 걸렸다. 나중에 본 BoltDB 통계에서 Raft 로그를 담는 4.2GB 저장소에 실제 데이터는 489MB 뿐이고 3.8GB 가 빈 공간이었다. BoltDB 는 로그를 덧붙일 때마다 빈 페이지 id 가 백만 개 가까이 든 7.8MB 짜리 빈 페이지 목록인 freelist 를 디스크에 새로 썼다.

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

원인

원인 소프트웨어 결함

구성 요소 코디네이션 키-값 저장소서비스 디스커버리인메모리 캐시
기여 요인 단일 장애점장애 중첩모니터링 사각지대수동 조치 악화늦게 드러난 변경
촉발
10월 27일 14:00 PST 에 트래픽 라우팅을 맡는 백엔드 서비스에 Consul 의 새 streaming 기능을 켰다. 같은 롤아웃에서 연말 트래픽에 대비해 트래픽 라우팅 노드 수를 50% 늘렸고, 하루 뒤 Consul 성능이 떨어지기 시작했다.

감지

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

조치

후속 조치

교훈

Roblox 는 원인 두 가지가 Consul 구현 깊숙이 묻혀 있어 진단이 어려웠던 것이 장애를 길게 만든 주된 이유라고 봤다. 원인을 보여 줄 모니터링 시스템이 장애가 난 Consul 에 기대고 있어 분석이 크게 막혔다. 모든 백엔드 서비스를 Consul 클러스터 하나에 올린 구성이 이런 장애에 취약했다.

HashiCorp 는 Roblox 와 비슷한 규모에서 streaming 을 벤치마크했지만, 이 경합은 스트림 수가 많고 교체가 잦은 조건이 겹칠 때만 나타나 전에는 보지 못했다. 더 빠른 하드웨어는 도움이 되지 않았고 오히려 안정성을 해쳤을 수 있다. 오래 완전히 멈춘 상태에서 서비스를 올리는 데도 캐시 배포와 데우기 때문에 시간이 많이 걸렸다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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