여러 대의 서버가 세션(Session)을 공유하는 방법

HTTP 프로토콜의 특징 중 하나는 무상태성(Stateless)이다. 상태가 없기 때문에 서버는 요청이 왔을 때 이전 클라이언트와 동일한 클라이언트인지 확인할 방법이 없다.

이는 세션(Session)을 통해 해결한다.

세션이란 쿠키를 기반으로 일정 시간 동안 같은 브라우저로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 유지하는 기술이다.

또한, 세션은 서버에 저장 및 관리된다.

 

서비스의 규모가 조금만 커지더라도 대부분의 서비스들은 하나가 아닌 여러 대의 서버를 두고 운영한다.

하지만 트래픽이 여러 서버로 분산되지 않고 한 서버로만 집중된다면 여러 대의 서버를 둘 이유가 없어진다.

따라서 트래픽을 여러 대의 서버에 적절히 분산시켜줘야 하는데 이를 가능하게 해주는 친구가 바로 로드 밸런싱(Load Balancing)이다.

로드 밸런싱(Load Balancing)이란 여러 대의 서버로 트래픽(Load)을 균등하게 분산(Balancing)해주는 기술이다.

 

세션은 서버에 저장된다고 하였다. 그렇다면 위와 같은 상황에서 어떤 문제가 발생할 수 있을까?

로드 밸런싱에 의해 요청이 분산될 경우 서버마다 세션이 공유되지 않기 때문에 세션을 제대로 활용 못하는 상황이 생겨버린다.

 

서버 A가 로그인 서비스를 담당하고, 서버 B가 상품 관련 서비스를 관리한다고 하자.

클라이언트는 상품 관련 서비스를 이용하기 위해 먼저 로그인을 한다. 로그인을 성공하면 클라이언트의 세션은 서버 A의 세션 저장소에 저장될 것이다.

다음으로 클라이언트가 상품 관련 서비스를 사용하기 위해 서버 B에게 요청을 보내면 서버 B의 세션 저장소에는 클라이언트의 세션이 없기 때문에 로그인이 필요하다며 로그인 페이지로 리다이렉트 해버리는 상황이 발생해버린다.

이는 로드 밸런싱에 의해 세션이 없는 서버로 요청이 가거나, 서버마다 세션이 공유되지 않기 때문에 발생하게 되는 문제이다.

그렇다면 이 문제를 어떻게 해결해야 할까?

단순하다. 요청을 세션이 있는 서버로만 보내거나, 모든 서버에 세션이 공유되도록 만들면 된다.

이를 가능하게 해주는 방법들에 대해서 알아보도록 하자.

 

 

Sticky Session

 

Sticky는 끈적끈적하다는 의미이다. 이처럼 Sticky Session은 첫 요청에 대한 응답을 준 서버에게 끈적끈적하게 붙어서 이후의 모든 요청들을 해당 서버로만 보내는 방법이다.

쿠키나 클라이언트의 IP tracking을 활용하여 기능을 제공한다. 

이 방법으로 문제를 해결할 수 있지만 단점이 존재한다.

첫 번째로 로드 밸런싱의 효율이 떨어질 수 있다. 로드 밸런싱은 트래픽을 여러 대의 서버로 적절하게 분산시켜줘야 하는데 Sticky Session은 특정 서버에게 트래픽을 보내기 때문이다.

따라서 최악의 경우에는 여러 대의 서버를 둬도 하나의 서버만 사용되는 상황이 발생하게 된다.

두 번째로 결국 세션은 하나의 서버에서만 관리되기 때문에 서버가 죽어버리면 서버의 세션 저장소에 있는 모든 세션들이 사라지게 된다.

잘 생각해보면 이러한 단점은 여러 대의 서버가 세션을 공유한다면 해결할 수 있다. 바로 Session Clustering과 Session Server이다.

 

 

Session Clustering

 

클러스터링이란 여러 대의 서버를 하나의 서버처럼 운영하는 것을 의미한다.

즉, Session Clustering이란 각 서버의 세션 저장소를 하나로 묶어서 관리하는 것이다.

모든 서버가 동일한 세션을 공유하기 때문에 특정 서버로만 트래픽이 몰릴 필요가 없으며, 하나의 서버가 죽어도 세션 정보를 잃어버릴 일은 없게 된다.

하지만 모든 서버의 세션 데이터를 동일하게 유지하기 위해서 하나의 세션이 생기면 모든 서버의 세션 저장소를 업데이트해줘야 하며 그만큼 많은 메모리가 필요하기 때문에 성능 저하가 발생하게 된다.

또한, 새로운 서버를 만들 때마다 기존의 세션 데이터를 옮겨서 클러스터링 해줘야 하는 번거로움도 존재한다.

이러한 번거로움을 없애기 위해 세션만 관리하는 별도의 서버를 하나 두는 방식이 바로 Session Server 방식이다.

 

 

Session Server

 

서버마다 세션 저장소를 둬서 관리하지 말고 세션만 관리하는 별도의 서버를 하나 두는 방식이다.

세션 서버를 사용하기 때문에 모든 서버의 세션 저장소를 업데이트해줄 필요가 없으며, 클러스터링할 필요도 없다.

또한, Redis 같은 In-memory(인메모리) 데이터 저장소를 사용함으로써 빠르게 세션을 조회할 수 있다.

Session Server 방식은 Session Clustering의 단점을 해결하지만, 결국 하나의 Session Server를 통해 관리하기 때문에 서버가 죽어버리면 모든 세션 데이터를 잃게 된다.

하지만 Redis 같은 In-memory(인메모리) 데이터 저장소는 메모리에 데이터를 저장하면서 다른 서버의 메모리에 실시간으로 복사본을 저장하거나, 디스크에 직접 저장하여 데이터를 보관 및 백업이 가능하다.

또한, Master - Slave 형식으로 구성이 가능하기 때문에 Master Server가 죽어도 Slave Server로 접속하면 서비스를 계속 유지할 수 있는 장점이 있다.

다만, 데이터를 별도로 저장하기 위한 메모리가 추가적으로 필요하고, 메모리 파편화가 발생하는 단점도 있다.

 

 

 

 

[ Reference ]

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

· https://goodgid.github.io/Redis/