{"id":"IL-0581","org":"MUSINSA","date":"2025-11-03","docs":[],"title":{"en":"29CM product display servers lost pods and saturated Netty event loops on the first day of the Igu Week sale","ko":"이구위크 첫날 Redis 커넥션이 실패하며 29CM 상품 전시 서버의 파드가 다운되고 Netty 이벤트 루프가 포화됐다"},"domain":["database","aws","kubernetes"],"impact":{"scope":"29CM's main product display screens, including search results and product listings","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"CPU and memory metrics alone did not show the problem, so Redis needs network monitoring against the node's bandwidth baseline. Burst credits kept the nodes working for about two hours after traffic passed the baseline, which delayed the failure and made its cause slower to find.","ko":"CPU 와 Memory 지표만으로는 Redis 대역폭 초과를 알아채기 어려웠고, 팀은 네트워크 관점의 모니터링이 필요하다는 것을 다시 느꼈다. 버스트 크레딧 구간이 있으면 Baseline 을 넘은 시점과 Throttling 이 시작된 시점 사이에 시간이 벌어져 원인을 찾기가 늦어진다. 트래픽이 더 늘면 스케일업만으로는 같은 문제가 되풀이될 수 있어 근본적인 재발 방지가 필요하다고 봤다."},"related":[],"sources":[{"url":"https://techblog.musinsa.com/%EC%9D%B4%EA%B5%AC%EC%9C%84%ED%81%AC-%EC%A0%84%EC%8B%9C-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91%EA%B8%B0-redis%EC%97%90%EB%8A%94-%EB%AC%B4%EC%8A%A8-%EC%9D%BC%EC%9D%B4-%EC%9E%88%EC%97%88%EB%82%98-5599562d76b9","kind":"blog","archived":null}],"summary":{"en":"29CM, part of MUSINSA, held Igu Week, its largest Black Friday sale, in winter 2025. The display servers used ElastiCache Redis on cache.r7g.large nodes with a baseline network bandwidth of 0.937Gbps, about 117MB per second. ElastiCache lets traffic go over an instance type's baseline for a while by spending burst credits, which build up while traffic stays under the baseline; when the credits run out, AWS throttles the node to the baseline. Normally Redis out traffic stayed at about 0.49Gbps (about 61MB/s), within the baseline. During the sale it rose to about 2.0Gbps (about 250MB/s).\n\nFrom 19:00 the nodes ran above the baseline on burst. At 20:58 the credits built up over about two hours ran out and network throttling began. Redis connections and commands started to fail, the application's readiness probes failed, and many pods went down. Because the burst period hid the problem at first, finding the cause took longer. Once the cause was found, the team scaled the Redis nodes up from cache.r7g.large to cache.r7g.2xlarge, whose baseline of 1.875Gbps is about twice the network capacity, and the outage ended the same day.\n\nAfterwards the team added ElastiCache network metrics and Datadog alerts, and moved data that rarely changes into a Caffeine local cache in front of Redis, so that requests go from the local cache to Redis to the database. Redis command counts and outgoing bytes dropped visibly. For the longer term the team is looking at compressing cached data with Snappy and storing it as Protocol Buffers instead of JSON, which it expects to cut the size of the cached item data by about 73%.","ko":"29CM 는 2025년 겨울 최대 규모의 블랙프라이데이 행사인 이구위크를 열었다. 첫날인 11월 3일, 검색 결과와 상품 리스팅을 맡은 전시 서버의 파드 일부가 다운되고 남은 파드에서 Netty 이벤트 루프가 포화됐다. 팀은 Netty 와 Spring WebFlux 쪽의 처리 지연을 먼저 의심했고, Redis 는 CPU 와 Memory 가 10% 이하여서 원인일 가능성을 낮게 봤다.\n\nRedis 헬스체크 실패 로그를 보고 네트워크 지표를 다시 살펴 원인을 찾았다. 당시 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 가 실패해 파드가 여럿 다운됐다. 버스트 구간이 있어 원인을 찾는 데 시간이 더 걸렸다.\n\n팀은 원인을 찾은 즉시 Redis 노드를 기본 대역폭 1.875Gbps 의 cache.r7g.2xlarge 로 스케일업했고, 장애는 당일 풀렸다. 그 뒤 네트워크 대역폭 지표의 대시보드와 Datadog 알림을 더하고, Caffeine 로컬 캐시, Redis, DB 로 이어지는 캐시 계층 구조로 바꿔 Redis 명령 호출 수와 Outgoing 트래픽을 줄였다."},"trigger":{"en":"Igu Week, 29CM's largest Black Friday sale and its busiest traffic of the year, raised Redis network traffic to about four times normal.","ko":"2025년 11월 3일 29CM 최대 규모의 블랙프라이데이 행사인 이구위크가 시작되면서 트래픽이 몰렸다."},"severity":"unknown","symptoms":["readiness-probe-failures","intermittent-connection-failures","high-latency"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Anomalies on the display servers, pods going down and Netty event loops saturating, were the first sign. The Redis cause was found from Redis health check failure logs and then the Redis network metrics.","ko":"팀은 이구위크가 시작되고 얼마 지나지 않아 전시 서버의 파드 일부가 다운되고 Netty 이벤트 루프가 포화된 것을 보고 이상을 알아챘다. 원인을 분석하던 중 Redis 헬스체크 실패 로그를 보고 네트워크 지표에서 대역폭 초과를 찾았다."},"components":["cache","health-probe"],"root_cause":"capacity","remediation":[{"text":{"en":"Scaled the Redis nodes up from cache.r7g.large to cache.r7g.2xlarge, about twice the baseline network bandwidth","ko":"원인을 찾은 즉시 Redis 노드를 cache.r7g.large 에서 기본 대역폭이 1.875Gbps 로 약 2배인 cache.r7g.2xlarge 로 스케일업했다."}}],"action_items":[{"text":{"en":"Extended the monitoring dashboard to show in real time whether network in and out bandwidth exceeds the baseline, with metrics such as aws.elasticache.network_bandwidth_out_allowance_exceeded and aws.elasticache.traffic_management_active","ko":"네트워크 In/Out 대역폭의 초과 여부를 실시간으로 볼 수 있게 모니터링 대시보드를 강화했다. 주요 지표는 aws.elasticache.network_bytes_in, aws.elasticache.network_bytes_out, aws.elasticache.network_bandwidth_in_allowance_exceeded, aws.elasticache.network_bandwidth_out_allowance_exceeded, aws.elasticache.traffic_management_active 다."}},{"text":{"en":"Added Datadog alerts that fire when network bandwidth crosses a threshold","ko":"네트워크 대역폭이 임계치를 넘으면 곧바로 알림이 오도록 Datadog Alert 를 연동했다."}},{"text":{"en":"Added a Caffeine local cache in front of Redis for data that changes rarely","ko":"응답이 자주 바뀌지 않는 데이터를 중심으로 Redis 하나에 기대던 구조를 Caffeine 로컬 캐시, Redis 원격 캐시, DB 로 이어지는 캐시 계층 구조로 바꿨다."}},{"text":{"en":"Look into compressing cached data with Snappy to reduce Redis network bandwidth","ko":"Redis 네트워크 대역폭 사용량을 줄이려고 CPU 사용량이 적고 압축과 해제가 빠른 Snappy 로 캐시 데이터를 압축하는 방안을 검토한다."}},{"text":{"en":"Look into storing cached data as Protocol Buffers instead of JSON; measured on the cached Item Document data, Snappy and protobuf together are expected to cut the size by about 73%","ko":"JSON 으로 저장하던 캐시 데이터를 Protocol Buffers 형식으로 바꾸는 방안을 검토한다. 팀이 캐싱 중인 Item Document 데이터로 재 본 결과, Snappy 압축과 protobuf 를 함께 쓰면 용량을 약 73% 줄일 수 있을 것으로 예상됐다."}},{"text":{"en":"Keep improving the architecture for traffic growth, building on the cache restructuring, stronger monitoring and read separation already applied","ko":"캐시 구조 개선, 모니터링 고도화, 읽기 분리 적용으로 기술 부채를 해소했고, 이를 바탕으로 트래픽 증가에 대비한 아키텍처 개선을 진행한다."}}],"contributing":["limit-unknown","monitoring-blind-spot","probe-depends-on-dependency"],"recurrence_of":null,"symptoms_text":{"en":"Shortly after 29CM's Igu Week sale began on 3 November 2025, the servers for the display domain, which serve search results and product listings, showed anomalies. Some pods went down and stopped taking traffic, and the remaining pods received more traffic than they could handle and saturated their Netty event loops.\n\nThe display servers run on Netty and Spring WebFlux, so the team first checked downstream delays and event loop delays caused by the traffic increase. Redis was checked too, but its CPU and memory metrics were all in the normal range, under 10%, so the team judged it an unlikely cause.\n\nDuring the analysis, Redis health check failure logs stood out, and the team looked at the metrics again. The network metrics showed that Redis network out traffic, normally about 0.49Gbps, had risen to about 2.0Gbps at the peak, against a baseline bandwidth of 0.937Gbps for the cache.r7g.large nodes. Traffic had exceeded the baseline from 19:00, and at 20:58 Redis response delays and connection failures surged suddenly.","ko":"이구위크가 시작되고 얼마 지나지 않아 검색 결과와 상품 리스팅 같은 전시 도메인을 맡은 서버에 이상 징후가 나타났다. 파드 일부가 다운되어 트래픽을 받지 못했고, 남은 파드도 처리할 수 있는 양을 넘어 Netty 이벤트 루프가 포화됐다.\n\n전시 서버는 Netty 와 Spring WebFlux 기반이어서, 팀은 트래픽 증가로 생긴 다운스트림 지연이나 이벤트 루프 처리 지연을 먼저 점검했다. Redis 도 확인했지만 CPU 와 Memory 같은 주요 시스템 메트릭이 모두 10% 이하로 정상 범위여서 원인일 가능성을 낮게 봤다.\n\n원인을 분석하던 중 Redis 헬스체크 실패 로그가 보였다. 리소스 지표는 정상인데 Redis 와의 통신이 실패하고 있었고, 네트워크 지표를 보자 평소 약 0.49Gbps 이던 네트워크 Out 대역폭이 피크 때 약 2.0Gbps 까지 올라 있었다.\n\n트래픽은 19:00 부터 Redis 대역폭 Baseline 을 넘었지만 버스트 크레딧 덕분에 바로 문제가 드러나지 않았다. 약 2시간 뒤인 20:58 에 크레딧이 바닥나 Throttling 이 시작되자 Redis 응답 지연과 커넥션 실패가 갑자기 크게 늘었고, 애플리케이션의 Readiness Probe 가 실패하며 파드가 여럿 다운됐다."},"updated_at":"2026-11-14T12:34:22.703570Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0581","org_slug":"musinsa"}