잡다한 기술 지식

1. 서버가 여러대일때 세션 관리하는방법

 

-물론 실습을 바탕으로 진행이 되어야 하지만, 간단하게 지식을 익혀보자

세션이란, 사용자의 정보 혹은 로그인 정보를 서버 쪽에서 캐싱해서 가지고 있는 것이다.

redis 와같이 세션 관련, 서버가 있는 경우도 있고 was내에서 별도 세션을 저장하는 경우도 있다.

 

만약에 a라는 사용자가, 로그인을 하고 이정보를 세션에 저장했다고 가정한다.

이 경우에, 서버의 트래픽이 몰릴것을 감안하여, 스케일 아웃을 했다고 한다면,

각 서버에서 가지고 있는 세션의 정보는 각 was 별로 다르게 된다.

 

이럴 경우에는, 어떻게 해야 문제를 해결할수 있을까

 

1. sticky session 방식을 사용하면된다. 말그대로, 고정 세션이다.

사용자 usr1이 로그인을 하고 이 정보를 was1번에 저장하게된다면, 이 usr1이 세션을 저장한 시점 이후부터는

lb를통해서, 세션을 생성한 was에만 요청을 생성한다.

즉 lb가 첫번째 세션을 생성한서버로 usr1의 모든 요청을 리다이렉트한다.

 

이런경우에는 단점이 존재한다.

자신의 세션에 있는 서버에만 집중 접속을 하기 때문에, 해당 서버에대한 부하가 높아질수있다.

따라서 스케일 아웃으로 인한 가용성 증가와, 트래픽 분산을 사용하는데 문제가있다.

 

2. 결국 문제는 세션 클러스터링으로 해결해야한다.

 

세션 클러스터링 이런 무엇일까? 여러개의 분산된것을 하나의 움직임처럼 동작한다는 것이다.

예를 들면 군대인원이 같은 동작을 하듯이, 하나의 세션에 변경이 일어나면, 모두 같이 복제를 한다.

조금더 자세히 알아보자.

 

all to all 세션 복제방식

all to all 세션 복제란 하나의 세션 저장소에 변경되는 요소가 발생하면 변경된 사항이 다른 모든 세션에

복제가 된다는 것을 의미한다.

이것은, 어떤 서버에 접속하더라도, 세션정보를 같이 가지고 있기때문에 정합성 문제도 해결이 가능하다.

 

단, 서버가 동일한 세션 객체를 가져야 하기때문에, 많은 메모리가 필요하다.

세션 저장소에 데이터가 저장될때마다 모든 서버에 값을 입력해야하므로, 서버 수에 비례하여,

네트워크 트래픽이 증가하는 등 성능 저하가 발생한다.

 

따라서 all to all 복제 방식은 소규모 클러스터링에서 적합하다.

 

 

그렇다면 대규모에서는 이를 해결 할수 없을까?

 

Tomcat은 이를 BackupManager를 활용한, primary-secondary 세션 복제 방식을 제시한다.

 

그림과 같이 Primary서버는 Secondary 서버에 세션객체의 key value전체를 복제한다.

하지만 이외의 서버에는 Key에 해당하는 JSESSION ID만 복제한다.

전체를 복제하는 것보다 메모리 사용이 줄어들게 되고, Key만 복제하여 시간도 절약된다.

하지만, primary,secondary 서버를 제외한 서버에 세션 정보를 요청할 경우에는, 

primary 서버에 요청하여, 해당 key에 해당하는 객체를 받아와야한다. (이것 또한 단점)

 

 

 

 

세션 스토리지 분리를 통해, 정합성 이슈를 해결해보자.

스케일 아웃과는 별개로, 세션 스토리지를 분리하면, 트래픽이 비정상적으로 몰릴 현상 고려를 하지않아도되고,

여러개의 스케일아웃을 고려하지않아도 된다. 또한 서버 하나가 장애가 나도, 계속 서비스가 가능하다.

(서버 별 세션이 아니기 때문에 날아가는 일도 없다.)

 

 

해당 세션 스토리지 분리를 통해서 데이터 정합성 및 여러가지 이점이 존재한다는것을 알았다.