유저 세션을 레디스로 관리하기

당면한 문제는 아니지만 앞으로 WAS를 스케일아웃하면서 반드시 생기게 될 문제는 로그인한 유저의 세션 관리였다.

 

세션을 유지하는 방법에는 스티키 세션, 세션 클러스터링 등이 있지만 여러모로 트레이드 오프를 고려해봤을때 세션 클러스터링이 베스트 프랙티스라는 판단이 들었다.

 

스티키 세션은 처음에 연결된 세션으로만 유저를 계속해서 연결시키는 방법이며 세션간의 정합성을 유지시킬 필요가 없고 네트워크를 통한 오버헤드가 발생하지 않는다는 장점이 있지만

해당 노드가 죽었을때 노드에 붙어있던 세션들이 유실되며 로드밸런싱을 통한 이점을 얻지 못한다는 단점이 있다. 

세션 클러스터링은 추가 서버와 메모리를 이용하여 세션의 정합성을 유지하고 세션을 관리하는 서버가 죽지만 않는다면 세션 유실에 대한 걱정을 할 필요가 없다는 장점이 있지만

해당 서버를 유지하는데 들어가는 리소스와 세션 유실을 방지하기 위한 redundancy 관리, 네트워크를 통해 발생하는 오버헤드 등을 단점으로 들 수 있다.

 

스케일업에는 한계가 있지만 스케일아웃에는 사실상 한계가 없다는 점과 MSA로의 변경 가능성 등을 염두한다면 세션 클러스터링을 통한 세션 관리가 좋은 방법이라 생각하였다.

 

스프링에서 Session 관리로 JDBC, Redis, MongoDB 등의 설정을 제공하는데 인메모리의 이점을 이용하려면 Redis가 유일한 선택지였으며 Redis는 데이터에 대한 접근을 거의 항상 O(1)에 가깝게 유지하므로 가장 훌륭한 선택지였다.

 

도커를 통한 Redis 설치

처음에 설정할때 약간 헷갈렸던 것이 Redis를 설치해야 되냐 말아야 하나였다.

먼저 세션 클러스터링 용으로 이용하는 디펜던시가 따로 있는 것을 보아 특정 기능을 분리해서 해당 기능 만을 디펜던시해줄 수도 있다는 생각과 톰캣처럼 임베디드일 수도 있는 가능성을 생각했다.

하지만 열심히 구글링을 해본 결과 정답은 '반드시 설치를 해야한다.'이다.

 

도커 이미지 pull

docker pull redis

 

도커 이미지 run

docker run --name redis -d -p 6379:6379 redis

 

application.properties 및 build.gradle 설정

 

application.properties

host와 port는 default가 각각 localhost, 6379이므로 필요에 맞게 설정하면 된다.

spring.redis.host=localhost
spring.redis.port=6379
spring.session.store-type=redis

 

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-data-redis'
implementation 'org.springframework.session:spring-session-data-redis'

 

위와 같이 작성하면 끝이다. 

세션만을 사용할 것이라면 RedisConfig 클래스나 @EnableRedisHttpSession와 같은 부가적인 설정은 필요없다,

 

이후 레디스를 실행시킨 다음 프로젝트를 실행시킨 후 로그인을 진행해본다.

 

아마 높은 확률로 Serialization에 관련된 Exception이 발생할 것이다.

레디스에서 세션은 객체로 다뤄지므로 아래와 같이 Serializable을 implements해야한다.

public class User implements Serializable

 

그 후 도커 컨테이너를 실행시키고

redis-cli
keys *

명령을 통해 세션이 관리되고 있는지 여부를 확인할 수 있다.