세션 클러스터링 방식 및 주의 사항 (Jeus, Tomcat)

세션 클러스터링이란?

세션 클러스터링은 2대 이상의 WAS 또는 서버를 사용할 때 로드 밸런싱, 장애 대비 등 세션을 공유하는 것을 의미한다.

일반적으로, 사용자가 접속하면 L4 스위치가 접속을 유도해주지만, 서버 과부하 등 문제 발생 시 다른 연결가능한 서버로 유도해준다. 이 때 서버 간 세션 정보 불일치를 해결하기 위해 사용된다. (tomcat, jeus 등 WAS 설정으로 적용)

세션은 사용자 정보 또는 방문기록을 WAS 메모리에 저장하여, 클라이언트와 서버 간 고유한 세션 ID를 통해 Stateless한 연관성을 설정하는 것을 의미한다.

예를 들면, 이중화 되어있는 서버 구성에서 한 서버가 장애가 발생했을 때, 다른 서버에 세션 정보를 동일하게 유지 시키기 위한 기능이다. 따라서, 장애를 방지하는 세션 클러스터링과 분산 처리를 목표로하는 로드밸런싱과는 목적이 다르다고 볼 수 있다.

쿠키와 세션에 대한 자료는 다음 포스팅을 참고하자.

https://sasca37.tistory.com/146

[Web] - Cookie & Session

Cookie & Session http protocol 특징 Http (Hyper Text Transfer Protocol) : 인터넷에서 데이터를 주고 받는 스펙 client가 서버에 요청 서버는 요청에 대한 처리를 한 후 클라이언트에 응답 응답 후 연결을 해제 (sta

sasca37.tistory.com

클러스터링 구성 (Jeus)

Jesus 7에서 제공하는 클러스터링 구성도이다. (ServerCluser1에서 A,C는 동일한 컨텍스트이므로, 서버 안에서 세션 유지가 된다. 마찬가지로 2에서도 B,D가 세션 유지를 한다)
C와 D는 세션 클러스터로 묶어두면 서로 다른 컨텍스트지만, 공유하도록 설정할 수 있다. 단, 주의할 점이 있다. ServerCluster1에서 A와 C 간 세션 공유를 하고 싶다면, C의 세션 클러스터 설정을 해제해야한다. (동일한 서버 내에 애플리케이션 간 설정을 하면 세션 클러스터링 지정을 못한다는 의미 같다)
Jeus 클러스터링 설정 관련해선 다음 링크를 참고하자.

https://technet.tmaxsoft.com/

technet.tmaxsoft.com

클러스터링 설정 (Tomcat)

# jvmRoute 라우팅 식별자 지정 (로드밸런싱할 톰캣 이름명 지정 - 세션 ID 뒤에 추가로 표시됨)
<Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">
# 주석 해제
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="8">
# 추가 구성
          <Manager className="org.apache.catalina.ha.session.DeltaManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"/>

          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="4000"
                      autoBind="100"
                      selectorTimeout="5000"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=""/>
          <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
        </Cluster>

톰캣 server.xml에서 해당 클러스터 태그 주석을 해제하자.
멀티 캐스트 주소는 228.0.0.4 포트는 45564 이다. 설정을 통해 TcpFailureDetector 와 MessageDispatchInterceptor 두 개의 인터셉터가 구성된다.

<distributable/>

애플리케이션 WEB-INF/web.xml에 태그 추가 (태그를 넣어야 server.xml에 설정 적용)

Sticky Session 방식

Sticky 세션 방식은 고정된 세션 방식을 의미한다. 예를 들어 사용자가 최초에 A 서버에서 세션을 생성하면, 이후 요청이 A 서버로 보내지게 되는 방식이다.

세션을 가진 사용자가 동일한 서버로 요청이 오기 때문에 서버 간 정합성 문제를 해결할 수 있지만, 한 곳에만 몰리는 트래픽 문제의 위험이있다.

All to All Session Replication

All to All 이란 의미 그대로, 하나의 세션 저장소에서 변경 사항이 발생하면 변경된 사항이 모든 세션에 복제가 되는 방식이다.

세션 정합성에서 벗어날 수 있고 장애 발생 시에도 무중단 운영이 가능하지만 메모리, 성능 등의 비용이 발생한다.

primary-secondary Session Replication

primary 서버가 secondary(백업) 서버에 세션 객체의 Key - Value 전체를 복제한 후, 이외의 서버에는 키에 해당하는 세션 ID만을 복제하는 방식이다.

톰캣 세션 클러스터링에서 사용하고 있는 방식이며, 톰캣 8 버전 부터 제공하고 있다.

클러스터링 적용 시 주의 사항

public class UserVO implements Serializable {
  // 직렬화 과정에서 UID 버전이 포함되고 역직렬화를 통해 버전 일치를 체크한다.직접 명시하지 않고, 객체의 변경이 발생하면 역직렬화 과정에서 오류가 발생한다. (타입 변경 등)
  // ObjectOutputStream 와 같은 직렬화 제공 스트림도 있다.
  private static final long serialVersionUID = -12938129318293819L;
  private String name;
  // 직렬화 대상 제외 : null 반환
  private transient List<Object> dummyList;
}

세션을 관리하는 객체는 전송을 위해 반드시 Serializable 을 구현해야한다. 불필요한 데이터는 transient를 사용해서 직렬화를 제외처리 하도록 하자. (직렬화된 데이터는 클래스 메타정보를 포함하기 때문에 JSON 포맷보다 2배 이상 사이즈가 크다. 포맷 변경도 고려 사항이다.)
애플리케이션 간 데이터 전송을 위해 멀티캐스트(1 대 N 통신) 프로토콜 방식을 사용해야 한다. 톰캣의 경우 IP와 PORT가 지정되어 있다. (방화벽 해제 여부 확인 필요)
이것도 안되고 저것도 안되면 Redis, Memcached와 같은 별도의 세션 저장소를 사용하는 방법도 고려해보자.