서비스 성능을 높이기 위해 여러 영역에서 캐싱을 활용하고 있습니다. 그중 사용자 맞춤 데이터를 빠르게 제공하기 위해 Redis를 사용하고 있는데요. Redis 관련 지표를 모니터링 하던 중 신규 커넥션 생성이 많은 현상을 발견하였습니다. 처음엔 단순한 설정 문제로 생각했지만, 원인을 추적하는 과정에서 Redis와 Lettuce, Elasticache의 동작 방식을 깊이 이해하게 되었습니다. 이번 글에서는 그 과정을 공유하려 합니다. 프로젝트 환경 […]
The post Redis New Connection 증가 이슈 돌아보기 first appeared on 우아한형제들 기술블로그. ||
서비스 성능을 높이기 위해 여러 영역에서 캐싱을 활용하고 있습니다. 그중 사용자 맞춤 데이터를 빠르게 제공하기 위해 Redis를 사용하고 있는데요. Redis 관련 지표를 모니터링 하던 중 신규 커넥션 생성이 많은 현상을 발견하였습니다. 처음엔 단순한 설정 문제로 생각했지만, 원인을 추적하는 과정에서 Redis와 Lettuce, Elasticache의 동작 방식을 깊이 이해하게 되었습니다. 이번 글에서는 그 과정을 공유하려 합니다.
프로젝트 환경
Spring Boot 3.2.4
lettuce 6.3.2
elasticache valkey 8
상황
Redis 관련 지표를 살펴보다가 신규 커넥션 연결 수량 지표가 이상한 것을 확인하였습니다. 오후 저녁 시간대가 지나서 자정으로 향하는데도 불구하고 신규 커넥션 연결 지표가 줄어들지 않고 있었습니다. 행여라도 조회 시점에 매번 새로운 커넥션을 만들고 있으면 커넥션 생성시간 동안 지연이 될 가능성도 있을 것 같았습니다.
혹시라도 커넥션 풀 없이 매번 커넥션을 새로 만드나 하여 서버 내 Lettuce 설정을 보았을 때 이미 커넥션 풀을 사용하고 있었습니다. 그렇다면 커넥션을 생성하더라도 적은 수의 커넥션을 생성할 것으로 예상이 되었는데요. 커넥션을 새로 맺는 횟수가 오히려 피크시간에 비해 자정에 더 높게 잡히는 것에서 의문이 들어 상황을 좀 더 파악해 보았습니다.
가장 먼저 의심한 부분은, 파이프라이닝에서 커넥션을 만드는 부분이었습니다.
파이프라이닝에서의 커넥션 사용
저희 팀에서는 특정 사용자가 최근 본 상품을 캐싱하는 데 Redis를 사용하고 있습니다. 이 때, redis list 자료구조를 사용하고 있는데요. list의 데이터 중 일부 데이터들만을 효율적으로 처리하기 위해 파이프라이닝을 사용하고 있습니다.
파이프라이닝 내부에서 수행하는 동작은 대략 아래와 같습니다.
push (최근 본 상품 추가)
trim (전체 list 개수 조정)
expire (TTL 재조정)
일반적으로 redisTemplate을 사용하는 경우, 하나의 커넥션을 공유해서 사용하는데요. 위 케이스에서는 여러 명령어를 묶어서 효율적으로 처리하기 위해 redisTemplate의 executePipelined 메소드를 사용하여 파이프라이닝을 구성하고 있는 상태였습니다. executePipelined 메소드를 사용하는 경우, 파이프라이닝 처리를 위한 전용 커넥션을 할당받게 됩니다.
코드 분석
RedisTemplate의 executePipelined 메소드를 조금 더 살펴보겠습니다.
public class RedisTemplate<K, V> extends RedisAccessor implements RedisOperations<K, V>, BeanClassLoaderAware {
...
@Override
public List<Object> executePipelined(RedisCallback<?> action, @Nullable RedisSerializer<?> resultSerializer) {
return execute((RedisCallback<List<Object>>) connection -> {
connection.openPipeline(