이구위크 전시 장애 대응기: Redis에는 무슨 일이 있었나

안녕하세요. 29CM에서 고객이 상품을 탐색하고 발견하는 상품 전시 영역을 담당하고 있는 Customer Engagement Engineering 팀 김송이입니다.

2025년 겨울, 29CM 최대 규모의 블랙프라이데이 행사인 이구위크를 진행했습니다. 연중 가장 트래픽이 몰리는 행사인 만큼, 설렘과 긴장이 공존하는 시즌이기도 합니다. 매년 대규모 트래픽을 대비하지만, 플랫폼의 성장 속도만큼 새로운 변수도 함께 생겨납니다.

이구위크 시작 첫날이었던 11월 3일, 유저가 상품을 둘러보는 주요 상품 전시 화면에서 장애가 발생했습니다. 장애 원인을 추적하고 해결한 과정, 이후 개선한 내용을 정리해 공유합니다.

1. 장애 발생과 원인을 찾기까지

이구위크 본편이 시작된 지 얼마 되지 않아, 검색결과, 상품 리스팅 등의 전시 도메인을 담당하는 서버에 이상징후가 포착되기 시작했습니다. 파드(pod)가 일부 다운되며 트래픽을 못 받기 시작했습니다.

남아있는 파드도 처리 가능한 트래픽을 초과하면서 Netty 이벤트 루프 포화가 발생했습니다.

Netty Pending Tasks

전시 트래픽을 받는 서버의 경우 Netty, Spring WebFlux 기반으로 운영 중이었기 때문에, 트래픽 증가로 인한 다운스트림 지연이나 이벤트 루프 처리 지연 쪽을 먼저 점검했습니다. Redis도 확인했지만, CPU, Memory 등 주요 시스템 메트릭이 모두 정상 범위(10% 이하)였기 때문에 원인일 가능성을 낮게 판단했습니다.

2. Redis 대역폭 병목이 드러나다

원인 분석 중 Redis 헬스체크 실패 로그가 눈에 들어왔고, 메트릭 지표를 다시 살펴봤습니다. 리소스는 멀쩡한데, 왜 Redis와의 통신은 실패하고 있었을까? 이 의문은 네트워크 지표에서 풀렸습니다.

당시 운영 중이던 Redis 노드 타입은 cache.r7g.large로, 기본 네트워크 대역폭은 0.937Gbps였습니다. 이는 이론적으로 초당 약 117MB 수준의 데이터 전송량에 해당합니다.

평소에는 네트워크 Out 대역폭이 약 0.49Gbps(약 61MB/s) 수준으로 유지되고 있어, 기본 대역폭 범위 내에서 안정적으로 동작하고 있었습니다. 그러나 이구위크 트래픽이 몰리면서 피크 시점에는 네트워크 사용량이 평소 대비 약 4배 수준인 2.0Gbps(약 250MB/s)까지 치솟았습니다.

Network In/Out 허용 초과량

여기서 문제가 되었던 것은 AWS의 네트워크 대역폭 스로틀링(Throttling) 메커니즘입니다. ElastiCache는 인스턴스 타입마다 기본 제공 대역폭 베이스라인(Baseline)이 정해져 있고, 순간적으로 베이스라인을 초과하는 트래픽이 발생했을 때, 이를 허용해 주는 버스트(Burst) 기능을 제공합니다. 이때 버스트는 ‘버스트 크레딧(Burst Credit)’이라는 일종의 네트워크 체력을 사용해 동작합니다.

휴대폰 데이터 요금제와 비슷하다고 생각하면 이해하기 쉽습니다. 기본 데이터를 다 쓰면 속도가 확 느려지는 것처럼, 크레딧이 소진되면 Baseline으로 강제 제한됩니다.

Baseline 이하로 사용 → 크레딧 축적

Baseline 초과 → 크레딧 소모하며 버스트 유지

크레딧 소진 → AWS가 Baseline 이하로 강제 제한(Throttling)

