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

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

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

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

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

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

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

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

대부분의 국내 웹 사이트에서는 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 의 사용은 애플리케이션 별 검증이 필요하다.

한가지 더, 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, 정윤진)

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


오늘은 세션 공유에 대한 이야기.

윈도우 웹 서버에서 세션을 공유하는 방법은 일전에도 소개 한 바와같이 2가지란다. ( InProcess 의 경우 시스템 하는 사람 기준에는 '공유' 의 방법으로 보이지 않아서 제외 )

하나는 ASP.NET 의 State Service 를 사용하는 방법, 다른 하나는 MSSQL DB를 사용하는 방법.

이 중 두번째 방법은 그냥 그 개념을 생각만 해도 세션 전용의 디비를 두어야 하나 싶을 정도로 고민스러운 방법이라 패스. ( 그 수많은 요청에 의한 세션 정보 열람을 위해 디비에 접근하는 웹서버를 상상해 보시라! )

뭐 아시는 분들은 다 아실만한 이야기 들이지만, 이번에 어찌저찌 하다 보니 보게되어 소개 한다.

웹 서버의 로드밸런싱을 처리하다 보면 세션 공유의 필요성이 발생하게 되는데, 유닉스/리눅스 기반에서는 jsp 라면 웹로직이나 기타 WAS 의 도움을 받는 경우가 대부분이고, php 등은 memcached 를 사용하거나 NFS(?) 를 사용하는 등의 방법이 많다.  여기에 고객의 수가 증가하게 되면서 보다 안정적인 서비스로 가기위해서는 이 세션 공유 서버에 대한 복제 등이 지원이 되어야 하는데, asp state service 는 여기까지는 지원을 하지 않는 듯 하다.

대략적인  IIS 의 Session State 의 동작에 대한 다이어그램은 다음과 같다.



대체 Session State 라는게 뭐냐? 라는 점이 궁금하신 분은,  닷넷 개발자면 아주 잘 아는 내용을 억지로 시스템하는 사람이 번역한 아래의 내용을 참조 하시면 되겠다.  물론, 충분한 이해를 바탕으로 한 것이 아니기 때문에 뭔가 알맹이-껍데기 스러운 번역이기에 괜히 머리 복잡해 지기 싫으신 분은 안펼쳐도 무방하겠다.  lol (나중에 현희형이 감수 및 이해를 도와주면 보다 윤기가 흐르는 번역이 될지도... 퍽!!@!! )


더보기

아무튼, 본 서비스를 사용하여 윈도우 서버의 세션 공유는 다음의 순서로 적용할 수 있다. ( Windows 2008 서버 이상 기준 )

1. 서비스 설치
  서비스의 설치는, 다른 윈도우 구성요소와 마찬가지로 윈도우 Feature 추가에서 쉽게 찾을 수 있다.

2. 서비스의 구동.
  서비스를 구동하고 netstat -na 를 통해 바인딩 된 포트 및 주소를 확인 해 보면,
  127.0.0.1:42424 
  로 리스닝 하는 것을 볼 수 있다.

  당연히 많은 서버의 로드 밸런싱에 사용 할 것이므로, 로컬 호스트 리스닝은 의미 없다.  다음의 레지스트리를 수정하여
  바인딩 되는 주소를 변경하도록 한다.
 
  HKML\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnections
  의 값을 0에서 1로 변경하고 서비스를 재시작 후, netstat -na 를 다시 찍어 보면
  0.0.0.0:42424
  를 확인 가능하다.

  물론, 이때 외부에서 해당 포트로 접근을 시도하면 당삼 안된다.  윈도우 방화벽의 Inbound 에 해당 포트 규칙을
  추가하자.  이후 타 서버에서 정상적으로 접근이 가능하다면, 설정 완료.

  + 다음의 설정 값을 통해 포트도 변경이 가능하다.
  HKML\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

  

3. 웹 서버들이 state 서버를 사용하도록 설정 ( web.config )



4. 윈도우에서 세션을 공유하기 위해서는 몇가지 주의 해야 할 사항이 있다.
  a. ASP.NET 의 <machineKey> 설정이 로드밸런싱 되는 모든 웹 서버에서 동일해야 한다. 
      <machineKey> 에 대한 자세한 설정은 다음의 링크를 참조 한다.
       http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx
  b. 운용 중 웹 팜에서 세션 상태가 손실 되는 경우.
      - IIS 의 메타베이스 에서 응용프로그램의 경로가 모두 동일해야  함.  ( IIS 메타베이스의 확인 및 수정 방법 클릭 )
      - IIS 의 메타베이스 백업 및 복구 방법


방법이 약간 복잡하거나, IIS 로 서비스 하는 경우 보통 Stand Alone 서버의 소규모 사업장이 많지만, 이러한 .NET 기반의 서비스가 확장 되는 경우에 대비하여 간단한 테스트를 통해 사전에 확장 가능한 방법에 대한 고려가 필요하겠다.

보다 대규모가 되는 경우, DFS 등에 대한 고려 역시 따라야 할 것.



본 포스팅을 위해 참조된 링크.

http://msdn.microsoft.com/en-us/library/aa479041.aspx#aspnetsessionstate_topic2
http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state).aspx
http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx
http://support.microsoft.com/kb/325056
http://support.microsoft.com/kb/240225/
http://support.microsoft.com/kb/302573/
http://msdn.microsoft.com/en-us/library/aa227609(VS.60).aspx


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