Multi Server에서 Session 관리 방법 (Sticky Session, Session Clustering, Redis Session Storage)

Scale-up을 하기 전에는 한대의 WAS 서버로 세션을 처리했습니다.

하지만 서버의 대수를 늘린 후에는 세션을 어디에 저장할 것인지라는 이슈가 발생합니다. 만약 1번 서버에 어떤 사용자의 세션을 저장하고 배달 주문을 하는 Request가 2번 서버로 전달된다면 B서버에는 이 사용자의 세션이 없기 때문에 로그인이 유지되지 않는 문제가 발생합니다. 따라서 이러한 Session 정합성 문제를 해결해야했고 여러 가지 방법을 고민해보았습니다.

첫째로 고려한 방법은 Sticky Session입니다.

Sticky Session은 어떠한 사용자의 세션이 1번 서버에서 생성되었다면 이 사용자의 Request는 1번 서버로만 보내지는 방식입니다. 이러한 방법은 로드밸런스에 의해 이루어집니다. 세션이 만료되기 전까지 A 사용자의 세션이 생성된 서버로 로드밸런스가 A 사용자의 요청을 리다이렉트합니다.

특정 사용자의 세션은 한 서버에 의존하고 있기 때문에 특정 서버에 트래픽이 집중된다면 장애가 발생할 수 있습니다. 서버의 대수가 많고 다른서버가 여유롭더라도 트래픽이 몰린 서버로만 요청을 보내야하는 경우가 생길 수 있기 때문입니다. 또한 하나의 서버에 문제가 발생했을 시, 그 서버에 저장된 세션정보들이 분실될 수 있습니다.

두번째로 Tomcat에서 지원하는 Session Clustering을 고려해봤습니다.

세션 클러스터링 방식은 여러대의 WAS가 있어도 동일한 세션으로 관리하여 Sticky Session의 단점을 극복했다는 장점이 있습니다.

Session Clustering이란?

Session clustering은 WAS가 2대 이상 설치되어 있을 경우 동일한 세션으로 세션을 관리하는 것입니다. 즉, 여러대의 서버가 하나의 서버처럼 연결되어 동작하는 방식입니다.

Session Clustering을 하지 않았을 경우

하나의 WAS에서 허용된 트래픽이 많이 발생할 경우 다른 WAS로 접속을 시켜줍니다. 이러한 경우 기존 WAS의 세션이 아닌 다른 WAS로 연결이되고 이 WAS에는 기존의 세션에 대한 정보가 없으므로 세션 불일치 이슈가 발생합니다. 이러한 세션 불일치 문제 때문에 각 WAS에 대한 세션을 하나의 세션으로 관리하여 사용자가 기존에 접속했던 WAS가 아닌 다른 WAS로 접속하더라도 세션은 하나로 관리되므로 세션에 대한 불일치가 발생하지 않습니다.

단점

하지만 make-delivery 프로젝트에서는 Scale-up방식을 사용하기 때문에 새로운 서버를 추가할때마다 기존에 존재하던 WAS에 새로운 서버의 IP,Port등을 매번 설정해서 클러스터링 해줘야 하는 단점이 있습니다. 새로운 서버를 추가할때마다 기본 서버를 수정해야하고 에러가 발생할 가능성이 있습니다.

세번째로 고려한 점은 세션서버를 레디스에 따로두어 세션 스토리지를 관리하는 것입니다.

레디스는 Inmemory DB이며 Session Storage 기능을 제공합니다.

이 방식은 Scale-up을 하여 새로운 서버를 추가하더라도 레디스 세션 서버에 연결만 해주면 되기 때문에 기존 WAS서버의 수정이 필요 없다는 장점이 있습니다. 앞서 고려했던 Sticky Session, Session Clustering의 단점을 극복한 방법이기 때문에 Redis Session Storage를 이용하여 세션 정보를 관리하기로 결정했습니다.

참고자료

https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/
https://ignite.apache.org/use-cases/caching/web-session-clustering.html
https://thenewstack.io/how-to-build-intelligence-into-your-session-stores/