Q. i3를 도입하는 고객사의 경우, 다른 튜닝 솔루션 가운데 i3를 선택하는 주요 이유가 무엇이라고 보는지.

A. 우선 기존의 오라클 관련 튜닝 툴로는업계에서 가장 명성이 높았던 프리사이즈(Precise)를 모체로한 제품이라는 점과 이를 기반으로 DB 뿐 아니라WAS로 확장해 연계 분석이 가능하다는 점일 것 같다. 티어가 복잡해지는 만큼 DBA나 시스템 관리자가 관리해야 할 포인트나 보틀넥이 발생하는 포인트 또한 많아지고 있어서전체 트랜잭션 흐름에 대한 연계된 성능 분석이 필요하다.

Q. 베리타스 i3가 가진 기능 중 유일하거나 혹은 가장 뛰어난 기능이라고 생각하는 것이 있다면.

A.스마트링크(SmartLink)라는 기능을 고객사들이 선호한다.클라이언트에서 웹 그리고 WAS, DB로 연계되는 트랜잭션의 흐름에서 각 티어별 처리 시간을 산정해주기 때문에 어느 티어가 문제인지 정확하게 원인을 찾을 수 있어서, 성능 저하의 원인을 찾는 시간을 단축시켜 준다.또 운용 중에정보 수집 여부를 다이내믹하게 지정하는 기능이 있어서, 시스템 부하의 피크 여부에 따라 고객이자유롭게 i3의 기능 활용 범위를 변경할 수 있다. 따라서 시스템 부하가 주기적으로 몰리는 업무 환경을 갖는 고객사들이 유용하게 활용한다.

Q. 베리타스 i3가 완벽한 솔루션은 아니기 때문에, 경쟁 제품에 비해 미흡한 기능이 있을 것이다. 어떤 것을 지적할 수 있을까.

A. i3는 애플리케이션 성능을 분석하고 튜닝하는데 초점이 맞춰진 제품인 만큼,장애를 관제하는 실시간 애플리케이션 모니터링 기능의 보완이 필요하다. DB를 관장하는 i3 for Oracle의 경우 5분 단위, WAS를 관장하는 i3 for WebJ2EE의 경우엔 30초 단위로 데이터를 축적, 처리한다. 물론 얼마나 상세한 데이터를 축적해 보여주는지 부분에서 차이가 있을 수는 있지만 경쟁사들 중에는 1분 이내로 장애를 관제하는 경우가 있다. 물론 이렇게 장애 관제 모니터링 시간 간격을 줄이면 그만큼 해당 시스템의 부하에도 영향을 미치기 때문에 장단점이 있는 게 사실이다.부하에 영향을 미치지 않는 선에서 모니터링 시간 간격을 좁히는 것이 해결과제일 것으로 본다.

Q. i3를 사용하는 고객 중, i3에 대해 불만을 제기하기도 할텐데 주로 어떤 요구사항을 제시하는지.

A. i3는 DB, WAS, 웹의 연계 분석이 가능한 솔루션이기 때문에 다른 제품들에 비해 설치해야 하는 해당 시스템이 많다. 예를 들어 웹, WAS, DB 서버를 1대씩만 운용하는 기업 고객이라고 하더라도, OS와 해당 소프트웨어의 버전에 맞춰 i3를 설치하면, 총 6개의 버전에 맞춰 설치를 해야 하는 것이다. 이런 점에서 초기 세팅 시간 소요나 작업 과정에 대해 불만을 제기하는 고객들이 있다.

Q. 관련 툴 도입시 고객들이 고려해야 할 요소들이 많이 있을 텐데, 컨설턴트 입장에서 권고하고 싶은 체크리스트가 있다면.

