기록이 기억을 지배한다.

0.

“Maserati Problem"이라고 있다. 차에 별로 관심이 없어 내 눈에는 "주차하기 어려워 보이는 차"일 뿐이긴 하지만 무지 좋고 비싼 차인가보다. 왠지 유명한 알고리즘 문제일 것 같지만 그런건 아니고, 마세라티 문제는 ‘네가 마세라티를 탈 때쯤 걱정하게 될 문제'를 말한다. 즉 당장은 커녕 영원히 걱정 안해도 될지 모르는 문제인 것이다.

1.

극단적인 예를 들자면 이런 것이 있겠다. 간단한 웹 어플리케이션을 하나 만들었는데 개발자 입장에서는 이게 영 마음에 안드는 것이다. 동시접속자가 100만명이 되면 어떻게 하지 하는 마음에 좋다고 소문난 언어를 배워서 서버를 죄다 갈아엎는다. "어느어느 유명한 서비스가 하둡을 쓴다는데!” 이러면서 생전 본적도 없는 하둡을 갑자기 공부해서 어설프게 쓰기 시작한다. “Fault-tolerance는 기본이지"라면서 서버를 두 배로 박고 그 사이에 자동으로 failover를 하는 시스템을 만든다. 또 왠지 새로운 임의의 기능을 추가하게 될 것 같은데 그게 뭐가 될지는 모르겠어서 "기능을 추가하는 기능”, 즉 플러그인 시스템을 만들기도 한다. 기존에 파는 인트라넷 서비스는 왠지 어설프고 마음에 안드는 부분이 있어서 인트라넷과 관리페이지도 직접 만들고 소스코드 관리까지 완벽히 연동한다. 이 모든걸 2~4주씩 걸려서 만든다.

2.

하지만 현실은 하루에 30명정도 들어 오는 웹사이트일 뿐이다. 개발자는 뭔가 잘못되었다는 생각을 한다. 내 코드는 완벽했는데 기획이, 마케팅이, 아무튼 뭔가 다른 것들이 잘못 돌아가고 있다고 생각을 한다. 그러면서 개발자는 또 이런이런 기술이 뜬다는 이야기를 어딘가에서 줏어듣고는 신기술을 적용하는 데에 집중한다…

3.

이런 경향은 코딩 좀 한다는 개발자들이 의기투합하여 스타트업을 만들었을 때도 자주 나타난다. 뭔가를 만들어보려 했더니 코드에 문제가 있고 프레임웍을 갈아엎는다. 기술조사를 하는 시간이 부족해서 그랬다고 생각하고 그 시간을 확보하지만 그 사이에 핫한 기술은 다른 것으로 바뀌어 있다. 그래서 또 갈아엎는다. 그러다 파트타임으로 일하던 동료들은 한명 한명 자신의 사정이 생기고 지금까지만큼 회사에 시간을 투자하기 어렵게 된다. 그리고 자연스럽게 회사는 이름만 남고 사라진다. (그래도 그 결과물로 괜찮은 오픈소스 프로젝트가 나올 때가 있으니, 기술은 아무것도 모르고 경영동아리같은거 하다가 나도 스타트업이나 해볼까 하고 아무 개발자나 구해다 망하는 스타트업보다는 사회에 기여하는 바가 있다 하겠다..)

4.

동접 백만명은 동접 십만명이나 됐을 때 슬슬 걱정하라는게 마세라티 문제가 주는 메세지다. 일단 중요한건 만드는거다. 익숙하지 않은 시스템을 쓰기보다는 그냥 쓰던 것을 쓰고 기한 맞춰 빠르게 개발하는 것이 더 낫다는 생각을 한다. “전 PHP밖에 안해봤는데 PHP가 그렇게 안좋고 파이썬이 그렇게 좋다면서요?”…그냥 파이썬은 틈날때 들여다 보시고 PHP로 하시라. “요즘 NoSQL이 뜨고 있는데 MySQL밖에 모르지만 NoSQL을 써야 할까요?”…그냥 MongoDB는 마음 맞는 사람들과 스터디나 하시고 MySQL 쓰시라. 나중에 서비스가 정말 흥하면 피곤해지지 않겠느냐고? 물론 피곤할 것이다. 하지만 그때는 훨씬 행복하고 풍족하게 피곤할 수 있을 것이다.

