JWT 로그인 시 RefreshToken 저장에 Redis를 사용하는 이유

이전에 진행했던 프로젝트에서 JWT 로그인을 구현하였습니다.

JWT 로그인에는 Access-Token과 Refresh-Token이 쓰입니다.

한마디로 표현하면, 액세스 토큰은 인증을 위한 토큰, 리프레시 토큰은 액세스 토큰을 재발급하기위한 토큰입니다.

 

리프레시 토큰은 서버에서 만들어서 MySQL에 저장하고, http 쿠키로 생성하여 프론트엔드로 넘겨주었습니다.

그런데 프로젝트 리팩토링을 진행하면서, MySQL에 저장했던 리프레시 토큰을 Redis로 바꾸려고 합니다.!!

 

왜 Redis로 바꾸는 것이 좋을 지에 대해 정리해보겠습니다.

 

 

 

 Redis 란? 

Redis(Remote Dictionary Server)는 [키(Key) - 값(Value)] 쌍의 해시 맵과 같은 구조를 가진 비관계형(NoSQL) 데이터베이스입니다.

또한, SSD/HHD 같은 보조기억장치가 아닌, 컴퓨의 주 메모리인 RAM에 데이터를 저장하는 In-Memory 방식의 데이터베이스입니다.

따라서 별도의 쿼리문이 필요 없고, In-Memory에 저장되기 때문에 빠르다는 장점이 있습니다.

 

💡 인-메모리 방식이 빠른 이유?
프로그램을 실행할 때, CPU는 주 메모리인 RAM에 있는 데이터를 처리합니다.
RAM은 영구적으로 데이터를 저장하는 곳이 아니라, 일시적으로 데이터를 저장하는 휘발성 메모리입니다.(전원이 꺼지면 날아감)
그래서 비휘발성의 특징을 가진 디스크(SSD/HDD)에서 필요한 데이터를 RAM에 올려 CPU가 처리하게끔 합니다.
즉, 디스크 -> 메모리 -> CPU의 과정을 거쳐야하지만, 인메모리 방식의 경우 메모리에 데이터를 저장하기 때문에 디스크에 접근을 하지 않아도 되어 빠른 속도를 가집니다.

 

 

이러한 이유로, Redis는 캐싱에 많이 쓰이기도 합니다.

빠르다는 특징 외에도, Refresh-Token을 Redis에 저장하는 경우 장점이 몇가지 더 있습니다.

위에 말한 장점과 같이 정리해보겠습니다.

 

 

 

 

 Refresh Token을 Redis에서 사용하는 이유 

1) 유효기간 지정 가능

Redis는 데이터의 유효기간(TTL, Time-To-Live)을 정할 수 있습니다.

관계형 데이터베이스에서는 리프레시 토큰을 만료시키기 위해서 주기적으로 만료된 토큰을 삭제시키는 요청이나 스케쥴링을 해야하고, 이는 비효율적인 비용을 발생시킵니다.

Redis에서는 리프레시 토큰의 만료일과 똑같이 맞춰 지정할 수 있어, 토큰이 자동으로 삭제되도록 하여 더 효율적입니다.

 

2) 성능 이점

Redis는 앞서 말한것처럼 레디스는 인-메모리 방식이라 성능이 RDB에 비해 빠릅니다.

리프레시 토큰은 액세스 토큰을 재발급하기 위해서 자주 호출해야하기 때문에, 성능이 더 빠른 레디스(인-메모리)에 저장하는 것이 더 유리합니다.

 

 

 

 Redis vs RDB 

 

그런데, Redis는 휘발성 메모리여서 장애가 나거나 전원이 끊어질 경우 데이터가 날아갈 수 있습니다.

그렇다면 영구적으로 저장할 수 있는 RDB가 낫지 않을까요?

 

그렇지만, 리프레시토큰은 전부 지워지더라도 모든 유저가 로그아웃되고 재로그인을 해야한다는 것이 전부여서 그렇게 크리티컬한 일은 아니라고 판단하였습니다. 혹여나 데이터가 날아가 재로그인을 해야하는 상황을 고려하더라도, 속도가 매우 뛰어나기 때문에 Redis를 선택하는 것이 더 이득이라고 생각하여 리팩토링을 진행중입니다.

 

어떤 기술을 변경할때는 항상 트레이드오프가 있지만, 상황과 비용을 잘 따져서 선택하는 것이 중요하다고 생각합니다.