Spring 분산 환경에서 세션 관리하기 (Redis Session Clustering)

🔗 Spring 분산 환경에서 세션 관리하기(세션 클러스터링)

안녕하세요, 이번 포스팅에서는 여러 서버 환경에서 세션을 관리하는 방법에 대해 살펴보겠습니다.

(코드는 깃허브에서 확인하실 수 있습니다.)

 

단일 서버에서 세션을 관리한다면 아무런 문제가 없겠지만, 보통 스케일 아웃 등을 통해 분산된 서버 환경에서 세션을 관리할 때(로그인 유저의 세션 정보) 세션 불일치 문제가 발생할 수 있습니다.

 

예시로 살펴볼까요?

두 개의 서버: localhost:8080, localhost:8081

localhost:8080

사용자 A가 localhost:8080포트로 login 호출 시 세션이 생성되고 JSESSIONID에 임의의 값을 설정합니다.

JSESSIONID?
 - 세션을 유지하기 위해 Tomcat Container에서 발급하는 Key이고 Value를 통해 세션을 유지할 수 있습니다.

동작 방식?
 1. 브라우저 최초 접근 시 Tomcat Response에 JSESSIONID 값을 발급합니다(Set-Cookie)
 2. 브라우저 재요청 시 이전에 발급받은 JSESSIONID를 Request Headers의 쿠키에 값을 넣어 서버에 요청합니다.
 3. 클라이언트로부터 전달받은 JSESSIONID의 값을 기준으로 서버에서는 세션에 상태를 유지할 값들을 저장할 수 있습니다.
JSESSIONID는 포트번호는 달라도 동일한 값을 유지합니다.

 

localhost:8080

동일하게 localhost:8080 URL로 myName을 호출하면 이전에 발급받은 JSESSIONID를 Header에 설정하여 요청을 보내고, 저장된 세션 데이터를 정상적으로 반환합니다.

 

localhost:8081

만약 다른 컨테이너인 localhost:8081 URL을 호출하면 다른 서버를 호출하기 때문에 동일한 JSESSIONID 값으로 요청이 오지만 세션에 데이터가 존재하지 않기에 아무런 데이터도 반환하지 않습니다.

또한 Response Headers의 쿠키에 새로운 JSESSIONID의 값을 반환하고, 이후 요청은 해당 값을 통해 요청합니다.

 

localhost:8081

위에서 발급받은 JSESSIONID 값으로 요청을 보내는 것을 확인할 수 있습니다.

 

localhost:8080

다른 서버인 localhost:8080에 myName API를 호출하면 마찬가지로 세션 데이터가 존재하지 않기 때문에 새로운 JSESSIONID 값을 반환하고, 이후 요청은 해당 값을 Header에 넣어서 요청하게 됩니다.

 

이처럼 Scale-out 등을 통해 분산된 환경에서 세션을 사용할 경우 동일하게 세션을 유지할 수 없습니다.

이러한 문제를 해결하기 위해 Session Clustering, Sticky Session, Redis Session Clustering 등이 존재합니다.

그중 여기서는 Redis Session Clustering 방식으로 코드를 작성해 보고, 다른 방식에 비해 어떠한 이점이 있는지 살펴보겠습니다.

 

 

 

🔗 Sticky Session

https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/

 

Sticky session은 세션을 사용해 트래픽을 분산하는 기능으로 특정 세션의 요청을 최초 처리한 서버로만 전송하는 것을 의미합니다.

 

예를 들어 회원 1이 서버 A에서 세션을 생성한다면, 이후 회원 1이 보내는 모든 요청은 서버 A로만 전송하게 됩니다.

 

이러한 Sticky session은 아래와 같은 단점이 존재합니다.

• 동일한 세션은 동일한 서버로만 전송하기 때문에 특정 서버에 요청이 몰려 과부하가 발생할 수 있습니다.
• 특정 서버에 장애가 발생할 시 해당 서버에 연결되어 있는 세션들이 모두 소실될 수 있습니다.

위와 같은 단점을 해결하기 위해 Session Clustering 방식이 존재합니다.

 

 

 

🔗 Session Clustering (세션 클러스터링)

https://smjeon.dev/web/sticky-session/

