[Redis] Redis scan의 performance 테스트

 

ㅁ 개요

 ㅇ ELB 쪽에서 처리 지연 알람이 발생하였다. 외부에서 연동된 정보를 처리하면서 내부처리 로직의 수행시간이 지연이 되면서 전체 응답속도에 지연이 발생한 것이다. 

 ㅇ 구체적인 원인은 Redis Scan 명령어 처리 시에 count가 기본 10으로 책정되어 있어서 발생한 문제점이었다.

 ㅇ 이 문제점을 분석하면서 수행하였던 Scan performance 테스트 과정을 정리하였다.

 

 

ㅁ Redis Scan이란?

 ㅇ  HSCAN key cursor [MATCH pattern] [COUNT count] 명령문으로 사용하고

      count를 통해 분할 조회 건수를 조정할 수 있고, 

      pattern으로 like 조회를 지원한다. pattern은 GLOB style pattern이다.

pattern	Example	Matches
*	Law*	Law, Laws, Lawyer...
?	?at	Cat, cat, Bat, bat...
[abc]	[CB]at	Cat, Bat
[a-z]	Num[0-9]	Num0, Num1, Num2, Num3...

 

 

 

ㅁ Scan 속도지연 원인은?

 ㅇ 다른 고객의 정보를 동기화하는 과정은 문제가 발생하지 않았다. 하지만 특정 대형고객의 경우는 2만건 이상이기 때문에 

     count가 기본으로 되어 있는 경우 10건씩 2천번 이상을 호출하게 된다.

이럴 경우 Redis가 다른 명령어를 처리하는 blocking을  최소화 하겠지만, 네트워크를 연결하고 전송하고 수신하는 일련의 과정에 따른 네트워크 I/O가 추가적으로 발생하게 된다. Redis 자체는 event loop방식으로 비동기로직이기 때문에 고성능이지만 어디까지나 Redis도 TPS 네트워크를 기반으로 하기 때문에 너무 빈번한 호출은 네트워크  I/O를 발생시키는 한계점이 있는 것이다.

 

이를 해결하기 위해서는 blocking을 최소화 하면서도 너무 빈번한 호출로 인한 네트워크 I/O를 최소화 할 수 있는 방안을 검토해야만 하였고, 그 지표를 얻기 위해 테스트를 진행하였다.

 

ㅁ 테스트 코드

 ㅇ scan 조회 시 cnt를 동적으로 주어 처리 속도를 로그에 기록하도록 하였다.

 

 

 ㅇ 조회 대상이 되는 키의 사이즈는 약 1만건이었다.

 

 

ㅁ count 10건 테스트

 ㅇ 22.119 초가 소요되었다.

 

 

ㅁ count 100건 테스트

 ㅇ 2.845 초가 소요되었다.

 

 

ㅁ count 500건 테스트

  ㅇ 0.43초가 소요되었다.

 

 

count	시간(ms)
10	22119
100	2845
500	430

 

ㅁ  redis scan 가장 이상적인 performance는 무엇인가?

redis scan은 1.4 이후 제공된 기능으로 기존 keys를 호출하여 전체 key를 조회 하였을 때의 blocking를 최소화하기 위해
paging과 offSet 개념을 도입하여 분산처리가 가능하게 하여 blocking 시간을 최소화 하였다.
하지만 scan count를 기본 10으로 할 경우 오히려 너무 분산처리 한 나머지

지나친 분산처리로 인해 네트워크I/O에 따른 병목현상이 발생하여 더 큰 blocking를 초래할 수 있다.

실제로 count 10건 테스트에 따라 1000번의 트래픽이 발생하여 22119ms가 걸렸다.

 

count 500건으로 테스트한 결과 속도는 430ms 소요되었는데,
적정 카운트 숫자는 300~500 정도가 적당하다고 판단된다.

너무 많은 데이터를 호출할 경우 Redis의 blocking 시간도 걸리겠지만, 수집된 데이터를 전달하는 네트워크 시간도 소요되기 때문이다.

 

사실 근본적인 문제는 Redis의 특성을 고려하여 키에 너무 지나친 데이터를 넣는 것은 바람직하지 않다고 판단된다. 

현재 운영에서 문제의 KEY는 49211건 인데,

KEY가 6만건이 넘어가는 시점에는 해당키_{구분자}로 키를 분리하는 것이 바람직하다고 판단된다..

결론적으로, scan의 경우도 hashTable이 5만건 이상이 될 경우 병목현상이 일어 날 수 있기 때문에
현재 상황에서는 5만 건에 count : 300~500에서 조정하는 것이 바람직하다고 생각한다.

 

 

ㅁ 함께 보면 좋은 사이트

https://tjdrnr05571.tistory.com/11