1ST 해우소저널-제니퍼 포지셔닝..in APM

 

이미 APM은 선택이 아닌 필수가 된지 오래 입니다. 시장에서 APM을 지원하는 엔지니어만해도 얼추 40명 가량이고, 판매하는 영업사원도 50명에 육박 하고 있습니다. 그러다 보니 몇몇 사이트에서는 채널사간의 충돌,분쟁(?)일 일어나기 까지 할 정도 입니다. 성능관리 라는 주제로 이 사업이 과연될까? 하는 수줍은 마음으로 와일리가 국내 소개된지 어언 7년여의 세월이 흘렀습니다. 초기 시장에 대한 확신이 없는 상태에서 시작한 와일리 비즈니스는 SK Telecom, 국민은행등 굵직굵직한 고객사를 확보 하면서 나름의 성공을 거두었습니다. APM이 어느정도 시장에 정착 할 때 즈음해서 머큐리, 시만텍, 컴퓨웨어, 캔들등의 업체에서는 나름의 사상을 접목한 제품들을 내 놓았지만 국내에서는 왠지 성공과는 거리가 멀었고 와일리만 나름의 성공을 거두고 있었을 즈음에 제니퍼가 시장에 나왔습니다.

 

와일리가 복잡하고 커스터마이징 요건이 많아 고민 하던 많은 고객들이 제니퍼로 돌아서게 되는 것은 어쩌면 당연한듯 하면서도 아이러니 한 일 이었습니다. 국내에 들어오는 솔루션들이 성공가기 위한 가장 큰요소는 한글화를 포함한 국내 실정에 맞게 자유롭게 커스터마이징이 되어야 했었는데 APM에서는 이상하게도 이 커스터마이징이 발목을 잡는 희귀 현상이 벌어진 것이지요.

 

어쨌든 제니퍼는 성공적으로 정착하였습니다. 그리고 외산제품은 사그러들었구요. 제니퍼의 성공에 힘입어 여러 국내 업체들이 APM제품을 쏟아내기 시작 할 때도 이 즈음 인 듯 합니다. 물론 제니퍼의 아성에 정면으로 도전하기에는 역부족 이긴 하지만 이런 현상만으로도 제니퍼가 IT 시장에서 하나의 새로운 분야를 개척하는데 성공했다는 것은 부인 할 수 없는 사실이 되었습니다. 물론 와일리의 역할도 무시 할 수는 없었지만….

 

그렇다면 제니퍼가 성공할 수 있었던 이유는 무엇이었을까요?

 굴지의 외산 벤더를 제치고 제니퍼가 성공할수 있었던 이유를 이해하기 위해서는 제니퍼의 정확한 포지셔닝을 알아야 하고 더욱이 요즘 같이 APM의 개념이 여타 다른 솔루션들과 크로스오버되는 시기에는 우리만의 독자적인 포지션을 우리 스스로 만들어가고 이러한 메시지를 지속적으로 시장에 던져야 한다고 생각 합니다. 그런 취지에서 나름대로 정리해 보겠습니다.

 

APM은 Production 환경의 성능관리에 포커싱 해야 합니다. 물론 제니퍼가 가장 강점을 가지는 부분입니다. 일반적으로 APM 솔루션 하면 어떻게 장애를 찾아내서 수정하고 운영이 정상적으로 이루어 지게 하느냐를 고민 합니다. 그러나 여기서 짚고 넘어가야 하는 부분이 Production 환경 이라는 것 입니다. 개발이나 시스템 OPEN 초기에는 크고 작은 프로그램적인 버그나 운영관리 상의 오류로 장애가 난무(?) 합니다. 이 시기는 누구나 어느정도 장애를 인정 합니다. 고객도, 책임자도 “그럴수 있지…. 어서 안정화 시키자…. “ 뭐 이런 식 이지요. 그래서 안정화 되고 나면 이런 장애는 현저히 줄고 그야 말로 별일 없이 돌아 갑니다. 이렇게 별일 없는 상황을 만들기 위해서 개발관련 각종 솔루션, 디버깅 솔루션, 부하테스트 솔루션 등등이 활용 됩니다. 안정화를 시키기 위해서……

 

그런데 운영상태에서는 무얼 하지?

 

APM이 고민 할 것은 바로 이 단계 입니다. 뭘 해야 할까요?

시스템 관리 솔루션이 아닙니다. 말 그대로 성능관리 제품 이라는 거지요. 성능을 모니터링 하고 그것을 개선시켜야지 장애를 찾아내고 장애를 해결하는데 초점이 맟춰지면 안된다는 것 입니다. 그런데 대부분의 솔루션들은 장애 발견과 해결에 초점을 맟추고 있습니다. 물론 제니퍼도 장애 관련해서 수많은 기능을 제공 하지만 그 보다 먼저 성능관리에 주안점을 두고 있다는 것 입니다.

 

