{"id":"IL-0216","org":"Wikimedia Foundation","date":"2023-09-20","docs":["https://phabricator.wikimedia.org/T285347"],"title":{"en":"Wikimedia on-wiki search was slow or rejected after a datacenter switchover overloaded one Elasticsearch node in codfw","ko":"데이터센터 전환 직후 CirrusSearch Elasticsearch 지연이 치솟아 위키 검색이 일부 사용자에게 늦거나 안 됐다"},"domain":["database"],"impact":{"scope":"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","users":"a subset of end users of all Wikimedia wikis","region":"codfw datacenter"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Monitoring caught the problem, but not quickly enough to prevent user-facing impact. The heightened attention during the switchover meant the impact was recognised immediately, and banning a single node was quick and easy. The mitigation was not guided by an existing runbook, and the shards on the overloaded host were not checked before it was banned.","ko":"데이터센터 전환 때문에 SRE 들이 경계하고 있어 영향을 바로 알아챘고, 노드 하나를 빼는 간단한 조치로 빠르게 완화했다. 잘못된 점은 more_like 쿼리가 예상과 달리 주 데이터센터로 간 것이었다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보내 주 데이터센터로만 갈 수 있었던 것이 원인으로 보였다. 급히 완화하느라 부하가 높은 호스트의 샤드 배치는 확인하지 않았다."},"related":[],"sources":[{"url":"https://wikitech.wikimedia.org/wiki/Incidents/2023-09-20_Elasticsearch_unavailable","kind":"runbook","archived":"https://web.archive.org/web/20260520042216/https://wikitech.wikimedia.org/wiki/Incidents/2023-09-20_Elasticsearch_unavailable"}],"summary":{"en":"Wikimedia's on-wiki search runs on Elasticsearch through CirrusSearch. During the switchover of the primary datacenter to codfw, more_like queries were expected to be routed to eqiad, the non-primary datacenter, but went to codfw instead, apparently because RESTBase sent these requests as POST rather than GET, which forces routing to the primary datacenter. The CirrusSearch cache hit rate fell from 71.6% to 55.5%, response times grew, and the PoolCounter rejected up to 25% of queries. Six responders troubleshot after a ping in #wikimedia-search; at 14:26 Grafana showed extremely high load on elastic2044, the node was banned from the cluster, latency began to return to normal, and by 14:35 the PoolCounter rejections were at zero. It is not certain whether the ban or the cluster healing by itself ended the incident. One responder theorised that two enwiki shards may have been on the same host, which is very expensive with more_like queries, so the switchover may have worsened the problem rather than caused it directly.","ko":"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 들이 곧바로 문제를 알아챘다.\n\n14:26 UTC 에 Grafana 에서 elastic2044 의 부하가 극도로 높은 것을 보고 inflatador 가 이 노드를 클러스터에서 뺐고, 지연이 정상으로 내려가기 시작했다. 14:34 UTC 에 영향이 끝난 것을 확인했고 14:35 UTC 에 PoolCounter 거부가 0 이 됐다. 문제는 약 30분 만에 풀렸는데, 스스로 회복했는지 노드를 뺀 덕분인지는 가리지 않았다. Dcausse 는 enwiki 샤드 두 개가 같은 호스트에 있었을 수 있다고 봤는데, 이런 배치는 more_like 쿼리에서 특히 비용이 크다. 그렇다면 데이터센터 전환이 문제를 키웠을 뿐 직접 일으키지는 않은 셈이다."},"trigger":{"en":"At 14:00 UTC the primary datacenter was switched from EQIAD to CODFW. more_like queries that were expected to go to eqiad, the non-primary datacenter, went to codfw instead, apparently because RESTBase sent them as POST rather than GET.","ko":"14:00 UTC 에 주 데이터센터를 EQIAD 에서 CODFW 로 전환했다. 주 데이터센터가 아닌 eqiad 로 갈 것으로 예상한 more_like 쿼리가 주 데이터센터인 codfw 로 갔다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보낸 것이 원인으로 보였다."},"severity":"unknown","symptoms":["high-latency","high-error-rate","uneven-load","requests-misrouted"],"timeline":{"detected_after":"6m","resolved_after":"24m"},"date_kind":"incident","detection":{"en":"Automated monitoring caught the problem, but not quickly enough to prevent user-facing impact: the Grafana alert \"CirrusSearch codfw 95th percentile latency - more_like\" went to IRC and the Search Platform email list at 14:08. No one was paged; SREs were already watching closely because of the datacenter switchover. At 14:14 Hashar pinged #wikimedia-search and engineers began troubleshooting.","ko":"자동 모니터링이 먼저 찾았지만 사용자에게 영향이 가기 전에 막을 만큼 빠르지는 않았다. 14:08 UTC 에 CirrusSearch codfw more_like p95 지연 알림이 IRC 와 Search Platform 메일 목록으로 갔고, 14:14 UTC 에 Hashar 가 #wikimedia-search 에서 알려 엔지니어들이 문제를 찾기 시작했다. 호출받은 사람은 없었고, SRE 들은 데이터센터 전환 때문에 이미 경계하고 있었다."},"components":["elasticsearch-opensearch","cache"],"root_cause":"software-bug","remediation":[{"text":{"en":"Banned the overloaded node elastic2044 from the Elasticsearch cluster","ko":"14:26 UTC 에 Grafana 에서 부하가 극도로 높은 elastic2044 를 보고 inflatador 가 이 노드를 클러스터에서 뺐고, 지연이 정상으로 내려가기 시작했다."}}],"action_items":[{"text":{"en":"Work out which Elasticsearch steps are needed before a datacenter switchover","ko":"데이터센터 전환 전에 필요한 Elasticsearch 관련 작업을 정한다."}},{"text":{"en":"Update the Elasticsearch section of the datacenter switchover documentation","ko":"Switch Datacenter 문서의 ElasticSearch 절을 고친다."}},{"text":{"en":"Review the suggested switchover improvements in T285347 and decide whether to implement them","ko":"데이터센터 전환 개선 제안인 T285347 을 검토해 적용할지 정한다."}},{"text":{"en":"Make the RESTBase /related/{article} endpoint send GET instead of POST so the CirrusSearch query cache stays warm in both datacenters","ko":"여러 데이터센터를 운영할 때 두 데이터센터 모두에서 CirrusSearch 쿼리 캐시가 데워져 있도록 RESTBase /related/{article} 엔드포인트가 POST 가 아니라 GET 요청을 보내게 바꾼다."}},{"text":{"en":"Review the shard balance of busy wikis, especially enwiki_content","ko":"바쁜 위키, 특히 enwiki_content 의 현재 샤드 배치를 검토한다."}}],"contributing":["assumption-unverified","warm-cache-dependency","no-runbook"],"recurrence_of":null,"symptoms_text":{"en":"Right after the primary datacenter was switched from EQIAD to CODFW at 14:00 UTC on 20 September 2023, on-wiki search on all Wikimedia wikis became delayed or unavailable for a subset of users. At 14:08 the alert \"CirrusSearch codfw 95th percentile latency - more_like\" fired and reached IRC and the Search Platform email list as \"PROBLEM alert - graphite1005/CirrusSearch codfw 95th percentile latency - more_like is CRITICAL\".\n\nThe PoolCounter rejected a share of search queries, up to 25% at the peak, for about half an hour. The rejections came from long response times, made worse by an unexpected fall in the cache hit rate from 71.6% to 55.5%. The more_like queries had been expected to go to eqiad, the non-primary datacenter, but were reaching codfw. At 14:26 Grafana showed extremely high load on one Elasticsearch node, elastic2044. After that node was banned from the cluster, latency began to return to normal, and at 14:35 the PoolCounter rejections were at zero.","ko":"2023년 9월 20일 14:08 UTC 에 \"CirrusSearch codfw 95th percentile latency - more_like\" 알림이 울렸다. 그동안 모든 위키의 검색이 일부 사용자에게 늦거나 되지 않았다.\n\n알림은 PROBLEM alert - graphite1005/CirrusSearch codfw 95th percentile latency - more_like is CRITICAL 이라는 문구로 IRC 와 Search Platform 메일 목록에 갔다.\n\n14:00 UTC 에 주 데이터센터를 EQIAD 에서 CODFW 로 바꾼 직후부터 동시 요청 수를 제한하는 PoolCounter 가 쿼리 일부를 거부하기 시작했고, 정점에는 25% 까지 거부했다. 요청 응답 시간이 길어진 탓이었고, 캐시 적중률이 71.6% 에서 55.5% 로 떨어지며 응답 시간이 더 나빠졌다. 팀은 more_like 쿼리가 주 데이터센터가 아닌 eqiad 로 갈 것으로 예상했지만, 쿼리는 codfw 로 가고 있었다.\n\n14:26 UTC 에 Grafana 에서 elastic2044 의 부하가 극도로 높은 것이 보였다. 이 노드를 클러스터에서 빼자 지연이 정상으로 내려가기 시작했고, 14:35 UTC 에 PoolCounter 거부가 0 이 됐다."},"updated_at":"2026-11-14T05:53:42.616256Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0216","org_slug":"wikimedia-foundation"}