다중 서버에서의 Session 관리

 기존에 단일 서버를 통해 운영하던 서비스의 트래픽이 증가함으로써 Scale-out 방식으로 서버를 확장해야 하는 상황이 찾아왔다고 가정해보자. 기존 서버와 동일한 사양의 서버를 추가함으로써 하나의 서버에서 처리하던 일을 여러 서버에서 분산 처리하게 된다. 하지만 여러 대의 서버가 제공하는 서비스를 이용하는 유저가 마치 한 대의 서버를 이용하는 것 같은 효과를 주기 위해서는 반드시 Session 불일치 문제를 해결해주어야 한다.

 

 여기서 Session 불일치 문제란 서버마다 각각의 세션 저장소를 가지고 있고 가지고 있는 세션들을 공유하지 않기 때문에 발생하는 문제이다. 예를 들어 특정 유저가 로드 밸런싱을 통해 1번 서버에 접속하여 로그인을 하였고 로그인 정보는 A 서버의 세션 저장소에 저장되었다고 생각해보자. 그 이후 유저가 다시 요청을 보냈을 때 그 요청을 로드 밸런서가 B 서버에 전송한다면 해당 서버의 세션 저장소에는 유저의 로그인 정보가 존재하지 않는 상태이기 때문에 로그인 정보를 얻지 못하는 문제가 발생하는 것이다.

 

 위 사례와 같은 Session 불일치 문제를 해결하기 위한 몇 가지 방법이 존재한다.

 

 

Sticky Session

 Sticky Session 방식은 처음 세션을 생성한 서버에만 요청을 전송하는 방식이다. 클라이언트가 보낸 요청에서 로드 밸런서가 쿠키를 확인하고, 쿠키가 존재한다면 해당 서버에만 요청을 전송하게 되는 것이다.

 

 Sticky Session 방식을 이용하면 클라이언트별로 요청이 고정된 서버에만 전송되기 때문에 세션의 교환 없이도 Session 불일치 문제를 해결할 수 있다.

 

 하지만 Sticky Session 방식은 트래픽의 분산을 어렵게 만들 수 있으므로 특정 서버에 과부하를 일으킬 수 있다는 단점이 존재한다.

 

 

WAS 설정을 이용한 Session Clustering

 Session Clustering이란 2대 이상의 WAS를 사용할 때 동일한 세션으로 세션을 관리하는 것을 의미한다. Tomcat도 역시 Session Clustering 설정이 가능하며, 설정 시 세션이 변경되면 다른 모든 서버의 세션 저장소에 해당 세션을 복제한다.

 

 Session Clustering 방식을 이용하면 역시 세션 불일치 문제가 발생하지 않으며, Sticky Session 방식과는 달리 온전히 로드 밸런서의 알고리즘 대로 각 서버에 트래픽을 분산하므로 한 서버에 트래픽이 집중되는 현상 또한 막을 수 있다.

 

 하지만 모든 서버의 세션 저장소에 동일한 세션을 저장해야 하기 때문에 메모리가 효율적으로 관리된다고 보기 어려우며, 서버의 개수만큼 세션을 복제하기 위한 네트워크 트래픽이 발생하기 때문에 성능 상 비효율적일 수 있는 방식이다.

 

 

Session Storage 분리

 기존의 각 서버가 가지고 있던 Local Session Storage를 외부 Session Storage로 분리하는 방식이다. Session Storage는 휘발성 데이터인 세션의 저장소이기 때문에 당연히 영구적으로 데이터를 저장하며 상대적으로 속도가 느린 Disk 기반 DB 보다는 In-Memory DB가 적합하다.

 

 Session Storage를 분리하는 방식을 채택하게 된다면 모든 서버가 같은 Session Storage를 공유하고 있기 때문에 세션 불일치 문제는 당연히 해결할 수 있으며, 서버 간 세션을 복제할 필요도 없기 때문에 성능 문제도 해결할 수 있게 된다.