제1장 세션 트래킹
이전   다음

제1장 세션 트래킹

내용 목차

1.1. 개요
1.2. 세션 트래킹 구조
1.3. 세션 트래킹 동작
1.3.1. 웹 엔진에서 동작
1.3.2. 클러스터 환경에서 동작
1.4. 세션 트래킹 모드
1.5. 컨텍스트간 세션 공유
1.6. 세션 트래킹 설정
1.6.1. 세션 설정
1.6.2. 세션 서버 설정
1.7. 세션 트래킹 튜닝
1.8. 세션 모니터링

본 장에서는 세션 트래킹에 관련된 기본적인 개념과 세션, 세션 ID, 세션 쿠키, URL Rewriting 등에 대한 정의를 설명한다. 또한 JEUS 웹 엔진과 보다 복잡한 분산 환경인 서버 클러스터링 환경에서의 세션 트래킹 구현 및 설정 방법에 대해 설명한다.

1.1. 개요

세션 트래킹(Session Tracking)은 좁은 의미로 요청된 세션을 찾아 주는 동작이다.

클러스터링 환경에서 세션 트래킹의 지원 범위(Scope)에 따라 라우팅(Routing)에 의한 세션 트래킹과 세션 서버(Session Server)를 통한 세션 트래킹으로 구분된다.

1.2. 세션 트래킹 구조

본 절에서는 기본적인 세션 트래킹의 구조에 대해 설명한다. 본 절에서는 매우 간단한 설명만이 제공되기 때문에 익숙하지 않은 사용자들은 서블릿과 세션 트래킹에 대한 내용을 참고한다.

다음 그림은 세션 트래킹과 세션 관리에 관련된 웹 엔진의 컴포넌트의 구조이다.

[그림 1.1] JEUS 웹 엔진의 구조 중 세션 관련 부분

JEUS 웹 엔진의 구조 중 세션 관련 부분

HTTP 세션은 동일한 클라이언트(예를 들면 웹 브라우저)의 HTTP 요청과 연관된 일련의 작업들이다. 여러 클라이언트가 이런 요청을 표준 HTTP를 통하여 보낼 때 기본적으로 HTTP 헤더에 유일한 "Client ID"가 없기 때문에 웹 서버는 이 클라이언트들을 구별할 수 없는 문제가 발생한다. 따라서 웹 서버는 관련된 사용자 요청을 하나의 세션으로 트래킹할 수 없다. 이것은 HTTP가 무상태(stateless)와 무연결(connectionless) 프로토콜이기 때문이다.

참고

웹 서버도 세션 트래킹에 관련되어 있음을 주의한다.

HTTP 요청은 다음과 같이 작동한다.

  1. 클라이언트는 웹 서버에 연결한다.

  2. 클라이언트는 무상태 HTTP 요청을 생성한다.

  3. 클라이언트는 응답을 받는다.

  4. HTTP 연결이 끊어진다.

"Client ID"나 지속적인 세션의 개념은 HTTP 프로토콜에 포함되어 있지 않다. 따라서 웹 서버는 HTTP 연결이 끊어지거나 요청에 대한 응답 수신을 종료한 순간, 각 요청에 대한 사항들을 잃어버린다(단일 요청의 경우 발생). 그렇기 때문에 복잡한 웹 애플리케이션에서 사용자가 지속적으로 서로 연관된 요청을 수행하는 경우에는 사용이 불가능하다.

이 문제를 극복하기 위해 세션 ID라는 특수 string을 각 HTTP 요청에 추가한다. 이 유일한 ID는 클라이언트가 최초 요청을 할 때 필요에 따라 생성되어 클라이언트에 전달된다. 이후 클라이언트의 요청에 이 세션 ID가 지속적으로 붙여진다. 이러한 과정을 통해서 웹 엔진은 각 요청의 근원을 파악할 수 있기 때문에 사용자가 거래를 하는 동안에 대화성 상태(Conversational state)를 유지할 수 있고, 세션의 기능이 없는 HTTP 프로토콜을 이용하여 세션의 개념을 지원할 수 있다.

