지용운 유피니트 기술/컨설팅 이사
[아이티데일리] 지난 2002년 펜타시스템을 통해 국내에 와일리 인트로스코프 제품이 첫 선을 보이면서 국내에 APM(Application Performance Management) 시장이 열린지 10년이 훌쩍 지났다. 이후 APM 시장에는 와일리 이외에도 국산 솔루션인 제니퍼, 파로스 등 여러 솔루션들이 소개되면서 잠시 경쟁 구도를 보이기도 했다.
하지만 발 빠르게 사용자 입장에서 직관적인 관리 화면과 부하가 적은 가벼운 엔진을 무기를 앞세운 제니퍼에 의해 시장은 평정됐고 최근에는 70% 이상의 놀라운 시장 점유율을 보이면서 시장을 평정하는 양상을 보이고 있다.
그러나 최근 “WAS 기반에서 JAVA로 구현된 단일 시스템을 모니터링 하는 APM은 이미 검증된 솔루션으로 인정받고 있으나 이기종의 미들웨어가 혼재한 복잡하고 다양한 환경에서는 최종사용자 응답시간, 트랜잭션들 간의 상호작용 등의 성능을 감시/측정하고 운영하기 위해서는 새로운 형태의 기술 스킬을 적용한 솔루션이 필요하다”고 지적한 가트너 그룹의 코멘트는 시사 하는바가 크다고 할 수 있겠다.
여기에 다른 조사기관의 코멘트를 하나 더 참조해 보자. “오늘날 IT 시스템이 웹과 이기종 미들웨어가 공존하고 멀티티어 환경으로 나날이 복잡해지면서 JVM 기반의 컴포넌트들의 모니터링을 목적으로 자리를 잡았던 APM 솔루션들은 자연스럽게 그 한계를 드러내고 관리 포인트 역시 시스템 자원과 애플리케이션의 성능에서 더욱더 발전하여 각각의 시스템간의 연계를 규명하는 비즈니스 트랜잭션 모니터링으로 확대되고 있다”라는 포레스트 그룹의 최근 코멘트이다.
복잡한 업무 환경이 거래추적 유발
두 코멘트를 조합해 보면 최근 국내 IT 시장의 현황을 정확히 짚어낸 말이라고 생각된다. APM 솔루션이 JVM을 모니터링 하고 WAS 서비스에 대해서 메소드 레벨까지 상세 모니터링이 가능하지만 최근 애플리케이션들은 서로 다른 이기종 미들웨어 환경에서 업무 환경이 복잡해지고 또한 각종 시스템 통합(EAI) 등으로 인해 더욱더 복잡한 아키텍처를 요구하고 있다.
이러한 환경의 변화는 단순한 애플리케이션 모니터링을 넘어 비즈니스 트랜잭션(Business Transaction)을 모니터링 하고자 하는 새로운 요구를 만들어 내고 국내에서는 거래추적이라는 형태로 발전하고 있다.
이러한 시장의 요구를 반영하듯이 오래 전부터 거래추적 분야에서 메이저 플레이어로서 역할을 했던 유피니트, 펜타시스템 이외에도 엑셈, 티맥스 등 에서도 새로운 제품을 발표하거나 기능을 대폭 개선하여 시장 진입을 시도 하고 있다. 뿐만 아니라 HP, 오라클 등 외국 벤더들도 관련 제품들을 발표하고 있어 이미 시장은 초기 단계를 넘어선 느낌이다.
거래추적이란 말 그대로 사용자의 서비스 요청에 대한 서버사이드의 처리 절차를 추적하여 구간 상세 정보를 보여 주는 솔루션을 말한다. APM 솔루션이 수행중인 jsp, ejb 단위의 성능에 대한 정보를 제공한다면 거래추적 솔루션에서는 계좌이체 업무를 처리한다.
예를 들어 계좌 잔액 조회, 출금, 입금 서비스 등이 순차적으로 수행된다. 이때 각 서비스는 하나의 장비에서 동작할 수도 있고 서로 다른 장비에서 동작이 일어날 수도 있는데 이 각 구간, 각 장비 간의 처리 현황을 보여주기 때문에 장애나 성능 저하가 발생할 경우 장애 상황 발생 시 정확한 장애 구간과 장애 원인을 판별함으로써 애플리케이션 관리자에게 최단 시간 내에 조치를 할 수 있도록 하는 애플리케이션 운영 관리 솔루션인 것이다.
물론 각 사의 솔루션마다 성능 정보를 수집하는 방식이나 거래 연계를 구현하는 방식 등에서 저마다의 특성을 가지고 있다. Hooking에 의한 정보수집, API를 이용하는 방법, 동작인 라이브러리를 이용하는 방식 등 다양한 방식을 사용하고 있지만 운영시스템에 적용되는 솔루션임을 감안하면 무엇보다 시스템에 부하가 적어야 되고 시스템 환경에 대한 변경을 최소화해야 한다.
거래추적 솔루션은 3% 내외의 부하 정도와 애플리케이션 변경이 없어야 한다는 것을 기본 전제로 하고 있다. 그러나 일부 솔루션들은 애플리케이션을 컴파일해야 한다거나 API를 사용하기 위하여 일부 애플리케이션을 변경해야 하는 등의 이유로 인해 고객의 선택에 고민을 하게 하는 부분도 존재 한다.
각각의 애플리케이션 서비스를 하나의 거래로 연계하기 위해서는 GUID(Global Transaction ID)라고 하는 각각의 거래를 구분할 수 있는 ID로 관리 되어야 한다. 일부 금융시스템에서는 거래전문에 이 GUID를 포함하고 있어서 거래추적 솔루션들은 거래 전문에서 이 GUID를 분리해내 사용하기 때문에 비교적 손쉽게 각 거래간의 연계를 완성할 수 있지만 거래 전문에 GUID를 포함하지 않는 경우 상황이 복잡해지게 된다. 여기서 각 솔루션들의 장단점이 확연히 드러난다. 이는 애플리케이션 수정 없이 자발적으로 GUID를 생성하여 활용하는 솔루션이 있는 반면 일부 솔루션은 프레임워크에서 GUID를 생성해 애플리케이션을 수정해주어야 하기 때문이다.
단순하게만 생각한다면 가장 좋은 솔루션이란 운영시스템에 미치는 부하양이 작고(3% 이하) 애플리케이션을 전혀 수정하지 않고 적용이 가능한 제품일 것이다. 기본적으로 위 2가지를 충족한 이후에 나머지 성능수집 항목을 검증하거나 거래추적의 정확성, 사용상의 편의성, 향후 시스템 확장성, 타 관제시스템과의 연계 용이성 등 다양한 점검항목을 따져서 제품 평가가 이뤄져야 할 것이다.
유피니트는 파로스라는 제품 라인업을 구축하고 있어 업계에서 주목 받고 있다. 이는 WAS 모니터링과 티맥스, 턱시도 등 미들웨어에 대한 모니터링 그리고 티맥스 애니링크를 이용한 EAI 시스템 모니터링에 이르기까지 다양한 APM 라인업과 각각의 솔루션 간의 연계를 통하여 애플리케이션에 전혀 변경을 가하지 않고 거래추적까지 가능하게 하고 있다는 부분이 강점이다.
펜타시스템 역시 거래추적의 원조라고 할 수 있는데 TranManager라는 솔루션으로 널리 알려져 있다. 초창기에는 와일리라는 APM 제품의 국내총판을 하면서 외산 와일리 제품의 대시보드 등 일부 기능을 활용하여 금융기관을 중심으로 레퍼런스를 넓혀 왔다. TranManager가 거래추적 중심의 솔루션이기 때문에 APM 기능을 자체적으로 제공하지 못하고 와일리와 같은 APM 솔루션을 이용해야 한다는 점은 다소 아쉬움이 있는 부분이다.
솔루션마다 중점 두는 부문 달라 부족한 부분도 드러나
이밖에도 업체마다 저마다의 특성을 반영한 솔루션들을 살펴보면 데이터베이스 전문 업체는 데이터베이스 중심적인 거래추적을 선보이고 있으며 또 일부 업체에서는 거래로그를 수집하여 로그 기반 거래추적 솔루션을 선보이기도 하고 있다. 하지만 데이터베이스 중심적이다 보면 애플리케이션의 프로파일링이 다소 부족하고 거래로그 중심이다 보면 데이터베이스 측면의 성능정보가 부족하거나 SQL Bind 변수가 확인이 안 되는 아쉬운 부분들을 역시 포함 하고 있다.
최근 I은행, N은행, H카드, C조합, M화재 등에서 5~10억 이상의 굵직굵직한 거래추적 프로젝트들의 제안 요청이 줄을 이루고 있고 일부 업체에서는 PoC, BMT를 진행하고 있는 등 활발한 움직임을 보이고 있다.
거래추적 솔루션 도입을 목적으로 나오는 제안요청서(RFP)나 PoC(Proof of Concept)의 주요 항목을 정리해 보면 이런 솔루션을 도입함으로써 기대하는 효과가 무엇인지 쉽게 가늠할 수 있을 것 같다. 다음은 최근 모 금융기관의 Poc 항목을 정리해 보았다. 이들 항목에서 주목할 사항은 대부분의 요건들이 거래에 대한 모니터링이고 거래에 대한 성능이라는 것이다.
하나의 거래는 여러 개의 메소드가 합해져서 이루어지는데 JVM으로 모니터링 하는 APM 솔루션들은 자바 메소드 단위의 성능을 모니터링 한다는 것에서 차별성이 있는 것이다. 메소드를 추적하는 것이 아니고 거래를 추적한다는 것이다.
다른 측면에서 생각해 본다면 메소드 단위의 성능이나 오류를 관리한다는 것이 개발자 중심이라고 본다면 거래단위의 성능이나 오류를 관리한다는 것은 운영자 중심이라고 표현하는 게 적절하지 않을까 싶다.
사용자 체감속도 기반 둔 SLA 집중한 제품도 흥미로워
최근 대부분의 금융 시스템에서는 거래추적 시스템을 적용해 애플리케이션의 성능관리를 구현하고 있다. 이에 반해 컴퓨웨어나 CA 등 외산 제품들은 애플리케이션보다는 주로 사용자 체감속도에 기반을 둔 SLA(Service Level Agreement)에 집중하고 있는 것도 재미있는 현상이다.
외국과 달리 국내 IT 시장에서는 서비스 기반의 SLA 관리에 중점을 둬 애플리케이션 자체의 품질을 향상시켜 대 고객 서비스 수준을 향상 시키려는 근본적인 노력을 기울이는 것으로 보인다.
개인적인 생각이지만 외산 제품들과 국내제품들의 관점이 다른 이유는 아마도 IT 인프라에 기인하고 있는 듯하다. 외국의 경우 인터넷 환경이 국가마다 지역마다 차이가 있기 때문에 최종 사용자가 느끼는 체감속도는 애플리케이션의 속도 보다 네트워크 속도에 더 영향을 받는다고 생각한다.
그러나 우리나라의 경우 산간벽지까지 100Mbps 이상 초고속의 인터넷을 지원하고 있기 때문에 네트워크 등 물리적인 속도 보다는 애플리케이션의 속도를 관리하는 것을 더 중요한 요소라고 생각하는 것은 어쩌면 당연한 현상이 아닐까?