분산 서버 환경에서 세션 공유 문제 해결하기

학습 목표

· 분산 서버 환경에서 발생하는 세션 공유 문제

· 고정 세션(Sticky Session)

· 데이터베이스를 세션 저장소로 사용하기

· WAS를 사용하여 세션 공유하기

---

분산 서버 환경에서 발생하는 세션 공유 문제

 

일반적인 웹 서비스에서 하나의 서버로 부하를 처리할 수 없을 만큼 서비스가 확장되면, 로드 밸런서를 이용한 분산 서버 구조를 사용하여 문제를 해결한다.

 

이때 하나의 서버로 사용자의 요청을 관리했을 때는 발생하지 않는 문제가 발생한다.

 

웹에서 사용하는 http 프로토콜은 stateless하다. 즉, 각각의 요청은 이전 요청과 무관한 각각의 요청을 독립적인 트랜잭션으로 취급한다는 의미다. 하지만 사용자 인증, 장바구니 기능, 트래킹, 개인화 등 다양한 이유로 사용자의 상태를 저장해야하는 상황이 발생한다. 이럴 때 '세션'을 사용할 수 있다. 이러한 세션은 기본적으로 서버의 메모리에서 관리된다.

세션이란?

 

그런데 여러 대의 서버를 사용하면 사용자의 세션이 여러 대의 서버에 서로 공유되지 않는 문제가 발생할 수 있다. 예를 들어 'Server1'에 요청을 보내 이미 로그인한 사용자가 'Server 2'로 요청을 보냈을 때, 또 다시 로그인을 해야한다는 메세지를 받을 수 있다. 즉, 데이터 정합성 유지가 어렵다.

 

이러한 문제를 해결하는 방법은 여러가지가 존재한다.

 

고정 세션(Sticky Session)

고정 세션은 로드 밸런서가 사용자의 세션을 특정한 서버에 바인딩하는 방식이다. 이렇게 하면 세션 중에 사용자에게 들어오는 모든 요청이 동일한 서버로 전송된다.

 

고정 세션은 로드 밸런서로 들어오는 사용자 요청의 IP 또는 쿠키를 확인하여 사용자를 식별하는 방식으로 작동한다.

고정 세션은 로드밸런서의 간단한 설정을 통해 사용할 수 있다. 예시를 살펴보자.

 

네이버 클라우드 플랫폼에서 고정 세션 사용하기

네이버 클라우드 플랫폼을 통해 서버 세팅을 할 경우 Load Balancer 탭에 접속하여 '로드밸런서 실행 변경' 버튼을 클릭하고,

 

 

Sticky Sessions 속성에 체크하여 고정 세션을 사용할 수 있다.

 

 

AWS에서 고정 세션 사용하기

AWS를 통해 서버 세팅을 할 경우 로드 밸런싱 탭에 접속하고, 

 

'속성 편집' 버튼을 클릭한 후,

 

활성화 속성에 체크하여 고정 세션을 사용할 수 있다.

 

장점

· 최소환의 데이터 교환

   - 고정 세션 방식을 사용하는 네트워크 내의 서버는 세션 데이터를 서로 교환하는 수고가 들지 않는다.

· RAM 캐시 활용

   - 고정 세션 방식은 RAM 캐시를 보다 효율적으로 활용하여 응답성을 향상시킨다.

     (디스크를 사용할 필요가 없고, 데이터베이스에 요청할 필요 없기 때문이다.)

 

단점

· 서버 과부하 가능성

   - 세션이 고정되므로 특정 서버 세션이 누적되어 과부하가 걸릴 수 있다.

 

 

데이터베이스를 세션 저장소로 사용하기

분산 서버에서 세션 공유 문제는 여러 서버에서 각자 세션을 관리하여 발생하는 문제이므로,

공통 세션을 저장-관리하는 데이터베이슬 만들어 해결할 수 있다.

이러한 외부 저장소로 다양한 데이터베이스를 사용할 수 있지만, 세션을 확인할 때마다 디스크를 확인하는 작업은 너무 속도가 느리기 때문에 in-memory 데이터베이스인 레디스가 많이 활용된다.

 

장점

· 세션 복제 없는 데이터 정합성 해결

   - 세션 저장소가 하나이므로 세션을 복제-공유하지 않아도 문제를 해결할 수 있다.

 

단점

· 서버 과부하 가능성

   - 사용자 요청을 받는 서버는 여러 대인 반면에 세션을 저장-관리하는 저장소는 하나이므로 이 부분에서 병목 현상이 발생할 수 있다.

   - 해당 문제를 해결하기 위해 세션 저장소를 여러 개 만들고, 공유하는 방식을 사용할 수 있다.

 

예시

https://scshim.tistory.com/447

 

WAS를 사용하여 세션 공유하기

로드밸런스에 연결된 여러 대의 WAS가 존재할 때 WAS는 세션 클러스터를 통해 서로 생성된 세션을 공유하여 세션 공유 문제를 해결할 수 있다. 예를 들어 대표적인 WAS 중 하나인 Tomcat을 통해 알아보자.

https://www.javacodegeeks.com/2012/11/tomcat-clustering-series-part-3-session-replication.html

 

톰캣에서는 세션을 복사하는 두 가지 전략이 존재한다.

 

세션 복제 전략1: all-to-all

모든 세션이 모든 클러스터 노드에 복제되는 방식이다. 

작은 클러스터에는 잘 작동하나, 4개 이상의 노드를 가진 큰 클러스터에서는 추천하지 않는 방식이다. 

톰캣의 여러 Session Manager 중 DeltaManager를 이용한다.

 

세션 복제 전략2: primary-secondary

세션이 하나의 Backup node에만 복제되는 방식이다. 오직 어플리케이션이 배포된 노드에만 복제된다.

 

클라이언트로 부터 요청이 들어오면, 요청을 받은 서버가 세션을 생성하고, Primary node로 선정된다. 다른 서버들 중 하나가 Backup node(Secondary node)로 선정되고 나머지 노드들은 Proxy node가 된다. 

 

Proxy node는 세션 아이디와 Primary node, Secondary node의 주소값을 저장한다. 그리고 요청이 들어오면, Primary에게 해당 세션 아이디의 데이터를 요청한다.

 

톰캣의 여러 Session Manager 중 BackupManager를 이용한다. 

 

출처

 

https://jane096.github.io/project/how-to-solve-server-overload-p2/

https://hyuntaeknote.tistory.com/6

https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

https://ko.wikipedia.org/wiki/%EB%AC%B4%EC%83%81%ED%83%9C_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C