Redis 스캔 때려서 성능 이슈 발생할 썰

개요

Redis 사용할 때 삽질한 썰 풀어봅니다.

이 삽질의 원인은 2가지 정도로 축약할 수 있는데, 1) Redis 는 싱글스레드 구조란 걸 간과한 점, 2) Redis에 scan 명령어를 날리면 어떤 일이 벌어지는지 간과한 점입니다.

 

환경 

- Java 11

- Redis Reactive 2.7

 

Redis 의 특징

우선 Redis 는 싱글스레드 구조로 작동합니다. 즉 한번에 하나의 요청만 처리할 수 있습니다. 만약 하나의 작업에서 긴 시간이 소요되면 그 뒤의 작업은 blocking 되어 시스템 전체적으로 성능이 느려질 수 있습니다. 병목이 발생할 수 있다는 의미죠. 

 

그럼 Redis 의 어떤 작업이 긴 시간을 소요하는 걸까요? 아래 이미지를 보시면 인메모리 데이터 저장소인 Redis 는 비교적 빠른 속도를 낼 수 있습니다.

 

이렇게 빠른 Redis 의 성능을 낮출 수 있는 명령어가 몇가지 있는데, 대표적으로 scan 이 있습니다. scan 명령어는 Redis에서 특정 패턴을 갖는 key를 검색하는데 사용됩니다. 아래 코드는 scan() 명령어를 사용해 "KEY" 라는 키를 검색하는 명령어입니다.  해당 키에 해당되는 값을 조회하는 것으로 예상할 수 있습니다.

 

병목 발생 지점

public List<Object> sample() {
    return redisOperations.opsForSet()
            .scan("KEY")
            .collectList()
            .block();
}

하지만 Scan 명령어는 Redis 전체의 키 값을 하나씩 조회하므로  O(N) 의 복잡도를 가져 성능 영향을 미칠 수 있습니다.

즉 key-value 데이터 구조인 Redis 에 시간복잡도 O(1)이 아닌 O(N) 의 작업을 수행하게 되는 것이죠. Redis 에 저장된 key 수가 적을 땐 괜찮겠지만, 저장되는 데이터가 점차 늘어날 수록 부하가 걸릴 수 있습니다.

이럴 경우엔 scan() 이 아닌 members() 나 isMember() 메서드를 사용하면 시간복잡도 O(1)로 동일한 결과를 낼 수 있습니다.  members 메서드를 사용하면 한 번의 조회로 값을 가져올 수 있고, 빠른 속도로 조회도 가능합니다. 

실제로 핀포인트에서 병목지점을 살펴보니, scan() 메서드를 사용한 부분에서 응답 시간이 비약적으로 오래걸린 것을 확인할 수 있었습니다 🥲

 

개선된 코드

위 코드는 아래처럼 바꾸어 개선할 수 있습니다. 

// old
public Set<Object> sample() {
    return redisOperations.opsForSet()
            .scan("KEY") // 병목 지점
            .collectList()
            .block();
}

// improved
public Set<Object> sample() {
    return redisOperations.opsForSet()
            .members("KEY")
            .collect(Collectors.toSet())
            .block();
}

코드상 시간 측정의 결과는 아래와 같습니다. 

scan() 과 members() 메서드의 시간 차이가 무려 20배 가까이 나는 것을 확인할 수 있습니다. 

 

마무리

Redis 의 싱글스레드 특성과 scan 명령어를 날리면 O(N) 시간 복잡도가 걸리는 점을 잊은 채 코드를 작성해 발생한 문제였습니다. 핀포인트에서 성능 이슈를 알려주지 않았더라면 모르고 지나칠 뻔한 내용이었습니다.

 

사실 너무 간단한 내용이라 글로 써도 되나 싶었지만, 당연한 일도 간과할 수 있다는 점을 반성하기 위해 썼습니다. 결론은 제대로 알고 쓰자!