2nd 해우소 저널 …HP Open MCM

MCM은 아시다시피 월드와이드한 제품이 아니고 국내에서 개발된 제품으로 당연히 HP본사의 공인 된 제품이 아닙니다. 또한 핵심엔진에 대한 부분도  HP 기술진에 의해 개발되어진 것이 아니고 국내 네트웍 전문업체인 엔소프트에 의뢰(?)해 개발 하였습니다.

여기서 알 수 있듯이 MCM은 네트웍 패킷을 수집하여 이 수집된 정보를 조합하여 각 Tier별 연관관계를 맺고 응답시간을 기준으로 구간의 성능을 측정하고 문제 있는 구간의 장애 원인을 규명 하고자 시도 합니다.

여기서 구간(Tier)라 함은 웹구간을 포함 하여 TP구간(Tuxedo, TMAX)등 과 DB 구간을 포함 합니다.

즉, MCM이 모니터링 하는 범위는 HP에서 목소리 높여 얘기 하듯이 IT 전구간을 그 대상으로 합니다. 여기서 MCM의 장점(?)과 약점(?)을 찾아볼 수 있습니다.

 

첫째 : MCM은 단위 업무기준이 아니라 IT 전반에 적용하는 솔루션으로 자리메김 되어 있습니다. 그러다 보니 프로젝트 규모가 대형 사이트에만 적용이 가능해지고 또한 MCM은 WAS모니터링 혹은 TP 모니터링 모듈만을 분리하여 적용이 안되기 때문에 제안금액도 최소한 10억 이상이 됩니다. 웹기반의 업무 시스템인 경우는 일단 MCM 적용대상에서 제외가 된다는 것 이지요. 아무리 솔루션이 좋다 하여도 10억 이상을 모니터링 예산으로 쓰는 것은 무리 이기 때문 입니다. C/S, 웹이 복잡하게 얽힌 그야말로 미션 크리티컬한 업무가 아니면 기본적으로 검토조차 어려운 제품이라는 것 입니다. 이런 복잡한 중요업무라면 아마도 금융권의 계정계 시스템 이외에는 없지 않을까 합니다.

 

둘째 : 그렇다면 미션 크리티컬한 업무에서는 MCM이 훌륭한 솔루션일 것 같은데 과연 그럴까요? 먼저 생각하여야 할 것은 최근의 IT Trend가 아닐까 합니다. 중소규모의 단위 업무가 아닌 대형 금융권의 차세대 시스템 아키텍처는 어떨까요? 물론 웹과 C/S가 혼재 되어 있습니다., 대부분이 정보계는 웹이고 계정계 시스템은 턱시도 티맥스 등과 같은 TP 를 이용해 개발 하고 있습니다. 그리고 빠질 수 없는 것이 채널통합이라 하여 클라이언트 환경은 웹환경으로 보여준다는 것 입니다. 내부적으로는 턱시도가 업무 처리를 한다 하더라도 앞 단에서는 100% 웹으로 보여진다는 것이지요. 다시 말하면 모든 사용자의 Request(창구, 자동화 기기, 텔레뱅킹 등등)는 웹을 통하여 시스템에 접속이 되고 그 웹이 게이트웨이 역할을 하면서 백엔드 서비스를 호출 하기 때문에 웹에 대한 모니터링만 정확히 된다고 하면 백엔드에 어떤 어플리케이션이 문제인지도 자연스럽게 알 수 있게 되는 것 입니다. 복잡한것 처럼 들리지만 쉽게 한마디로 제니퍼만 잘 써도 된다는 것 이지요. 핵심적인 업무 로직은 물론 턱시도,티맥스 서비스로 처리 되기 때문에 제니퍼를 이용하여 이를 모니터링 할 수 없지만 운영환경에서 중요한 것은 업무 로직의 버그가 아닙니다. 운영에서 업무로직의 버그는 있을 수 없기 때문 입니다. 운영환경에서 중요한 것은 채널서버를 통해서 들어온 서비스 요청이 어떤 경로를 타고 처리가 이루어 지고 있으며 그 구간별 서비스 품질은 정상적인가를 모니터링 하는 것 입니다. 이러기 위해서는 게이트웨이 역할을 하는 채널과 WAS 부분을 실시간으로 정확히 모니터링 하면 된다는 얘기 입니다. 물론 모든 티어를 모니터링 하고 그에 합당한 보고서를 획득할 수만 있다면 더할나위 없이 좋겠지만 그러기 위해서 제니퍼 같은 APM 솔루션보다 10배, 20배 되는 비용을 투자하는 것은 과도해도 너무한 투자라는 것 입니다.

 