제니퍼 X-View의 가치가 더욱더 빛나는 이유가 바로 여기 있습니다. X-view는 모든 서비스의 응답을 관리 합니다. 잘 돌아가는 시스템 이라 할 지라도 그중에 하나의 서비스라도 불량한 녀석이 있는지를 상시 감시 할 수 있습니다. 장애가 아니고 불량이라는데 주목 해야 합니다. 응답이 이루어 지는 즉시 그야말로 실시간으로 반응을 보이고 서비스의 응답을 나타내 줍니다.

 

그럼 다른 제품은?

 

다른 제품들은 먼저 엑티브 서비스를 모니터링 합니다. 응답하지 않는 서비스를 모니터링 하지요. 그럼 응답한 녀석들의 관리는?

수행중인 서비스에 대해서는 제품마다 일정 기능 들을 제공 해서 어떤 서비스가 수행중이고 왜 수행시간이 오래 걸리는지 확인 하기 위한 Trace, Dump 기능들을 제공 합니다. 그런데 정상적인 응답을 한 서비스에 대해서는 평균값으로 대신 합니다. 왜 평균 값일까요? 오버헤드 때문에 실시간 요건이 안되기 때문에 평균이라는 멋진 포장을 해서 표현 합니다. 성능관리에서 가장 경계를 해야 하는 것이 바로 이 평균 이라는 단어 인데 말이지요. 다른 제품들을 보면 응답시간에 대해서는 빠른 것이 15초 평균, 심지어는 15분 평균 값을 보여주기 까지 합니다. 초당 1000건 이상의 처리를 하는데 15초간의 평균이 어떤 의미가 있을지 한번만 생각해 보면……  정말 문제 있는 수치는 이 평균에 묻혀 버리는 겁니다. 물론기술적인 이유로 실시간 요건을 맞추지 못하고 말도 안 되는 평균을 이야기 하는 것 이겠지요?

  

X-View에서는 모든 거래 응답시간을 직관적으로 보고 판단 할 수 있는 강력함이 있지요?

 

정리하자면 APM은 안정적으로 운영되는 중에서 그 성능을 모니터링 하고 관리 함으로써 한발 더 나아가 개선할 수 있는 방안이 제시되어야 하는 솔루션이고 제니퍼가 딱 이라는 것 입니다.

 

최근에는 APM의 범위가 마치 확장되어 구간별 성능까지도 보여주고 관리 되어야 한다고 얘기를 합니다. HP와 TMAX 에서 그런 말들을 많이 하고 마치 제니퍼와 경쟁인양 영업을 합니다. 그리고 많은 제니퍼 영업대표들이 이로 인해 어려움을 격고 있습니다. 물론 멋진 이론 입니다. 어플리케이션을 가리지 안고 자바든 C든 심지어 Cobol까지도 그 구간을 다 모니터링하고 문제 구간을 정확히 구분해 낼수 있다면 그것도 간단한 기술로 가볍게 그리만 할수 있다면 얼마나 좋겠습니까? 하지만 현실적으로 그러기 위해서는 전용하드웨어와 전용 데이터베이스를 이용해야 하고 어쩌고 저쩌고 해서 적게는 10억에서 많게는 20억 이상의 비용이 소요 된다면 다시 한번 생각해볼 문제 아닐까요?.

 

이미 제니퍼는 WAS 중심의 어플리케이션 성능 관리라는 독자적인 위치를 확보 하였고 성능관리의 올바른 방법을 제시하고 시장에서 이미 인정을 받았습니다. 수많은 고객사가 이에 대한 당연한 반증 이겠지요. 이 응답시간을 중심으로 모니터링 하더라도 백엔드 시스템(TP)에 대한 성능 관리는 가능 해 집니다. End-To-End에 대한 구체적인 이야기는 다음번 해우소 저널에서 거론 하기로 하겠습니다.

 

제니퍼는 이미 성능관리의 표준이 되었고 최근 하나둘씩 소개되는 국산 솔루션들이 이런 제니퍼를 모방해서 제품을 만들어가고 있는 것은 하나의 희열(?)이면서 또한 또 다른 도전 이기도 합니다.

 

앞에서 언급한 바와 같이 다음 번 저널에서는 APM과 End-To-End에 대해 이야기해 보겠습니다. 늘 승리 합시다.

                                                         

                                                                                                         Written by 제니퍼소프트 기술상무 지용운