A. DB 튜닝 툴 분야에서 검토할 사항으로 3가지를 거론하고자 한다.첫 번째는 상호 티어 간 연계 분석이 가능한 툴인가이다. 현재 대다수 기업의 애플리케이션 환경은 DB만 혼자 운용되는 것이 아니라 클라이언트부터 웹, WAS, DB로 연계되는 멀티 티어 환경이기 때문에 일련의 트랜잭션 흐름에 맞춰 여러 티어 간의 연계 분석이 필요하다.

두 번째는 기본적인 응답 시간 모니터링 외에 자동화된 분석 기능을 갖고 있어서 문제 상황에 대한 가이드라인까지 받을 수 있는지여부다. 이런 자동화 측면은 고객 요구가 점차 높아지고 있어서 관련 툴들의 변화가 예상된다.

세 번째는 부하 부분이다. 대부분 성능 분석 대상 시스템의 부하 문제 때문에 모니터링이나 튜닝 툴을 도입하는 것이 일반적인데 오히려 DB 시스템에 부하를 주는 툴들이 적지 않다. 이에 대한 검토가 필요하다.

Q. 툴 도입이 모두 성공적이긴 힘들 것이다. 경험했던 실패사례와 실패한 이유를 설명해 달라.

A. 가장 일반적인 경우는 부하 문제에 대한 간과다. 한 공공기관의 경우 트랜잭션이 월말에 지나치게 폭주해, CPU 부하가 90% 선을 넘어서 A사의 제품을 도입했다. 그런데 적용하고 보니, 전체 CPU 사용률이 거의 100%에 도달해 A 제품을 사용하지 못하게 됐다. 오히려 해당 툴이 CPU 부하에 영향을 미친 사례다. 결국 부하 문제에 안전한 B사 툴을 이용한 컨설팅을 통해 수정함으로써 CPU 부하를 20%대로 낮춰, 문제를 해결했지만 도입 목적을 간과함에 따른 실패사례라고 볼 수 있다.

두 번째는 최근에 조금씩 발생하는 문제인데, DB와 WAS 간의 연계된 성능 분석을 고려치 않은 경우다. DB 성능관리 툴은 A사 제품을 사용하고 있는 와중에 WAS 성능 관리 요구가 발생해서 WAS 성능 관리는 B사 제품을 구매하다 보니 툴과 툴이 연계가 안 돼서 오히려 DBA가 각각 분석된 내용을 매칭, 재작업을 해야 하는 번거로움을 야기하는 경우들이 생기고 있다. 결국은 솔루션 재구매 요구로 이어지는 사례들이 발생하고 있다.

Q. 최근 모니터링 및 튜닝 툴의 기술 흐름에 어떤 변화가 있는지 설명해 달라.

A. 최근에 의뢰가 들어오는 컨설팅이나 잠재 고객의 솔루션 선정을 위한 RFP(Request for Proposal) 기재 사항을 보면 두 가지의 흐름을 알 수 있다.엔드-투-엔드 성능 연계 분석과인텔리전트한 자동화 분석 기능이 그것이다.

약 2년 전부터 새로 구축되는 시스템의 대부분은 WEB-WAS-DB 구조로 아키텍처가 구성된다. 기존의 전통적인 아키텍처에선 성DB 성능관리 툴만을 도입해 문제를 해결하고자 했지만, WAS가 보편화된 이후엔 DB 성능관리 만으론 문제의 근본적 해결이 어려워지고 있다. WAS의 JVM이 블랙박스 같은 역할을 해, 이 부분에 대한 성능 분석을 간과할 수 없기 때문이다. 이에 고객들이 솔루션 도입시 WAS-DB 혹은 클라이언트에서 백엔드에 이르는 상호 연계된 성능 분석을 요구하고 있다.

이 흐름과 함께 성능 모니터링 이후 툴 사용자가 문제 사항을 일일이 점검해 해결 방법을 찾는 방식에서 벗어나 툴에서 문제 해결 방식까지 인텔리전트하게 판단해주는 자동화된 기능에 대한 요구도 점차 증가하고 있다.