ps. 눈치채셨겠지만 당연히 이 포스트는 자아비판이기도 하다…

주로 회사나 대학 등에서 자산관리 시 보안용으로 사용하는 프로그램입니다.

예를 들어 특정 프로그램을 못 깔게 한다거나, (비인가 유료 프로그램 등)

네트워크를 차단시킬 수도 있죠.

그래서 이 녀석을 강제로 종료하거나 삭제하기가 매우 번거롭게

되어있습니다.  이 때문에 정상적으로 PC가 작동 안하는 경우가 많이 발생하죠.

삭제 방법 공유 드립니다. (첨부파일 참조)

netclient5-uninstaller.zip

 정리 및 출처

-         세션 복제 사용 여부

-         세션 변경 여부(dirty check) 기 준

-         세션 복제 단위

-         세션 복제 시점

-         세션 복제 메시지 전송 방식

1) 세션 복제 사용 여부

WAS에서는 각 모듈 별로 분산 혹은 클러스터링 여부를 설정할 수 있도록 하고 있습니다.

특히 웹 어플리케이션의 경우에는 web.xml에서 <distributable/>을 설정해 표준적인 방법으로 클러스터링을 설정합니다.

WEB-INF/web.xml

<web-app>

   <distributable/>

   … …

</web-app>

(*) 서버 상에 클러스터링 설정을 잘 했어도 정작 웹 어플리케이션에 이 설정을 하지 않으면 세션 복제는 일어나지 않습니다.

2) 세션 변경 여부 기준

JBoss Clustering 세 션 관리자는 HTTP 요청 처리 후 변경된 세션을 클러스터를 구성하는 각 노드로 복제합니다.

그렇다면 세션 관리자는 어떻게 세션이 변경되었는지 알 수 있을까요?

가장 쉬운 방법은 프로그램에서 session.setAttribute()를 호출하면 세션이 변경된 것으로 간주하는 것입니다.

UserInfo user = session.getAttribute("user");

// user 정보 변경

session.setAttribute("user", user);

JBoss를 비롯한 대부분의 WAS는 이 방법을 지원합니다.

그런데 JBoss에 서 이 방식이 기본설정이 아니므로 이 방식을 사용하기 위해서는 해당 웹어플리케이션의 JBoss Deployment Descriptor에 추가적인 설정이 필요합니다.

WEB-INF/jboss-web.xml

<jboss-web>

   <replication-config>

      <replication-trigger>SET</replication-trigger>

      <replication-granularity>SESSION</replication-granularity>

   </replication-config>

</jboss-web>

JBoss에서 지원하는 세션 변경 여부 판단 기준은 다음과 같습니다.

SET_AND_NON_PRIMITIVE_GET은 개발자가 세션에서 객체를 가져와 변경한 후 setAttribute()를 해주지 않는 경우를 위한 것입니다.

이는 SET_AND_GET과 유사하지만 Integer나 String과 같이 변경 불가능한 객체에 대해서는 변경으로 간주하지 않는다는 차이가 있습니다.

주로 클러스터링을 고려하지 않고 단독 서버 용으로 개발된 어플리케이션을 클러스터 상에 디플로이할 때 사용합니다.

(*) 프로그램 상에 위와 같은 문제가 없다면 replication-trigger를 SET으 로 설정하는 것이 가장 좋습니다.

3) 세션 복제 단위

변경된 세션을 클러스터상의 각 노드로 복제할 때 가장 단순한 방법은 세션을 통째로 복제하는 것입니다.

