JEUS 웹 컨테이너는 URL rewriting과 Cookie를 모두 지원하여 Session Tracking을 가능하게 하기 위해서 기본적으로 Cookie가 사용된다. Session ID를 운반할 때 사용되는 Cookie를 Session Cookie라고 한다.

웹 컨테이너에서 하나의 Session은 하나의 Servlet API인 HttpSession 클래스의 인스턴스로 표현된다. 이 인스턴스는 Session Cookie(또는 URL rewriting의 결과로 생긴 URL 파라미터)의 Session ID와 연관되어 있다. HttpSession 객체는 기본적으로 그것을 생성하는 웹 컨테이너에 존재하고 이것은 사용자 선호 성향이나 사용자가 전자 상거래 사이트에서 구매하고 싶은 물품의 목록 등과 같은 사용자에 대한 데이터를 가지고 있다.

지금부터 JEUS의 웹 컨테이너에서 어떻게 Session Cookie와 HttpSession 객체가 사용되어 Session을 Tracking하는지에 대하여 알아보자. URL rewriting은 여기서 설명한 기술의 개념과 유사한 것임을 알아두자. 단, Session ID가 HTML 페이지의 URL 링크에 포함되어 있다는 것이 별도의 Cookie header에 담겨진다는 것과 다르다.

다음은 한 클라이언트가 JEUS 웹 컨테이너가 관리하는 리소스를 요청하는 과정에 대한 설명이다.

[그림 5.2] 웹 컨테이너가 Session Cookie를 발급하는 과정

이제 클라이언트는 Session Cookie를 지니고 있고, 같은 웹 컨테이너에 또 다른 요청할 때 Cookie를 포함해서 보낼 수 있다. 웹 컨테이너는 클라이언트를 인식할 수 있고(Cookie의 Session ID를 보고), 클라이언트의 HttpSession 객체를 가져올 수 있다.

다음은 이 과정에 대한 설명이다.

[그림 5.3] Session ID Cookie로 웹 컨테이너에 두 번째 요청을 보내는 과정

이전 절에서는 단 하나의 클라이언트, 하나의 웹 서버, 하나의 웹 컨테이너가 연계된 간단한 상황에서 Session Tracking이 이루어지는 것을 살펴보았다. 그러나 실제 운영 환경에서는 이러한 간단한 구조는 충분하지 않은 경우가 많다. 많은 양의 사용자 요청을 수용하기 위해서는 부하 분산과 웹 서버 클러스터링이 구현되어야 한다.

어떻게 클러스터가 구성되는지에 대한 자세한 내용은 “제4장 웹 서버 연결과 클러스터링”을 참고한다.

웹 서버 클러스터에 있어서 Session Tracking 메커니즘을 구성하고 설정할 때에는 특별한 주의가 필요하다. 분산된 클러스터에서 Session을 관리할 때에는 3가지의 주요 사항들이 쟁점이 된다.

첫 번째 논점은 Session Routing(Sticky Session)이라는 기능으로 대처 가능하고 나머지 2가지 논점들은 Session Server로 대처 가능하다. 지금부터 이 3가지의 문제와 해결 방법에 대하여 설명한다.

Session Routing(Sticky Session)은 클러스터된 환경에서 Client ID뿐만 아니라 웹 컨테이너 ID와 함께 Session ID Cookie로 꼬리표를 붙이기 위해 사용된다. Container ID는 Session Cookie를 처음 생성했던 컨테이너에 의해 추가되고, 웹 서버가 원래의 웹 컨테이너에게 요청을 전달해 줄 수 있게 한다.

예를 들면, 2개의 웹 컨테이너 A, B가 하나의 웹 서버에 연결된 클라이언트 요청 상황을 고려해보자.

이 과정은 다음과 같이 나타낼 수 있다.

[그림 5.4] Session ID Cookie를 이용하여 2개의 웹 컨테이너와 Session을 시작하는 경우

지금까지 모든 것이 정상적이었다. 심각한 문제는 두 번째 요청이 같은 클라이언트로부터 생성될 때 발생하기 시작한다. 이 문제의 시나리오는 다음과 같이 그림으로 표현이 가능하다.

[그림 5.5] Session Routing이 없는 경우 클라이언트 Session 삭제

이 문제를 해결하기 위하여 처음에 HttpSession 객체를 생성했던 동일한 웹 컨테이너에게 Session으로 제한된 요청을 올바르게 Routing해 줄 방법이 필요하다. 이것은 Session Cookie에게 추가의 웹 컨테이너 ID를 부여함으로써 해결된다. 다음은 이 해결 과정을 그림으로 나타낸 것이다.

[그림 5.6] Session Cookie에 추가의 웹 컨테이너 ID 부여

이렇게 함으로써 Routing 문제가 쉽게 해결된다. 다음은 Session Routing의 작동에 대한 그림이다.

[그림 5.7] Session Routing의 작동

두 번째 요청에 웹 서버는 Session Cookie와 Container ID 값(CID)을 찾아낸다. 웹 서버는 해당 HttpSession이 존재하는 원래의 웹 컨테이너로 요청을 Routing시킨다.

