System Compleat.

'memcached-session-manager'에 해당되는 글 1건

  1. Session Clustering (2)

Session Clustering

Techs
(younjin.jeong@gmail.com, 정윤진)

친구랑 술을 먹다가, WebLogic 과 Jboss 의 클러스터링 기능 때문에 매년 일정 라이센스 비용을 내고 서비스를 구축한다는 친구의 이야기를 들었다. 그녀석의 조직은 오픈소스를 워낙 겁내서, lighttpd 로 구현한 단순 static 파일 전송용 이미지 서버가 잘 돌아가지 않을까봐 걱정하는 조직에 몸담고 있다.

일이 이정도 되면, apache 를 왜 서비스에 사용하냐고 물어 볼 염두 조차 나지 않게 된다. 당연하겠지만 이런 대부분의 조직의 경우, 지원이 없는 제품을 굉장히 겁내곤 한다. 아... 생각해 보면 굳이 내 돈 들여서 라이센스 구매하는 것도 아닌데 왜 친구랑 박터지게 소맥을 마셔가며 언쟁을 했는지도 모를일이다.

아마도, 내가 웹 개발자가 아니어서 그런 듯.

세션 데이터의 특징을 보자.

1. 한번 쓰여지고, 자주 참조 된다.
2. 만료 시간이 되면 삭제해도 무방하다.
3. 여러대의 서버에서 참조될 가능성이 있다.
4. 데이터의 구조가 간단하다.
5. 전체 데이터를 잃어도 서비스에 크나큰 해악을 끼치는 경우가 드물다.

stateless 가 주가 되는 현대의 많은 웹 서비스들이 있지만, 그렇다고 세션 처리가 필요 없어지는 것은 아니다. 세션을 처리하는 방법에는 다음과 같은 것들이 있다.

1. L4 장치의 도입
2. Cluster 옵션 또는 라이센스가 제공되는 프레임웍 또는 WAS 의 사용
3. memcached / repcached 를 사용하여 각 페이지의 코드레벨에서 세션을 저장, 참조 하는 방법.

memcached

image from: http://wiki.eol.org/display/ITPUB/Memcached+System+Synchronization


대부분의 국내 웹 사이트에서는 L4 를 사용한다. 클라우드에서는 apache 의 모듈 또는 nginx 와 같은 서버가 제공하는 proxy 를 사용하는 경우가 대부분이다. 이런 1~3번 구조와 같은 것들은 이미 그 구성을 다이어그램으로 그리기 조차 민망한 지경이라고 할까.

다만 3번의 경우, 많은 업장에서 그 효용성을 모르는 듯 하다. 지난번의 오픈소스 관련 포스팅에도 썼지만, 3번과 같은 방법을 꺼리는 가장 큰 이유는 보안도 아니고 코딩의 어려움도 아니고 바로 고장나면 누가 고쳐줄건데 의 인식이 제일 큰 듯 하다.

묻고 싶다.

L4 에서 persistent 또는 sticky 로 클라이언트 별 session 을 이미 기억하고, 클라이언트가 접근했던 웹서버로 이미 던져주고 있는데, 왜 WAS 레벨의 session clustering 이 필요한가. 만약 동작중인 WAS 가 사망했을 경우, L4 의 healthcheck 에 의해서 지정한 retry 와 지정한 timeout 이후에 고객은 '다시 로그인' 외에 다른 행위가 없을 텐데. 만약 세션에 기반한 장바구니와 같은 기능을 구현하고 있었다면, 저렴한 WAS의 N 대 만큼의 고객만 다시 로그인 하면 될 일이다.

만약 3번을 통해 구현했다면, L4 에서 굳이 비용을 들여 session state 를 저장할 필요가 없지 않겠는가.

repcached 사용시 multi-master session cache 로서의 사용은 논의가 필요한 부분이라고 볼 수 있다. heartbeat 을 사용한 repcached 의 구현과 같은 것들이 있을 수 있다고 본다. 다만 안타까운 것은, 상용이 아니면 불가능하다고 생각하고, 만약 오픈소스로 구현 했을 때 문제가 발생한 경우 1빠로 '전에 오픈소스로 바꾼거 그게 문제 아냐?' 라고 생각하는 어간없는 상식이 문제가 아닐까.

세션이 은행의 DB 트랜젝션 만큼 중요하다면 돈을 아낌없이 투자해도 할 말은 없다만, 단지 세션때문에 L4 구매하고, WAS의 클러스터 라이센스를 구매하고 있다면 해 줄 말이 없다. 1인 블로그 만들려고 오라클 엔터프라이즈 구매하는 경우랄까..

Cache 를 쓰는 방법에는 여러가지가 있지만, session 이라는 데이터 특성을 잘 고려해 보는 것이 필요할 수 있다. 물론 내가 틀렸을 수도 있지만, 국내의 잘 나가는 쇼핑몰의 세션 공유 처리에 잘 들 사용하는 것을 보면 많이 잘못 되지도 않은 것 같다.

JSP 는 많이 다를까?

음...
 

repcached

image from: http://wiki.eol.org/display/ITPUB/Memcached+System+Synchronization

위와 같은 repcached 의 사용은 애플리케이션 별 검증이 필요하다.

한가지 더, memcached, memcachedb, repcached 등은 단순 세션 처리에만 사용되는 것은 아니다.
그리고, nodejs 짱이더라... 

NCache
http://cgeers.com/2010/07/11/ncache-distributed-in-memory-object-cache/

Nginx Subsystem, NCache
http://code.google.com/p/ncache/
http://code.google.com/p/ncache/wiki/HowToNcacheV3
http://code.google.com/p/ncache/wiki/HowToNcacheV2

Repcached
http://repcached.lab.klab.org/

Memcached
http://memcached.org/

Consistent Hashing
http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html

Terracotta
http://www.terracotta.org/

Java EE scaling article
http://www.theserverside.com/news/1320914/Scaling-Your-Java-EE-Applications-Part-2

Hazelcast ( In Memory Grid )
http://www.hazelcast.com/documentation.jsp

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

PHP session memcached
http://www.ducea.com/2009/06/02/php-sessions-in-memcached/

EHCache
http://ehcache.org/



(younjin.jeong@gmail.com, 정윤진)