[REDIS] 레디스 조회 성능 개선 - 1

1. 문제 상황

회사에서 겪은 문제입니다.

 

레디스 hash 구조로 데이터가 저장되어 있습니다.

그리고 이 중 몇 개를 가져와서 가공 후 실제 데이터를 제공합니다.

 

부하테스트를 했을 때 기대치보다 낮은 결과가 나왔었습니다.

그래서 원인을 파악하기 위해서 시간을 로그로 찍어본 결과, redis에서 데이터를 조회하는 데에 대부분의 시간을 소모하고 있었습니다.

 

레디스에서 데이터를 읽는 데만 약 140~200ms 정도 걸렸었습니다.

2. 원인

첫 번째로 생각했던 이유는 redis 설정 문제였습니다. 하지만 os 파라미터 등을 조회해봤을 때 큰 문제는 없었습니다.

두 번째는 네트워크 부하입니다. 데이터가 꽤 크기 때문에 네트워크 단에서 부하가 일어나지 않았을까라고 생각했었습니다.

마지막으로는 redis의 hkey 같은 O(N) 연산을 호출하는 연산 때문이라고 생각했습니다. 레디스는 싱글 쓰레드 기반이기 때문에 영향을 줄 수 있다고 합니다. 하지만 해당 명령어를 2분마다 한 번 호출하고 데이터 개수도 200개가 넘지 않아서 아니라고 생각했습니다.

 

 

그래서 3 가지 중 네트워크 부하가 가장 큰 문제라고 생각해서 이 문제를 해결하려고 했습니다.

 

3. 해결(?)

 

우선 redis에 데이터를 넣을 때, 크기를 줄일 필요가 있다고 생각했습니다.

그러기 위해서 저는 압축을 이용했습니다.

가상면접 사례로 배우는 대규모 시스템 설계 기초에서도 초반에 압축을 해서 응답할 경우 속도 개선이 크다고 한 걸 본 기억이 있습니다.

 

그래서 redis에 넣을 때 snappy로 압축을 해서 넣었습니다.

snappy 같은 경우에는 mongoDB에서도 쓰고 있고, 압축율은 조금 낮더라도 cpu 소모량이 낮습니다.

 

redis에 데이터를 넣는 서버는 압축을 해서 넣어야 하고, 실제 데이터를 꺼내서 처리하는 서버는 압축을 해제해야 하기 때문에 cpu 소모량이 적은 snappy를 선택했습니다.

 

146 ~ 225ms 걸리던 것이 70 ~ 87 ms 까지 개선 되었습니다. 약 2배 이상 빨라졌습니다.

또한 redis에 적재되는 용량이 3.5배 정도 줄어들었습니다.

 

하지만 압축 알고리즘이 있기 때문에 cpu 소모량을 봐야 하고, 부하 테스트도 다시 해봐야 합니다.

이 부분도 해보고, 실제 tps가 올라가는 지 실험 후 결과 공유하겠습니다.