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

장애 발생 및 원인 분석

• 이구위크 행사 중 상품 전시 서버에서 Netty 이벤트 루프 포화 및 파드 다운 발생.
• 초기 Redis CPU/Memory 정상으로 판단했으나, Redis 헬스체크 실패 로그 발견 후 네트워크 지표 재확인.
• cache.r7g.large 타입의 Redis가 기본 **네트워크 대역폭(0.937Gbps)**을 초과하는 2.0Gbps 트래픽을 받음.
• AWS ElastiCache의 버스트 크레딧 소진 후 **네트워크 스로틀링(Throttling)**이 발생하여 Redis 응답 지연 및 커넥션 실패 폭증. 장애 대응 및 재발 방지
• 원인 파악 후 즉시 **Redis 노드 스케일업(cache.r7g.2xlarge)**을 통해 네트워크 용량 약 2배 증설하여 장애 해소.
• 모니터링 강화: 네트워크 In/Out 대역폭 초과 및 Throttling 발생 여부를 실시간으로 확인할 수 있도록 대시보드 및 Datadog Alert 설정.
• 캐시 전략 변경: Caffeine(Local Cache) → Redis (Remote Cache) → DB로 이어지는 캐시 계층화 구조 도입으로 Redis 부하 감소 및 응답 안정성 향상. 장기 개선 과제
• 캐시 데이터 최적화: Snappy 압축 알고리즘과 Protocol Buffers(protobuf) 형식 전환을 통해 Redis 네트워크 대역폭 사용량 및 데이터 크기 절감 검토.
• Snappy + protobuf 적용 시 기존 대비 약 73% 용량 절감 예상.