Incident Library

IL-0298 Wikimedia Foundation · 2025-03-31database

Wikimedia sessionstore 의 Cassandra 노드가 디스크가 가득 차 잇따라 죽고 쿼럼을 잃어 편집이 실패했다

2025-03-31 02:58 UTC 무렵 두 데이터센터의 sessionstore 에서 Cassandra 노드 여러 대가 디스크 고갈로 죽었다. 죽은 노드가 많아 클라이언트가 쿼럼을 만들 수 없게 됐고, 서비스가 500 오류를 내며 편집이 실패했다. Cassandra 의 저장 구조는 로그 구조라서 덮어쓰기가 제자리에서 일어나지 않고, 덮어쓴 옛 값은 컴팩션 때 지워진다. 세션을 높은 비율로 덮어쓰는 비정상적인 워크로드가 컴팩션이 치울 수 있는 속도를 넘어서며 공간이 바닥났다. 조사는 이어지고 있지만, 이 워크로드는 SUL3 롤아웃과 시기가 강하게 겹친다. 장애 전까지 팀은 sessionstore 클러스터의 용량이 지나치게 넉넉하다고 여겼다. 03:04 에 호출이 나가 03:09 에 대응이 시작됐다. 03:14 에 Cassandra 를 보려고 다른 엔지니어를 불렀다. 03:18 에 노드 다수가 내려가 쿼럼을 만들 수 없다는 것을 확인했고, 03:22 에 디스크 고갈과 3월 10일 무렵부터 이어진 사용률 상승을 확인했다. 03:32 에 서비스를 되살리려고 스토리지를 지우기로 했다. 03:36 에 스토리지를 지우고 Cassandra 를 재시작하자 편집이 다시 들어왔고, 03:40 무렵 평소 수준으로 돌아왔다. 스토리지를 지우면서 모든 세션이 사라졌다. 장애는 batphone 시간대인 UTC 기준 월요일 이른 시각에 일어나 대응이 늦어졌다.

심각도
–
영향 범위
Edits failed for the whole outage; all sessions were removed when the storage was wiped
영향 사용자
–
지역
Both data centres
감지까지
5m
복구까지
38m

증상

2025-03-31 02:58 UTC 에 두 데이터센터의 sessionstore 서비스가 500 오류를 내기 시작했고 편집이 실패했다. 03:03 에 세션 손실을 알리는 MediaWikiEditFailures 가 critical 로 울렸고, 03:04 에 SessionStoreErrorRateHigh 가 호출을 보냈다.

SessionStoreErrorRateHigh 는 높은 5xx 비율을 알렸을 뿐, 그 뒤에서 Cassandra 노드 여러 대가 완전히 멈췄다는 사실은 알림에 드러나지 않았다.

03:18 에 Cassandra 를 쓸 수 없는 상태임을 확인했다. 많은 노드가 내려가 있어 쿼럼을 만들 수 없었다. 03:22 에 디스크 공간 고갈이 원인으로 드러났고, 디스크 사용률은 2025-03-10 무렵부터 꾸준히 오르고 있었다.

증상 오류율 상승서비스 중단노드 디스크 가득 참데이터 유실

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 한계 경보 부재미검증 가정
촉발
세션 쓰기가 늘어 저장 장치를 채웠다. 쓰기가 늘어난 배경에는 세션을 높은 비율로 덮어쓰는 비정상적인 워크로드가 있었고, 이 워크로드는 SUL3 롤아웃과 시기가 강하게 겹쳤다.

감지

03:04 UTC 에 SessionStoreErrorRateHigh 가 높은 5xx 비율로 울려 batphone 으로 호출이 나갔고, 그 1분 앞서 03:03 에 MediaWikiEditFailures 가 critical 로 울렸다. Cassandra 노드의 디스크 사용률이나 증가 속도에는 자동 알림이 없었다. 사용자 신고도 task T390512 로 들어왔다.

조치

후속 조치

교훈

노드 장애는 디스크 공간이 모자라서 났고, 그 전의 저장 증가 속도로 장애 시점을 내다볼 수 있었다. 노드가 죽기 한참 전에 높은 저장 사용률을 알렸다면 영향이 생기기 전에 막을 기회가 있었다. 5xx 비율로 호출한 것은 맞았다. 다만 Cassandra 노드가 치명적인 수만큼 죽었다는 알림이 따로 있었다면 대응하는 엔지니어에게 상황을 더 잘 알려 줬을 것이다. 지나치게 넉넉하다고 여긴 클러스터도 비정상적인 워크로드가 생기면 감당할 수 없이 빠르게 찰 수 있다. 디스크가 고갈됐을 때 스토리지를 비우는 완화책도 서비스를 흔든다. 그래도 편집이 계속 멈추는 것보다는 영향이 작다. sessionstore 쓰기 비율이 오른 데 워크로드 변화와 SUL3 마이그레이션 같은 요인이 어떻게 얽혔는지는 지금도 파악하기 어렵다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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