셋째 : 수집하는 데이터에 대해서 한번 생각해 봅시다. MCM은 모든 티어의 서비스들에 대한 거래현황을 수집합니다. 네트웍 패킷을 수집하여 이 수집된 패킷을 파싱하여 필요한 정보를 획득 합니다. 여기서 필요한 정보라 함은 Global Transaction ID(이하 GID)와 시간 정도의 데이터 입니다. 이런 데이터를 수집하기 위해 100MBPS 이상의 모든 네트웍 트래픽을 후킹 하려다 보니 오버헤드도 만만치 않고 수집하는 데이터 양도 상상 초월이 됩니다. 물론 최소한의 데이터(GID와 시간 데이터)만을 취하고 나머진 다 버리는 데이터가 되겠지요. 모 증권사에서 평상시에는 MCM을 잘 활용하지만 Peak 때는 MCM을 운영하지 못한다는 하소연을 혹시 들어보셨는지 모르겠습니다. 장애를 대비하여 도입된 솔루션이 운영현황 통계나 내는 솔루션으로 전락하여 활용되어 지는 모습이라 아니할 수 없겠습니다. 수집하는 데이터가 이처럼 대량이다 보니 MCM에서는 전용서버(이 서버 역시 HP서버만 탑재 가능함)와 메모리 데이터베이스를 반드시 제안 하는데 이 역시 MCM의 약점 중 하나 입니다.

 

지금까지는 MCM의 모니터링 방식에 대한 검토를 하였다면 지금 부터는 수집하는 데이터와 APM 관점에서의 MCM을 검토해 보도록 하겠습니다.

 

첫째 : MCM은 모니터링을 위하여 상당부분 커스터 마이징을 필요로 합니다. 따라서 MCM은 솔루션 이라기 보다는 SI 프로젝트 성격의 접근을 합니다. 비록 APM솔루션이 어플리케이션을 모니터링 한다 하더라도 고객의 운영중인 어플리케이션이나 시스템에는 어떠한 변경을 가해서도 되지 않는 것을 기본으로 하지만 MCM은 어플리케이션의 구조를 먼저 파악하고 각 어플리케이션들의 그룹핑을 통하여 콘솔 화면을 구성하기 때문에 필요한 경우 고객의 응용프로그램의 코드 체계를 바꾸는 등 대폭적인 변경이 필요 할 수도 있습니다. 또한 MCM을 적용하기 위해서는 프레임웍(공통모듈)을 변경하고 동적인 라이브러리를 추가 하는데 이로인해 만약의 경우에 긴급하게 시스템에서 MCM을 제거 하는 것이 거의 불가능 하게 될 수도 있습니다. 솔루션을 선정하는데 있어서 중요한 사항은 적용의 용이성도 중요하지만 그에 못지 않게 운영시스템에 영향을 주지 않고 손쉽게 제거 되어야 하는 부분도 강조가 되어야 합니다.

둘째 : MCM은 Tier구간별 응답 속도를 성능 지표로 삼지만 중요한 것은 평균 응답시간을 측정 한다는 것 입니다. 평균응답시간을 관리 한다 함은 실시간(Real Time)이 아니라는 얘기도 되겠지요. 아시다시피 제니퍼는 실시간으로 응답시간을 체크해서 X-View에 표시하고 주요 선은지표들은 1초 간격으로 수집 합니다. 평균이라는 탈은 아주 무서운 결과를 초래 할 수 있음을 간과 해서는 절대 안됩니다. 성능 자료들을 평균을 내게 되면 중요 펙터는 평균에 가려져 보여지질 않게 됩니다. 더욱이 초당 수백, 수천 건의 거래가 발생 할 경우에는 더욱더 평균이 위험해 지게 됩니다. 

셋째 : MCM이 성능관리상의 관심은 수행중인 서비스(Active Service) 입니다. 이는 티맥스 SysMaster도 마찬 가지 입니다. 그러나 APM은 말 그대로 성능 관리에 초점이 맟추어야 됨을 잊어서는 안됩니다. APM의 관리 대상이 되는 시스템은 테스트나 개발 서버가 아니고 운영서버이기 때문에 중요한 것은 응답시간을 관리하고 이를 지속적으로 개선 시킬 수 있게 해야 합니다. 이게 제니퍼의  강점중에 강점임은 이 전에도 또 이전 해우소 저널 첫번째 이야기에서도 여러 차례 강조 한 적이 있습니다.

 

여기까지 이야기 하고 나니 내용이 좀 길어 지는 경향이 있네요.

양이 많으면 지루해 하는 우리네 습성을 고려 해서 이번주제는 여기서 얘기를 일단 중단해야 할 것 같습니다. 보다 나은 세번째 이야기를 기대하시구여……….

                                                                                                                      제니퍼소프트 Scott, Chi