사례2건

2건 중 1~2번째

1. 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. IL-0279 Redis Cluster 의 슬레이브 노드 하나가 죽자 파이프라인 읽기가 실패해 Grab 의 운송 예약 서비스 Apollo 호출이 1분 동안 21번에 1번꼴로만 성공했다

   Grab2019

   증상

   2019년 2월 15일 Apollo 가 쓰는 Redis Cluster 의 슬레이브 노드 하나가 죽어 교체해야 했다. 그동안 운송 예약의 핵심 서비스인 Apollo 로 가는 호출이 대략 21번에 1번꼴로만 성공했고, Redis Cluster 가 스스로 복구하는 1분 동안 Grab 의 승차 이용이 크게 줄었다.

   오류율 상승오래된 엔드포인트 라우팅

   촉발

   2019년 2월 15일 Apollo 가 쓰는 AWS ElastiCache Redis Cluster 의 슬레이브 노드 하나가 죽었다.

   원인

   소프트웨어 결함

   구성 요소

   인메모리 캐시

   기여 요인

   미검증 가정

   교훈

   Redis Cluster 는 서비스 성능을 높이는 좋은 도구지만 쓰는 데 위험이 있다. 파이프라인 전용 Redis Cluster 클라이언트를 따로 만들고 RouteByLatency 를 true 로 두면, 지연이 1ms 아래일 때 파이프라인 읽기가 마스터 노드로 가서 파티션의 과반이 살아 있는 한 기대한 결과를 받는다. 이렇게 하면 마스터로 가는 부하가 늘어나므로 마스터 노드의 CPU 사용량을 살펴야 한다. 마스터가 그만한 트래픽을 감당하지 못하면, 파이프라인 호출에 오류가 나더라도 질의마다 오류를 따로 확인하면 된다. 그러면 성공한 질의는 영향을 받지 않아 피해가 줄어든다. Go-Redis 라이브러리는 오류가 나면 노드 상태를 다시 읽도록 고칠 수 있다. defaultProcessor 에 있는 이 로직을 defaultProcessPipeline 에 적용하면 된다.

   사례 보기

원인별1