Incident Library

IL-0295 Pusher · 2022-04-11database

Pusher Channels mt1 클러스터의 메시지 발행 API 가 Redis 장애 조치 도중 11분 동안 거의 멈췄다

Pusher 는 2021년 11월부터 Redis 그룹을 새 버전의 모듈로 옮기고 있었다. 그룹 하나는 마스터 하나와 replica 둘로 이루어진다. 노드가 종료될 때 도는 스크립트는 그 노드가 마스터인지 보고, 마스터면 replica 하나로 장애 조치를 실행한다. 늘어나는 트래픽에 대비해 Redis 설정의 복제 버퍼를 키웠고, 이를 반영하려면 Redis 노드를 모두 재시작해야 했다. 이 작업은 테스트 클러스터와 작은 운영 클러스터 하나에서 문제없이 끝난 적이 있었다. 2022-04-11 08:47 UTC 에 엔지니어가 mt1 클러스터에서 노드 교체를 시작해 한 Redis 그룹의 replica 두 대를 하나씩 재시작했다. 10:42 에 마스터 노드에서 같은 작업을 하자 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다. 종료 스크립트는 장애 조치 명령이 성공하면 노드를 꺼도 된다고 가정했다. 보통은 장애 조치가 충분히 빨라 맞는 가정이었지만, mt1 처럼 부하가 가장 큰 클러스터에서는 장애 조치 도중에 노드가 꺼졌다. 그룹은 일관되지 않은 상태가 됐고, 이 상태에서 회복하는 데는 장애 조치를 아예 시작하지 않았을 때보다 오래 걸렸다. 옛 마스터와 새 마스터가 리더 자리를 다투다 10:53 에 새 마스터가 자리를 잡았다. 그 11분 동안 메시지 발행은 거의 실패했고, 일부 메시지가 사라졌을 수 있다.

심각도
–
영향 범위
Publishing to Channels on the mt1 cluster largely unavailable; messages delayed or lost
영향 사용자
–
지역
–
감지까지
–
복구까지
11m

증상

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

사용자는 메시지 발행이 실패하거나, 메시지가 종단 간 지연 900ms 를 넘겨 늦게 도착하거나, 메시지가 전달되지 않고 사라지는 일을 겪었을 수 있다.

장애 동안 Redis 그룹 안에서 옛 마스터와 새 마스터가 리더 자리를 두고 다퉜다. 10:53 에 그룹이 회복해 새 마스터가 모든 메시지를 처리했다.

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

원인

원인 소프트웨어 결함

구성 요소 인메모리 캐시데이터베이스 장애 조치 관리자
기여 요인 미검증 가정스테이징 불일치
촉발
엔지니어는 Redis 설정의 복제 버퍼를 키운 것을 반영하려고 mt1 클러스터의 노드를 하나씩 교체하다가, 10:42 UTC 에 마스터 노드를 재시작했다. 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다.

감지

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

조치

–

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인메모리 캐시, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.