세션 ID는 쿠키 또는 클라이언트에게 반환되는 HTML 페이지의 각 URL 링크의 파라미터로 자동 추가되고 이것을 URL Rewriting이라고 한다. 또 다른 옵션은 hidden field로 HTML 폼에 세션 ID를 저장하는 방법이 있다. 물론 서블릿 프로그래머의 관점에서 이 논점들은 강력한 Servlet API에 의해 모두 구현되는 것들이다.

1.3. 세션 트래킹 동작

본 절에서는 JEUS 웹 엔진에서의 세션 트래킹 동작 방식과 클러스터 환경에서의 세션 트래킹 동작 방식에 대해 설명한다.

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

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

참고

URL Rewriting은 여기서 설명한 기술의 개념과 유사한 것이다. 단, 세션 ID가 HTML 페이지의 URL 링크에 포함된다는 것이 세션 쿠키가 별도의 쿠키 헤더(Cookie Header)에 포함된다는 것과 다른 점이다.

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

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

[그림 1.2] 웹 엔진의 세션 쿠키 발급 과정

웹 엔진의 세션 쿠키 발급 과정

  1. 클라이언트는 웹 서버에 초기 요청을 한다.

  2. 웹 서버는 웹 엔진에 요청을 전달한다.

  3. 웹 엔진은 해당 클라이언트를 위한 HTTP 세션 객체와 해당 HTTP 세션의 세션 ID를 지닌 세션 쿠키를 생성한다. 이렇게 생성한 세션 ID는 동일한 클라이언트가 지속적인 요청을 할 때 메모리에서 생성한 HTTP 세션 객체를 가져오기 위해 사용된다.

  4. 응답 데이터와 세션 쿠키가 웹 서버에 전달된다.

  5. 세션 쿠키는 클라이언트의 웹 브라우저에 응답과 함께 전달되고 HTTP 연결은 끊어진다.

  6. 세션 ID를 포함하는 세션 쿠키는 클라이언트의 웹 브라우저에 저장된다.

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

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

[그림 1.3] 세션 ID 쿠키로 웹 엔진에 두 번째 요청을 보내는 과정

세션 ID 쿠키로 웹 엔진에 두 번째 요청을 보내는 과정

  1. 클라이언트는 동일한 웹 서버에게 또 다른 요청을 보낸다. 이번에는 이전에 받은 세션 쿠키를 웹 브라우저에서 받아 요청에 첨부한다.

  2. 웹 서버는 세션 쿠키가 포함된 요청을 받아서 처음의 요청과 같이 동일한 웹 엔진에 전달한다.

  3. 웹 엔진은 요청과 세션 쿠키를 받는다. 세션 쿠키에서 발견된 세션 ID에 해당하는 HTTP 세션 객체를 자신의 메모리 영역에서 찾아온다. 웹 엔진은 찾아온 HTTP 세션 데이터를 사용하여 요청을 처리한다.

  4. 응답 데이터와 세션 쿠키는 웹 서버에 전달된다.

  5. HTTP 응답이 웹 브라우저에게 전달되고 HTTP 연결은 끊어진다. 세션 쿠키는 연결이 처음 생성될 때에만 응답에 포함되어 전달되면 되고, 그 이후의 응답에는 함께 전달될 필요는 없으므로 이 응답에 쿠키가 함께 전달될 필요는 없다.

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

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

  1. 세션 쿠키를 포함한 요청을 처음 요청했던 웹 엔진에게 어떻게 전달할까?

  2. 세션을 이용하여 모든 웹 엔진이 제한적인 요청을 처리하기 위해 하나의 엔진에서 생성된 HTTP 세션 객체를 어떻게 다른 웹 엔진에서도 사용할 수 있게 할까?

  3. 내부 또는 외부적인 장애로 웹 엔진이 다운되었을 때 어떻게 세션 데이터를 백업할까?

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

