세션 트래킹

JEUS 웹 엔진은 세션 트래킹을 가능하게 하기 위해 URL Rewriting과 쿠키를 지원하고, 그 중에서 기본적으로 쿠키가 사용된다. 세션 ID를 운반할 때 사용되는 쿠키를 세션 쿠키(Session Cookie)라고 한다.

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

세션 쿠키는 하나의 클라이언트가 JEUS 웹 엔진이 관리하는 리소스를 요청하는 과정에서 사용한다.

다음은 웹 엔진이 세션 쿠키를 발급하는 과정에 대한 설명이다.

이제 클라이언트는 세션 쿠키를 갖게 되었고, 동일한 웹 엔진에 또 다른 요청할 경우에 쿠키를 포함해서 보낼 수 있다. 웹 엔진은 쿠키의 세션 ID를 통해 클라이언트를 인식할 수 있고, 클라이언트의 HTTP 세션 객체를 가져올 수 있다.

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

웹 엔진에서 동작에서는 클라이언트, 웹 서버, 웹 엔진이 각각 하나씩 연계된 간단한 상황에서의 세션 트래킹 과정에 대해 살펴보았다. 그러나 실제 운영 환경에서는 이러한 간단한 구조는 충분하지 않은 경우가 많다. 다수의 사용자 요청을 수용하기 위해서는 부하 분산과 웹 서버 클러스터링이 구현되어야 한다. 클러스터의 구성에 대한 자세한 내용은 JEUS Web Engine 안내서의 부하 분산을 위한 웹 서버 설정을 참고한다.

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

첫 번째 논점은 스티키 세션 라우팅(Sticky Session Routing)이라는 기능으로 대처가 가능하고, 나머지 2가지 논점들은 세션 서버(Session Server)로 대처 가능하다. 본 절에서는 위 3가지의 문제와 해결 방법에 대해 상세히 설명한다.

스티키 세션 라우팅은 클러스터된 환경에서 해당 세션에 자신이 생성 또는 저장된 엔진의 ID를 부여하는 기능을 의미한다. 해당 엔진 ID가 쿠키에 포함되어 있기 때문에 웹 서버에서는 해당 엔진 ID를 확인하여 요청을 할 수 있다. 그로 인해 웹 엔진의 메모리에 저장되어 있는 세션의 효율을 증가시킬 수 있다.

예를 들어 2개의 웹 엔진 A, B가 하나의 웹 서버에 연결된 클라이언트 요청 상황은 다음과 같이 나타낼 수 있다.

첫 번째 요청은 문제없이 정상적으로 종료되었다. 그러나 두 번째 요청이 동일한 클라이언트로부터 생성될 때에는 심각한 문제가 발생한다.

위의 설명과 같이 엔진의 수를 늘리고 동일한 서비스를 수행해서 트랙픽을 분산시킬 수는 있다. 그러나 실제로 갖고 있는 정보를 찾을 수 없거나 전달할 수 없기 때문에 문제가 발생한다. 이 문제를 해결하기 위해 처음에 HTTP 세션 객체를 생성했던 동일한 웹 엔진에 세션으로 제한된 요청을 제대로 라우팅해줄 수 있도록 세션 쿠키에 웹 엔진 ID를 추가로 부여한다.

다음은 이 해결 과정을 그림으로 나타낸 것이다.

다음은 스티키 세션 라우팅의 동작 과정이다.

두 번째 요청에 웹 서버는 세션 쿠키와 엔진 ID 값(EID)을 찾아낸다. 웹 서버는 해당 HTTP 세션이 존재하는 원래의 웹 엔진으로 요청을 라우팅한다.

스티키 세션 라우팅 기능을 위해서는 모든 웹 서버가 모든 웹 엔진과 연결을 맺어야 한다. 부하 분산기를 사용할 경우 여러 대의 웹 서버 중에서 요청을 받은 웹 서버가 해당 웹 엔진에 접속하지 못하면 세션이 끊어질 수 있기 때문이다. 그러나 부하 분산기가 스티키 세션 라우팅을 자체적으로 지원하고 있다면 모든 웹 서버와 웹 엔진이 연결될 필요는 없다. 예를 들어 WebtoB를 부하 분산기로 사용하고 있다면, 스티키 세션 라우팅은 클러스터링이 완벽하게 연결되어 있지 않아도 사용할 수 있다.

스티키 세션 라우팅 기술은 다른 동작에는 영향을 주지 않고 오직 요청을 전달하는 라우팅에만 관련이 있다. 스티키 세션 라우팅이 효율적으로 수행되면 세션의 중복 생성 및 중복 저장을 방지할 수 있기 때문에 성능이 많이 향상된다. 하지만 스티키 세션 라우팅을 사용해도 요청의 전달을 강제하지 않음을 상기할 필요가 있다. 효율을 늘리는 부분이므로 요청을 보내야 할 엔진이 부하가 걸리거나 장애 상황에 있다면 요청은 다른 엔진으로 전달된다. 즉, 스티키 세션 라우팅 기술만으로는 완벽한 클러스터링 환경을 구성할 수 없다.

간단한 스티키 세션 라우팅을 사용하는 것보다 한 층 더 강력한 것이 세션 서버를 사용하는 것이다.

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