웹 서버에서 표준이 아닌 Container ID를 식별하기 위해서 Apache, IIS, SunOne(Iplanet)과 같은 다른 웹 서버의 경우에는 mod_jk 모듈을 설치해야 한다. WebtoB 웹 서버에게는 이 기능은 내장되어 있다. 자세한 내용은 “4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정” 부분의 설명을 참고한다.

간단한 Session Routing을 사용하는 것보다 한 층 더 강력한 것이 Session Server를 사용하는 것이다.

Session Server를 사용할 때에는 모든 웹 컨테이너가 클러스터 내의 모든 웹 서버에 연결될 필요는 없다. 또한, Session Server는 클러스터 내의 모든 Session 데이터에게 신뢰적인 백업 기능을 제공한다. 따라서 특정 웹 컨테이너에 장애가 발생하더라도 Session 데이터는 저장되고 다른 정상적인 웹 컨테이너가 장애가 발생한 웹 컨테이너의 요청을 대신 처리한다.

다음 그림에는 장애가 발생한 웹 컨테이너의 문제가 표현되어 있다. 이 시나리오에서는 웹 컨테이너에 존재하는 모든 사용자 Session 데이터가 소멸된다. 이런 상황은 운영 환경에서는 반드시 피해야 하는 것이다.

[그림 5.8] 장애가 발생한 웹 컨테이너의 문제

이와 같이 특정 웹 컨테이너에 장애가 발생하는 상황에서도 Session을 지속시키기 위해서 Session Server가 클러스터에 추가되었다. 이런 Session Server가 사용될 경우에는 클라이언트의 첫 HTTP 요청이 다음과 같은 방법으로 처리된다.

[그림 5.9] Session Server가 사용될 경우 클라이언트의 첫 HTTP 요청 처리

후에 웹 컨테이너 B가 무작위로 웹 서버에 의해 클라이언트 A의 요청을 처리하도록 선택되거나 웹 컨테이너 A에 장애가 발생하더라도 Session 데이터는 Session Server에서 가져올 수 있다.

[그림 5.10] Session 데이터의 요청 처리

게다가, Session 데이터 저장소를 좀 더 안정적으로 만들기 위하여 백업 Session Server가 설정될 수 있다. 자세한 내용은 “5.3. Session Tracking 설정”에서 간략하게 다시 설명한다.

실제로 Session Server는 JEUSMain.xml에서 설정하며 특정 Context가 Session Server를 사용할지의 여부는 Context 레벨의 웹 애플리케이션의 설정 즉, jeus-web-dd.xml에서 설정한다.

일반적으로 Context 레벨에서 설정을 하지만 WEBMain.xml에서 Web Container 레벨, Context Group 레벨의 설정도 가능하다. 이와 관련된 자세한 내용은 “2.3.7. Session”을 참고한다.

위에서 설명한 Session Routing 방법과 Session Server 방법이 혼합된 것이 혼합 모드이다.

Session Routing(Sticky Session) 방법은 웹 컨테이너의 Session 객체를 접근하므로 빠르다. 그러나 문제가 발생할 경우에 웹 컨테이너의 모든 Session 데이터는 소멸되고 복구가 불가능하게 될 것이다.

Session Server를 사용하면 Session Server에 모든 Session 객체가 서버에 저장되므로 특정 웹 컨테이너에 문제가 생기더라 하더라도 Session 객체의 소멸은 없다. 특정 웹 컨테이너에 문제가 발생하더라도 Session Server는 Session을 유지할 수 있다. 그러나 이 기술은 Session이 필요한 요청이 들어왔을 경우에 Session 객체를 Session Server로부터 가져와야 하는 부담이 있다. 또한 HTTPSession 객체가 변경되었을 경우 Session Server에 다시 저장되어야 한다. 그러므로 Session Server를 사용하는 단점은 Session Routing의 방법보다 처리 속도가 늦다는 것이다.

혼합 방식을 사용함으로써 2가지 방식의 장점을 모두 살릴 수 있다. 만약에 2가지 방법이 혼합되면 Session 객체는 Session Server와 Session 객체를 생성한 웹 컨테이너에 모두 존재한다.

혼합 방식을 사용하여 웹 컨테이너는 필요할 때만 Session Server에서 HTTP Session 객체를 꺼내서 변경한다. 따라서, 혼합 방식을 사용할 경우에는 사용되는 네트워크 대역폭도 Session Server만을 사용하는 방식에 비해 거의 절반 가량 줄이고 모든 Session 데이터의 안전한 백업도 보장받을 수 있다. 이 때문에 클러스터 환경에서는 혼합 방식의 Session 관리의 사용을 권장한다.

Session Server를 사용하면 특정 웹 컨테이너에 장애가 발생하더라도 지속적으로 Session을 유지할 수 있는 장점이 있다. 그러나 Session Server를 사용하는 경우 소규모의 클러스터링 환경에서는 좋은 성능을 유지 할 수 있으나 클러스터링 규모가 커질수록 Session Server에 부담이 가중되어 선형적인 성능 향상을 얻을 수 없는 단점이 있다. 분산 Session Server는 대규모 클러스터링 환경에서 성능 향상을 위해 고안된 Session Server이다.

