이구위크 장애, Redis 대역폭 병목이 원인이었다!
이구위크 기간 중, 상품 전시 화면에서 Redis 장애 발생
Redis 네트워크 대역폭 초과로 인한 AWS Throttling이 원인으로 밝혀짐
Redis 노드 스케일 업 및 캐시 계층화를 통해 문제 해결
모니터링 강화 및 캐시 데이터 최적화를 통한 재발 방지 노력
향후 Snappy 압축, protobuf 적용을 통한 캐시 성능 개선 계획
Redis 대역폭 병목의 기술적 배경
이구위크 트래픽 급증으로 인해 Redis 네트워크 대역폭(0.937Gbps) 초과가 발생했다.
AWS ElastiCache의 버스트 크레딧 소진으로 인한 Throttling 발동
Throttling: Baseline 초과 시 네트워크 성능이 강제로 제한되는 현상
결과: Redis 응답 지연 및 커넥션 실패로 전시 서비스 장애 발생
평소에는 문제없던 환경에서 트래픽 급증 시 네트워크 대역폭 한계가 드러난 사례이다.
장애 해결을 위한 즉각적인 조치
장애 발생 후, Redis 노드 스케일 업을 통해 즉각적인 서비스 복구를 시도했다.
기존: cache.r7g.large (0.937Gbps) → 변경: cache.r7g.2xlarge (1.875Gbps)
노드 스케일 업으로 네트워크 대역폭을 2배로 증설
장애 당일 서비스 정상화 완료
한계: 근본적인 해결책이 아니며, 트래픽 증가 시 재발 가능성 존재
결과적으로 임시 방편이었지만, 서비스 중단을 막는 데 기여했다.
재발 방지를 위한 모니터링 강화
네트워크 대역폭 초과를 실시간으로 감지하기 위해 모니터링 시스템을 개선했다.
주요 지표: 네트워크 In/Out 바이트, Baseline 초과 여부, Throttling 발생 여부
Datadog Alert 연동: 임계치 초과 시 즉시 알림 발송
목적: 이상 징후를 조기에 감지하고, 사전 대응 가능하도록 지원
효과: 문제 발생 시점 파악 및 빠른 대응을 가능하게 함
결과적으로, 가시성 확보를 통해 문제 재발 가능성을 낮췄다.
캐시 계층화를 통한 Redis 부하 감소
Redis 부하를 줄이기 위해 캐시 계층화를 도입하여 로컬 캐시를 활용했다.
기존: 단일 Redis 의존 구조 → 변경: Caffeine(Local Cache) → Redis (Remote Cache) → DB
로컬 캐싱: 응답 빈도가 낮은 데이터를 서버 메모리에서 우선 처리
결과: Redis 명령어 호출 수 감소, Redis Outgoing Throughput 감소
장점: Redis 부하 감소, 전체적인 응답 안정성 향상
결과적으로, Redis의 병목 현상을 완화하고 시스템 전반의 성능을 개선했다.
장기적인 캐시 데이터 최적화 전략
Redis 네트워크 대역폭 사용량 절감을 위해 캐시 데이터 압축 및 형식 변경을 계획하고 있다.
Snappy 압축: CPU 사용량 적고 압축/해제 속도가 빨라 캐시 환경에 적합
Protocol Buffers(protobuf): JSON 대비 데이터 크기 감소 및 직렬화/역직렬화 속도 향상
예상 효과: 약 73%의 용량 절감 예상
목표: 지속적인 트래픽 증가에 대비하고, 시스템 성능을 향상
결과적으로, Redis의 효율성을 극대화하고 미래의 확장을 위한 기반을 마련한다.
