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

서비스 고도화 및 MSA 변환 과정에서 Redis 도입 후 API 버전 업데이트로 장애가 발생했다. APM 분석 결과, Key 값 미적재로 인해 AWS RDS에 부하가 집중되는 Look-Aside-Caching 방식의 문제가 확인되었다. 회사 내 표준 Redis 규격과 성능 테스트 기반 Sizing 모델이 부재하여, 문제 재현 및 검증과 팀 내 경험 공유를 위해 테스트를 진행했다.

테스트 환경 및 도구 선정

AWS Elasticache 사용으로 외부에서 redis-benchmark 명령어 수신 불가, 문제 재현 필요성, 팀 공유 목적 등으로 인해 Node.js와 Express로 작성된 간단한 API와 nGrinder를 부하 테스트 도구로 선정했다. 테스트 환경은 cache.m5.large(Failover 모드)와 EC2 c5.large 2대로 구성했으며, 기존 PHP 기반 API가 Strings 타입을 사용하므로 NodeRedis 클라이언트를 이용해 Strings 데이터 처리 코드를 작성했다.

부하 테스트 결과 및 원인 분석

첫 번째 시나리오에서 nGrinder Total Vuser 1,500명으로 부하를 가했을 때 무수한 Error가 발생하고 TPS가 바닥을 쳤다. Key 부재 또는 Expire 후 Set 및 데이터 체크 시점에 Read Endpoint의 CPU 사용률이 높게 나타났으며, 200 유저 이상 요청 시 Primary Endpoint CPU 사용률이 25% 이상 상승했다. 이는 Single Process 특성상 느린 명령어 실행이나 동시 다발적 GET 호출로 인한 Key 존재 여부 확인 로직의 병목 현상으로 판단했다.

최적화 및 시사점

두 번째 시나리오에서는 Loop 문을 제거하고 Key가 null일 때만 Set 및 Value를 체크하는 단순 로직으로 변경했다. 그 결과, 긴 Strings 값을 넣어도 CPU 사용률이 높지 않았으며 평균 TPS가 초기 테스트 대비 훨씬 높게 측정되었다. 개발자 의견에 따르면, 많은 클라이언트가 동시에 호출하며 특정 Key 값 변경이 빈번한 경우 Redis보다 File Cache 사용이나 적절한 Collection 선택이 중요하다. Redis 사용 시 데이터 적재 방식 고민과 장애 대응 대책 마련이 필수적임을 확인했다.