Incident Library

IL-0216 Wikimedia Foundation · 2023-09-20database

데이터센터 전환 직후 CirrusSearch Elasticsearch 지연이 치솟아 위키 검색이 일부 사용자에게 늦거나 안 됐다

2023년 9월 20일 14:00 UTC 에 Wikimedia 는 주 데이터센터를 EQIAD 에서 CODFW 로 전환했다. 팀은 more_like 쿼리가 모두 주 데이터센터가 아닌 MediaWiki 데이터센터인 eqiad 로 갈 것으로 예상했지만, 주 데이터센터인 codfw 로 갔다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보내 주 데이터센터로 갈 수밖에 없었던 것이 원인으로 보였다. 같은 시각부터 PoolCounter 가 쿼리를 최대 25% 까지 거부했다. 요청 응답 시간이 길어진 것이 원인이었고, 캐시 적중률이 71.6% 에서 55.5% 로 떨어져 응답 시간이 더 나빠졌다. 14:08 UTC 에 more_like p95 지연 알림이 울렸고, 데이터센터 전환으로 경계하던 SRE 들이 곧바로 문제를 알아챘다.

14:26 UTC 에 Grafana 에서 elastic2044 의 부하가 극도로 높은 것을 보고 inflatador 가 이 노드를 클러스터에서 뺐고, 지연이 정상으로 내려가기 시작했다. 14:34 UTC 에 영향이 끝난 것을 확인했고 14:35 UTC 에 PoolCounter 거부가 0 이 됐다. 문제는 약 30분 만에 풀렸는데, 스스로 회복했는지 노드를 뺀 덕분인지는 가리지 않았다. Dcausse 는 enwiki 샤드 두 개가 같은 호스트에 있었을 수 있다고 봤는데, 이런 배치는 more_like 쿼리에서 특히 비용이 크다. 그렇다면 데이터센터 전환이 문제를 키웠을 뿐 직접 일으키지는 않은 셈이다.

심각도
–
영향 범위
On-wiki search for all wikis delayed or unavailable for a subset of end users; up to 25% of search queries rejected by the PoolCounter at the peak
영향 사용자
a subset of end users of all Wikimedia wikis
지역
codfw datacenter
감지까지
6m
복구까지
24m

증상

2023년 9월 20일 14:08 UTC 에 "CirrusSearch codfw 95th percentile latency - more_like" 알림이 울렸다. 그동안 모든 위키의 검색이 일부 사용자에게 늦거나 되지 않았다.

알림은 PROBLEM alert - graphite1005/CirrusSearch codfw 95th percentile latency - more_like is CRITICAL 이라는 문구로 IRC 와 Search Platform 메일 목록에 갔다.

14:00 UTC 에 주 데이터센터를 EQIAD 에서 CODFW 로 바꾼 직후부터 동시 요청 수를 제한하는 PoolCounter 가 쿼리 일부를 거부하기 시작했고, 정점에는 25% 까지 거부했다. 요청 응답 시간이 길어진 탓이었고, 캐시 적중률이 71.6% 에서 55.5% 로 떨어지며 응답 시간이 더 나빠졌다. 팀은 more_like 쿼리가 주 데이터센터가 아닌 eqiad 로 갈 것으로 예상했지만, 쿼리는 codfw 로 가고 있었다.

14:26 UTC 에 Grafana 에서 elastic2044 의 부하가 극도로 높은 것이 보였다. 이 노드를 클러스터에서 빼자 지연이 정상으로 내려가기 시작했고, 14:35 UTC 에 PoolCounter 거부가 0 이 됐다.

증상 지연 시간 증가오류율 상승부하 불균형요청 오라우팅

원인

원인 소프트웨어 결함

구성 요소 Elasticsearch 와 OpenSearch인메모리 캐시
기여 요인 미검증 가정데워진 캐시에 기댄 구조런북 부재
촉발
14:00 UTC 에 주 데이터센터를 EQIAD 에서 CODFW 로 전환했다. 주 데이터센터가 아닌 eqiad 로 갈 것으로 예상한 more_like 쿼리가 주 데이터센터인 codfw 로 갔다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보낸 것이 원인으로 보였다.

감지

자동 모니터링이 먼저 찾았지만 사용자에게 영향이 가기 전에 막을 만큼 빠르지는 않았다. 14:08 UTC 에 CirrusSearch codfw more_like p95 지연 알림이 IRC 와 Search Platform 메일 목록으로 갔고, 14:14 UTC 에 Hashar 가 #wikimedia-search 에서 알려 엔지니어들이 문제를 찾기 시작했다. 호출받은 사람은 없었고, SRE 들은 데이터센터 전환 때문에 이미 경계하고 있었다.

조치

후속 조치

교훈

데이터센터 전환 때문에 SRE 들이 경계하고 있어 영향을 바로 알아챘고, 노드 하나를 빼는 간단한 조치로 빠르게 완화했다. 잘못된 점은 more_like 쿼리가 예상과 달리 주 데이터센터로 간 것이었다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보내 주 데이터센터로만 갈 수 있었던 것이 원인으로 보였다. 급히 완화하느라 부하가 높은 호스트의 샤드 배치는 확인하지 않았다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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