이번 장애는 바로 이 버스트 크레딧 소진 → 네트워크 강제 제한 과정에서 발생했습니다. 트래픽이 19시부터 Baseline을 초과해 계속 버스트 상태로 운영되었지만, 약 2시간 동안 누적된 버스트 크레딧이 모두 고갈된 시점(20:58)에 네트워크 Throttling이 시작되면서 Redis 응답 지연과 커넥션 실패가 갑자기 폭증했습니다. 결과적으로 Redis 커넥션과 커맨드가 실패하기 시작했고, 이로 인해 애플리케이션의 Readiness Probe가 실패하면서 다수의 파드가 다운되었습니다.

3. 장애 대응과 즉시 조치

19:00부터 트래픽이 Redis 대역폭 Baseline을 초과했지만, Burst 크레딧 덕분에 바로 문제가 드러나지 않았고, 약 2시간 뒤인 20:58 크레딧이 고갈되면서 Throttling이 시작되었습니다. Burst 구간이 있었기 때문에 원인 파악이 늦어진 측면이 있습니다.

원인 파악 후 즉시 Redis 노드 스케일업(cache.r7g.large → cache.r7g.2xlarge)을 진행했습니다. 2xlarge는 기본 대역폭이 1.875Gbps로, 기존 대비 약 2배의 네트워크 용량을 제공합니다. 서비스 장애는 당일 해소되었지만, 트래픽이 더 늘어나면 같은 문제가 반복될 수 있기 때문에 근본적인 재발 방지 전략이 필요했습니다.

4. 재발 방지를 위한 개선 작업

장애 직후, 같은 문제가 반복되지 않도록 몇 가지 조치를 진행했습니다.

4–1. 모니터링 강화

Burst 크레딧 구간 때문에 원인 파악이 늦어졌던 만큼, 네트워크 In/Out 대역폭 초과 여부를 실시간으로 확인할 수 있도록 모니터링 대시보드를 강화했습니다.

주요 모니터링 지표는 아래와 같습니다.

• aws.elasticache.network_bytes_in : 네트워크 수신 바이트
• aws.elasticache.network_bytes_out : 네트워크 송신 바이트
• aws.elasticache.network_bandwidth_in_allowance_exceeded : 수신 대역폭 Baseline 초과 여부
• aws.elasticache.network_bandwidth_out_allowance_exceeded : 송신 대역폭 Baseline 초과 여부
• aws.elasticache.traffic_management_active : Throttling 발생 여부

또한 Datadog Alert를 연동해 네트워크 대역폭이 임계치를 넘을 경우 즉시 알림을 받을 수 있도록 설정하여 이상 징후를 빠르게 인지하고 사전에 대응할 수 있는 기반을 마련했습니다.

4–2. 캐시 전략 변경 (캐시 계층화)

Redis 네트워크 부하를 줄이기 위해 로컬 캐시로 처리 가능한 데이터는 서버 내부 메모리에서 우선 처리하도록 구조를 변경했습니다.

응답 변경 빈도가 낮은 데이터를 중심으로, 기존의 단일 Redis 의존 구조에서 벗어나 Caffeine(Local Cache) → Redis (Remote Cache) → DB로 이어지는 캐시 계층화 구조로 전환했습니다. 이를 통해 Redis에 집중되던 트래픽을 완화하고, 전체적인 응답 안정성을 높일 수 있었습니다.

캐시 전략을 적용한 직후, 실제로 Redis 부하가 감소했는지 지표를 확인했습니다.

Redis Command Count

우선 로컬 캐시가 제대로 역할하고 있는지 확인하기 위해 Redis 명령어 호출 수를 살펴봤습니다. 그 결과, Redis 명령어 호출이 눈에 띄게 감소한 것을 확인할 수 있었습니다.

로컬 캐시가 상당 부분을 흡수하면서 Redis가 직접 처리해야 하는 요청이 그만큼 줄어든 것입니다.

