WAS간 세션공유
*** 사용자 인증여부만 참조할 경우
1. 쿠키에 사용자 키 저장
2. DB에 WAS간 세션아이디 매핑 테이블을 두어 상태 참조 등등
*** 세션에 많은 객체를 담아 상태를 유지할 필요가 있는 경우
1. 세션 클러스터링 구현
*** 발췌
========================================================================================
가장 단순한 방법은 Cookie를 이용하시고, 실질적인 정보는 DB에 저장하시어
두 머신이 공유하는 방법일 거라 생각 됩니다.
예를 들어 한 머신에서 Login을 하면 그 정보가 DB에 기록되고, Cookie에
특별한 자신만의 고유한 session_id를 발생시킨 후, 다른 머신으로 변환될 경우
DB에서 session_id에 해당하는 정보를 DB에서 Query해서 "아하, 이 Client는
이미 로그인 했었군"이라 판단할 수 있겠지요....
(단, Cookie는 모든 머신으로 날아갈 수 있게 도메인이 셋팅되어야 할 것이고,
session_id는 서블렛엔진의 기본적인 세션이 아니라, 비즈니스적으로 만들어진
임의의 것이어야 합니다.)
그러나, 이것은 user_id에 대해서만 공유될 수 있을 뿐, Servlet의 Session 에
저장된 여하한의 java Object에 대해서는 적용받을 수 없겠지요....
기능상의 제한이 있게 마련입니다.
========================================================================================
javax.servlet.http.HttpSession을 의미하시는지요? 그렇다면, 정확히는 WAS 에서 세션클러스터링을
지원해야 합니다.. 그렇지 않고서는.. 개발자가 세션클러스터링을 구현해야 겠죠..
Naming Service 같은걸 이용해서. 근데,, 그게 쉬운일 같아 보이지는 않습니다.
두 머신상의 세션의 동기화 문제랄지 그런부분이 아주 골치아플것입니다.. 특히 이것은 앞단에
L4 의 세션이 sticky 하지 않아서 request가 왔다 갔다 할수 있는 상황에서 문제겠지요..
========================================================================================
http://blog.naver.com/kyt0223.do?Redirect=Log&logNo=20017526292
몇몇 사이트에서, "세션유지기능"을 직접 제작하는 분들을 보았습니다. cookie에
key값을 생성하여 담고, key값을 이용해 static java.util.Hashtable에 넣고 빼는 방법으로
자체 제작하는 하는 것이지요.
혹은, 몇 명이 접속하였는지를 보기 위해, "접속자를 모니터링하기 위한 용도"로 이러한
시도를 하시곤 합니다.
이 분들이 종종 놓치는 부분 중의 하나는, H/W머신(혹은 하나의 인스턴스)가 하나일
뿐이라는 가정을 하는 경향이 있다는 겁니다. 부하량이 늘어나 여러대의 서버로 확장할
경우, 원격의 인스턴스간의 데이타를 공유할 수 있도록 클라이언트/서버 구조의 TCP/IP
Socket/RMI를 사용할까, 데이타베이스를 경유해버릴까 등의 고민이 시작되고,
MOM(Message Oriented Middleware)를 사용하거나 simple MOM 를 TCP/IP로 구현해 볼까도
생각합니다.
하나의 서버에 담겨 있는 Hashtable의 값을 다른 서버에게 publish/subscribe방식으로
공유케 하는 것이지요. 실시간 변경된 값을 전달해 줄까, 아니는 주기적으로 전달해
줄까를 고민합니다. 또한 늘어만 가는 Hashtable의 데이타를 session timeout과 같은
기능을 어떻게 효율적으로 구현할까를 고민하게 됩니다.
.....이쯤되면, "잉, WAS(Web Application Server)의 Http Session Clustering 기능을
만들고 있군..."라는 최종적인 결론에 도달합니다.
이미 적용되어 있던 자체 제작된 기능을 나중에 여러대의 서버로 확장운영될 시점에
구조적인 문제나 성능상의 이슈로 결국 제거됩니다. (3곳 정도의 고객사에서 그러한
상황을 목격했습니다.)
J2EE스펙에서는 동일한 WAR(Web ARchive)내에서만 HTTP Session이 유지됩니다.
일부 WAS는 동일한 EAR(Enterprise ARchive)내에 존재하는 여러개의 WAR간에도
세션클러스터링을 지원합니다. (하나의 EAR에는 여러개의 WAR 및 EJB-jar가 존재할 수
있고, EAR단위로 서버(Server,인스턴스)에 deploy되는데, 서버는 인스턴스가 하나일
수도 있고, 여러대의 H/W박스에 분산되어 여러대의 Server(인스턴스) 클러스터일 수도
있습니다.)
========================================================================================
http://www.javaservice.net/~java/bbs/read.cgi?m=qna&b=consult&c=r_p&n=959681361
질문하신 분도 지적한 바와 같이 당연히 떠오르는 문제가 바로 "세션클러스터링"
입니다. 여러 머신으로 운영할 때, 한 머신에 접속했다가 다른 머신으로 부하분산
메카니즘에 의해 다른머신으로 Request가 이동되면, 기존 머신에서 저장시켜둔
각종 "세션정보", 예를 들어, UserID, 자신이 선택한 Shopping Items 등이 그대로
머신과 머신사이에서 유지되어야 한다는 것이지요...
IBM WebSphere Application, BEA WebLogic, SilverStream Application 등등은
각기 고유한 방식으로 이러한 세션 클러스트링 기능을 제공합니다.
(세션클러스트링은 스펙이 존재하는 것이 아니기에 Vendor 고유한 방식으로
Implementation 됩니다.)
IBM WebSphere Application Server의 경우, Version 2.0.x 역시 세션클러스트링을
제공하며, Version 3.0.x에선 DB를 이용하여 "Persistent Session" 기능을 제공합니다.
보통 Memory상에서 세션정보를 갖게 하는 것이 일반적이지만, file을 이용하기도하고,
DB를 이용하기도 합니다.
========================================================================================
http://www.dev2dev.co.kr/pub/a/2005/05/session_management.jsp
세션 속성을 여러 JVM에서 처리하려면 세션 속성을 serialize할 수 있어야 합니다. 이것은 클러스터링
요구 사항입니다.
세션 속성의 일부 필드를 transient로 선언하여 논-클러스터(non-clustered)로 만들 수 있습니다.
그러면 세션 속성의 모든 필드를 serialize할 수 있어야 하는 요구 사항이 없어지는 반면 이러한 속성이
백업 서버로 완전히 복제되지 않을 것임을 의미하기도 합니다. 이러한 접근 방법을 따르는 개발자는
이 속성 필드가 상실되더라도 애플리케이션이 일관된 방식으로 작동될 수 있도록 아주 신중하게 해야 합니다.
대부분의 경우 이러한 접근 방법은 단순히 모든 세션 속성을 serialize할 수 있는 객체로 변환하는 것보다
마무리가 좀 더 복잡합니다. 하지만 세션에서 아주 방대한 양의 사용자별 데이터를 캐시하는 경우 유용한
패턴일 수 있습니다.
J2EE 서블릿 사양(버전 2.2, 2.3 및 2.4)은 클러스터에서 공유해서는 안되는 서블릿 컨텍스트에 대해 설명합니다.
WebLogic Server는 기술된 대로 이 사양을 구현합니다. 싱글톤(singleton) 데이터 구조로서 서블릿 컨텍스트에
의존하는 논-클러스터(non-clustered) 애플리케이션을 클러스터 환경으로 이동하면 포팅 문제가 발생합니다.
일반적으로 애플리케이션이 J2EE 사양을 따르도록 하는 것이 모든 개발자 팀의 목표여야 함에도 불구하고
Coherence*Web은 클러스터 컨텍스트 옵션을 지원합니다.
클러스터 환경에서 발생하는 보다 미묘한 문제는 객체 공유 문제입니다. 논-클러스터(non-clustered)
응용 프로그램에서 두 세션 속성이 공통 객체를 참조하는 경우 공유 객체를 변경하면 두 세션 속성의 일부로서
표시됩니다. 그러나 이것은 클러스터 애플리케이션에서 흔한 경우는 아닙니다. 컴퓨팅 리소스의 불필요한 사용을
막기 위해 대부분 세션 관리 구현은 요청 시 세션 속성을 개별적으로 serialize 및 deserialize합니다.
WebLogic Server와 Coherence*Web(Traditional 및 Split 세션 모델)은 모두 기본적으로 이런 방식으로 작동합니다.
공통 객체를 참조하는 두 세션 속성을 개별적으로 deserialize하면 공유된 공통 객체는 두 번 인스턴스화됩니다.
공유 객체 동작에 의존하고 쉽게 수정할 수 없는 애플리케이션의 경우, Coherence*Web은 전체 세션 객체를
단일 동작으로 serialize 및 deserialize하는 Monolithic 세션 모델 옵션을 제공합니다. 그러면 처음부터 클러스터링을
염두에 두지 않고 설계된 애플리케이션에 대한 호환성이 제공됩니다.
========================================================================================
| |