세션 서버는 클라이언트의 세션 데이터를 관리하거나 백업하는데 사용된다. 그 중에서도 특히 여러 웹 서버들과 서블릿 엔진들이 클러스터링된 환경에서 세션 데이터를 관리할 때 유용하다.

JEUS 7에서는 세션 데이터의 관리 방식인 세션 서버로 분산식 세션 서버를 운용한다.

분산 세션 서버는 세션 클러스터링 기능을 제공하면서 확장성 및 안정성을 개선한 방식이다. 따라서 대규모 클러스터링 환경에서 성능을 발휘할 수 있다.

분산 세션 서버는 기본적으로 세션 서버로서의 동작면에서는 기존의 중앙 세션 서버와 동일하다. 여러 서블릿 엔진들로 구성된 클러스터링 환경에서 동일한 클라이언트에서 요청된 일련의 요청들이 특정 서블릿 엔진에서 처리되지 않더라도 세션을 계속 유지해주는 기능을 제공한다.

분산식 세션 서버는 해당 세션들의 관리 주체들이 분산되어 있음을 의미하며, 이에 따라 높은 확장성을 제공한다.

분산 세션 서버의 특징은 다음과 같다.

분산 세션 서버는 세션 객체를 서비스하는 서버가 각각의 서블릿 엔진(웹 엔진) 또는 각각의 EJB 엔진에 분산되어 있는 분산식 구조이다.

분산 세션 서버 방식은 클러스터링에 참여하는 모든 엔진 내에 독립적인 분산 세션 서버가 존재하고, 이들 분산 세션 서버들이 Peer-to-Peer로 다른 엔진의 분산 세션 서버와 통신하여 지속적인 세션 서비스를 제공한다.

다음은 분산 세션 서버 방식을 사용하여 4개의 웹 엔진을 세션 클러스터링하는 구조이다.

[그림 2.1] 분산 세션 서버를 이용한 세션 클러스터링 구조

위의 구조도에서 화살표는 분산 세션 서버 간의 소켓 연결을 나타낸 것이다. 항상 모든 연결을 맺는 것이 아니고, 연결에 대한 가능성을 의미한다. 일반적으로 연결이 필요없으며 세션 유지를 위해 다른 엔진과의 통신이 필요한 경우에만 연결을 맺고 유지한다. 장애 발생의 경우를 제외하고 연결은 보통 하나씩만 갖는다.

다음은 웹 엔진의 서브 컴포넌트로 동작하는 분산 세션 서버의 내부 구조이다.

[그림 2.2] 분산 세션 서버 내부 구조

분산 세션 서버 방식은 세션 라우팅 기능을 기본으로 동작한다. 세션 ID에 특정 서버의 이름을 붙여서 발급하여 기존에 생성된 서버의 위치를 알고 해당 정보로부터 세션을 유지한다. 그렇기 때문에 세션 라우팅 기술을 강제로 사용하지 않을 경우에는 성능의 효율이 떨어진다.

세션 라우팅을 지원하는 웹 서버를 앞단에 배치하면 정상적인 경우 세션 객체가 존재하는 웹 엔진으로 요청이 라우팅될 것이다. 따라서 이러한 경우의 동작 방식은 세션 라우팅에 의한 세션 클러스터링과 동일하다. 이에 대한 내용은 “1.3.2. 클러스터 환경에서 동작”을 참고한다.

세션 라우팅 기능을 기본으로 동작하는 분산 세션 서버 방식에서는 SessionKey를 사용한다.

다음은 웹 엔진에서 사용되는 SessionKey의 예제이다.

<SessionID>.<primary-engine-name>
   예) XXX.domain1/server1

각 엔진은 세션 라우팅에 사용하는 세션 라우팅 ID를 하나씩 부여받는다. 이 ID는 웹 서버에 웹 엔진이 접속할 때 웹 엔진을 구분하는 구분자로 사용된다. 세션 라우팅 ID는 설정에 의해 자동 생성된다.

[그림 2.3]의 3개의 웹 엔진은 다음과 같은 세션 라우팅 ID 및 백업 서버의 세션 라우팅 ID가 할당되었다고 가정한다.