참고

위의 첫 번째와 두 번째 논점은 근본적으로는 같은 문제이지만, 스티키 세션 라우팅과 세션 서버라는 서로 다른 2가지 방법으로 해결한다.

스티키 세션 라우팅(Sticky Session Routing)

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

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

[그림 1.4] 세션 ID 쿠키를 이용하여 2개의 웹 엔진과 세션을 시작하는 경우

세션 ID 쿠키를 이용하여 2개의 웹 엔진과 세션을 시작하는 경우


  1. 클라이언트는 웹 서버에 초기 요청을 한다.

  2. 웹 서버는 임의적으로 요청 전달을 위해 1개의 웹 엔진을 선택한다. 예제에서는 웹 엔진 A가 선택되었다.

  3. 요청은 웹 엔진 A로 전달된다.

  4. 웹 엔진 A는 HTTP 세션 객체를 생성하고 응답과 함께 세션 ID 쿠키를 돌려보낸다. 이 ID는 다음에 오는 동일한 클라이언트의 요청을 처리할 HTTP 세션 객체를 메모리에서 불러올 때 사용된다.

  5. 웹 엔진은 응답을 하고 웹 서버에 세션 쿠키가 반환된다.

  6. 세션 쿠키는 응답과 함께 클라이언트의 웹 브라우저로 전달되고, HTTP 연결은 끊어진다.

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

[그림 1.5] 스티키 세션 라우팅이 없는 경우 클라이언트 세션 삭제

스티키 세션 라우팅이 없는 경우 클라이언트 세션 삭제


  1. 클라이언트는 동일한 웹 서버에 또 다른 요청을 한다. 이번에는 첫 번째 요청 과정에서 반환된 세션 쿠키가 웹 브라우저로부터 가져와 요청에 붙여진다.

  2. 웹 서버는 요청을 받아들이고 2개의 웹 엔진 중 임의로 1개의 웹 엔진을 선택한다. 이번 예제에서는 웹 엔진 B가 선택되었다.

  3. 요청과 세션 쿠키는 웹 엔진 B에 전달된다.

  4. 웹 엔진 B는 요청과 세션 쿠키를 받는다. 자신의 메모리 영역에서 쿠키에 대응하는 HTTP 세션을 가져오려고 시도하지만 대응하는 HTTP 세션 객체가 없기 때문에 가져올 수 없다. 따라서 웹 엔진 B는 클라이언트 세션을 유지할 수 없고 새로운 세션을 강제로 생성하거나 또는 오류 메시지를 반환한다(물론 두 옵션 모두 권장하지 않는다).

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

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

[그림 1.6] 세션 쿠키에 추가의 웹 엔진 ID 부여

세션 쿠키에 추가의 웹 엔진 ID 부여

  1. 클라이언트는 웹 서버에 초기 요청을 한다.

  2. 웹 서버는 임의의 웹 엔진을 선택한다. 예제에서는 웹 엔진 A가 선택된다.

  3. 요청은 웹 엔진 A에 전달된다.

  4. 웹 엔진 A는 HTTP 세션, 세션 ID 쿠키를 생성하고 웹 엔진 ID(EID)를 쿠키에 삽입한다.

  5. 웹 서버에 응답과 세션 쿠키를 반환한다.

  6. 웹 브라우저에 응답과 세션 쿠키를 반환한다.

  7. 웹 엔진 ID(EID)를 포함하는 세션 쿠키는 웹 브라우저에 저장된다.

참고

JEUS 6에서는 해당 엔진의 ID를 직접 입력해서 운용했지만, JEUS 21에서는 해당 정보를 인코딩해서 운용한다.

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

[그림 1.7] 스티키 세션 라우팅의 동작 과정

스티키 세션 라우팅의 동작 과정

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

참고

