Incident Library

IL-0430 Hatena · 2018-09-26database

Redis 장애 조치 뒤 Mackerel 전체가 느려지고 생존 여부 감시가 4시간 넘게 멈췄다

2018년 9월 26일 Mackerel 팀은 감시 데이터를 담는 Redis 의 메모리 사용량이 늘어나는 것을 보고 Redis 를 스케일업하기로 했고, 그 준비로 복제를 구성했다. 복제 구성이 오래 걸리면서 Redis 가 응답하지 않는 시간이 생겼고, 클러스터링 소프트웨어인 keepalived 가 이를 노드 고장으로 보고 10시 51분에 장애 조치를 일으켰다. 애플리케이션 서버는 Redis 에 접속하지 못해 올바른 응답을 내지 못했고, Mackerel 시스템 전체가 불안정해지며 생존 여부 감시가 멈췄다.

10시 55분 팀이 Redis 를 올바른 쪽으로 다시 전환해 애플리케이션이 돌아온 것을 잠시 확인했다. 하지만 장애 전부터 있던 네트워크 불안정과 Redis 메모리 증가가 겹치면서 애플리케이션 서버의 지연 시간이 나빠지고 타임아웃이 이어졌다. 애플리케이션 서버를 차례로 재시작해도 나아지지 않았고, 이것이 장애가 길어진 이유였다. 11시부터 14시 50분까지 팀은 부적절한 메트릭을 보내는 Mackerel 조직의 요청을 막고 타임아웃 간격을 조정했다. 또 TSDB 인 Diamond, Kinesis 샤드 수, Redis Cluster 샤드 수, API 애플리케이션 서버를 늘렸다. 그 뒤 잠시 점검 모드로 바꿔 사내에서 확인하고 외부 요청을 조금씩 되돌렸고, 15시 20분 복구를 선언했다.

장애의 발단은 Redis 작업에 따른 의도하지 않은 장애 조치였다. 복구가 길어진 원인은 정확히 밝혀지지 않았다. 회고에서는 특정 접근 패턴이 이어질 때 Scala 애플리케이션에서 스레드 풀이나 커넥션 풀의 동기화 대기 또는 락 경합 때문에 지연 시간이 나빠진다는 가설이 나왔다. 격리된 환경에서 장애 상황을 재현하려 했지만 재현되지 않았고, 원인 조사는 중단했다.

심각도
–
영향 범위
The whole Mackerel service malfunctioned and alive monitoring stopped from 10:51 to 15:20 JST
영향 사용자
–
지역
–
감지까지
–
복구까지
4h 29m

증상

10시 51분 Redis 에 장애 조치가 일어난 뒤 애플리케이션 서버가 Redis 에 접속하지 못해 Mackerel 이 요청에 제대로 응답하지 못했다. Mackerel 시스템 전체가 불안정해졌고 생존 여부 감시가 멈췄다.

Redis 를 올바른 쪽으로 다시 전환하자 애플리케이션이 잠시 되살아난 것처럼 보였다. 그러나 동작이 안정되지 않았고, 애플리케이션 서버의 지연 시간이 나빠지고 타임아웃이 났다.

장애 전부터 네트워크 상태가 좋지 않았고 Redis 메모리 사용량도 늘고 있었다. 팀은 애플리케이션 서버를 차례로 재시작했지만 증상은 나아지지 않았다.

복구 단계에서는 mackerel-agent 가 메트릭을 다시 보내고 있었고, TSDB 에 메트릭이 늦게 반영되었다. 팀은 애플리케이션 서버의 응답이 안정되고 이 재전송이 잦아들고 반영 지연이 풀린 것을 보고 15시 20분에 복구를 선언했다.

증상 모니터링 중단지연 시간 증가간헐적 타임아웃

원인

원인 설정 변경

구성 요소 인메모리 캐시데이터베이스 복제데이터베이스 장애 조치 관리자
기여 요인 자동화 증폭장애 중첩
촉발
감시 데이터를 담는 Redis 를 스케일업하려고 복제를 구성하는 작업을 했다. 복제 구성에 시간이 걸리는 동안 Redis 가 응답하지 않았고, keepalived 가 이를 노드 고장으로 판단해 의도하지 않은 장애 조치를 일으켰다.

감지

–

조치

후속 조치

교훈

Hatena 는 상세한 원인을 밝히지 못했다. 그래도 장애 조치 오작동을 막고, 애플리케이션 성능에 여유를 더 두고, Redis 에 저장하는 데이터를 줄이고, 부적절한 요청을 빨리 찾아 막으면 이번처럼 긴 장애는 막을 수 있다고 보았다. 장애가 나더라도 영향이 좁은 범위에 그치도록 하는 작업을 이어 가겠다고 했다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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