사례2건

2건 중 1~2번째

1. IL-0232 codfw WikiKube 클러스터에서 Calico 구성 요소가 자원 한도에 걸려 calico-node 파드가 하나씩 죽고 노드가 차례로 빠지면서 MediaWiki 지연과 오류가 났다

   Wikimedia Foundation2024

   증상

   2024-10-09 05:01:36 UTC 에 codfw 의 rest-gateway 에서 page-analytics_cluster 의 5xx 오류가 늘었다는 GatewayBackendErrorsHigh 알림이 울렸다. 05:03:32 UTC 에는 KubernetesCalicoDown 알림이 16건 묶여 울렸고, 알림 문구는 kubernetes2037.codfw.wmnet is not running calico-node Pod 였다. 05:04:15 UTC 에는 MediaWiki memcached 오류율이 전 세계에서 올랐다는 MediaWikiMemcachedHighErrorRate 알림이 울렸다.

   오류율 상승지연 시간 증가컨테이너 재시작 반복프로브 실패컨트롤 플레인 지연

   촉발

   한 운영자가 새 mwscript-k8s 도구로 TimedMediaHandler 의 requeueTranscodes.php 를 돌려 동영상 트랜스코딩을 일괄 정비했다. mwscript-k8s 는 스크립트를 실행할 때마다 helm 릴리스를 통째로 배포하므로, 이 작업이 몇 시간 동안 리소스를 계속 만들었다.

   원인

   용량 한계

   구성 요소

   CalicoHelm잡과 크론잡

   기여 요인

   늦게 드러난 변경런북 부재

   감지

   자동 모니터링이 알아채고 당직 SRE 가 대응했다. 05:01:36 UTC 에 GatewayBackendErrorsHigh, 05:03:32 UTC 에 KubernetesCalicoDown 16건, 05:04:15 UTC 에 MediaWikiMemcachedHighErrorRate 알림이 울렸다.

   조치

   • calico 와 typha 의 자원 한도를 올리는 변경을 CI 를 기다리지 않고 반영하고, helmfile -e codfw --selector name=calico apply -i --context 5 로 적용했다. 적용 중 새 calico 파드가 정상으로 떴고, 06:10 UTC 에 Calico 가 회복되었다.

   후속 조치

   • mwscript-k8s 가 리소스를 너무 많이 만드는 문제를 해결한다.

   교훈

   완전한 장애 직전까지 갔다. 자동 모니터링이 장애를 잡았다. 새로 들어온 여러 사람이 함께 본 덕에 근본 원인을 찾았다. 미주 SRE 에서 EMEA SRE 로 장애 대응을 문제없이 넘겼다. 반면 최종 사용자에게 영향이 갔고, 비상시에 eqiad 로 전환할 수 있는지 확신하지 못했다. 운도 따랐다. 장애는 미주 SRE 근무가 끝나고 EMEA SRE 근무가 시작되기 바로 전에 발견되었다. 이 시간대는 오래전부터 대응 인력이 비는 때로 알려져 있었다. 트랜스코딩 작업을 미국의 금요일 저녁에 넣지 않은 것도 다행이었다.

   사례 보기
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