Redis를 이용해서 토큰 재발급 기능 성능 최적화

1. 토큰 재발급에 저장공간이 필요한 이유

현재 JWT 인증방식을 적용하고 있다.
해당 방식의 플로우는 대략 아래와 같다.

1. 로그인시 Access Token과 Refresh Token이 발급된다.
2. 권한이 필요한 API의 경우 header에 Access Token을 추가하여 요청한다.
3. Access Token이 만료된 경우에는 Refresh Token을 통해 Access Token과 Refresh Token 모두 재발급 받는다.

이러한 절차 과정에서 토큰을 저장할 공간이 필요하다.

현재 사용하고 있는 RDBMS인 MariaDB를 사용한 경우와 Redis를 사용한 경우 기능, 성능적 차이를 비교해보았다.

아래는 최종 비교 결과이다.

 

Redis에 대해 자세히 알고 싶으면 이전에 작성한 포스팅을 참고하자!

2023.08.20 - [🛢️Database] - Redis 알고 사용하자!

Redis 알고 사용하자!

 

잠깐! java의 HashMap에 데이터 저장하면 안되나?

private final Map<String, Object> map = new HashMap()

"HashMap에 데이터를 저장해도 메모리에 저장할 수 있는데 이걸 사용하면 안되나?" 라고 생각할 수 있다.

문제는 크게 두가지가 있다.

1. 서버가 여러대인 경우 Consistency 문제가 발생가능하다.
2. Multi-Threaded 환경에서 Race Condition 문제가 발생가능하다.

Race Condition의 경우
 RedIs는 기본적으로 Single Threaded이고 자료구조를 Atomicity Critical Section에 대한 동기화를 제공한다.

Critical Section?
동시에 여러 프로세스가 접근해서는 안되는 영역

따라서, Redis는 서로 다른 Transaction Read/Write를 동기화해서 Race Condition 문제를 해결한다.

 

2. Redis의 TTL을 사용한 기능적 이점과 RDB 사용한 경우 대체 기능

Redis는 특정 시간 동안만 데이터가 저장되는 TTL(Time To Live) 기능을 'expire'라는 명칭으로 제공하고 있다.
간략하게 설명하면 아래와 같은 작업을 진행한다.

Redis가 초당 10회로 다음 작업을 수행한다.
1. TTL이 첨부된 임의의 키 20개를 테스트한다.
2. 20개 중 만료된 모든 키를 삭제한다.
3. 20개 중 25% 이상이 만료된 경우, 1단계를 반복한다.

캐시는 메모리를 사용하기에 주기적으로 데이터를 백업하거나 만료기간을 설정하여 자동으로 삭제되도록 구현해야 한다.

1. 로그인 시에 발급된 Refresh Token을 Redis에 저장한다. (해당 토큰의 만료시간을 TTL로 설정)
2. 토큰 재발급을 요청받았을 때 Redis에서 클라이언로부터 전달받은 Refresh Token과 일치하는게 있는지 확인한다.
        (1) 일치하는게 있을 경우 토큰을 새로 발급하여 전달한다.
        (2) 일치하는게 없을 경우 재로그인하도록 한다.

위 과정을 거친다. 

 

여기서 만약 RDB를 사용했다면 TTL 기능을 대체하려면 어떻게 해야할까?
1. 애플리케이션에서 스케줄링 작업을 생성해서 만료시간이 지난 Refresh Token 데이터를 삭제한다.
2. MariaDB의 event_scheduler 기능을 이용하여 DB단에서 주기적으로 만료시간이 지난 Refresh Token을 삭제하도록 한다.
3. 만료시간이 지난 Refresh Token 데이터를 삭제하지 않고 가장 최근에 들어온 데이터로 비교한다.  

이렇듯 만료시간이 지난 Refresh Token을 삭제하기 위해서 많은 작업을 진행해야 한다.

 

3. 토큰 재발급 기능의 Redis와 MariaDB 성능 비교

 

토큰 재발급 API의 성능을 Redis를 사용한 경우와 MariaDB를 사용한 경우 성능을 측정해보았다.

각각 10회씩 실행하여 Redis를 사용한 경우에는 평균적으로 99.6ms, MariaDB를 사용한 경우에는 130.8ms의 성능을 보여주었다.

별로 차이가 안나보일 수 있지만, 99.6ms -> 130.8ms 성능향상도를 퍼센트로 나타내면 31.3% 향상되었음을 알 수 있다.