[DB] MySQL이 아니라 redis에 refresh token을 저장했을 때의 이점이 뭘까

Refresh token을 MySQL과 같은 일반 RDBMS를 사용하는 것이 아니라 RDBMS가 아닌 redis에 저장하여 사용하는 사례가 있어서 "왜?"라는 질문을 던지고 답을 해나아가는 과정을 기록하고자 한다.

 

Redis란

redis는 디스크가 아니라 메모리에 데이터를 저장하는 인메모리 방식의 DB이다.

익숙한 MySQL의 경우 SSD, HDD와 같은 보조기억 장치(involatile 비휘발성)에 데이터를 저장하는데 In-Memory 방식의 데이터베이스의 경우 컴퓨터의 주 메모리인 RAM(volatile 휘발성)에 데이터를 저장한다.

 

운영 체제 시간에 배웠던 내용을 떠올려 보면

특정 프로세스가 실행이 되면 컴퓨터는 보조기억장치에 저장된 데이터를 RAM으로 불러와 CPU가 일을 수행한다. 

따라서 redis와 같이 인메모리 DB를 사용할 경우 보조기억장치에서 데이터를 로드하는 단계를 수행하지 않아도 되기 때문에 디스크에 데이터를 저장하는 DB보다 속도가 빠를 수 밖에 없다.

 

redis는 key-value 형태의 DB이기 때문에 조회 성능이 O(1)까지 나올 수 있다는 장점이 있고 휘발성인 RAM에 저장하기 때문에 refresh token과 같이 영원히 영구적으로 저장될 필요가 없는 값을 다루기 적합하다.

 

또한 데이터 만료일을 정할 수 있다는 것이 특징이다.

 

Refresh token을 왜 DB에 저장해야 할까

유효 기간이 비교적 짧은 Access token과 긴 Refresh token으로 분리한 이유는 토큰이 탈취될 경우 유저의 권한을 해커가 악용할 우려가 크기 때문에 보안상의 이유로 유저에 따라 Refresh token을 저장하고 Refresh token을 일회성으로 발급하여 RTR(Refresh Token Rotation)을 적용함으로써 해커의 토큰 재발급을 막을 수 있다.

그래서 Refresh token을 DB에 저장하여 토큰 재발급 시 인증된 유저임을 확인하기 위함이다.

 

 

Redis + Refresh token 뭐가 좋은 걸까

MySQL과 같은 일반적인 RDB 관계형 데이터베이스와 다르게 TTL 특징이 있다.

TTL이란 Time-To-Live으로 위에서 언급한 만료일을 지정할 수 있다는 것이다. Refresh token의 만료일과 동일하게 지정하고 만료일에 맞게 토큰이 삭제되도록 하면 된다.

 

redis의 In-Memory 방식의 조회 속도가 빠르기 때문에 자주 호출 되는 토큰 재발급 로직의 병목 현상을 방지할 수 있지만 trade-off가 존재한다. RAM이 휘발성이기 때문에 전원이 끊어지면 데이터가 모두 휘발된다. 하지만 Refresh token이 모두 삭제 되었을 때 유저가 다시 로그인해야 하는 단점이 있는데 이 단점이 Refrest token이 아니라 다른 것들이 모두 삭제 되었을 때에 비해 미미하다고 볼 수 있어서 trade-off 측면에서 손실보다 이득이 더 크다고 생각한다. 

 

위와 같은 redis의 이점을 알게 되었으니 key는 유저 정보, value는 refreshToken으로 해서 redis로 토큰 관리를 해보려고 한다~ 공부 내역인 이 이슈 링크에서 확인할 수 있다.

redis 설치부터

 

ping pong 완료