세션 라우팅 ID가 할당된 분산 세션 서버에 의한 세션 트래킹의 Failover 구조는 다음과 같다.

[그림 2.3] 분산 세션 서버에 의한 Failover 구조

다음은 [그림 2.3]의 동작에 대한 설명이다.

웹 서버가 세션 라우팅을 지원해도 웹 서버에 세션 라우팅 ID에 해당하는 웹 엔진으로의 연결이 존재하지 않거나 해당 웹 엔진에 장애가 발생하여 요청을 전달할 수 없는 경우에 웹 서버는 세션 라우팅을 지원할 수 없다. 이러한 경우 웹 서버는 보통 임의로 선택된 다른 웹 엔진으로 요청을 전달한다.

다음은 세션 라우팅 기능을 사용하지 않는 상황을 가정할 경우의 [그림 2.3]의 분산 세션 서버 동작에 대한 설명이다.

본절은 분산 세션 서버에서 새롭게 추가된 기능인 중복 로그인 방지 기능에 대해 설명한다.

중복 로그인 방지 기능은 기본적으로 애플리케이션에서 관리 하는 중복 로그인 관리 기능 중 기본적인 기능을 분산식 세션 서버에서 제공하는 서비스이다.

분산식 세션 서버의 중복 로그인 방지 기능을 사용하게 되면 애플리케이션의 아이디에 대해 중복된 로그인을 허용하지 않음을 내부적으로 지원한다. 즉, 다른 세션에 대해 동일한 아이디로 로그인을 수행한 경우 기존의 로그인을 수행하였던 세션을 제거하여 근본적으로 중복 로그인을 방지한다.

중복 로그인 방지 기능을 위해 Login Manager는 기존의 중앙 세션 서버와 유사하게 구성된다. 여러 서버들 간의 클러스터링 안에서 로그인 정보를 저장하는 서버를 지정하여 동작하며 장애 상황을 고려하여 secondary 서버를 구성하여 동작한다.

중복 로그인 방지 기능은 개별 애플리케이션별로 설정 가능하며 로그인 정보를 애플리케이션별로 관리된다. 해당 설정은 jeus-web-dd.xml에 <use-jeus-login-manager>를 true로 설정한다.

중복 로그인 방지에 대한 동작은 다음과 같다.

[그림 2.4] 중복 로그인 방지 기능의 동작 방식

다음은 [그림 2.4]의 동작에 대한 설명이다.

본 절은 분산 세션 서버의 Fail-back 기능에 대해 설명한다.

Fail-over 기능은 장애 상황에 대처 하여 기존의 서비스를 지속적으로 이뤄지도록 해주는 세션 서버의 기본적인 기능이다. 즉, 세션의 생성 이후 백업에 전달된 세션으로 인해 특정 서버가 장애가 발생하여도 세션의 유실이 발생하지 않으며, 기존 세션으로 지속적인 서비스를 하도록 하는 기능이다.

새롭게 제공하는 Fail-back 기능은 위의 1차적인 장애 상황에 대한 고려가 아닌, 연속적인 서버의 재시작 또는 장애 서버의 복구시에 제공 되는 서비스이다. 이전의 버전의 분산 세션 서버는 Fail-over는 지원하였으나, Fail-back은 지원하지 않았었다. 해당 부분은 단순한 예로 순차적으로 서버를 재기동 하는 시나리오로 설명한다.

다음 그림은 Fail-back를 지원하지 않는 상태에서의 진행 상황에 대한 설명이다.

[그림 2.5] Fail-back을 지원하지 않는 경우

처음 Server1이 재기동 되면 Server1이 가지고 있던 세션 "A"는 Server2의 백업에만 존재하게 된다. 다음으로 Server2가 재기동되면 Server2의 백업이 제거 되기 때문에 세션 "A"는 전체 시스템에서 제거 되게 된다. 만약 이후 세션 "A"의 요청이 온다면 세션 유지에 실패하게 되고 새로운 세션이 생성된다. 이는 기존의 분산식 세션 서버에서는 백업으로 받은 세션에 대한 처리를 수행하지 않았기 때문이다.

다음은 Fail-back를 지원하는 경우 결과이다.

