사례2건

2건 중 1~2번째

1. IL-0299 Wikimedia CirrusSearch 의 OpenSearch 클러스터에서 인덱스 약 60개가 red 상태가 되어 쓸 수 없었다

   Wikimedia Foundation2025

   증상

   2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸다. 검색 업데이트 파이프라인이 red 상태가 된 인덱스 약 60개에 쓰지 못하고 있었다.

   쓰기 거부

   촉발

   2025-05-28 21:08 에 폐기할 호스트 elastic/cirrussearch10[53-67] 의 클러스터 접근을 없애는 Puppet 패치가 머지됐다. 이 중 일부 호스트가 아직 primary 샤드를 가지고 있었다.

   원인

   설정 변경

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   미검증 가정런북 부재미검증 백업

   감지

   사람이 발견했다. 2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸지만, 클러스터 유지보수 작업 때문에 다른 알림 다수가 억제돼 울리지 않았다. 엔지니어가 다음 날 07:24 에 조사를 시작했다.

   조치

   • 09:29 에 red 인덱스를 지워 클러스터를 green, 즉 쓸 수 있는 상태로 되돌렸다. 업데이트 파이프라인이 회복하기 시작했다.
   • 09:47 에 망가진 인덱스 복구를 시작했고 14:50 에 모든 인덱스가 돌아왔다.

   후속 조치

   • 운영 CirrusSearch 의 스냅샷 저장소를 다시 켠다.
   • 운영 대응에 맞춘 OpenSearch 대시보드를 만든다.
   • Search Platform 이 맡은 OpenSearch 클러스터의 Logstash 파이프라인을 확인하고 고친다.

   교훈

   노드 ban 은 성공을 보장하지 않는 동작이라 기대대로 되지 않았다. 같은 종류의 서버를 한꺼번에 여러 대 폐기하는 큰 작업에 유지보수 계획이나 런북이 없었다. 스냅샷과 대시보드, 로깅 같은 중요한 도구를 쓸 수 없거나 문서가 모자랐다. 데이터센터가 depool 돼 있던 덕분에 사용자 영향이 없었다.

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

   Wikimedia Foundation2023

   증상

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

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

   촉발

   14:00 UTC 에 주 데이터센터를 EQIAD 에서 CODFW 로 전환했다. 주 데이터센터가 아닌 eqiad 로 갈 것으로 예상한 more_like 쿼리가 주 데이터센터인 codfw 로 갔다. RESTBase 가 이 요청을 GET 이 아니라 POST 로 보낸 것이 원인으로 보였다.

   원인

   소프트웨어 결함

   구성 요소

   Elasticsearch 와 OpenSearch인메모리 캐시

   기여 요인

   미검증 가정데워진 캐시에 기댄 구조런북 부재

   감지

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

   조치

   • 14:26 UTC 에 Grafana 에서 부하가 극도로 높은 elastic2044 를 보고 inflatador 가 이 노드를 클러스터에서 뺐고, 지연이 정상으로 내려가기 시작했다.

   후속 조치

   • 데이터센터 전환 전에 필요한 Elasticsearch 관련 작업을 정한다.
   • Switch Datacenter 문서의 ElasticSearch 절을 고친다.
   • 데이터센터 전환 개선 제안인 T285347 을 검토해 적용할지 정한다.
   • 여러 데이터센터를 운영할 때 두 데이터센터 모두에서 CirrusSearch 쿼리 캐시가 데워져 있도록 RESTBase /related/{article} 엔드포인트가 POST 가 아니라 GET 요청을 보내게 바꾼다.
   • 바쁜 위키, 특히 enwiki_content 의 현재 샤드 배치를 검토한다.

   교훈

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

   사례 보기

원인별2