대용량 서비스에서의 Tomcat Session Clustering의 한계?

1. jsession id를 가지고 서버 요청을 하게 되면, jsession id를 기반으로 하는 데이터(영속성 데이터)를 각 jvm에서 알아야 하니 session 데이터가 클 경우에 대해서는 각 jvm 에서 session copy해야하는 overhead가 존재한다.

1) 만약 쿠키 용량이 5Kb이면, 자바 웹 서버인경우 String으로 변환하면서 약 120kb가 될 것이다. 사용자가 많은 경우, 몰리는 경우에 session copy overhead가 서버에서 감수해야 한다. Session Clustering 하다가 OOME가 날 가능성이 많다.
2) 서버가 많으면 많을수록 Session Clustering하는 비용은 커진다. 반복작업임..
 

2. L4에서도 jsession id를 이용한 L4 sticky bit로 활용해야 하니, L4에 부담이 된다.

3. 장애시 또는 동시 restart가 되는 경우에는 다시 session을 만들어야 할 상황이 생긴다.
 -> 로그인을 다시 해야 하는 상황이 발생한다..

4. multicast (udp)방식이기 때문에 방화벽을 신경써야 한다.

5. multicast 을 지원하는 네트워크 카드가 필요하다.

대용량 서비스의 경우에는 세션관리비용보다는 cookie기반이 훨씬 서버에 영향을 덜 주게 되며, 고민은 적게 할 수 있다.

Persistent한 사용자 정보는 DB나 캐쉬서버를 이용하면 된다.