분산 Session Server란 각 웹 컨테이너마다 Session Server를 두는 방식을 말한다. 기본적으로 Session Routing 기술(Sticky Session)을 사용하며(물론 Session Routing(StickySession)이 적용되지 않는 환경에서도 이상 없이 동작한다) Session Server와 마찬가지로 Session 데이터 백업을 설정할 수 있어 웹 컨테이너에 장애가 발생하여도 지속적으로 Session을 유지할 수 있다.

소규모 클러스터링 환경에서는 중앙 Session Server를 사용하고 대규모 클러스터링 환경에서는 분산 Session Server를 사용하기를 권장한다. 분산 Session Server 설정은 JEUSMain.xml를 통해서 이루어지며, 특정 Context가 Session Server를 사용할지의 여부는 Context 레벨의 웹 애플리케이션의 설정 즉, jeus-web-dd.xml에서 설정한다. 일반적으로 Context 레벨에서 설정을 하지만 WEBMain.xml에서 웹 컨테이너, Context Group 레벨의 설정도 가능하다. 이와 관련된 자세한 내용은 “2.3.7. Session”을 참고한다.

기본적으로 웹 컨테이너는 클라이언트의 Session ID를 지속되는 요청동안 유지하기 위하여 Cookie를 사용한다. 한 가지 문제점은 대부분의 웹 브라우저가 새로운 요청에 대하여 Cookie가 원래 생성된 곳의 도메인 이름과 다른 도메인 이름을 가지고 요청을 하면 SessionID Cookie를 보내지 않는다는 것이다.

이런 이유로, jeus-web-dd.xml deployment descriptor에 특수한 태그가 필요한데, <url-rewriting> 태그가 그것이다. 이 태그가 사용되면, Session ID는 웹 브라우저가 Cookie를 지원하여도 URL rewriting을 사용하여 유지된다. 이런 방법으로, Session Tracking은 다른 도메인 이름이 몇 개의 요청에 사용되어도 작동한다. 이와 관련된 설정에 대해서는 Session 설정인 “2.3.7. Session” 및 “제6장 Web Context(웹 애플리케이션)”를 참고한다.

일반적으로 Session은 같은 Context에서만 관리된다. 하지만 같은 Session을 다른 Context 간에 공유를 하기를 원한다면 Session 설정의 <shared>를 "true"로 설정한다. 이와 관련된 자세한 설정은 “2.3.7. Session”의 <shared> 부분을 참고한다.

중앙 Session Server를 사용하는 경우 JEUSMain.xml에 중앙 Session Server 설정을 하고 JEUS 노드를 재시작해야 한다. 중앙식 Session Server는 사용한 Session 클러스터링이 노드 클러스터링 상태와 아닐 때 모두 가능하다. 2가지 경우에 따라 설정 방법은 다르며 구체적인 설정 방법은 다음과 같다.

노드 클러스터링 상태일 때 설정

노드 클러스터링 상태일 때는 웹 컨테이너 설정을 위해 WEBMain.xml에서 다음의 예제와 같이 Session Server 사용 여부를 설정해 주기만 하면 된다. 다음은 Session Tracking 설정에 대한 예이다.

<?xml version="1.0"?>
<web-container xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    . . .
    <session-config>
        <distributable>true</distributable>
        . . .
    </session-config>
    . . .
</jeus-web-dd>

노드 클러스터링 상태가 아닐 때 설정

노드 클러스터링 상태가 아닐 경우에는 웹 컨테이너 설정인 WEBMain.xml에 해당 컨테이너가 사용할 Session Server의 정보를 설정해야 한다. 그리고 Session Server 사용 여부를 [예 5.1]과 같이 설정한다.

노드 클러스터링을 하지 않은 상태에서 중앙 Session Server를 사용하기 위해서는 WEBMain.xml의 Session Server 설정은 다음과 같이 한다.

<?xml version="1.0"?>
<web-container>
    . . .
    <session-server>
        <primary-server>node1</primary-server>
        <backup-server>node2</backup-server>
        <connect-timeout>120000</connect-timeout>
        <read-timeout>12000</read-timeout>
        <check-level>set</check-level>
    </session-server>
    . . .
</web-container>

다음은 설정 태그에 대한 설명이다.

WEBMain.xml를 설정할 때 <primary-server>와 <backup-server>에 설정되는 JEUS 노드 정보를 설정하는 vhost.properties의 설정 예는 다음과 같다.

jeus.vhost.enable=true
node1=xxx.xxx.xxx.xxx:10003
node2=yyy.yyy.yyy.yyy:10004

각 설정값들의 의미는 다음과 같다.

분산 Session Server를 사용하고자 할 때에도 JEUSMain.xml에 설정을 하고 JEUS 노드를 재시작한다. 자세한 설정 방법은 “JEUS Server 안내서”의 “10.3. 분산 세션 서버”를 참고한다.