Redis로 요청을 빠르게 처리하기

1. 문제 상황

• 서비스 주요 기능 중 하나인 피드백 작성
  • 면접 진행 중 빈번하게 피드백 저장 api에 요청
• 피드벡을 입력하면서 요청마다 DB(MySQL)에 update 하다 보니 부하가 높은 상황
• 병목지점의 판단이 필요했음. 불필요한 DB 요청이 많아 지는 것이 부담

<모면 - 면접 진행 중 피드백 작성 화면>

2. 문제 정의

• 다수의 사용자가 빈번하게 피드백을 저장 요청을 할 경우 불필요한 DB 접근 증가
• 피드백 저장 속도를 높여 다수의 사용자에게 동시에 원활한 서비스 제공

3. 해결 과정

• 저장 속도를 높여보자 => In memory 저장소인 redis와 기존 DB를 비교

부하테스트

• 측정 도구: wrk2
• 서버 환경: nCloud 2vCPU, 8GB RAM 인스턴스
• Mysql에 직접 피드백을 저장하는 api, redis에 피드백을 저장하는 api에 대해 측정
• 측정 결과는 HdrHistogram Plotter로 백분위를 시각화
• 첫번째 테스트 상황 (동시접속 100명 이상 가정)
  • 명령어: wrk2 -t10 -c100 -d20 -R100 -L [테스트 api 주소] > [결과 파일]
  • 10개의 스레드로 100개의 http connection을 열어두고, 100의 throughput(초 당 요청 수)를 유지하며 20초간 latency를 측정
• 두번째 테스트 상황 (동시접속 1000명 이상 가정)
  • 명령어: wrk2 -t10 -c100 -d20 -R1000 -L [테스트 api 주소] > [결과 파일]
  • throughput을 1000으로 늘리고 나머지 조건은 위의 상황과 동일

테스트 결과 - 첫번째 상황(throughput 100)

• MySQL에 직접 저장

  • p90값이 200ms, 가장 오래걸린 응답은 약 230ms

    

• Redis에 임시 저장

  • p90값이 125ms, 가장 오래걸린 응답은 약 165ms

    

• Redis 사용 시 성능 향상률 = (이전 시간) - (이후 시간) / (이후 시간) = 약 39%

테스트 결과 - 두번째 상황(throughput 1000)

• MySQL에 직접 저장

  • p90값이 12500ms, 가장 오래걸린 응답은 약 13000ms

  

• Redis에 임시 저장

  • p90값이 5300ms, 가장 오래걸린 응답은 약 5500ms

  • Redis 사용 시 성능 향상률 = (이전 시간) - (이후 시간) / (이후 시간) = 약 136%

    

4. 결과

• 불필요한 DB 접근을 줄이고 피드백 저장 속도를 높여 동시에 약 100명 이상이 요청을 할 경우 유의미한 경험 개선
• 보다 좋은 사용자가 경험을 제공할 것을 기대

5. 그 밖의 redis 활용

• JWT 인증에서 refresh 토큰을 관리하기
  • refresh 토큰은 access 토큰을 갱신할 때 사용
  • DB에 저장할 경우 사용자 갱신이 필요할 때마다 DB에 접근
  • refresh 토큰을 redis에서 관리하여 접근속도를 증가

참고

HdrHistogram

getting-started-with-wrk-and-wrk2-benchmarking