[그림 2.6] Fail-back을 지원하는 경우

처음 Server1이 재기동 되었을 경우 DumpToBackup에 의한 동작은 동일하다(세션 "B"가 유지 되는 모습). 이후 추가적으로 Fail-back 기능에 의해 Server2가 지닌 세션 "A"가 다시 Server1로 전달 되는 모습을 확인할 수 있다. 다음으로 Server2가 재기동되었을 경우에도 최초 환경과 동일하게 세션들이 유지되는 모습을 확인할수 있다.

Fail-back 기능은 기본적으로 reply-response 방식이로 이뤄지게 되며, 장애 서버에서 <jeus.sessionmanager.failback.allow>를 true로 설정한다.

기능의 시작은 자신이 백업 서버로 동작하였던 서버의 재기동을 감지함으로써 시작된다.

본 절은 분산 세션 서버의 Handover 기능에 대해 설명한다.

Handover 기능은 기본적으로는 클라우드 서버 환경에서 Scale In하는 경우 세션을 유지하기 위해 제공한다. 클라우드 서버 환경에서는 Scale In, Scale Out이 빈번하게 발생할 수 있는데 기존 서버 환경과 작동 방식에 차이가 존재한다.

예를 들어, 기존 서버 환경에서 Server1, Server2, Server3가 존재한다. 서비스를 하는 중에 부하가 많이 발생하지 않아서 Server3를 잠시 중지상태로 만들었다. 그리고 얼마 있지 않아 부하가 발생하여 Server3를 재기동하였다. 이런 경우 Server3가 다시 기동한 것이기 때문에 Fail-over나 Fail-back 기능을 통해 해당 서버의 세션을 유지할 수 있다.

반면에 클라우드 서버 환경에서 Server1, Server2, Server3이 존재한다. 클라우드 서버 환경에서는 부하가 적어지면 Scale In을 수행하여 서버 갯수를 줄이게 된다. 이 경우 Server3의 Scale In을 수행하여 기동 중지 시키고 부하가 발생하였을 때 Scale Out을 수행하여 서버를 추가하면, 추가한 서버가 직전에 Scale In을 통해 기동 중지 되었던 Server3라고 보장하지 못한다. 왜냐하면 클라우드 서버 환경에서는 Scale Out할 때 새로운 서버를 기동시키기 때문이다. 따라서, 클라우드 서버 환경에서 Scale In하는 경우 세션을 유지하는 기능이 없다면 세션이 유실될 가능성이 있다. 물론 기존의 Fail-over 기능을 통해 세션의 유실을 막을 순 있지만, 연속적인 Scale In이 일어나면 세션이 유실될 가능성이 크다.

Handover는 위와 같은 상황에서 Server3가 Scale In 될 때, Server3의 세션을 기동 중인 다른 서버(Server1, Server2)에 전송하고 기동을 중지하는 기능이다. 이렇게 되면 Server3의 세션 유실 없이 정상적인 서비스가 가능해진다. Handover 기능은 클라우드 서버 환경이 아닌 기존 서버 환경에서도 사용할 수 있는 기능이다.

Handover 기능은 해당 서버에서 <jeus.sessionmanager.use.handover>를 true로 설정한다. 기능은 서버가 중지(정상 종료), 실패(비정상 종료료)함으로써 시작된다.

본 절에서는 세션 클러스터링에 대해 설명한다.

세션 클러스터링은 단순히 생각하면 세션의 공유를 지원하는 기능이라고 할 수 있다. 하지만 기본 스펙에 의해 세션 클러스터링의 중요한 기능은 스코프 외에는 세션이 공유되지 않아야 하는 것이다. 세션 스코프에 따라 JEUS에서는 3가지 종류의 세션 클러스터링을 지원한다.

2.8.3. 사용자 정의 스코프 세션 클러스터링

사용자 정의 스코프 세션 클러스터링은 JEUS에서 제공하는 기본적인 클러스터링 구성과 관계없이 특정 애플리케이션을 그룹화 하여 세션을 공유하며, 그룹이 여러 개 존재할 경우 사용하는 세션 클러스터링이다.

