DevOps 엔지니어의 Redis Test 분투기 - Part 1

MSA 전환 과정에서 Redis 캐시의 키를 읽지 못해 RDS에 부하가 집중되는 장애가 발생했지만, 회사에 Redis 사이징 기준이나 재현 사례가 없어 원인 분석용 테스트를 진행했다. ElastiCache 환경에서 redis-benchmark를 쓰기 어려워 Node.js·Express로 Redis 호출 API를 만들고 nGrinder로 부하를 주었으며, redis-cli와 AWS 지표를 통해 키가 없거나 만료된 뒤 여러 요청이 동시에 GET·SET하는 구간에서 오류와 CPU 상승이 나타나는 것을 확인했다. 테스트 코드의 반복문을 제거하자 CPU 사용률이 낮아지고 TPS가 높아져, 특정 키의 동시 조회·갱신 패턴과 Redis 자료구조 선택을 신중히 해야 한다는 점을 얻었다. 또한 캐시 장애 시 Look-Aside 방식은 DB에 부하가 쏠릴 수 있으므로, Redis 장애 대응과 캐시 외 대안을 함께 고려해야 한다.

• AWS ElastiCache에서는 외부에서 redis-benchmark를 사용할 수 없고 일부 성능 관련 명령도 비활성화되어 있어, Node.js·Express API와 nGrinder로 실제 호출 흐름을 재현했다.
• redis-cli --stat와 --latency, CPU·연결 수·메모리 지표를 함께 살펴 장애가 발생하는 시점을 좁혀갈 수 있다.
• 동일한 키를 여러 요청이 동시에 확인하고 갱신하는 로직은 Redis CPU 부하와 오류를 키울 수 있으므로, 반복 처리와 동시성 패턴을 점검해야 한다.
• Redis가 응답하지 않을 때 Look-Aside 캐시의 요청이 DB로 몰릴 수 있으므로, 캐시 장애 시의 부하 대응책도 마련해야 한다.