이번에 토스 러너스 하이 2기 프로그램에 참여하게 되었고, 결과 발표 시점에 이전 직장에서 경영 악화로 개발 조직이 해체되는 상황을 겪었습니다.
현업 목표를 이어가기 어려워진 상황에서, 제가 선택한 최선은 이전 직장에서 실제로 겪었던 실무 문제를 다시 꺼내 정의하고 직접 해결하는 것이었습니다. 아래는 본 러너스 하이 2기 기간 동안 설정한 목표와 그에 대한 수치화 된 결과를 요약한 내용입니다.
SUMMARY
- Redis Cluster 환경에서 단일 노드 메모리 사용률이 60% 이상으로 Redis Stream 에 의해 집중되는 문제
→ 파티셔닝을 도입하여 3대 노드에 평균 20% 수준으로 부하를 분산 관련 링크 - Redis Stream에 대한 모니터링 및 알림 체계 부재로 장애 대응이 지연되던 문제
→ Grafana 기반으로 Stream lag 및 Redis memory 임계치 초과 시 Slack 알림을 구성하여 초 단위 대응 가능 - 메시지 상태 관측 수단 부재로 개별 확인 시 평균 5분 이상 소요되던 문제
→ 별도의 Redis Stream 모니터링 API를 구현하고 Grafana와 연동
→ consumer, group, memory, length 등 메타 정보를 통합 제공하여 원클릭 수준의 관측 환경 구축 - MAXLEN 초과 시 기존 메시지를 삭제(trimming)하던 위험한 처리 방식
→ 메시지 전송 이전 MAXLEN 근사치 도달 시 즉시 에러 반환하도록 변경
→ 기존 메시지 삭제 이전에 차단함으로써 메시지 유실 및 evict 리스크 제거 - 롤백을 위한 설정 변경 시 반영까지 최대 10분 이상 소요되던 문제
→ 기존 인프라 활용한 Redis Pub/Sub 기반 설정값 Bus Refresh 구조를 구현
→ 설정 적용 시간을 수 초 단위로 단축 관련 링크
DAILY PROGRESS LINKS
아래는 러너스 하이 2기 기간 동안 문제 정의부터 개선까지의 과정을 기록한 로그입니다.
- 2025-12-17 프로젝트 개요 및 목표 정리
- 2025-12-18 Redis 8.4 를 써야하는 이유
- 2025-12-21 Redis Cluster 내 설정값 관리 및 구축
- 2025-12-22 Redis Stream 파티셔닝 시 한계점
- 2025-12-24 XACKDEL 미지원, Grafana 대시보드
- 2025-12-26 Grafana Redis Cluster 대시보드 + Stream lag 모니터링 쿼리
- 2025-12-29 Arxiv 서버 헬스체크
- 2025-12-30 Redis Stream 내부 메세지 모니터링 pagination
- 2025-12-31 Redis Stream 모니터링 API 안에 lag 데이터까지 가져와서 확인하기
- 2026-01-01 Consumer 제거 필요 및 stream 별 redis node 메모리 사용량 모니터링 추가
- 2026-01-03 stream key size 확인
- 2026-01-05 실패 메세지 재처리 시 중복방지를 위한 XAUTOCLAIM lua 구현
- 2026-01-09 추가적인 모니터링 지표들과 stream 크기 동적 확장을 위한 버스 리프레시 구현(redis pub/sub)
- 2026-01-12 aws-secret/bus-refresh 직접구현은 매우 비효율적. CDL 로 max retry 이후 전송되는 것 관측
- 2026-01-14 컨슈머 재정리 로직 개선 및 cdl 개별 interval/retry 설정값 적용
- 2026-01-17 메모리 사용률 50% 임계값 alert 및 파티셔닝 전/후 메모리 부하 분산 확인