다중 서버에서 Session 관리하는 방법! (Multi-server session)

다중 서버 Session 관리

요즘은 서버의 성능을 업그레이드 하는 방법으로 스케일 아웃을 많이 사용한다. 그리고, 쿠버네티스의 여러 개의 POD에 각각 올려서 관리하기도 한다.

 

일반적인 멀티 서버의 환경은 아래와 같다.

가령, 스프링 부트 프로젝트를 분산 서버로 배포하고있다고 가정하자.

 

일반적으로 Tomcat이 JSESSIONID라는 세션을 만들어서 관리한다. 세션 저장소는 Tomcat 내부에 있으므로 여러개의 톰캣이 뜨게되면 각각이 가지는 세션 저장소는 다르다.

 

그러면 WAS1에서 세션을 생성한 사용자가 WAS2로 접속했을 때 세션을 찾을 수 없는 현상이 발생한다.

 

Sticky Session

Sticky Session 방식을 사용하면 WAS1에서 세션을 생성한 사용자는 다시 접속할 떄도 WAS1로 접속하게 된다.

 

예를 들면 WAS1에서 세션을 생성한 사용자에게 아래와 같은 쿠키를 만들어준다.

ex. Sticky_server: WAS1

 

그 후, 모든 사용자의 요청에서 Sticky_server 쿠키가 존재할 시 해당 서버로 리다이렉트시켜준다.

 

다중 서버에서의 세션 문제를 해결할 수 있다는 장점이 있지만, 이 방법은 트래픽이 집중될 뿐 아니라 부하 분산의 이점을 잃어버리게 된다.

 

Session clustering

WAS는 다중 서버의 세션 문제를 해결하기 위한 기능으로 세션 클러스터링(Session clustering)을 지원한다.

 

아래는 Tomcat 9 버전의 Session Clustring 기술이다.

• All-to-all session replication
  • 모든 분산 서버의 세션 저장소에 세션을 기록한다.
    • 메모리가 많이 낭비된다.
    • 트래픽이 많이 발생한다.
• Primary-secondary replication
  • Primary는 Secondary에 세션을 기록한다.
  • 다른 서버에서는 세션 ID만 가지고 있다가, 조회 요청이 들어오면 Primary에 풀세션을 요청한다.
    • 세션 복제 시간을 줄일 수 있다.
    • 트래픽은 여전히 많이 발생한다.

 

즉, 세션 클러스터링을 사용해서 정합성을 해결할 수 있지만, 많은 자원과 트래픽을 낭비하게 된다.

 

In-memory Database

위의 문제들 때문에 세션을 관리하는 중간 계층으로 Database를 사용하게 된다.

 

Database는 On-disk 데이터베이스가 있고, In-memory 데이터베이스가 있다.

 

On-disk 데이터베이스의 예로 Oracle, SQL Server, MySQL 등이 있지만, 디스크보다 메모리가 비교도 안될 정도로 빠르기 때문에 Redis나 Memcached같은 In-memory 데이터베이스를 사용한다.

 

세션 정보는 누적되는 정보가 아니기 때문에, In-memory의 성격과도 적합하다. 문제가 생겨도 다시 로그인하여 세션을 발급하면 된다.

 

추가적으로, 세션 정보를 보관하는 In-memory DB도 문제가 생기면 세션이 먹통이 되기 때문에 복제를 해서 사용한다.

 

---

 

Reference1: https://hyuntaeknote.tistory.com/6

Reference2: https://hyuntaeknote.tistory.com/7