웹 서버에서 표준이 아닌 엔진 ID를 식별하기 위해서 Apache, IIS, SunOne(Iplanet)과 같은 다른 웹 서버의 경우에는 mod_jk 모듈을 설치해야 한다. WebtoB 웹 서버에 이 기능은 내장되어 있다. mod_jk 모듈 설치에 대한 자세한 내용은 “JEUS Web Engine 안내서”의 “2.4. 부하 분산을 위한 웹 서버 설정”을 참고한다.

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

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

세션 서버(Session Server)

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

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

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

[그림 1.8] 장애가 발생한 웹 엔진의 문제

장애가 발생한 웹 엔진의 문제


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

[그림 1.9] 세션 서버가 사용될 경우 클라이언트의 첫 HTTP 요청 처리

세션 서버가 사용될 경우 클라이언트의 첫 HTTP 요청 처리


  1. 클라이언트는 웹 서버에 요청을 보낸다.

  2. 웹 서버는 웹 엔진 A를 클러스터 내에서 선택하여 요청을 처리하게 한다.

  3. 웹 서버는 웹 엔진 A에 요청을 전달한다.

  4. 웹 엔진은 HTTP 세션 객체와 세션 쿠키를 생성한다. 이 ID는 다음에 동일한 클라이언트로부터 요청이 왔을 때 세션 서버로부터 생성된 HTTP 세션 객체를 꺼내기 위해 사용된다.

  5. 요청에 대한 처리가 완료되면 웹 엔진은 HTTP 세션 객체와 세션 ID를 세션 서버에 저장한다.

  6. 응답 데이터와 세션 쿠키는 웹 서버로 전달된다.

  7. 세션 ID 쿠키는 응답과 함께 웹 브라우저로 전달되고 HTTP 연결이 끊어진다.

  8. 웹 브라우저는 이 세션 쿠키를 저장한다.

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

[그림 1.10] 세션 데이터 요청 처리

세션 데이터 요청 처리


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

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

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

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

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

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

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

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

참고

JEUS 21에서는 세션 서버로 Redis와 Hazelcast를 지원한다. 설정 방법은 “2.7. 분산 세션 서버 설정” 를 참고 한다.

혼합 모드(Mixed Mode)

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

 세션 라우팅 방식세션 서버 방식
장점웹 엔진의 세션 객체를 접근하므로 속도가 빠르다.세션 서버에 모든 세션 객체가 저장되므로 특정 웹 엔진에 문제가 발생해도 세션 객체가 소멸되지 않고, 세션을 유지할 수 있다.
단점문제가 발생할 경우 웹 엔진의 모든 세션 데이터는 소멸되고 복구가 불가능하다.필요한 요청이 들어온 경우에 세션이 세션 객체를 세션 서버로부터 가져와야 하고 HTTP 세션 객체가 변경된 경우 세션 서버에 다시 저장해야 한다. 그러므로 세션 라우팅의 방법보다 처리 속도가 느리다.

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

1.4. 세션 트래킹 모드

Servlet 4.0에서는 기존의 세션 트래킹의 여러 가지 방법을 선택할 수 있는 기능을 제공한다.

1.5. 컨텍스트간 세션 공유

일반적으로 세션은 동일한 컨텍스트에서만 관리되지만, 다른 컨텍스트 간의 공유도 가능하다.

세션 서버를 사용한다고 해서 모든 세션이 공유되는 것은 아니며, 서로 다른 컨텍스트 간의 세션 데이터 공유를 원한다면 분산 세션 설정의 scope를 설정한다. scope 설정은 다른 컨텍스트 간의 세션 공유를 위해 반드시 설정해야 하고, 이와 관련된 자세한 설정은 “2.7. 분산 세션 서버 설정”을 참고한다.

1.6. 세션 트래킹 설정