Redis Outgoing Bytes 일별 비교 (노란색: 전일, 빨간색: 당일)

Redis 명령어 호출이 줄어든 만큼, 네트워크 Outgoing Throughput 역시 함께 감소했습니다.

기존에는 대용량 데이터를 주고받느라 네트워크 사용량이 높게 유지되었으나, 로컬 캐시가 이를 대신 처리하면서 Redis까지 전달되는 데이터양이 크게 줄어들었습니다.

5. 장기 개선 과제

이번 장애를 계기로, 단기적인 문제 해결에 머무르지 않고 중·장기 관점에서 트래픽 성장에 대비할 수 있는 인프라 구조로 전환하고자 합니다.

5–1. 캐시 데이터 최적화 (Snappy + protobuf)

Redis 네트워크 대역폭 사용량을 근본적으로 줄이기 위해 캐시 데이터 압축을 검토하고 있습니다. CPU 사용량이 적고 압축/해제 속도가 빨라 실시간으로 데이터를 읽고 쓰는 캐시 환경에 적합한 Snappy 압축 알고리즘을 고려하고 있습니다.

또한 JSON 형태로 저장되고 있는 캐시 데이터를 Protocol Buffers(protobuf) 형식으로 전환하는 것을 검토 중입니다. protobuf는 JSON 대비 데이터 크기가 작고 직렬화/역직렬화 속도도 빠르므로, 네트워크 대역폭 절감과 성능 향상을 동시에 기대할 수 있습니다.

실제 캐싱 중인 Item Document 데이터를 기준으로 측정한 결과, Snappy 압축 + protobuf를 함께 적용했을 때 기존 대비 약 73%의 용량 절감이 가능할 것으로 예상합니다.

6. 마치며

이번 장애를 통해 Redis 대역폭 초과라는 예상치 못한 장애 지점을 발견할 수 있었습니다. CPU와 Memory 지표만으로는 문제를 인지하기 어려웠으며, 네트워크 관점의 모니터링 필요성을 다시 한번 체감하는 계기가 되었습니다.

문제 해결 과정에서 캐시 구조 개선, 모니터링 고도화, 읽기 분리 적용 등 여러 기술적 부채를 해소했고, 현재는 이를 바탕으로 트래픽 증가에 대비한 아키텍처 개선을 진행하고 있습니다.

저희 팀은 전시, 콘텐츠, 기획전, 선물하기 등 사용자가 마주하는 서비스의 첫인상과 주요 탐색 흐름을 책임지고 있습니다. 앞으로도 더 빠르고 안정적인 사용자 경험을 제공하기 위해 지속적으로 구조를 점검하고, 확장 가능한 시스템으로 발전해 나가고자 합니다. 언제나 문제 해결의 모든 과정에서 적극적으로 함께해 준 팀원 모두에게 감사의 말씀을 전하며 글을 마칩니다.

긴 글 읽어주셔서 감사합니다.

TEAM MUSINSA CAREER

무신사는 2001년 온라인 커뮤니티로 시작해 2005년 무신사 매거진, 2009년 무신사 스토어를 오픈하며 빠르게 성장하고 있는 국내 대표 온라인 패션 스토어입니다. ‘입점 브랜드와 동반성장’이라는 경영 철학을 바탕으로 브랜드가 안정적으로 사업을 전개할 수 있도록 무신사가 보유한 노하우와 인프라를 지원합니다. 고객에게는 풍성한 패션 콘텐츠와 패션에 특화된 차별화된 서비스로 최상의 온라인 쇼핑 경험을 제공하고 있습니다. 글로벌 №1 패션 기업으로 성장할 무신사와 함께 새로운 도전과 혁신을 만들 인재를 기다립니다.

29CM는 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!

*🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)*

🚀 팀 무신사 테크 소식을 받아보는 링크드인

🚀 팀 무신사 뉴스룸