[Redis] LREM의 큐처리방향에 따른 처리속도지연 정리

 

ㅁ 개요

 ㅇ 트래픽이 증가 하면서 Redis 부하상태가 발생하였다.

 ㅇ 원인은 데이터가 적체되면서 lrem의 처리 속도가 저하되었고, 

     그로 인해 적체 가속도가 증가하여 처리 속도는 더욱 늦어지는 교착상태가 되었다.

 ㅇ Redis큐의 처리 방향에 따라 처리 속도 지연이 발생했던 문제점을 분석하고 정리하였다.

 

ㅁ LLEM 이란

lrem {키} {건수} {value} 형태로 사용하며 값으로 삭제한다.

건수가 양수이면 value를 리스트 왼쪽부터 찾아서 건수만큼 삭제한다.

건수가 0이면 value 전체를 삭제하고 삭제건수를 리턴한다.

 

건수가 음수이면 value를 리스트 오른쪽부터 찾아서 건수만큼 삭제한다.

 

 

ㅁ 큐 방향성 문제 분석

문제점은 큐 처리 방식을 first in last out에서 first in first out으로 변경하면서 큐 적체 시 lrem이 지연되는 현상이었다.

큐를 처리할 때에 색인 방향을  first in last out -> first in first out으로 변경 하였고, 
삭제 시 큐가 적체되면 lrem의 처리속도도 함께 지연되면서  Redis 엔진 CPU 과부하 상태가 되었고,

이는 또 큐적체가 가중되는 교착상태가 되었다.

 

 

ㅇ 기존 큐 처리 방식

  - first in last out : 큐는 lpush로 등록되어 lrange로 조회하여 마지막에 넣은 것이 처음으로 처리가 된다.

 - 큐를 1 2 3 4 5 6 7 8 9 0 순서로 등록

 - lrange que 0 -1 조회 시 0, 9, 8, 7, 6, 5, 4, 3, 2, 1 조회됨.
 - 처리 순서는 0, 9, 8, 7, 6... 되고 삭제처리(lrem)도 0, 9, 8, 7, 6... 방향으로 처리된다.

 - 구체적으로 삭제 처리 시 0, 9, 8 순차적으로 삭제처리하기 때문에 큐가 적체되어도 lrem 처리지연은 발생하지 않는다.

 - 모든 요청 처리 시 색인 payload가 1뎁스로 처리되기 때문이다.

명령	que 상태	payload
lrem que 1 0	0, 9, 8, 7, 6, 5, 4, 3, 2, 1	1뎁스
lrem que 1 9	9, 8, 7, 6, 5, 4, 3, 2, 1	1뎁스
lrem que 1 8	8, 7, 6, 5, 4, 3, 2, 1	1뎁스

 

ㅇ 변경 된 큐 처리 방식 

- first in first out : 처음 등록된 큐가 처음 처리 되도록 변경작업

- 변경 큐 처리 방법

 1) lrange que 0 5 -> lrange que -5 -1으로 변경하였다.

     조회 시 5, 4, 3, 2, 1

 

 2) java에서 리스트 연전처리 

 Collections.reverse(list);

 큐처리 순서는 1, 2, 3, 4, 5... 으로 순차적 진행이 되었지만
 삭제처리 시  큐가 젝체되면서 지연이 발생하였다.

명령	que 상태	payload
lrem que 1 1	0, 9, 8, 7, 6, 5, 4, 3, 2, 1	10뎁스
lrem que 1 2	0, 9, 8, 7, 6, 5, 4, 3, 2	9뎁스
lrem que 1 3	0, 9, 8, 7, 6, 5, 4, 3	8뎁스

여기서 큐가 더 추가되면 payload는 증가하고 lrem의 처리 속도는 저하되는 문제가 발생한다.

 

% 참고로

 - LRANGE의 Enterprice 버젼의 경우 sort, asc, desc를 제공한다.

 - 현재 사용중이 Redis버젼은 무료버젼이라서 java에서 순서 조정을 하고 있다.

 

 

ㅁ 해결방안 도출과정

ㅇ 근본적 원인 도출을 위해 grafana 지표로  LREM 지연현상 확인

 command 통계를 확인하여 지연이 되었던 long쿼리 command 확인

ㅇ slowlog 확인

 

ㅁ LLEM 검증 로컬 테스트

ㅇ 로컬에서 redis에 TEST2 큐에 400만 건을 주입한 후 삭제 처리 시 속도 비교

 

ㅇ 결과 로그

2022-03-14 10:11:00.114 [ctor-http-nio-6]  INFO [k.c.u.r.r.c.CommonController  ] (147 ) : test ldelete speed start 2022-03-14 10:11:00.140 [ctor-http-nio-6]  INFO [k.c.u.r.r.c.CommonController  ] (154 ) : test ldelete speed end, time=24 2022-03-14 10:11:00.141 [ctor-http-nio-6]  INFO [k.c.u.r.r.c.CommonController  ] (156 ) : test rdelete speed start 2022-03-14 10:11:00.602 [ctor-http-nio-6]  INFO [k.c.u.r.r.c.CommonController  ] (163 ) : test rdelete speed end, time=460

 -  큐가 적체 되어 있어도 lpush 후 lrem 시 왼쪽부터 삭제하면 처리속도의 지연은 없지만

     오른쪽부터 삭제할 경우 처리속도가 큐의 길이만큼 지연이 발생한다.

 

 

ㅁ 참조

http://redisgate.kr/redis/command/lrange.php

http://redisgate.kr/redis/command/lrem.php