세션 트래킹을 위해 세션 라우팅이나 세션 서버 기능을 사용하려면 다음과 같은 설정이 필요하다.

  • 스티키 세션 라우팅 설정

    기본적으로 세션 라우팅을 지원하기 때문에 지원 여부에 대한 별도의 설정을 필요로 하지 않으며 자동으로 지원한다.

    추가적으로 엔진 정보의 인코딩에 설정이 존재한다.

    항목설명
    BASE64

    설정의 기본값으로 스티키되는 정보를 BASE64 룰에 의해 인코딩하여 전달된다.

    세션 아이디를 통해 엔진정보나 도메인 정보가 노출되는 것을 원치 않아 직관적으로 의미 없는 정보로 보이도록 인코딩하여 전달한다.

    BASE64_WITHOUT_PADDING

    설정의 기본값으로 스티키되는 정보를 BASE64 룰에 의해 인코딩 후 PADDING("=") 없이 전달된다.

    세션 아이디를 통해 엔진정보나 도메인 정보가 노출되는 것을 원치 않아 직관적으로 의미 없는 정보로 보이도록 인코딩하여 전달한다.

    RAW

    스티키되는 정보를 인코딩하지 않고 그대로 노출하여 전달한다.

    인코딩되는 정보는 내부에서도 직관적으로 어떤 엔진에서의 요청인지에 대한 판단이 어렵기에 디버깅을 위해 설정하거나, 엔진 이름 노출이 보안상 영향을 주지 않을 경우에 설정한다.

  • 세션 서버 설정

    분산 세션 서버를 사용하려면 클러스터 설정에서 해당 서버를 클러스터에 참여시키면 된다.

참고

1. 세션 서버 및 스트키 세션 라우팅에 대한 자세한 내용은 “2.7. 분산 세션 서버 설정”을 참고한다.

2. 설정은 콘솔 툴(jeusadmin)을 사용할 수도 있다. 콘솔 툴에서 사용하는 설정 관련 명령어는 “JEUS Reference 안내서”의 “4.2.9.16. set-sessionstorage-scope-session-config”을 참고한다.

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

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

  1. SuperFrameAdmin의 메뉴에서 [서버]를 선택하면 서버 목록 조회 화면으로 이동한다. 서버 목록에서 원하는 서버를 선택하면 서버 설정 화면으로 이동한다. 설정 화면에서 [Engine] > [WebEngine] > [Session Config] 메뉴를 선택한다.

  2. [수정] 버튼을 클릭해서 수정 모드로 전환한다.

  3. Session Config 화면은 다음과 같이 기본 설정 항목과 고급 선택사항으로 구분된다. 이 항목들은 웹 엔진에서 공통적으로 사용할 세션 설정을 정의한다. 컨텍스트별로 설정을 오버라이드(override)할 수 있으며 컨텍스트, 웹 엔진 순으로 우선순위를 갖는다. 각 항목을 설정한 후 [저장] 버튼을 클릭한다.

    [그림 1.11] 세션 설정 - 기본 정보

    세션 설정 - 기본 정보

  4. 설정을 완료한 후 [저장] 버튼을 클릭하면 다음과 같이 반영 결과가 화면에 표시된다. Session Config 화면의 각 항목은 동적 설정 항목이 아니므로 서버를 재시작해야 변경 내용이 서버에 반영된다.

    [그림 1.12] 세션 설정 - 결과 확인

    세션 설정 - 결과 확인


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

1.7. 세션 트래킹 튜닝

클러스터된 환경에서 최적의 성능을 위해 다음과 같이 수행한다.

  • 좋은 성능과 안정적인 운영을 보장하기 위해 항상 스티키 세션 라우팅과 세션 서버를 혼합하여 사용하도록 한다.

  • 웹 서버들이 제대로 연결되서 설정되고 튜닝되어 있어야 한다.

  • 사용자의 요청이 폭주하는 사이트에서는 분산 세션 서버를 사용할 것을 권장한다.

1.8. 세션 모니터링

생성된 세션들에 대한 기본적인 모니터링을 통해 현재 서버가 가지고 있는 세션의 개수를 확인할 수 있다.

세션의 모니터링은 다음과 같은 2가지 방법을 통해 가능하다.

이전   다음
안내서에 대하여 처음으로 제2장 분산 세션 서버