분산서버 환경에서 발생할 수 있는 Session 불일치 문제를 해결해봅시다 (1) - Sticky Session

 앞선 포스트에서 서버의 확장 방법인 Scale Up 과 Scale Out 에 대해서 알아보았습니다. 그리고 당근마켓 서버 API를 개발하는 프로젝트에서 서비스의 특징과 가용성을 고려하여 Scale Out 을 이용한 확장을 적용하기로 하였는데 이에 앞서서 먼저 해결해야할 문제가 존재합니다.

 

 Scale Out 을 적용하기 위해서는 반드시 데이터 불일치라는 문제를 해결해야한다고 언급했습니다. 일반적으로 HTTP 방식의 통신과 웹 애플리케이션 서버는 무상태성이라는 특징과 서버에 클라이언트의 정보를 저장하고있지 않기 때문에 데이터 불일치 문제로부터 자유롭게 Scale Out 방식을 적용한 확장이 가능합니다.

 

 하지만 세션을 이용한다면 이야기가 달라집니다. 현재 프로젝트에서는 사용자의 로그인 정보를 처리하기 위해서 세션을 이용한 로그인 방식을 사용하고 있습니다. 즉, 서버에 클라이언트 데이터를 저장하고 있기 때문에 데이터 불일치 문제로부터 자유로울 수 없다는 것인데요 그럼 어떻게 서버 확장에 따른 데이터 불일치 문제를 해결할 수 있을지 한번 알아보겠습니다.

 

 

---

 

Sticky Session 방식은 어떻게 세션 불일치 문제를 해결할 수 있을까요

먼저 Sticky Session 이라는 방식이 존재합니다. 단어의 뜻에서도 유추할 수 있듯이 Sticky Session 방식은 고정된 세션이라는 의미 그대로 클라이언트의 요청을 특정 서버에서 처리하도록 로드밸런싱 하여서 클라이언트 요청과 서버를 하나로 묶어서 고정시키는 방식을 사용합니다.

 

 

그림에서처럼 각각의 사용자가 보낸 로그인 요청에 의해 사용자의 로그인 정보가 각각의 서버의 세션 저장소에 저장된다고 가정해봅시다.

 

처음 클라이언트 요청은 어느 서버로도 보내질 수 있지만 로그인 이후 특정 서버에 사용자의 로그인 정보가 저장된 다음에는 로드밸런서에 의해 특정 클라이언트의 요청은 특정 서버로 연결되어 고정된 서버의 세션만을 사용하게 됩니다. 이 과정에서 클라이언트는 자신의 정보를 쿠키에 담아서 보내고 로드벨런서는 클라이언트 요청 정보에 포함된 쿠키를 통해 지정된 서버로 요청을 전달합니다.

 

Sticky Session은 세션이 유지되는 동안 클라이언트는 동일한 서버만을 사용하기 때문에 데이터 불일치 문제로부터 자유로울 수 있습니다. 하지만 Sticky Session 방식은 여러가지 단점과 한계점이 존재합니다.

 

특정 서버에 트래픽이 집중되는 문제

만약 현재 사용하는 로드밸런서가 사용자의 IP 정보를 기준으로 로드밸런싱을 적용하는 L4 로드밸런서라고 가정해봅시다. 그리고 대학교나 어떤 기관에서는 하나의 공공 와이파이를 사용하여 해당 서버로 요청을 보내 업무를 처리한다고 가정해봅시다.

 

 

 기관 내에서 사용하는 컴포넌트들의 IP는 사설 IP로써 동일한 와이파이를 사용하더라도 각기 다른 IP를 가지고 있지만 인터넷 상에서는 해당 기관의 클라이언트들이 하나의 공인IP로써 보일 것입니다. 

때문에 클라이언트의 요청은 L4 로드밸런서에 의해서 동일한 서버로 로드밸런싱이 이루어지게 될 텐데 이는 결국 하나의 서버에 트래픽이 집중되는 것을 의미합니다.

 

 앞서서 특정 서버로 부하가 집중되는 문제를 해결하기 위해서 Scale Out을 적용했지만 결국 다시 특정 서버로 부하가 집중되는 문제가 되풀이되면서 Scale Out이 가지고 있는 장점을 활용하지 못하게 됩니다. 

 

뿐만 아니라 서버에 장애가 발생하면 로드 밸런서는 클라이언트 요청을 다른 서버로 연결할 것이고 클라이언트는 다시 로그인만 하면 될 것입니다. 하지만 문제는 이러한 상황이 계속 반복될 것이라는 것에 있습니다. 결국 어떻게 보면 클라이언트 입장에서는 서버들이 각각 단일 고장점으로써 작용하고 있다고 봐도 무방할 것입니다.

 

 

 서버의 이용률과 효율성 문제 

위와 같이 장애가 발생한 서버가 복구되었다고 가정해봅시다. 복구된 서버는 이전 클라이언트들의 로그인 정보가 여전히 세션저장소에  저장되어있고 클라이언트 요청을 처리할 준비를 끝마친 상태입니다.

 

하지만 해당 서버는 더이상 이전 클라이언트 요청을 처리할 수 없습니다. 이미 클라이언트는 로드밸런서에 의해 다른 서버로 요청이 연결되었기 때문에 클라이언트의 요청은 더이상 이전 서버로 연결되지 않습니다.

 

결국 이러한 문제는 서버의 이용률과 효율성이라는 측면에서 문제를 가지고 있습니다. 서버가 복구되었지만 이전 클라이언트의 요청을 더 이상 처리할 수 없으며 이제는 더 이상 필요없는 이전 클라이언트의 로그인 정보를 여전히 세션 저장소에 저장하고 있기 때문에 불필요한 메모리를 낭비하게 됩니다. 

 

---

 

이러한 단점들로 인해서 Sticky Session은 데이터 불일치 문제를 해결해줄지는 몰라도 Scale Out 방식을 통해 얻을 수 있는 가용성과 부하분산이라는 단점을 제대로 활용하지 못하는 아이러니한 상황이 발생하게 됩니다. 

 

 

그렇다면 이러한 다중 서버 환경에서는 데이터 불일치 문제를 해결하기 위해서 이러한 단점을 감수해야만 하는 것일까요? 그렇지 않습니다.  Sticky Session 뿐만 아니라 다중 서버환경에서 데이터 정합성을 해결할 수 있는 방법은 Session Clustering, Session Storage를 외부로 분리하는 등의 다양한 방법이 존재합니다.

 

다음 포스트에서는 Session Clustering을 이용하여 데이터 불일치 문제를 해결하는 방법에 대해 알아보겠습니다.

 

github.com/f-lab-edu/daangn-market-used-trading

f-lab-edu/daangn-market-used-trading