대부분의 경우는 공유하는 그룹이 1개이기 때문에 애플리케이션 스코프 세션 클러스터링이나 도매인 스코프 세션 클러스터링을 권고한다. 해당 그룹은 애플리케이션에서 세션 클러스터링을 선택하여 디플로이되며, 해당 클러스터링 스코프에서 유지 및 관리가 이뤄진다.

사용자 정의 단위 세션 클러스터링은 분산식 세션 서버의 클러스터링 스코프만 차이가 있을 뿐 내부적 동작은 분산 세션 서버와 동일하다. 세션 클러스터링의 지원으로 클러스터 간의 세션 공유도 가능하며, 한 서버 안에 여러 개의 세션 클러스터링의 구성이 가능하다.

다음은 세션 클러스터링으로 설정한 예를 나타내는 그림이다. 그림의 도형은 애플리케이션을 의미한다.

[그림 2.11] 세션 클러스터링 구성 예

• server1, server2는 서버 클러스터로 묶여 있으며 해당 클러스터의 이름은 server cluster1이다.

• server3, serve4도 서버 클러스터로 묶여 있으며 해당 클러스터의 이름은 server cluster2이다.

• JEUS의 서버 클러스터에 애플리케이션을 디플로이 할 경우에는 클러스터내에 동일한 애플리케이션이 존재하여야 한다.

  • ApplicationA, C : server1, server2

  • ApplicationB, D : server3, server4

• 분산식 세션서버의 클러스터링에 의해서 ApplicationA, ApplicationB는 각 각 서로의 클러스터링의 범위 내에서 세션의 유지 및 관리가 이뤄진다.

• 분산식 세션 서버의 세션 클러스터링에 의해서 ApplicationC, ApplicationD는 클러스터링을 넘어선 공유가 가능하다. 즉, server1, server2, server3, server4에서 모두 세션이 유지 및 관리가 된다.

위와 같이 세션 클러스터링을 사용하면 기존의 클러스터링에 제한적인 세션 유지를 벗어나서 다양한 애플리케이션의 구성이 가능해진다.

참고

1. 서버 간 클러스터링을 맺었더라도 Http Session Config를 설정할 때 도메인 스코프 세션 클러스터링이 사용된다.

2. 서로 다른 애플리케이션에서 세션이 공유되기 위해서는 기본적으로 애플리케이션 간의 공통 URL이 필요하다. 이는 JEUS의 제약 사항이 아닌 브라우저와 쿠키의 제약 사항이다. 이를 위해 세션 클러스터링을 사용하는 애플리케이션들은 공통 URL을 가져야 하며 이 URL을 세션 쿠키 Path에 설정해 주어야 한다.

세션 클러스터링 설정

세션 클러스터링의 기본 설정은 분산식 세션 서버의 설정과 동일하며 WebAdmin에서는 다음과 같이 설정한다.

1. WebAdmin 왼쪽 메뉴에서 [Session]를 선택한다.

   [그림 2.12] 세션 클러스터링 설정 - 세션 선택

   
   

2. 'Session Cluster Config'를 선택하고 'Using Session Cluster' 항목을 설정한다.

   [그림 2.13] 세션 클러스터링 설정 - Common Config

   
   이어지는 설정들은 세션 클러스터링들의 공통적인 설정을 하는 부분이다. 이 부분의 설정은 개별적인 세션 클러스터링의 설정이 없을 경우 사용되는 값들이다.

3. 설정을 완료한 후 확인을 선택한 다음 [Activate Changes] 버튼을 클릭한다.

4. 세션 클러스터링을 추가하기 위해서는 하단에 있는 [ADD] 버튼을 클릭하면 Clusters의 Session Router Config 설정 화면과 동일한 화면이 나오며 해당 화면에서 동일하게 개별적인 세션 클러스터링의 설정을 할 수 있다.

   [그림 2.14] 세션 클러스터링 설정- session cluster 추가

   
   

5. 개별적인 세션 클러스터링을 적용하기 위해서 다시 확인 이후 [Activate Changes] 버튼을 클릭한다.

6. 해당 세션 클러스터링으로 애플리케이션을 deploy하기 위해서는 jeus-web-dd.xml의 <target-session-cluster>에 세션 클러스터링을 적용할 세션 클러스터을 설정해야 한다.

