내용 목차
본 장에서는 세션 트래킹에 관련된 기본적인 개념과 세션, 세션 ID, 세션 쿠키, URL Rewriting 등에 대한 정의를 설명한다. 또한 JEUS 웹 엔진과 보다 복잡한 분산 환경인 서버 클러스터링 환경에서의 세션 트래킹 구현 및 설정 방법에 대해 설명한다.
세션 트래킹(Session Tracking)은 좁은 의미로 요청된 세션을 찾아 주는 동작이다. 클러스터링 환경에서 세션 트래킹의 지원 범위(Scope)에 따라 라우팅(Routing)에 의한 세션 트래킹과 세션 서버(Session Server)를 통한 세션 트래킹으로 구분된다.
JEUS 6까지는 중앙식 세션 서버와 분산식 세션 서버가 운용되었으나, JEUS 7에서는 분산식 세션 서버만 운용된다.
본 절에서는 기본적인 세션 트래킹의 구조에 대해 설명한다.
본 절에서는 매우 간단한 설명만이 제공되기 때문에 익숙하지 않은 사용자들은 서블릿과 세션 트래킹에 대한 서적을 참고한다.
다음 그림은 세션 트래킹과 세션 관리에 관련된 웹 엔진의 컴포넌트를 보여주고 있다.
HTTP 세션은 동일한 클라이언트(예를 들면 웹 브라우저)의 HTTP 요청과 연관된 일련의 작업들이다. 여러 클라이언트가 이런 요청을 표준 HTTP를 통하여 보낼 때 기본적으로 HTTP 헤더에 유일한 "Client ID"가 없기 때문에 웹 서버는 이 클라이언트들을 구별할 수 없는 문제가 발생한다. 따라서 웹 서버는 관련된 사용자 요청을 하나의 세션으로 트래킹할 수 없다. 이것은 HTTP가 무상태(stateless)와 무연결(connectionless) 프로토콜이기 때문이다.
웹 서버도 세션 트래킹에 관련되어 있음을 주의한다.
HTTP 요청은 다음과 같이 작동한다.
클라이언트는 웹 서버에 연결한다.
클라이언트는 무상태 HTTP 요청을 생성한다.
클라이언트는 응답을 받는다.
HTTP 연결이 끊어진다.
"Client ID"나 지속적인 세션의 개념은 HTTP 프로토콜에 포함되어 있지 않다. 따라서 웹 서버는 HTTP 연결이 끊어지거나 요청에 대한 응답 수신을 종료한 순간, 각 요청에 대한 사항들을 잃어버린다(단일 요청의 경우 발생). 그렇기 때문에 복잡한 웹 애플리케이션에서 사용자가 지속적으로 서로 연관된 요청을 수행하는 경우에는 사용이 불가능하다.
이 문제를 극복하기 위해 세션 ID라는 특수 string을 각 HTTP 요청에 추가한다. 이 유일한 ID는 클라이언트가 최초 요청을 할 때 필요에 따라 생성되어 클라이언트에 전달된다. 이후 클라이언트의 요청에 이 세션 ID가 지속적으로 붙여진다. 이러한 과정을 통해서 웹 엔진은 각 요청의 근원을 파악할 수 있기 때문에 사용자가 거래를 하는 동안에 대화성 상태(Conversational state)를 유지할 수 있고, 세션의 기능이 없는 HTTP 프로토콜을 이용하여 세션의 개념을 지원할 수 있다.
세션 ID는 쿠키 또는 클라이언트에게 반환되는 HTML 페이지의 각 URL 링크의 파라미터로 자동 추가되고 이것을 URL Rewriting이라고 한다. 또 다른 옵션은 hidden field로 HTML 폼에 세션 ID를 저장하는 방법이 있다. 물론 서블릿 프로그래머의 관점에서 이 논점들은 강력한 Servlet API에 의해 모두 구현되는 것들이다.
본 절에서는 JEUS 웹 엔진에서의 세션 트래킹 동작 방식과 클러스터 환경에서의 세션 트래킹 동작 방식에 대해 설명한다.
JEUS 웹 엔진은 세션 트래킹을 가능하게 하기 위해 URL Rewriting과 쿠키를 지원하고, 그 중에서 기본적으로 쿠키가 사용된다. 세션 ID를 운반할 때 사용되는 쿠키를 세션 쿠키(Session Cookie)라고 한다.
웹 엔진에서 하나의 세션은 하나의 Servlet API인 HTTP 세션 클래스의 인스턴스로 표현된다. 이 인스턴스는 세션 쿠키(또는 URL Rewriting의 결과로 생성된 URL 파라미터)의 세션 ID와 연관되어 있다. HTTP 세션 객체는 기본적으로 그것을 생성하는 웹 엔진에 존재한다. 또한 사용자 선호 성향이나 사용자가 전자 상거래 사이트에서 구매하고 싶은 물품의 목록 등과 같은 사용자에 대한 데이터를 가지고 있다.
URL Rewriting은 여기서 설명한 기술의 개념과 유사한 것이다. 단, 세션 ID가 HTML 페이지의 URL 링크에 포함된다는 것이 세션 쿠키가 별도의 쿠키 헤더(Cookie Header)에 포함된다는 것과 다른 점이다.
세션 쿠키는 하나의 클라이언트가 JEUS 웹 엔진이 관리하는 리소스를 요청하는 과정에서 사용한다.
다음은 웹 엔진이 세션 쿠키를 발급하는 과정에 대한 설명이다.
클라이언트는 웹 서버에 초기 요청을 한다.
웹 서버는 웹 엔진에 요청을 전달한다.
웹 엔진은 해당 클라이언트를 위한 HTTP 세션 객체와 해당 HTTP 세션의 세션 ID를 지닌 세션 쿠키를 생성한다. 이렇게 생성한 세션 ID는 동일한 클라이언트가 지속적인 요청을 할 때 메모리에서 생성한 HTTP 세션 객체를 가져오기 위해 사용된다.
응답 데이터와 세션 쿠키가 웹 서버에 전달된다.
세션 쿠키는 클라이언트의 웹 브라우저에 응답과 함께 전달되고 HTTP 연결은 끊어진다.
세션 ID를 포함하는 세션 쿠키는 클라이언트의 웹 브라우저에 저장된다.
이제 클라이언트는 세션 쿠키를 갖게 되었고, 동일한 웹 엔진에 또 다른 요청할 경우에 쿠키를 포함해서 보낼 수 있다. 웹 엔진은 쿠키의 세션 ID를 통해 클라이언트를 인식할 수 있고, 클라이언트의 HTTP 세션 객체를 가져올 수 있다.
다음은 이 과정에 대한 설명이다.
클라이언트는 동일한 웹 서버에게 또 다른 요청을 보낸다. 이번에는 이전에 받은 세션 쿠키를 웹 브라우저에서 받아 요청에 첨부한다.
웹 서버는 세션 쿠키가 포함된 요청을 받아서 처음의 요청과 같이 동일한 웹 엔진에 전달한다.
웹 엔진은 요청과 세션 쿠키를 받는다. 세션 쿠키에서 발견된 세션 ID에 해당하는 HTTP 세션 객체를 자신의 메모리 영역에서 찾아온다. 웹 엔진은 찾아온 HTTP 세션 데이터를 사용하여 요청을 처리한다.
응답 데이터와 세션 쿠키는 웹 서버에 전달된다.
HTTP 응답이 웹 브라우저에게 전달되고 HTTP 연결은 끊어진다. 세션 쿠키는 연결이 처음 생성될 때에만 응답에 포함되어 전달되면 되고, 그 이후의 응답에는 함께 전달될 필요는 없으므로 이 응답에 쿠키가 함께 전달될 필요는 없다.
“1.3.1. 웹 엔진에서 동작”에서는 클라이언트, 웹 서버, 웹 엔진이 각각 하나씩 연계된 간단한 상황에서의 세션 트래킹 과정에 대해 살펴보았다. 그러나 실제 운영 환경에서는 이러한 간단한 구조는 충분하지 않은 경우가 많다. 다수의 사용자 요청을 수용하기 위해서는 부하 분산과 웹 서버 클러스터링이 구현되어야 한다. 클러스터의 구성에 대한 자세한 내용은 “JEUS Web Engine 안내서”의 “2.4. 부하 분산을 위한 웹 서버 설정”을 참고한다.
웹 서버 클러스터에서 세션 트래킹 메커니즘을 구성하고 설정할 때에는 특별한 주의가 필요하다.
분산된 클러스터에서 세션을 관리할 때에는 다음 3가지의 주요 사항들이 쟁점이 된다.
세션 쿠키를 포함한 요청을 처음 요청했던 웹 엔진에게 어떻게 전달할까?
세션을 이용하여 모든 웹 엔진이 제한적인 요청을 처리하기 위해 하나의 엔진에서 생성된 HTTP 세션 객체를 어떻게 다른 웹 엔진에서도 사용할 수 있게 할까?
내부 또는 외부적인 장애로 웹 엔진이 다운되었을 때 어떻게 세션 데이터를 백업할까?
첫 번째 논점은 세션 라우팅(Sticky Session)이라는 기능으로 대처가 가능하고, 나머지 2가지 논점들은 세션 서버(Session Server)로 대처 가능하다. 본 절에서는 위 3가지의 문제와 해결 방법에 대해 상세히 설명한다.
위의 첫 번째와 두 번째 논점은 근본적으로는 같은 문제이지만, 세션 라우팅과 세션 서버라는 서로 다른 2가지 방법으로 해결한다.
세션 라우팅은 클러스터된 환경에서 해당 세션에 자신이 생성 또는 저장된 엔진의 ID를 부여하는 기능을 의미한다. 해당 엔진 ID가 쿠키에 포함되어 있기 때문에 웹 서버에서는 해당 엔진 ID를 확인하여 요청을 할 수 있다. 그로 인해 웹 엔진의 메모리에 저장되어 있는 세션의 효율을 증가시킬 수 있다.
예를 들어 2개의 웹 엔진 A, B가 하나의 웹 서버에 연결된 클라이언트 요청 상황은 다음과 같이 나타낼 수 있다.
클라이언트는 웹 서버에 초기 요청을 한다.
웹 서버는 임의적으로 요청 전달을 위해 1개의 웹 엔진을 선택한다. 예제에서는 웹 엔진 A가 선택되었다.
요청은 웹 엔진 A로 전달된다.
웹 엔진 A는 HTTP 세션 객체를 생성하고 응답과 함께 세션 ID 쿠키를 돌려보낸다. 이 ID는 다음에 오는 동일한 클라이언트의 요청을 처리할 HTTP 세션 객체를 메모리에서 불러올 때 사용된다.
웹 엔진은 응답을 하고 웹 서버에 세션 쿠키가 반환된다.
세션 쿠키는 응답과 함께 클라이언트의 웹 브라우저로 전달되고, HTTP 연결은 끊어진다.
첫 번째 요청은 문제없이 정상적으로 종료되었다. 그러나 두 번째 요청이 동일한 클라이언트로부터 생성될 때에는 심각한 문제가 발생한다.
클라이언트는 동일한 웹 서버에 또 다른 요청을 한다. 이번에는 첫 번째 요청 과정에서 반환된 세션 쿠키가 웹 브라우저로부터 가져와 요청에 붙여진다.
웹 서버는 요청을 받아들이고 2개의 웹 엔진 중 임의로 1개의 웹 엔진을 선택한다. 이번 예제에서는 웹 엔진 B가 선택되었다.
요청과 세션 쿠키는 웹 엔진 B에 전달된다.
웹 엔진 B는 요청과 세션 쿠키를 받는다. 자신의 메모리 영역에서 쿠키에 대응하는 HTTP 세션을 가져오려고 시도하지만 대응하는 HTTP 세션 객체가 없기 때문에 가져올 수 없다.
따라서 웹 엔진 B는 클라이언트 세션을 유지할 수 없고 새로운 세션을 강제로 생성하거나 또는 오류 메시지를 반환한다(물론 두 옵션 모두 권장하지 않는다).
위의 설명과 같이 엔진의 수를 늘리고 동일한 서비스를 수행해서 트랙픽을 분산시킬 수는 있다. 그러나 실제로 갖고 있는 정보를 찾을 수 없거나 전달할 수 없기 때문에 문제가 발생한다.
이 문제를 해결하기 위해 처음에 HTTP 세션 객체를 생성했던 동일한 웹 엔진에 세션으로 제한된 요청을 제대로 라우팅해줄 수 있도록 세션 쿠키에 웹 엔진 ID를 추가로 부여한다.
다음은 이 해결 과정을 그림으로 나타낸 것이다.
클라이언트는 웹 서버에 초기 요청을 한다.
웹 서버는 임의의 웹 엔진을 선택한다. 예제에서는 웹 엔진 A가 선택된다.
요청은 웹 엔진 A에 전달된다.
웹 엔진 A는 HTTP 세션, 세션 ID 쿠키를 생성하고 웹 엔진 ID(EID)를 쿠키에 삽입한다.
웹 서버에 응답과 세션 쿠키를 반환한다.
웹 브라우저에 응답과 세션 쿠키를 반환한다.
웹 엔진 ID(EID)를 포함하는 세션 쿠키는 웹 브라우저에 저장된다.
이렇게 함으로써 라우팅 문제가 쉽게 해결된다.
JEUS 6에서는 해당 엔진의 ID를 직접 입력해서 운용했지만, JEUS 7에서는 해당 정보를 인코딩해서 운용한다.
다음은 세션 라우팅의 동작 과정이다.
두 번째 요청에 웹 서버는 세션 쿠키와 엔진 ID 값(EID)을 찾아낸다. 웹 서버는 해당 HTTP 세션이 존재하는 원래의 웹 엔진으로 요청을 라우팅한다.
웹 서버에서 표준이 아닌 엔진 ID를 식별하기 위해서 Apache, IIS, SunOne(Iplanet)과 같은 다른 웹 서버의 경우에는 mod_jk 모듈을 설치해야 한다. WebtoB 웹 서버에 이 기능은 내장되어 있다.
mod_jk 모듈 설치에 대한 자세한 내용은 “JEUS Web Engine 안내서”의 “2.4. 부하 분산을 위한 웹 서버 설정”을 참고한다.
세션 라우팅 기능을 위해서는 모든 웹 서버가 모든 웹 엔진과 연결을 맺어야 한다. 부하 분산기를 사용할 경우 여러 대의 웹 서버 중에서 요청을 받은 웹 서버가 해당 웹 엔진에 접속하지 못하면 세션이 끊어질 수 있기 때문이다.
그러나 부하 분산기가 세션 라우팅을 자체적으로 지원하고 있다면 모든 웹 서버와 웹 엔진이 연결될 필요는 없다. 예를 들어 WebtoB를 부하 분산기로 사용하고 있다면, 세션 라우팅은 클러스터링이 완벽하게 연결되어 있지 않아도 사용할 수 있다.
세션 라우팅 기술은 다른 동작에는 영향을 주지 않고 오직 요청을 전달하는 라우팅에만 관련이 있다. 세션 라우팅이 효율적으로 수행되면 세션의 중복 생성 및 중복 저장을 방지할 수 있기 때문에 성능이 많이 향상된다.
하지만 세션 라우팅을 설정해도 요청의 전달을 강제하지 않음을 상기할 필요가 있다. 효율을 늘리는 부분이므로 요청을 보내야 할 엔진이 부하가 걸리거나 장애 상황에 있다면 요청은 다른 엔진으로 전달된다. 즉, 세션 라우팅 기술만으로는 완벽한 클러스터링 환경을 구성할 수 없다.
간단한 세션 라우팅을 사용하는 것보다 한 층 더 강력한 것이 세션 서버를 사용하는 것이다.
세션 서버를 사용할 때에는 모든 웹 엔진이 클러스터 내의 모든 웹 서버에 연결될 필요는 없다. 또한 세션 서버는 클러스터 내의 모든 세션 데이터에 대해 신뢰적인 백업 기능을 제공한다. 따라서 특정 웹 엔진에 장애가 발생해도 세션 데이터는 저장되고, 다른 정상적인 웹 엔진이 장애가 발생한 웹 엔진의 요청을 대신 처리한다.
다음은 웹 엔진에 존재하는 모든 사용자의 세션 데이터가 소멸되는 문제가 발생한 웹 엔진의 요청 처리 과정이다. 이런 상황은 운영 환경에서는 반드시 피해야 하는 상황이다.
이와 같이 특정 웹 엔진에 장애가 발생하는 상황에서도 세션을 지속시키기 위해서 세션 서버가 클러스터에 추가되었다. 세션 서버를 사용할 경우에는 클라이언트의 첫 HTTP 요청이 다음과 같은 방법으로 처리된다.
클라이언트는 웹 서버에 요청을 보낸다.
웹 서버는 웹 엔진 A를 클러스터 내에서 선택하여 요청을 처리하게 한다.
웹 서버는 웹 엔진 A에 요청을 전달한다.
웹 엔진은 HTTP 세션 객체와 세션 쿠키를 생성한다. 이 ID는 다음에 동일한 클라이언트로부터 요청이 왔을 때 세션 서버로부터 생성된 HTTP 세션 객체를 꺼내기 위해 사용된다.
요청에 대한 처리가 완료되면 웹 엔진은 HTTP 세션 객체와 세션 ID를 세션 서버에 저장한다.
응답 데이터와 세션 쿠키는 웹 서버로 전달된다.
세션 ID 쿠키는 응답과 함께 웹 브라우저로 전달되고 HTTP 연결이 끊어진다.
웹 브라우저는 이 세션 쿠키를 저장한다.
이후에 웹 엔진 B가 클라이언트 A의 요청을 처리하도록 웹 서버에 의해 임의로 선택되거나 웹 엔진 A에 장애가 발생하여도 세션 데이터는 세션 서버에서 가져올 수 있다.
세션 서버는 위 그림과 같이 공용 저장소의 역할을 수행한다. 웹 엔진 A, 웹 엔진 B는 각각 별도의 저장 매체이며 서로의 내용을 참조할 수 없게 구성되어 있다. 그러나 세션 서버를 마치 둘의 공용 저장소처럼 두고 세션에 대한 정보를 저장하고, 또 불러오도록 하여 세션의 공유를 돕는다.
여기에서는 개념적으로 엔진 A, 엔진 B를 별도의 공간, 세션 서버를 공유되는 공간으로 비유하고 있다. 그러나 웹 엔진 A, 웹 엔진 B 또한 세션 서버처럼 공유되는 공간일 수 있고, 여기에서의 공유는 네트워크, 즉 다른 인터페이스 등을 통해 접근이 가능하다는 의미이다.
또한 좀 더 안정적인 세션 데이터 저장소를 위해 백업 세션 서버가 운용되고, 그로 인해 장애 사항에 대비할 수 있다. 백업 세션 서버는 내부적으로 운용되는 서버 중에서 자동 선택되며, 서버를 추가하거나 서버가 다운 및 fail되는 경우에도 자동으로 업데이트된다.
세션 서버는 JEUS 6에서 지원하는 중앙 세션 서버 방식처럼 별도의 저장 공간을 두고, 어느 웹 엔진에서나 접근이 가능한 인터페이스를 제공함으로써 특정 웹 엔진에 장애가 발생하더라도 지속적으로 세션을 유지할 수 있는 장점이 있다.
그러나 중앙식 세션 서버의 방식은 대규모의 클러스터링 환경에서는 좋은 성능을 유지할 수가 없다. 그러한 이유는 중앙식 세션 서버에 모든 웹 엔진의 세션이 집중되기 때문에 부담이 가중되어 선형적인 성능 향상을 얻을 수 없는 단점이 있다. 또한 여러 대의 서버가 동작함에도 불구하고 단 하나의 서버만 동작하는 부분도 지금과 같은 분산 환경에서는 적합하지 않다.
이러한 흐름에 맞춰 JEUS 7에서는 분산식 세션 서버가 기본으로 운영된다. 분산 세션 서버는 대규모 클러스터링 환경에서 성능 향상을 위해 고안된 세션 서버이다.
분산 세션 서버는 각 웹 엔진마다 세션 서버를 두는 방식이다. 기본적으로 세션 라우팅 기술을 사용하며(물론 해당 기술이 적용되지 않는 환경에서도 이상 없이 동작하지만 성능은 저하된다), 세션 서버와 마찬가지로 세션 데이터 백업을 설정할 수 있어 웹 엔진에 장애가 발생해도 지속적으로 세션을 유지할 수 있다.
분산 세션 서버에 대한 설정은 WebAdmin의 [Clusters] 메뉴의 [Session Router Config] 탭을 통해 가능하며, 해당 환경에서 설정되면 컨텍스트에서 별도로 설정하지 않아도 그 설정을 따르도록 되어 있다. 분산 세션 서버 설정에 대한 자세한 내용은 “2.9. 세션 서버 설정”을 참고한다.
혼합 모드는 위에서 설명한 세션 라우팅 방법과 세션 서버 방법이 혼합된 것이다. 각 방법의 장단점을 정리하면 다음과 같다.
세션 라우팅 방식 | 세션 서버 방식 | |
---|---|---|
장점 | 웹 엔진의 세션 객체를 접근하므로 속도가 빠르다. | 세션 서버에 모든 세션 객체가 저장되므로 특정 웹 엔진에 문제가 발생해도 세션 객체가 소멸되지 않고, 세션을 유지할 수 있다. |
단점 | 문제가 발생할 경우 웹 엔진의 모든 세션 데이터는 소멸되고 복구가 불가능하다. | 필요한 요청이 들어온 경우에 세션이 세션 객체를 세션 서버로부터 가져와야 하고 HTTP 세션 객체가 변경된 경우 세션 서버에 다시 저장해야 한다. 그러므로 세션 라우팅의 방법보다 처리 속도가 느리다. |
혼합 방식을 사용함으로써 2가지 방식의 장점을 모두 살릴 수 있다. 2가지 방법이 혼합되면 세션 객체는 세션 서버와 세션 객체를 생성한 웹 엔진에 모두 존재하고, 웹 엔진은 필요할 때만 세션 서버에서 HTTP 세션 객체를 꺼내서 변경한다. 따라서, 혼합 방식을 사용할 경우에는 사용되는 네트워크 대역폭도 세션 서버만을 사용하는 방식에 비해 거의 절반 정도 줄이고 모든 세션 데이터의 안전한 백업도 보장받을 수 있다. 이 때문에 클러스터 환경에서는 혼합 방식의 세션 관리의 사용을 권장한다.
Servlet 3.0에서는 기존의 세션 트래킹의 여러 가지 방법을 선택할 수 있는 기능을 제공한다.
기존의 기본적인 세션 트래킹 모드 중 하나는 쿠키를 활용하는 부분이다.
쿠키는 브라우저의 동작과 밀접한 관계를 가지고 있으며, 대부분은 이러한 쿠키를 통해 세션을 유지하고, 동작한다. 그러나 쿠키도 브라우저에 의존하기 때문에 규약이 다른 곳에서는 쿠키가 사용되지 않아서 세션이 유지되지 않을 수도 있다. 즉, 쿠키의 도메인과 경로에 대한 기본적인 지식이 요구되는 것으로 이러한 규약으로 인해 원하는 세션에 대한 트래킹이 가능한 것이다.
URL Rewriting 모드는 브라우저가 쿠키를 지원하지 않을 경우에는 쿠키 사용 모드를 사용할 수 없기 때문에 존재하는 모드이다.
기존의 JEUS 6의 URL Rewriting과 동일한 방법이다. 즉, 쿠키를 사용하지 않아도 Target URL 자체에 원하는 세션에 대한 정보를 기록하는 것이다. 이러한 기능으로 웹 브라우저가 쿠키를 지원하지 않더라도 세션을 유지할 수 있다.
이 모드를 사용하려면, jeus-web-dd.xml DD(Deployment Descriptor)에 특수한 태그가 필요하다. <tracking-mode><url> 태그를 사용하면, 세션 ID는 URL Rewriting을 사용하여 유지된다. 이런 방법으로 세션 트래킹은 다른 도메인 이름이 몇 개의 요청에 사용되어도 동작한다.
SSL 사용 모드는 SSL 연결에 세션을 제한적으로 전송하기를 원할 때 설정한다. JEUS를 운용할 때 세션에 보안상 보호되어야 할 데이터를 세션에 담는 경우가 존재하는데 이 경우에 설정하는 모드이다. SSL 사용 모드를 적용하면 SSL 연결이 아닌 곳에서 세션은 전송되지 않는다.
일반적으로 세션은 동일한 컨텍스트에서만 관리되지만, 다른 컨텍스트 간의 공유도 가능하다.
세션 서버를 사용한다고 해서 모든 세션이 공유되는 것은 아니기 때문에, 서로 다른 컨텍스트 간의 세션 데이터 공유를 원한다면 세션 설정의 Shared를 설정한다. Shared 설정은 세션 데이터의 공유를 위해 반드시 설정해야 하고, 이와 관련된 자세한 설정은 “1.6.1. 세션 설정”을 참고한다.
본 절에서는 JEUS WebAdmin(이하 WebAdmin)을 사용한 세션 트래킹 설정 방법을 설명한다.
세션 트래킹을 위해 세션 라우팅이나 세션 서버 기능을 사용하려면 다음과 같은 설정이 필요하다.
세션 라우팅 설정
JEUS 7에서는 기본적으로 세션 라우팅을 지원하기 때문에 지원 여부에 대한 특별한 설정을 필요로 하지 않으며 자동으로 지원한다.
세션 서버 설정
JEUS 7에서 분산 세션 서버를 사용하려면 클러스터 설정에서 해당 서버를 클러스터에 참여시키면 된다. 세션 서버 설정에 대한 자세한 내용은 “제2장 분산 세션 서버”를 참고한다.
세션 트래킹에 대한 설정은 콘솔 툴(jeusadmin)을 사용할 수도 있다. 콘솔 툴에서 사용하는 설정 관련 명령어는 “JEUS Reference Book”의 “4.2.8.17. modify-session-configuration”을 참고한다.
세션을 관리하기 위해 세션 객체의 공유 여부, 세션 쿠키 설정, Timeout 등 웹 엔진의 세션과 관련된 모든 사항에 대해 설정한다.
WebAdmin을 사용하여 세션을 설정하는 방법은 다음과 같다.
WebAdmin의 왼쪽 메뉴에서 [Servers]를 선택하면 서버 목록 조회 화면으로 이동한다. 서버 목록에서 원하는 서버를 선택하면 서버 설정 화면으로 이동한다. 설정 화면에서 [Engine] > [WebEngine] > [Session Config] 메뉴를 선택한다.
[LOCK & EDIT] 버튼을 클릭해서 설정 변경 모드로 전환한다.
Session Config 화면은 다음과 같이 기본 설정 항목과 고급 선택사항으로 구분된다. 이 항목들은 웹 엔진에서 공통적으로 사용할 세션 설정을 정의한다. 컨텍스트별로 설정을 오버라이드(override)할 수 있으며 컨텍스트, 웹 엔진 순으로 우선순위를 갖는다. 각 항목을 설정한 후 [확인] 버튼을 클릭한다.
다음은 설정 항목에 대한 설명이다.
기본 정보
항목 | 설명 |
---|---|
Timeout | 생성된 세션 객체의 유효 주기를 설정한다. 보통 웹 애플리케이션 설정인 web.xml에서 Session Timeout을 설정한다. 만약 web.xml에서 특별한 설정을 하지 않았다면 여기서 설정한 값이 적용된다. 즉, web.xml의 Session Timeout 설정이 존재한다면 현재 설정값은 적용되지 않는다(web.xml의 Session Timeout이 우선순위가 가장 높다). Int 형식의 설정이며 분 단위의 시간을 설정한다. 설정하지 않을 경우 기본값으로 설정된다. |
Max Session Count | 메모리에 유지하는 최대 세션 수를 설정한다. 설정한 개수 이상의 세션이 유지되고 있을때 세션의 생성 요청이 들어올 경우 오류를 발생시킨다. 특정 애플리케이션의 세션 갯수 증가가 다른 애플리케이션에 세션 생성에 영향을 주어서는 안되기에 애플리케이션 별로 해당 세션 갯수가 적용된다. 기본값은-1이며,무제한의 세션 생성을 허용한다는 의미이다. |
Shared | 현재 컨텍스트에서 생성된 세션 객체를 다른 컨텍스트들에서도 공유하여 사용할지의 여부를 설정한다. 즉, 컨텍스트 A에서 생성된 HTTP 세션 객체가 컨텍스트 B에서도 같은 사용자에 의해 사용될 수 있는지에 대한 설정이다. 세션 클러스터링이 아닌 환경의 경우 최대 공유 범위는 동일 애플리케이션 내의 컨텍스트이며, 세션 클러스터링 환경의 경우 공유 범위는 제한이 없다. 설정하지 않을 경우 기본값으로 설정된다. |
Shared를 선택하여 세션이 여러 컨텍스트들 간에 공유된다면 해당 Session Tmeout은 JEUS 웹 엔진에서는 해당 세션이 처음 생성되는 컨텍스트의 Timeout 설정을 따른다.
고급 선택 사항
항목 | 설명 |
---|---|
Reload Persistent | 일반적으로 서블릿 컨텍스트가 변경되어 리로딩이 발생할 때 해당 컨텍스트 내의 세션 객체의 속성들은 모두 삭제된다. 설정하지 않을 경우 기본값으로 설정된다.
|
세션을 전달하는 방법(세션 트래킹)을 설정한다. 다음은 세션 트래킹을 설정하는 3가지 방법으로 중복 설정이 가능하고 설정하지 않으면 쿠키에 의한 트래킹만을 사용하도록 설정된다.
항목 | 설명 |
---|---|
Cookie | 세션 트래킹 방법으로 쿠키를 사용하는 경우의 설정이다.
|
Url | 세션 트래킹 방법으로 URL Rewriting 방법을 사용할 경우의 설정이다.
|
Ssl | 세션 트래킹 방법으로 SSL을 사용할 경우의 설정이다.
|
사용자의 세션을 추적하는 기본 기술은 모든 클라이언트 응답에 반환되는 세션 쿠키를 이용하여 구현된다. 이는 웹 엔진에서 응답를 내보낼 때 HTTP 헤더의 세션 쿠키에 대한 설정이다. 일반적으로 엔진에서 쿠키를 구성하지만, 특별한 쿠키 정보를 구성하는 경우에 사용한다.
다음과 같은 세부 항목을 설정할 수 있다.
항목 | 설명 |
---|---|
Cookie Name | 세션 쿠키의 이름으로 표준 이름인 "JSESSIONID"를 사용하지 않고 다른 이름을 사용할 경우에 설정한다. String 형식의 설정이며, 설정하지 않을 경우 기본값으로 설정된다. (기본값: JSESSIONID) |
Version | 쿠키 ID의 버전을 설정한다. Int 형식의 설정으로 다음의 값 중에 하나를 설정한다.
|
Domain | 세션 쿠키가 전달될 때 서버의 도메인 이름을 설정한다. 쿠키는 이 도메인 요청에 대해서만 되돌아온다. 하나의 적합한 도메인 이름은 "."으로 시작되어야 하며, <host_name>을 지정해서는 안 된다. 이에 대한 자세한 내용은 "RFC-2109 스펙"을 확인한다. String 형식의 설정이며, 설정을 하지 않았을 경우 쿠키에 도메인 정보를 포함하지 않는다. |
Path | 세션 쿠키가 보내질 도메인 내의 String 형식의 URL 경로를 설정한다. 쿠키는 도메인이 적합할 때 해당 URL의 어떤 요청과 함께 보내진다. 예를 들어 만일 "/examples"라는 경로가 설정되고, 도메인은 ".foo.com"으로 설정되었다고 가정할 때 클라이언트의 요청들은 "www.foo.com/examples"의 형식에 맞을 경우에만 해당 쿠키를 포함하여 서버로 요청한다. 이 또한 위의 도메인 설정과 더불어 "RFC-2109 스펙"을 확인한다.
경로의 최상위 값인 "/"가 아닌 다른 값으로 설정할 경우에는 애플리케이션들의 세션 공유 특성들을 고려하여 주의 깊게 값을 설정한다. |
Max Age | 세션 쿠키의 expires 속성을 설정한다. 이 시간 주기가 되면 쿠키는 클라이언트로부터 제거되고 더 이상 보내지지 않는다. Int 형식의 설정이며, 설정하지 않을 경우 기본값으로 설정된다. (기본값: -1, 단위: 초) 기본값으로 설정하면 쿠키의 "expires" 속성을 사용하지 않겠다는 것을 의미한다. 즉, 브라우저의 LifeCycle을 따르겠다는 의미로, 브라우저가 닫힐 때 쿠키는 사용자의 세션이 끝남과 동시에 끝난다. |
Secure | 세션 쿠키의 secure 속성을 Boolean 형식으로 설정하고 설정하지 않을 경우 기본값으로 설정된다.
|
Http Only | 세션 ID 쿠키의 HttpOnly 속성을 Boolean 형식으로 설정한다. 설정하지 않을 경우 기본값으로 설정된다. HttpOnly 속성은 Servlet 3.0에 추가된 기술로 HTTP 외의 스크립트 요청에 의해서 해당 쿠키가 사용되는 것을 방지하는 보안 기술이다.
|
Same Site | 세션 쿠키의 SameSite 속성을 String 형식으로 설정한다. 설정하지 않을 경우 기본값으로 설정된다. SameSite 속성은 사이트 간 요청 위조(CSRF)를 방지하는 보안 기술이다.
|
Comment | 사용자가 해당 쿠키에 대한 정보를 쉽게 알 수 있도록 하기 위해 해당 쿠키에 대한 목적 또는 설명을 기록한다. Netscape Version 0 쿠키에서는 지원되지 않는다. |
설정을 완료한 후 [Activate Changes] 버튼을 클릭하면 다음과 같이 반영 결과가 화면에 표시된다. Session Config 화면의 각 항목은 동적 설정 항목이 아니므로 결과에 표시된 것처럼 서버를 재시작해야 변경 내용이 서버에 반영된다.
JEUS 7의 도메인 구조에서 세션 서버를 사용하려면 클러스터링에 참여해야 한다 . WebAdmin에서 클러스터에 참여하는 서버들을 설정만 하면 된다. 이러한 설정으로 인해 컨텍스트별 설정 없이 세션 서버를 사용할 수 있다. 클러스터링 구성 및 분산 세션 서버의 기본 설정에 대한 자세한 내용은 각각 “2.8. 세션 클러스터링”과 “2.9. 세션 서버 설정”을 참고한다.
여러 개의 분산 세션 서버가 클러스터링되는 환경을 위해서는 JEUS의 클러스터링이 전제되어야 한다. 하지만 JEUS 7에서는 중앙식 세션 서버의 유사 지원을 위해서 클러스터링이 전제되지 않은 상황에서도 분산식 세션 서버를 활용하여 세션을 공유할 수 있는 기능을 제공한다. 해당 부분에는 세션의 강제 공유 및 모든 도메인의 세션 공유와 같은 제약 사항이 있으며 자세한 설명은 “2.8.2. 도메인 스코프 세션 클러스터링”에서 설명한다.
클러스터된 환경에서 최적의 성능을 위해 다음과 같이 수행한다.
좋은 성능과 안정적인 운영을 보장하기 위해 항상 세션 라우팅과 세션 서버를 혼합하여 사용하도록 한다.
웹 서버들이 제대로 연결되서 설정되고 튜닝되어 있어야 한다.
사용자의 요청이 폭주하는 사이트에서는 분산 세션 서버를 사용할 것을 권장한다.
생성된 세션들에 대한 기본적인 모니터링을 통해 현재 서버가 가지고 있는 세션의 개수를 확인할 수 있다.
세션의 모니터링은 다음과 같은 2가지 방법을 통해 가능하다.
WebAdmin을 사용
WebAdmin을 사용하여 세션을 모니터링하는 방법은 “JEUS Web Engine 안내서”의 “1.4. 관리 도구”의 "웹 엔진 모니터링" 부분을 참조한다.
콘솔 툴을 사용
콘솔 툴을 사용한 세션 모니터링 방법은 “JEUS Reference Book”의 “4.2.8.38. show-web-statistics”를 참조한다.