세줄 요약
- TTL설정을 통해 Refresh Token이 쌓이는 것을 방지하기 위하여 Redis를 사용한다.
- DB(Disk)가 아닌 Redis(memory)에 저장하면, 데이터 작업 속도의 이점이 있다.
- Elasticache를 통해 Redis서버 모니터링을 할 수 있다.
수정 사항
access token의 만료 기한이 10분이므로 클라이언트에서는 계속하여 reissue(refresh token이 유효하면 access token이 재발급됨)을 자주 요청할 수밖에 없다.
현재 refresh token은 DB(디스크)에 저장되어 있고, 서버에서 DB에 refresh token이 존재하는지 찾아보는 로직으로 reissue가 구성되어 있다.
하지만 주기적으로 쌓인 refresh token을 삭제해주어야 하는 단점이 존재하고, DB에 쌓일수록 reissue의 응답시간은 길어질 수밖에 없다고 생각한다.
따라서 Redis에 TTL을 1일로 걸어두고 관리한다면, reissue 요청의 응답시간도 단축될 것을 기대한다.
환경구축
Redis를 EC2 인스턴스 내부에 설치하여 사용할까 고민했지만, 서버를 따로 두는 것이 더 안정적일 것이라고 판단하였기에 Elasticache를 사용하였다.
사용자 수가 적은 동안은 T2.micro(프리티어)를 사용할 예정이다.
배포환경 응답시간 비교(JMeter)
DB에 저장할 때
refresh token은 reissue가 요청될때마다 새롭게 변경되기 때문에 여러번의 요청을 한번에 보내진 못했지만, 여러번 테스트해본 결과 65~75ms가 평균을 이루었다.Redis에 저장할 때
마찬가지로 여러번 테스트 해봤을 때, 평균적으로 45~55ms가 평균을 이루었다.
즉, 배포 환경에서는 평균 70ms -> 50ms 로 속도가 개선되었다.
로컬환경 응답시간 비교(Profiler)
DB에 저장할 때
Redis에 저장할 때
둘 다 배포환경보다 빠르게 응답하였지만, 여전히 Redis를 사용할 때 더 빠른 응답 속도를 보여주었다.
로컬 환경에서는 평균 50ms -> 30ms로 속도가 개선되었다.
Redis서버 메모리
Elasticache에서 제공하는 모니터링 서비스로 위에 테스트를 하며 Refresh token이 2개가 저장되어 있을때 메모리를 체크해보았다.
실제로 사용자들을 받으며 모니터링 해보아야 하겠지만, 1.5%가량 차지하는 것을 보니 refresh token이 100개가 넘게 저장되어 있는 순간, 즉 사용자가 100명이 넘는 순간부터는 모니터링을 하며 메모리를 높이거나, EC2의 사양을 높이고 인스턴스 내부에 Redis를 설치하는 방향도 생각해 보아야겠다.