하지만 변경된 부분만 복제한다면 전송량을 줄일 수 있어 성능이 향상될 것입니다.

JBoss는 상황에 따라 선택할 수 있도록3가지 복제 단위를 지원합니다.

SESSION à ATTRIBUTE à FIELD 순으로 복제 단위는 더 세분화됩니다. 그런데 복제 단위를 세분화하는데 따르는 오버헤드가 있기 때문에 단순히 세분화할수록 좋은 것은 아닙니다.

통상 세션 크기가 5K 이하라면 세션을 통째로 복제하는 것이 가장 효율적입니다.

세션 크기가 그 이상이고 일부 attribute만 변경이 잦은 경우라면 ATTRIBUTE를 선택할 수 있습니다.

세션이 아주 크고, attrribute의 특정 필드만 변경이 잦은 경우라면 FIELD를 선택할 수 있습니다.

주의할 점은 그 변경되는 attribute 또는 필드가 세션 크기의 대부분을 차지한다면 전송량 자체가 줄지 않으므로 전혀 이점이 없겠죠.

WEB-INF/jboss-web.xml

<jboss-web>

   <replication-config>

      <replication-trigger>SET</replication-trigger>

      <replication-granularity>SESSION</replication-granularity>

   </replication-config>

</jboss-web>

4) 세션 복제 시점

JBoss는 세션의 변경 사항을 즉시 (instant) 또는 일정 간격 (interval)으로 복제할 수 있습니다.

기본값은 instant로 Tomcat 서비스에 설정되어 있습니다.

deploy/jboss-web.deployer/META-INF/jboss-service.xml

<attribute name="SnapshotMode">instant</attribute>

<attribute name="SnapshotInterval">2000</attribute>

SnapshotMode를 interval로 설정할 경우에는 추가적으로 SnapshotInterval 값으로 복제 주기를 ms 단위로 설정할 수 있습니다.

만약 주기를 30초 로 잡으면 그 사이에 장애가 발생할 경우 변경된 세션 정보를 잃어버리게 됩니다.

(*) 특별히 세션 정보를 잃어버려도 되는 상황이 아니라면 instant를 그대로 두는게 안전합니다.

5) 세션 복제 메시지 전송 방식

세션이 변경되어 클러스터상의 각 노드로 세션을 전송할 때에는 각 노드로부터 전송이 완료되었다는 ACK를 받을 때까지 기다리는 동기 방식 (REPL_SYNC) 과 그냥 큐에 넣어두고 별도 쓰레드에서 전송을 처리하는 비동기 방식 (REPL_ASYNC)을 선택할 수 있습니다.

기본값은 REPL_ASYNC로 Tomcat 클러스터 서비스에 설정되어 있습니다.

deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml

<attribute name="CacheMode">REPL_ASYNC</attribute>

ShapshotMode와 CacheMode를 함께 생각해보면 기본값 조합에서는 HTTP 요청을 처리한 후 세션이 변경되었으면 바로 각 노드로 세션을 복제하도록 메시지를 큐에 넣고 Servlet/JSP 수 행을 끝냅니다. 결국 클라이언트에게 응답이 간 시점에 세션 복제가 완료되었는지 장담할 수 없습니다.

만약 세션 복제가 이루어지기 전에 클라이언트가 다시 HTTP 요청을 했는데, 이 HTTP 요청이 다른 노드로 전달될 경우에는, 예 전 세션을 가지고 처리하는 문제가 발생할 수 있습니다.

이 때문에 JBoss 클러스터링 기본 설정을 그대로 사용할 경우에는 반드시 Sticky 로 드 밸런싱을 설정해 요청이 계속 세션이 생성된 노드로 가도록 해야 합니다.

동기 방식 (REPL_SYNC)을 선택했다면 모든 노드로 세션 복제를 완료한 후에야 Servlet/JSP 수행이 끝나므로 위의 문제가 발생하지 않습니다.