다음은 웹 엔진에 존재하는 모든 사용자의 세션 데이터가 소멸되는 문제가 발생한 웹 엔진의 요청 처리 과정이다. 이런 상황은 운영 환경에서는 반드시 피해야 하는 상황이다.

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

이후에 웹 엔진 B가 클라이언트 A의 요청을 처리하도록 웹 서버에 의해 임의로 선택되거나 웹 엔진 A에 장애가 발생하여도 세션 데이터는 세션 서버에서 가져올 수 있다.

세션 서버는 위 그림과 같이 공용 저장소의 역할을 수행한다. 웹 엔진 A, 웹 엔진 B는 각각 별도의 저장 매체이며 서로의 내용을 참조할 수 없게 구성되어 있다. 그러나 세션 서버를 마치 둘의 공용 저장소처럼 두고 세션에 대한 정보를 저장하고, 또 불러오도록 하여 세션의 공유를 돕는다.

여기에서는 개념적으로 엔진 A, 엔진 B를 별도의 공간, 세션 서버를 공유되는 공간으로 비유하고 있다. 그러나 웹 엔진 A, 웹 엔진 B 또한 세션 서버처럼 공유되는 공간일 수 있고, 여기에서의 공유는 네트워크, 즉 다른 인터페이스 등을 통해 접근이 가능하다는 의미이다.

또한 좀 더 안정적인 세션 데이터 저장소를 위해 백업 세션 서버가 운용되고, 그로 인해 장애 사항에 대비할 수 있다. 백업 세션 서버는 내부적으로 운용되는 서버 중에서 자동 선택되며, 서버를 추가하거나 서버가 다운 및 fail되는 경우에도 자동으로 업데이트된다.

기존 버전에서 제공하였던 중앙 세션 서버 방식처럼 별도의 저장 공간을 두고, 어느 웹 엔진에서나 접근이 가능한 인터페이스를 제공함으로써 특정 웹 엔진에 장애가 발생하더라도 지속적으로 세션을 유지할 수 있는 장점이 있다.

그러나 중앙식 세션 서버의 방식은 대규모의 클러스터링 환경에서는 좋은 성능을 유지할 수가 없다. 그러한 이유는 중앙식 세션 서버에 모든 웹 엔진의 세션이 집중되기 때문에 부담이 가중되어 선형적인 성능 향상을 얻을 수 없는 단점이 있다. 또한 여러 대의 서버가 동작함에도 불구하고 단 하나의 서버만 동작하는 부분도 지금과 같은 분산 환경에서는 적합하지 않다.

이러한 흐름에 맞춰 분산식 세션 서버가 기본으로 운영된다. 분산 세션 서버는 대규모 클러스터링 환경에서 성능 향상을 위해 고안된 세션 서버이다.

분산 세션 서버는 각 웹 엔진마다 세션 서버를 두는 방식이다. 기본적으로 세션 라우팅 기술을 사용하며, 세션 서버와 마찬가지로 세션 데이터 백업을 설정할 수 있어 웹 엔진에 장애가 발생해도 지속적으로 세션을 유지할 수 있다.

분산 세션 서버에 대한 사용은 서버들 간의 클러스터에 포함되어 자동으로 제공되는 것을 원칙으로 하고 있다. 즉 서버 클러스터를 사용할 경우 해당 클러스터에 참여한 서버들의 컨텍스트들은 별도의 설정이 없어도 분산식 세션 서버를 통해 세션을 공유하고 유지하는 동작을 수행한다. 분산식 세션 서버에 대한 세부적인 설정에 대한 자세한 내용은 분산 세션 서버 설정을 참고한다.

혼합 모드는 위에서 설명한 세션 라우팅 방법과 세션 서버 방법이 혼합된 것이다. 각 방법의 장단점을 정리하면 다음과 같다.

혼합 방식을 사용함으로써 2가지 방식의 장점을 모두 살릴 수 있다. 2가지 방법이 혼합되면 세션 객체는 세션 서버와 세션 객체를 생성한 웹 엔진에 모두 존재하고, 웹 엔진은 필요할 때만 세션 서버에서 HTTP 세션 객체를 꺼내서 변경한다. 따라서, 혼합 방식을 사용할 경우에는 사용되는 네트워크 대역폭도 세션 서버만을 사용하는 방식에 비해 거의 절반 정도 줄이고 모든 세션 데이터의 안전한 백업도 보장받을 수 있다. 이 때문에 클러스터 환경에서는 혼합 방식의 세션 관리의 사용을 권장한다.

세션을 관리하기 위해 세션 객체의 공유 여부, 세션 쿠키 설정, Timeout 등 웹 엔진의 세션과 관련된 모든 사항에 대해 설정한다.

WebAdmin을 사용하여 세션을 설정하는 방법은 다음과 같다.

도메인 구조에서 세션 서버를 사용하려면 클러스터링에 참여해야 한다 . WebAdmin에서 클러스터에 참여하는 서버들을 설정만 하면 된다. 이러한 설정으로 인해 컨텍스트별 설정 없이 세션 서버를 사용할 수 있다. 클러스터링 참여 방법 및 분산 세션 서버의 설정에 대한 자세한 내용은 각각 세션 클러스터 모드와 분산 세션 서버 설정을 참고한다.