사례4건

4건 중 1~4번째

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-0217 스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다

   Honeycomb2023

   증상

   2023년 7월 24일 밤 저장소와 쿼리 엔진인 Retriever 의 클러스터를 바꾼 지 몇 시간 뒤 수집 서비스 Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되기 시작했다. 엔지니어들은 소진이 느리고 들쭉날쭉하며 뚜렷한 설명이 없어서 아침에 조사해도 되는 작은 문제라고 판단했다.

   지연 시간 증가데이터베이스 과부하잠금 경합과 교착서비스 중단

   촉발

   7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터 두 개 사이를 전환했다. 전환 뒤 Retriever 가 마지막 쓰기 시각 기록을 데이터베이스에 쓰지 않았고, 그 뒤 쓰기만 되돌리려고 기능 플래그를 바꾸자 남은 쓰기마저 완전히 멈췄다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스인메모리 캐시

   기여 요인

   데워진 캐시에 기댄 구조초기 신호 무시수동 조치 악화미검증 가정

   감지

   Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되는 것을 엔지니어들이 봤지만 작은 문제로 판단해 아침으로 미뤘다. 아침에 Retriever 의 데이터베이스 호출이 끊긴 차트를 찾아 성능 문제의 원인을 알았다.

   조치

   • 클러스터의 쓰기에 문제가 있다고 보고 자주 쓰던 기능 플래그를 바꿔 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다.
   • 데이터베이스를 보호하려고 서킷 브레이커를 걸어 모든 Shepherd 트래픽을 5xx 오류로 거부했다.
   • 데이터베이스 호스트가 완전히 잠겨 살릴 수 없자 복제본으로 페일오버했고, 데이터베이스와 그에 기대는 서비스들이 돌아왔다.
   • 데이터베이스가 살아난 뒤 캐시에 데이터를 채우려고 Retriever 호스트를 모두 재시작했다.
   • 지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 손으로 바꿔 스키마 저장소가 캐시를 모두 다시 읽게 했다.
   • 서킷 브레이커를 풀어 수집을 완전히 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다.

   후속 조치

   • 클러스터 이전을 마쳤고, 캐시 뒤의 쓰기를 끌 수 있는 코드를 모두 지웠다.
   • 캐시를 더 튼튼하게 하는 방법을 찾는다.
   • 새 스키마로 갱신이 몰릴 때 데이터베이스에 거는 경합을 줄이는 방법을 찾는다.
   • 시스템 안 일부 작업의 성능 비용이 들쭉날쭉하지 않게 한다.
   • 이런 드문 경우를 더 잘 찾고 다루기 위한 계측과 실험 방법을 검토한다.

   교훈

   Honeycomb 은 기능 플래그, 잦은 배포, 장애 중 배포 중단, 지난 아차 사고에서 배운 것처럼 시스템을 안전하게 만드는 가장 믿는 관행들이 함께 이번 장애의 원인이 됐다고 봤다. 저마다 합리적인 결정들이 간접 의존 관계를 따라 예상하지 못하게 얽혔고, 환경 한쪽의 문제가 다른 쪽 서비스를 망가뜨렸다. 최근 여러 장애와 아차 사고에서 미묘한 버그를 피하려던 조치가 더 큰 예상 밖 장애로 이어진 일이 자주 있었다. 이런 드문 데이터베이스 잠김에는 페일오버가 가장 빠른 복구 방법이라는 것도 배웠다.

   사례 보기
3. IL-0295 Pusher Channels mt1 클러스터의 메시지 발행 API 가 Redis 장애 조치 도중 11분 동안 거의 멈췄다

   Pusher2022

   증상

   2022-04-11 10:42 UTC 부터 mt1 클러스터에서 Channels 메시지 발행 API 를 11분 동안 거의 쓸 수 없었다. 상태 페이지는 10:44 무렵부터 10:53 무렵까지 MT1 API 요청의 오류율이 올랐다고 알렸다.

   서비스 중단지연 시간 증가스플릿 브레인

   촉발

   엔지니어는 Redis 설정의 복제 버퍼를 키운 것을 반영하려고 mt1 클러스터의 노드를 하나씩 교체하다가, 10:42 UTC 에 마스터 노드를 재시작했다. 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다.

   원인

   소프트웨어 결함

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자

   기여 요인

   미검증 가정스테이징 불일치

   감지

   Pusher 는 10:44 UTC 무렵부터 MT1 API 요청의 오류율이 오른 것을 확인하고 상태 페이지에 알렸다.

   후속 조치

   • Redis 종료 스크립트가 노드를 끄기 전에 장애 조치가 끝났고 그 노드가 더는 마스터가 아닌지 확인하도록 고친다.

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