참고

세션 클러스터링은 애플리케이션에서 세션 클러스터링을 결정하는 구조이기 때문에 반드시 jeus-web-dd.xml에 세션 클러스터를 하나 선택하여 설정해야 한다.

WebAdmin을 사용해서 분산 세션 서버의 설정이 가능하다.

다음은 WebAdmin을 사용해서 분산 세션 서버를 설정하는 방법이다.

본 절에서는 위에서 소개했던 도메인 내의 server1 ~ server4의 세션 클러스터링 구성을 예로 사용하여([그림 2.1] 참고) 기존에 사용했던 JEUS 6의 분산 세션 서버 설정 방법과 JEUS 7의 새로운 분산 세션 서버 설정 방법에 대해 설명한다.

다음은 JEUS 6와 JEUS 7의 분산 세션 서버 설정에 대한 변경된 부분에 대한 설명이다.

<jeus-system>
     . . .
    <node>
        <name>MyNode</name>
        <engine-container>
            <base-port>3030</base-port>
            <name>container1</name>
            <engine-command>
                <type>servlet</type>
                <name>engine1</name>
            </engine-command>
           . . .
        </engine-container>
        <engine-container>
            <base-port>3031</base-port>
            <name>container2</name>
            <engine-command>
                <type>servlet</type>
                <name>engine2</name>
            </engine-command>
        </engine-container>
        . . .
        <session-router-config>
            <session-router>
                <!-- 노드이름, 엔진, 엔진 이름이 혼합된 full name을 이용 -->
                <engine-name>MyNode_servlet_engine1</engine-name>
                <!-- 특별한 백업을 원하지 않을 경우 설정이 없어도 자동 선택됨 -->
                . . .
            </session-router>
          <session-router>
                <!-- 노드이름, 엔진, 엔진 이름이 혼합된 full name을 이용 -->
                <engine-name>MyNode_servlet_engine2</engine-name>
                <!-- 특별한 백업을 원하지 않을 경우 설정이 없어도 자동 선택됨 -->
            </session-router>
        </session-router-config>
            . . .
    </node>
    . . .
    <node>
    <name>MyNode1</name>
        <engine-container>
            <base-port>3033</base-port>
            <name>container1</name>
            <engine-command>
                <type>servlet</type>
                <name>engine1</name>
            </engine-command>
            . . .
        </engine-container>
        <engine-container>
            <base-port>3034</base-port>
            <name>container2</name>
            <engine-command>
                <type>servlet</type>
                <name>engine2</name>
            </engine-command>
            . . .
        </engine-container>
        . . .
        <session-router-config>
        . . .
          <session-router>
                <!-- 노드이름, 엔진, 엔진 이름이 혼합된 full name을 이용 -->
                <engine-name>MyNode1_servlet_engine1</engine-name>
                <!-- 특별한 백업을 원하지 않을 경우 설정이 없어도 자동 선택됨 -->
                . . .
          </session-router>
          <session-router>
                <!-- 노드이름, 엔진, 엔진 이름이 혼합된 full name을 이용 -->
                <engine-name>MyNode1_servlet_engine2</engine-name>
                <!-- 특별한 백업을 원하지 않을 경우 설정이 없어도 자동 선택됨 -->
                . . .
          </session-router>
        </session-router-config>
        . . .
    </node>
    . . .
</jeus-system>

2.10.2. JEUS 7 설정 방법

JEUS 7에서의 분산 세션 서버 설정은 WebAdmin을 통해서 가능하다.

JEUS 6에서 총 4개의 컨테이너로 분산 세션 서버를 설정한 것과 같이 JEUS 7에서 기본적으로 서버를 클러스터링하여 동일한 설정 효과를 가져올수 있다. 즉, 다음과 같이 설정하면 총 4개의 서버로 구성된 분산 세션 서버를 설정하여 사용할 수 있다. 클러스터링 구성 및 분산 세션 서버 기본 설정에 대한 자세한 내용은 각각 “2.8. 세션 클러스터링”과 “2.9. 세션 서버 설정”을 참고한다.

[그림 2.16] JEUS 7 설정 예