Redis Timeout 으로 인한 서비스 전체 장애 대응 로그
날짜: 2025-07-29
목록으로
최근에 회사에서 2주 연속으로 정확히 동일한 시간에 동일한 서비스 전체가 멈추는 장애가 발생하여 관련하여 조치하였고 이를 해결한 사례를 기록으로 남긴다.
증상
- Redis connection timeout 발생
- API 서버 그룹에서 dead instance 가 점점 늘어남
- API 응답 시간이 점차 늘어남
- 서비스 전체가 뻗음
진단
- 로드밸런서
- API 서버 인스턴스 전체
- Redis 캐시 서버
- CPU, 메모리 정상
- Slow log 에 배송스케줄 또는 배송 휴무일 관련 캐시가 잡힘 (지속적으로 변경되는지 확인했어야…)
- RDB 서버
주요 원인으로 의심했던 부분 + 조치사항
- 배송스케줄, 배송휴무일 정보를 불러올때 MGET, MSET 을 남용하는 로직
- Redis 대신 RDB 사용하도록 로직 수정
- MGET 으로인한 Redis 액세스 횟수가 1회 요청당 800번 -> RDB 2번 액세스으로 변경
- 다행히 RDB 쿼리는 무겁지 않았음.
- health check API 관련 작업
- 미들웨어에서 공통적으로 기본적으로 RDB 또는 캐시 접근하는 로직이 있었음
- 설정값 추가하여 특정 endpoint 일경우 모든 미들웨어 패스스루 처리
- 기타 개선
- 서버 스펙업: t3.medium -> m6g.large
- 메모리 2배, 네트워크 성능 2배 (5 -> 10 기가비트)
- 엔진 변경: Redis OSS -> Valkey
- AWS ElastiCache 에서 제공하는 느린로그, 엔진로그
- Redis 사용 어플리케이션들 대응
- 호스트 변경
- 레디스 관련 pip 패키지 버전업 (주로 파이썬 프로젝트이므로 )
- Request log middleware 추가
- 요청 in, out 시 각각 로깅 (총 2회)
- user_id, client_ip, 응답시간 기록
느낀점
- 장애 대응을 위한 기본 프로토콜 마련이 되어있으면 좋을것 같다는 생각을 함.
- 장애 대응도 많이 해봐야 실력이 늘것같다…
- 장애 원인을 좁혀나가기 위해서 어떤 증상인지? 그럼 어떤 지표를 봐야하는지? 어떤식으로 구체화 해 나가는것이 좋은지?
- 혹은 위 과정을 거치기 위해 미리 마련되어야 하는 모니터링 도구는 어떤게 있는지? 알아야 하는구나 라는 생각을 함.
목록으로