Session clustering 기능 구현을 위한 WAS 선택에 기로 ...

[eager20]

안녕하십니까. 다들 잘 지내지종 ^^ 너무 오래간만에 안건을 올리네요.

제가 신규 프로젝트를 진행하는데 WAS 세션 클러스터링으로 구축하려고 하는데, 기존 상업 WAS (웹로직, 웹스피어)를 사용을 못하고....

오픈 소스 tomcat, jboss로 세션 클러스티링을 구축하려고 합니다.

일부 사람들은 불안하다라는 의견이 있고 해서....

회원분들의 경험이 필요해서 글을 올립니다. 

1. 우선 오픈소스 WAS를 구축 했을때 세션 클러스터링 경험 및 운영 이 어떤지에 대한질문!!!

2. 오프소스 WAS (jboss, tomcat...) 어떤것으로 구축 했을때 더 안정적인가?!!!

  - 찾아보니 jboss 안에 jsp/servlet 엔지는 톰켓이라고 하지만 ^^;;

  - 더 좋은 WAS가 있다면 알려주시면 감사하겠습니다. ^^

갑자기 추워진 여름에 감기 조심하시구요. 답변 부탁드리겠습니다. ^---------------^

[JeongHyeon Lee]

http://code.google.com/p/memcached-session-manager/

memcached 와 연동하여 세션 클러스터 추천 합니다.

2012년 8월 24일 오후 2:37, eager20 <eag...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
웹에서 이 토론을 보려면 https://groups.google.com/d/msg/ksug/-/XFa4ejDMPRsJ을(를) 방문하세요.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[eager20]

넵 감사합니다.

말씀하신 모듈을 확인해 봐야 할것 같습니다. ^-^ 

[임은철]

tomcat으로 세션 클러스터링 하시는게 편할것 같네요. 메뉴얼도 잘 나와 있고 해본 사람도 많을 것 같아요.

지금 저희 회사에서도 3개의 tomcat에 클러스터링해서 서비스중이구요.

로드밸런싱은 아파치로 하고 있습니다.

 

일부 사람이 톰캣은 불안하다고 하셨다는데요. 뭐가 불안한지는 잘 모르겠는데 다른 상용 WAS보다는 불안요소가 더 없을겁니다.

그만큼 버그가 있다하더라도 패치가 워낙 빠르게 되다보니 큰 문제 없습니다.

 

톰캣의 세션 클러스터링! 잘되도 너무~  너~~무 잘되요.

2012년 8월 28일 오전 10:23, eager20 <eag...@gmail.com>님의 말:

넵 감사합니다.

말씀하신 모듈을 확인해 봐야 할것 같습니다. ^-^ 

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

웹에서 이 토론을 보려면 https://groups.google.com/d/msg/ksug/-/VzT3XH3ziQQJ을(를) 방문하세요.

[KwonNam Son]

톰캣 자체 클러스터링은 서버가 20대 정도 될 때도 잘 될까요?
서버가 5대 미만이라면 괜찮을것 같긴 한데, 댓수가 늘어나면 서로간의 싱크를 맞추다가 성능이 떨어질듯한 느낌이 드는데요... (느낌입니다. 확신이아니라)

아무튼 제 생각엔 서버 댓수에 따라 선택이 달라져야 할것 같습니다.

저는 이런것 때문에 서버대수가 적으면 오히려 수년에 걸쳐 검증된 톰캣 세션 클러스터링을,

서버대수가 많을 경우  memcached 클러스터링이 낫지 않을까 싶은데요. 문제는 memecached 기반이 안정성이 검증됐는지를 모르겠네요..

2012년 8월 30일 오전 9:35, 임은철 <rcn...@gmail.com>님의 말:

--
* 까먹지말자! http://kwon37xi.egloos.com

[Sungchul Park]

제가 모든 솔루션을 다 비교해 본 경험이나 데이터가 없으니 믿을만하지 않지만 그냥 아는 한도 내에서 의견을 드립니다.

1) Tomcat Session Clustering vs Jboss Session Clustering

Tomcat은 자체 통신 프레임워크인 Tribes를 사용하고 Jboss는 자체 캐시인 JBoss Cache를 Tomcat의 Http Session Clutering에 사용할 수 있습니다. 저 Jboss 쪽이 설정으로 더 정밀하게 제어할 수 있을 뿐 아니라 모니터링에도 유리하며 클러스터의 노드 숫자가 많아질 때 훨씬 신뢰할 수 있다고 생각합니다.

2) 톰켓이 불안하다