Session Clustering의 개념은 단순합니다. 클러스터링 이란 개념이 군집, 뭉치기 등과 같은 의미를 지니고 있는데요, 세션 클러스터링은 여러 WAS가 세션을 공유하여 동일하게 세션을 관리하는 방식을 의미합니다.

 

세션 클러스터링 방식은 Sticky Session에서 발생했던 1. 특정 서버에만 트래픽이 많이 발생하거나, 2. 장애 발생 시 세션 소실의 문제를 해결할 수 있습니다.

 

하지만 세션 클러스터링은 세션 데이터가 생성될 때마다 모든 서버에 세션 정보를 추가해야 하기 때문에 서버의 메모리에 상당히 부담이 된다는 치명적인 단점이 존재합니다.

 

 

 

🔗 Redis Session Clustering

Redis를 이용한 세션 클러스터링 방식은 세션을 관리할 저장소를 Redis로 따로 두어 사용하는 방식입니다.

 

그렇다면 세션을 관리할 저장소를 RDB가 아닌 Redis를 사용하면 어떤 이점이 있을까요?

대략적으로 아래와 같은 이점이 존재할 것 같습니다.

• 세션은 데이터 모델이 관계형 데이터베이스처럼 복잡하지 않습니다.
• 세션은 보통 만료시간이 존재하기에 영속성이 필요하지 않습니다.
• 세션은 사용자가 로그인 후 요청을 할 때마다 확인이 필요하기 때문에 그만큼 I/O가 많이 발생하고, RDB를 사용하는 경우에는 디스크 I/O로 인해 성능 이슈가 발생할 수 있습니다.

따라서 Redis는 세션 저장소에 적합한 데이터베이스라고 할 수 있습니다.

 

 

Spring Redis Session Clustering 예제 코드

Spring에서 Redis를 세션 저장소로 사용하는 방법은 굉장히 간단합니다.

(redis 설치&설정 관련은 생략하겠습니다.)

1. redis 관련 의존성을 추가하고
2. application. yml(properties) 파일에 설정을 추가하고
3. API 요청 시 HttpSession 인터페이스를 매개변수로 추가하여 사용하면 됩니다.

 

localhost:8080/login

localhost:8080

localhost:8081

위 이미지를 확인해 보면 localhost:8080 URL로 login 요청을 했지만, 8080포트와 8081포트 모두 SESSION이라는 Key를 통해 동일한 데이터가 반환되는 것을 볼 수 있습니다.

 

 

Redis 확인

• spring:session:expirations:(expire time) = expire time에 삭제될 세션 정보들을 담고 있습니다. (Set)
• spring:session:sessions:expire:(session id) = 해당 세션의 만료 Key로 사용됩니다. (String)
• spring:session:sessions:(session id) = 세션의 생성 시간, 마지막 세션 조회 시간, 최대 타임아웃 허용시간, 세션에 저장한 데이터를 담고있습니다. (Hash)

 

Hash 타입인 spring:session:sessions:(session id)을 확인해 보면 세션 데이터가 저장되어 있는 것을 볼 수 있습니다.

 

spring.session.store-type을 통해 Session 설정을 Redis로 지정합니다.

 

Spring Boot의 AutoConfiguration로 인해 properties(yml) 파일에 위와 같이 설정만 하는것으로 Spring Session을 Redis로 설정하는 것이 손쉽게 가능합니다.

 

SessionProperties 클래스의 StoreType을 보면 Redis 외에도 MongoDB, JDBC, HAZELCAST(?) 등을 설정할 수 있습니다.

이후 Session 데이터를 저장할 때 기존과는 달리 RedisIndexedSessionRepository 클래스를 통해 set을 진행하여 세션과 관련된 데이터를 spring:session을 기본 네임스페이스로 각 key를 설정하여 관리합니다.

좌) 기존 Session, 우) Redis Session

 

 

 

📄 참고 문서

• https://redis.io/
• https://docs.spring.io/spring-session/docs/1.3.1.BUILD-SNAPSHOT/api/org/springframework/session/data/redis/RedisOperationsSessionRepository.html
• https://docs.spring.io/spring-session/reference/guides/boot-redis.html