Incident Library

IL-0581 MUSINSA · 2025-11-03databaseawskubernetes

이구위크 첫날 Redis 커넥션이 실패하며 29CM 상품 전시 서버의 파드가 다운되고 Netty 이벤트 루프가 포화됐다

29CM 는 2025년 겨울 최대 규모의 블랙프라이데이 행사인 이구위크를 열었다. 첫날인 11월 3일, 검색 결과와 상품 리스팅을 맡은 전시 서버의 파드 일부가 다운되고 남은 파드에서 Netty 이벤트 루프가 포화됐다. 팀은 Netty 와 Spring WebFlux 쪽의 처리 지연을 먼저 의심했고, Redis 는 CPU 와 Memory 가 10% 이하여서 원인일 가능성을 낮게 봤다.

Redis 헬스체크 실패 로그를 보고 네트워크 지표를 다시 살펴 원인을 찾았다. 당시 Redis 노드 타입은 cache.r7g.large 로 기본 네트워크 대역폭이 0.937Gbps 였다. 평소 네트워크 Out 은 약 0.49Gbps 로 이 범위 안이었지만, 이구위크 트래픽으로 피크 때 평소의 약 4배인 2.0Gbps 까지 올랐다. ElastiCache 는 인스턴스 타입마다 대역폭 Baseline 이 있다. ElastiCache 는 Baseline 을 넘는 트래픽을 버스트 크레딧으로 잠깐 허용하고, 크레딧이 바닥나면 Baseline 이하로 강제로 제한한다. 트래픽은 19:00 부터 Baseline 을 넘었고, 20:58 에 크레딧이 바닥나 Throttling 이 시작됐다. Redis 커넥션과 커맨드가 실패하면서 Readiness Probe 가 실패해 파드가 여럿 다운됐다. 버스트 구간이 있어 원인을 찾는 데 시간이 더 걸렸다.

팀은 원인을 찾은 즉시 Redis 노드를 기본 대역폭 1.875Gbps 의 cache.r7g.2xlarge 로 스케일업했고, 장애는 당일 풀렸다. 그 뒤 네트워크 대역폭 지표의 대시보드와 Datadog 알림을 더하고, Caffeine 로컬 캐시, Redis, DB 로 이어지는 캐시 계층 구조로 바꿔 Redis 명령 호출 수와 Outgoing 트래픽을 줄였다.

심각도
–
영향 범위
29CM's main product display screens, including search results and product listings
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

이구위크가 시작되고 얼마 지나지 않아 검색 결과와 상품 리스팅 같은 전시 도메인을 맡은 서버에 이상 징후가 나타났다. 파드 일부가 다운되어 트래픽을 받지 못했고, 남은 파드도 처리할 수 있는 양을 넘어 Netty 이벤트 루프가 포화됐다.

전시 서버는 Netty 와 Spring WebFlux 기반이어서, 팀은 트래픽 증가로 생긴 다운스트림 지연이나 이벤트 루프 처리 지연을 먼저 점검했다. Redis 도 확인했지만 CPU 와 Memory 같은 주요 시스템 메트릭이 모두 10% 이하로 정상 범위여서 원인일 가능성을 낮게 봤다.

원인을 분석하던 중 Redis 헬스체크 실패 로그가 보였다. 리소스 지표는 정상인데 Redis 와의 통신이 실패하고 있었고, 네트워크 지표를 보자 평소 약 0.49Gbps 이던 네트워크 Out 대역폭이 피크 때 약 2.0Gbps 까지 올라 있었다.

트래픽은 19:00 부터 Redis 대역폭 Baseline 을 넘었지만 버스트 크레딧 덕분에 바로 문제가 드러나지 않았다. 약 2시간 뒤인 20:58 에 크레딧이 바닥나 Throttling 이 시작되자 Redis 응답 지연과 커넥션 실패가 갑자기 크게 늘었고, 애플리케이션의 Readiness Probe 가 실패하며 파드가 여럿 다운됐다.

증상 프로브 실패간헐적 연결 실패지연 시간 증가

원인

원인 용량 한계

구성 요소 인메모리 캐시라이브니스·레디니스 프로브
기여 요인 한계 미인지모니터링 사각지대의존성에 묶인 헬스 체크
촉발
2025년 11월 3일 29CM 최대 규모의 블랙프라이데이 행사인 이구위크가 시작되면서 트래픽이 몰렸다.

감지

팀은 이구위크가 시작되고 얼마 지나지 않아 전시 서버의 파드 일부가 다운되고 Netty 이벤트 루프가 포화된 것을 보고 이상을 알아챘다. 원인을 분석하던 중 Redis 헬스체크 실패 로그를 보고 네트워크 지표에서 대역폭 초과를 찾았다.

조치

후속 조치

교훈

CPU 와 Memory 지표만으로는 Redis 대역폭 초과를 알아채기 어려웠고, 팀은 네트워크 관점의 모니터링이 필요하다는 것을 다시 느꼈다. 버스트 크레딧 구간이 있으면 Baseline 을 넘은 시점과 Throttling 이 시작된 시점 사이에 시간이 벌어져 원인을 찾기가 늦어진다. 트래픽이 더 늘면 스케일업만으로는 같은 문제가 되풀이될 수 있어 근본적인 재발 방지가 필요하다고 봤다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인메모리 캐시, 라이브니스·레디니스 프로브. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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