이런 종류의 소문은 근거가 분명하지 않다면 그리 신경쓰지 않아도 됩니다. 시스템에 장애가 생기는 요인은 상당히 많은 데 근거 없이 특정 기능 때문이라고 생각하는 사람이 많기도 하고 특정 버전에서 생겼던 문제인데 수정된 한참 후에도 살아 남아 유통되기도 합니다.
대표적인 것이 Tomcat 3인데요. 이 때 Tomcat 성능이 무지 안 좋아서 상용 WAS 장사꾼들이 오픈소스는 느려서 못 쓴다고 말하고 다녔는데 그 후에도 계속 Tomcat은 느려서 못 쓴단 얘기가 돌고 있죠.

3) Memcached session manager

Tomcat과 Jboss Session Clustering이 P2P 방식인 반면에 Memcached session manager는 중앙 집중식입니다. 그래서 복잡한 P2P에 비해 장애가 생길 가능성이 낮고 문제가 생겨도 단순하지만 단일 지점 장애(Single Point Failure)가 생기지 않도록 memcached farm을 잘 구성하고 운영하셔야 합니다.

원래 이 기술은 sticky 세션으로 운영하다가 장애가 생겨서 Tomcat이 내려갈 때 세션 값을 저장했다가 다른 Tomcat이 읽어가게 하는 용도로 만들어졌는데 최근에 non-sticky 세션에서도 사용할 수 있게 개선되었습니다.

4) Sticky Session

최초 접속시에는 클러스터 중 한 노드로 할당되고 그 후 접속부터는 해당 서버로만 접속하기 때문에 세션 클러스터링이 필요 없는 구성입니다. 서버 구성이 단순하지만 장애가 발생할 때 memcached session manager 같은 기술로 저장했던 세션 정보를 클러스터에 있는 타 노드로 복사하지 않으면 세션 정보가 사라지게 됩니다.
그리고 전체 서비스의 세션 수가 부하 분산기 용량은 넘어서면 부하 분산기가 정상으로 작동하지 않습니다. L4 부하 분산기 보다는 L7 부하 분산기나 Application Layer Proxy를 사용하는 것이 좋습니다.

이상의 내용을 근거로 제 의견은

• 부하 분산기 용량이 충분하다고 장애가 생겼을 때 세션이 날아가 상황(=로그아웃이 되는 상황)이 큰 문제가 아니라면 그냥 Sticky Session을 쓴다.
• 부하 분산기 용량이 충분하고 장애시 세션이 유지되어야 한다면 Sticky Session과 소규모(노드 수 2-3) Clustering을 사용한다.
• 기존에 Memcached farm을 운영하거나 운영할 수 있다면 Sticky Session + Memcached session manager를 쓴다.
  
• Sticky Session을 못 쓰고 노드 수가 많지 않다면 (그리고 Jboss에 익숙하지 않다면) Tomcat의 Session Clustering을 쓴다. 
• Sticky Session을 못 쓰고 노드 수가 많거나 관리 기능이 중요하다면 Jboss를 쓴다.

제 경험상 memcached는 신뢰도가 그리 높지 않아서 non-sticky session + memcached session manager는 조심스럽네요.

결국 전 최대한 단순한 구조로 가자는 생각입니다.

그리고 Scale out을 생각한다면 Session은 최대한 적게 사용하도록 하는 게 좋습니다. 위 어떤 방법으로 가더라도 session을 과도하게 사용하는 무책임한 방식은 피하는 게 좋겠죠.

12. 8. 30. 오후 12:12, KwonNam Son 쓴 글:

톰캣 자체 클러스터링은 서버가 20대 정도 될 때도 잘 될까요?
서버가 5대 미만이라면 괜찮을것 같긴 한데, 댓수가 늘어나면 서로간의 싱크를 맞추다가 성능이 떨어질듯한 느낌이 드는데요... (느낌입니다. 확신이아니라)

아무튼 제 생각엔 서버 댓수에 따라 선택이 달라져야 할것 같습니다.

저는 이런것 때문에 서버대수가 적으면 오히려 수년에 걸쳐 검증된 톰캣 세션 클러스터링을,

서버대수가 많을 경우  memcached 클러스터링이 낫지 않을까 싶은데요. 문제는 memecached 기반이 안정성이 검증됐는지를 모르겠네요..

2012년 8월 30일 오전 9:35, 임은철 <rcn...@gmail.com>님 의 말:

tomcat으로 세션 클러스터링 하시는게 편할것 같네요. 메뉴얼도 잘 나와 있고 해본 사람도 많을 것 같아요.

지금 저희 회사에서도 3개의 tomcat에 클러스터링해서 서비스중이구요.

로드밸런싱은 아파치로 하고 있습니다.

 

일부 사람이 톰캣은 불안하다고 하셨다는데요. 뭐가 불안한지는 잘 모르겠는데 다른 상용 WAS보다는 불안요소가 더 없을겁니다.

그만큼 버그가 있다하더라도 패치가 워낙 빠르게 되다보니 큰 문제 없습니다.

 

톰캣의 세션 클러스터링! 잘되도 너무~  너~~무 잘되요.

2012년 8월 28일 오전 10:23, eager20 <eag...@gmail.com>님 의 말:

넵 감사합니다.

말씀하신 모듈을 확인해 봐야 할것 같습니다. ^-^ 

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

웹에서 이 토론을 보려면 https://groups.google.com/d/msg/ksug/-/VzT3XH3ziQQJ을 (를) 방문하세요.

이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

[Sanghyuk Jung]

와...저도 최근 비슷한 문제로 고민을 했었는데, 역시 성철 고문님 최고입니다~

2012년 8월 30일 오후 1:57, Sungchul Park <gyu...@gmail.com>님의 말:

[이재일]

session less한 구현을 하면 session을 clustering하는 비용도 없을텐데요. 자주 접하는 일이지만, 과연 session less한 개발은 어려운것일까요?

2012년 8월 30일 오후 2:56, Sanghyuk Jung <ben...@gmail.com>님의 말:

[Sungchul Park]

@이권재: 전문적인 건 아닙니다. 그냥 검증되지 않은 제 생각일 뿐입니다. (그리고 이 오타 작렬 어쩔...)

@정상혁: 고민한 결과가 어떤지 궁금하네요. 공유해주세요. 상혁님처럼 치밀한 분은 뭔가 더 신뢰할만한 결과를 얻을셨을 것 같은...

@이재일: Stateless겠죠. ㅋㅋ stateless라고 해도 로그인 상태 정도는 session에 남기는 편이 좋은 것 같습니다. 쿠키를 암호화해서 처리하는 방법도 있지만 상대적으로 보안이 취약할 것 같네요.


12. 8. 30. 오후 3:29, 이재일 쓴 글:

session less한 구현을 하면 session을 clustering하는 비용도 없을텐데요. 자주 접하는 일이지만, 과연 session less한 개발은 어려운것일까요?

2012년 8월 30일 오후 2:56, Sanghyuk Jung <ben...@gmail.com>님 의 말:

와...저도 최근 비슷한 문제로 고민을 했었는데, 역시 성철 고문님 최고입니다~

2012년 8월 30일 오후 1:57, Sungchul Park <gyu...@gmail.com>님 의 말:

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
* 까먹지말자! http://kwon37xi.egloos.com
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com /group/ksug?hl=ko에서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--

[Sanghyuk Jung]

아 깊이 고민한건 아니였고, 기존에 JBOSS를 쓰고 있던 고객사라서 그냥 JBOSS로 가기로 했습니다..;  즉  Tomcat의 session clustering이 더 나은점이 있다..를  주장하지 않는다면 하던데로 해야하는 분위기였어요 ^^;   

프로젝트 끝난 다음에는 좀 더 공유드릴 내용이 많아질것 같네요 

2012년 8월 30일 오후 3:33, Sungchul Park <gyu...@gmail.com>님의 말:

[Jisung Ahn]

제가 있는 사이트에서는 제우스를 사용중인데, 비용문제로 세션 클러스터 엔진을 라이센스 하지 않았습니다.....

그리고 메모리 캐시류는 써본적 없으니 불안해서 사용하지 않는다고 선언한 고객때문에...

암호화된 쿠키를 세션처럼 사용하는 메커니즘을 구현하여 사용중입니다.  

객체 -> JSON 문자열-> 암호화 -> BASE64 해서 쿠키에 넣고 읽을때는 반대로. 

객체를 직접 담지 않는 이유는, 추후 클래스 버전 차이로 인한 오류를 방지하기 위해서 였습니다. 

암복호화에 따른 CPU 소비/덩치큰 쿠키로 인한 네트워크 소비 가 단점이긴 합니다만, 

장점으로는 WAS가 몇대로 늘어 나도 상관없다는 게 있겠네요. 

2012년 8월 30일 오후 4:25, Sanghyuk Jung <ben...@gmail.com>님의 말: