Cover Story - 웹 애플리케이션 성능 모니터 리뷰

‘엠피릭스’ 직관적 인터페이스로 ‘프로액티브네트’에 간발의 승

‘모니터링·관리·통합’ 능력 평가 … 가격비교는 특별히 신중해야

이번 호에는 웹 애플리케이션 성능 모니터들이 대형 네트워크에서 웹 애플리케이션과 장비에 대한 데이터를 얼마나 잘 수집하는지, 그리고 이러한 정보를 얼마나 선명하게 제시하는지도 또한 살펴봤다. 참가 자격은 스위치, 라우터, 부하조절기, 시스템, 데이터베이스, 웹 애플리케이션 서버 및 클라이언트 등 자신들의 인프라와 웹 애플리케이션에 대한 성능 정보를 수집, 처리, 디스플레이, 경보 및 배포할 수 있는 제품이어야 했으며, 6개 제품들이 시험대에 올랐다.

이번 스마트 웹 애플리케이션 모니터링 제품 테스트는 위스콘신 주 그린베이의 NWC 비즈니스 애플리케이션 랩에 있는 아이비엠 웹스피어(IBM WebSphere) 인프라를 이용해 시러큐스 대학의 리얼월드 랩에서 이루어졌다.
참가 자격은 스위치, 라우터, 부하조절기, 시스템, 데이터베이스, 웹 애플리케이션 서버 및 클라이언트 등 자신들의 인프라와 웹 애플리케이션에 대한 성능 정보를 수집, 처리, 디스플레이, 경보 및 배포할 수 있는 제품이어야 했다.
모니터링에 프리미엄을 주긴 했지만, 관리의 편이와 IT 및 사업팀에서 사용할 수 있게 충분한 포맷의 유연성을 갖춘 데이터 프리젠테이션도 또한 강조했다. 예를 들어 서버 가용성 정보는 기업 소유주들에게 핵심적인 정보지만, 시스템 관리자의 경우는 서비스 토폴로지에 대한 보다 깊은 통찰력을 갖춤으로써 결산에 영향을 미치기 이전에 서비스 고장을 진단 및 치료할 수 있기를 원할 것이다.
15장의 초대장이 발송됐지만, 6개 업체들만이 제안에 동의했는데, 이들이 보내온 제품은 각기 컴퓨터 어쏘시에이츠 (Computer Associates International)의 유니센터(Unicenter), 콘코드 커뮤니케이션즈(Concord Communi-cations)의 e헬스 스위트(eHealth Suite), 엠피릭스(Em-pirix)의 원사이트(OneSight), HP의 오픈뷰(OpenView), 넷아이큐(NetIQ)의 애프매니저 스위트(AppManger Suite), 프로액티브네트(ProactiveNet)의 동명 제품이었다.
머큐리 인터랙티브(Mecury Interactive)와 레드라인 네트웍스(Redline Networks)는 참가를 거부했으며, BMC 소프트웨어 역시 자원 부족을 이유로 참가를 거부했다. 다이어링 소프트웨어(Diring Software), 피크스톤(Peak-stone), 트래비 소프트웨어(Travve Software), 티리프 테크놀로지(TeaLeaf Technology) 및 윌리 테크놀로지(Wily Technology) 등은 우리의 초대에 응답을 보내지 않았다. 컨버스 소프트웨어(Converse Software)도 또한 응답하지 않았는데, 그 이유는 아마도 님버스 소프트웨어(Nimbus Software)와의 합병 작업에 여념이 없기 때문인 것 같았다.

데이터 수집에서 차별화
테스트한 모든 제품이 디폴트 웹스피어 플랜트스토어(Plantstore)와 펫스토어(Petstore) 애플리케이션이 포함된 우리의 테스트베드 모니터링에서 좋은 성과를 보였다. 제품간 차이는 주로 데이터 수집을 중심으로 해서 나타났는데, 데이터 수집에는 두 가지 모델이 있다.
넷아이큐의 애프매니저, CA의 유니센터 및 HP의 오픈뷰는 에이전트를 모니터링되는 시스템에 떨어뜨린 반면, 콘코드의 e헬스와 엠피릭스의 원사이트 및 프로액티브네트는 SNMP, HTTP 및 퍼프몬(perfmon) 등과 같이 인터페이스들에 있는 원격 프로토콜과 프록시를 이용해 통계를 수집했다. 이렇듯 보다 가벼운 풋프린트(footprint)의 이점과 맞서는 에이전트 기반 시스템의 이점은 시스템 성능 통계로 보다 깊이 들어갈 수 있다는 것이다. 예를 들어 넷아이큐와 HP는 둘 다 자신들의 시스템 에이전트에 자동화 및 진단 지능을 포함시켰다. 이것은 시스템 관리자들에게는 이점이 될 수 있지만 운영팀이나 서비스 전달 보고용으로는 그 가치가 덜하다.
HP의 오픈뷰는 로봇 트랜잭션과 유연한 딥 시스템 에이전트, 그리고 이번 리뷰에서 독특하게 개별적 트랜잭션의 트랜스 n티어 추적(이를 통해 각각의 티어에 자동으로 응답시간을 할당할 수 있었다) 등을 이용해 세부적인 데이터를 수집한다는 점에서 특히 뛰어났다.
HP와 CA는 또한 초대형 네트워크를 처리하기 위해 구축된 오류 콘솔과 네트워크 장비 모니터링을 제공하고 있는데, CA의 경우는 유니센터 네트워크(Unicenter Network)와 시스템즈 매니지먼트(Systems Management)로, HP의 경우는 오픈뷰 네트워크 노드 매니저(OpenView Network Node Manager)를 이용하고 있다. 사실 이러한 네트워크 모니터링 스위트들은 너무 잘 만들어져 있어서, 에이전트가 없는 업체들도 이들과 나란히 작업하며, 라우터의 CPU 활용도와 같은 네트워크 장비 시스템 성능과 중요한 인터페이스에 대해 보다 많은 정보를 보다 긴 시간 동안 추적함으로써 기존의 네트워크 관리를 오버레이하고 확장시킬 수 있다. 이러한 통합을 통해 이들은 보다 더 강압적으로 모니터링하고, 설치된 것을 이용하는 방법을 알게 됐다. 하지만 이런 방식은 약점이 있는데, 그것은 네트워크 관리 프레임워크가 제공하는 인벤토리와 폴링을 통합하고 이것을 사용해야 한다는 것이다.
웹 애플리케이션 모니터를 선택할 때 고려해야 할 중요한 부분은 관리와 이행(administration/implementation)이다. 물론 여기에는 초기 설치와 진행 중 케어와 피딩이 포함된다. 각 제품은 플래닝과 셋업을 필요로 하는데, 이들 중 상당수는 업체측의 서비스 파트에서 해결해준다(물론 유료로). 그리고 일단 설치가 되면 애플리케이션은 보통의 모델들보다 더 많은 유지보수를 필요로 한다. 돌려야 할 노브(knob)가 많다는 것은 곧 어떠한 TCO 계산에서든 이를 전담하는 관리비용이 포함돼야 한다는 사실을 의미한다.
이번 테스트에서는 프로액티브네트와 엠피릭스 원사이트가 설치 및 가동이 보다 수월했으며, 넷아이큐 애프매니저에는 최고의 관리 기능이 포함돼 있었다. 케어 및 피딩에 있어 반대쪽에는 HP 오픈뷰와 CA의 유니센터가 있었는데, 이들은 자기 회사에서 기존에 나왔던 제품 꾸러미를 그냥 하나로 합쳐 놓은 것에 불과해 이 부문에서 뒤쳐졌다.

가격도 꼼꼼히 살펴야
사용의 편이는 관리 점수에서 큰 비중을 차지하지 않았는데, 그 이유는 어떤 스위트를 선택하든 그 제품을 전담할 교육받은 인력이 필요할 것이기 때문이다. 그러나 이런 사람들이 쉬는 시간마다 다른 주주들에게 시스템을 내비게이팅하는 방법을 설명하느라 애를 먹어야 하는 상황이 발생하는 건 아닌지 확인하고 싶었다. 이 부문에서는 엠피릭스 원사이트와 프로액티브네트의 깔끔한 웹 인터페이스가 현재까지는 최고였다. 다른 제품들의 경우는 잘해야 레거시 인터페이스를 얼마간 끄집어 내서 초보자들을 혼란스럽게 했으며, 최악의 경우는 다른 뷰를 확보하기 위해 IT가 뛰어들어야 했다.
모든 제품들이 기본적인 정보에 대해 포탈 양식의 서비스 보고를 제공했다. 콘코드의 e헬스 비즈니스 서비스 콘솔(eHealth Business Service Console)은 다중 그룹을 위한 다중 서비스 보고서를 제공한다는 점에서 최고였는데, 이는 서비스 사업자에게 큰 이점이 된다. HP 오픈뷰는 멋진 포물선 서비스 토폴로지 뷰가 있는 통합 작동 콘솔을 제공하는데, 이는 서비스의 종속성(dependencies)을 문서화하는 데 유용하게 사용할 수 있다.
마지막으로 결코 간과해서는 안 되는 항목으로 가격을 꼽을 수 있다. 가격은 사전에 확실한 준비를 해둘 필요가 있다. CA는 할인된 가격이 250만달러를 상회하는 반면, HP는 실제로 50달러 선을 깼다. 물론 다른 여느 복잡한 소프트웨어 스위트와 마찬가지로, 이 가격에는 많은 ‘만약, 그리고, 그러나’들이 반영돼 있다. 테스트된 가격은 MSRP며, 테스트한 다른 특정 항목들과 함께 보고의 사양표에 포함시켜 두었으니 참고하기 바란다.
어떤 제품도 우리의 서비스 토폴로지를 자동으로 매핑할 수는 없었는데, 웹스피어 서버 그룹 A와 데이터베이스 B가 웹 서버 풀 X에 의해 서비스가 되며, 관련된 모든 종속성들이 쉽게 문서 디스플레이로 래핑이 될 수 있다는 개념은 좋긴 하지만 쉬운 일이 아니다. HP 오픈뷰는 n티어 인프라에서의 트랜잭션을 추적함으로써 이러 관계를 나타내주는 맵을 만들 수 있게 해줬지만, 이것 역시 수동 프로세스였다. HP의 기술력을 감안할 때 다음 번에는 자동화된 서비스 토폴로지 탐색이 지원될 것으로 예상된다.
시러큐스와 그린베이간에 많은 통화를 거친 후 엠피릭스의 원사이트와 프로액티브네트가 모두 최종평가에서 좋은 점수를 얻었다. 결국 에디터즈 초이스는 원사이트에게 가긴 했지만, 프로액티브네트도 2위를 차지하기는 아까운 제품이었다. 하지만 원사이트의 인터페이스가 초보자들로서는 이해하기가 약간 더 수월했으며, 통합 및 모니터링의 폭이 프로액티브네트에 앞섰다. 5위 안에 든 제품은 어떤 것이든 추천해도 무방하며, 유니센터가 관리의 편이면에서 뒤떨어지긴 했지만 모든 버튼과 노브를 사용해 온 CA 이용 조직에서는 이 제품도 고려해볼 만하다.

엠피릭스
원사이트 5.0
처음부터 엠피릭스 원사이트는 잘 작동해서 설치하고 에이전트를 이행하는 데 가장 문제가 없었다. 이 제품은 경쟁 제품들과 마찬가지로 웹스피어를 모니터링했다. HTTP PMI (Performance Management Infrastructure) 인터페이스는 웹스피어로부터 성능 데이터를 끌어 와서 우리 자바 프로세스의 가용성과 성능에 대한 명확한 뷰를 제공해 줬다.
원사이트의 모니터링에는 IIS, 익스체인지, 아파치, 오라클, 웹로직 및 SNMP 등과 같은 서비스나 애플리케이션들이 포함돼 있다. 우리는 이런 프로세스와 웹스피어 애플리케이션의 건강뿐만 아니라 애플리케이션 서버들의 건강 표지기를 점검해 보았다. 엠피릭스는 서로 다른 티어들로 로봇 트랜잭션(rootic transaction)을 보냄으로써 우리 서버를 모니터링했다. 트랜잭션이 실행되는 장소는 프록시 에이전트에 있는 서버로부터 원격이어도 가능하며, 그 결과는 관리 서버로 다시 전송된다. 프록시 에이전트 모니터링 셋업은 프로액티브네트나 콘코드 e헬스에서도 가능하지만, 원사이트의 경우 사용 가능한 모든 웹스피어 PMI 통계를 보여줌으로써 한층 더 수월하게 만들었다.
원사이트는 CA, HP 및 넷아이큐처럼 테스트 중인 시스템에 에이전트를 둘 필요가 없었다. 우리는 세 번째 서버에서 그린베이 랩에 있는 방화벽 뒤에 원격 프록시 에이전트를 셋업해서 두 개의 웹스피어 서버를 모니터링했다. 그런 다음에는 그린베이 플랜스토어와 펫스토어 애플리케이션으로 시러큐스에서 오는 HTTP 트랜잭션을 설정하고, 두 개의 랩 모두에 있는 우리의 네트워크 인프라를 모니터링하게 했다. 이런 식으로 해서 우리는 각각의 장비와 서비스의 맥박을 손가락 끝에서 계속 느낄 수가 있었다.
원사이트의 네트워크 장비 모니터링 및 오류 보정 기능의 부재로 엠피리스의 가격은 폭등했다. 엠피릭스는 우리의 전체 네트워크를 모니터링할 기회는 사양한다는 사실을 분명히 밝힌 바 있다. 2천500개의 네트워크 장비를 모니터링한다는 우리 가격 시나리오대로 하자면 SNMP 트랩을 이용해 기존의 네트워크 관리 애플리케이션으로 통합하는 데 300달러가 드는 데 30만달러가 원사이트 가격에 추가된다.

프로액티브네트
프로액티브네트 6.0
프로액티브네트에는 좋은 모니터링 기능이 있으며, 성능이 비정상적일 때를 판단함으로써 경보가 발생하도록 하는 값을 자동으로 설정할 수 있다. 이러한 자동 쓰레숄딩(automated thresholding)과 뛰어난 근본 원인 제안 엔진은 프로액티브네트가 더욱 돋보이게 하는 특징이다. 아웃오브더박스 기능성과 저렴한 관리 또한 눈에 띄는 장점이었다.
우리는 썬 솔라리스 9을 설치하고, 프로액티브네트 시스템의 필요조건들을 갖춘 다음 이것을 설치 및 이행했으며, 이 모두는 하루로 충분했다. 이렇듯 신속한 출발이 가능했던 다른 제품은 엠피릭스 원사이트뿐이었다. 관리 콘솔의 설치는 서버에서 간단한 다운로드 한 번이면 됐으며, 특정 애플리케이션을 어떤 시스템이 돌리고 있는지를 알아야 에이전트를 이행할 수 있기 했지만 이것 또한 포인트 앤 클릭 프로세스였다.
일단 데이터 수집 작업에 들어가자, 프로액티브네트는 자동 스레숄드 생성 프로세스를 발동시켰다. 제품들이 정적 스레숄드 제안을 포함시키는 것은 드문 일이 아니지만, 프로액티브네트는 그 대신 실질적인 성능을 모니터링하고, 시간이 경과하는 동안의 이상 행동을 인지한다. 정적 쓰레숄드 오버라이드(static-threshold override)도 또한 사용 가능하다. 우리는 두 가지를 모두 이행했으며, 우리의 정적 쓰레숄드 추측 중 일부가 잘못되었음을 금방 발견할 수 있었다. 보통은 우리가 모니터링을 기반으로 쓰레숄드를 바꾸지만, 프로액티브네트에서는 애플리케이션으로 하여금 쓰레숄드를 보고 바꾸도록 함으로써 우리 네트워크에서 무엇이 정상적인지를 반영하는 게 더 편했다.
웹스피어 애플리케이션을 테스트하기 위해 우리는 NWC에 있는 방화벽 뒤에 프록시 에이전트를 설치했으며, 크기가 작은 자가 실행 에이전트 설치 파일을 다운로드했다. 엠피릭스 원사이트와 마찬가지로 프로액티브네트는 HTTP를 통해 웹스피어의 PMI로 액세스함으로써, 많은 가능한 데이터 수집 지점을 노출시켜주며, 우리가 친한 이웃 개발자와 의논한 다음 선택을 할 수 있도록 해주고 있다.
서비스 모니터링 설정을 위해 우리는 포함된 로봇 에이전트를 이용해 종단간 트랜잭션을 만들었다. 그런 다음에는 핵심 경로의 네트워크 장비와 공유되는 시스템 장비를 나타내는 그룹을 만들었다. 또한 각각의 웹스피어 애플리케이션으로부터 얼마간의 로봇 트랜잭션을 사용하는 그룹도 만들었다. 프로액티브네트의 역할 기반 액세스를 테스트하기 위해서는 사용자 그룹을 기반으로 하는 SLA(Service Level Agreement)를 지정했으며, 이 모든 것들은 문제없이 진행되었다.
GUI는 꽤나 직관적이었다. 그룹을 설정하고, 관리 GUI에 모니터를 추가할 때 우리는 몇 번 길을 잃었으며, 사용자 GUI에는 살펴볼 게 엄청나게 많았지만, 내비게이팅하기가 힘들지는 않았다.
프로액티브네트의 가격은 엠피릭스와 마찬가지로 너무 많은 네트워크 장비를 모니터링하라는 우리의 요구조건 때문에 크게 올라갔다. 프로액티브네트는 볼륨 가격 견적서를 주는 쪽을 택했다. 이 회사가 5만 달러의 전문가 서비스를 바로 공개한 데 대해 칭찬을 보내고 싶다. 아마도 이것은 모든 제품에서 계산에 포함시켜야 할 것이다.

콘코드 커뮤니케이션즈
e헬스 스위트 5.6.6
콘코드는 성능 관리 영역을 규정한 바 있으며, 여전히 지속적인 혁신을 통해 관심을 집중시키고 있다. 이 회사의 e헬스 스위트는 우리의 테스트 환경에 쉽게 들어맞아 통합 부문에서 높은 점수를 얻었지만, 종단간 서비스 가용성에 초점을 두고 있어 세부적인 부분에 이르는 모니터링의 깊이 면에서는 부족해 보였다.
예상했던 바 대로 우리는 모든 제품에 e헬스에서 사용 가능한 모니터가 있다는 사실을 발견했으며, e헬스에는 능동적인 로봇 모니터링뿐만 아니라 실제 사용자의 수동적 모니터링도 포함돼 있다. e헬스에서 가장 강력한 기능 가운데 하나는 데이터를 볼 때의 편이성이다. 이 스위트는 BSC(Business Service Console), 웹 관리 콘솔, 마이크로소프트 윈32/x윈도 콘솔, 명령어 라인 인터페이스 및 퍼블리싱된 PDF 보고서 등 다섯 가지의 기본 인터페이스를 제시했다.
BSC는 여기서부터 서비스가 전달이 되고 서비스의 개요와 그 컴포넌트들로 사용자들이 가장 쉽고 맞춤으로 액세스할 수 있는 포털 형식의 톱 레벨이다. 웹 관리 인터페이스는 모든 모니터, 보고 및 그루핑의 셋업과 관리에 대한 데이터를 주는 한편, X 윈도 콘솔 안에서 돌아가는 윈32 인터페이스는 제품을 시작, 중단 및 라이선싱할 때 뿐만이 아니라 에이전트와 네트워크 장비를 찾기 위한 출발 지점이 됐다. 보고서는 이 인터페이스에서 실행될 수 있지만, 일일 보고서 정의 및 보고서 뷰잉은 각각 웹과 BSC 인터페이스에서 보다 쉽게 처리됐다.
톱 레벨 서비스 모니터링의 경우 e헬스의 뷰는 자신들이 지원하는 고객들에게 매우 잘 맞춰져 있다. 예를 들어 상태와 예상치를 실시간으로 보여주는 하이브헬스(LiveHealth)에서는 IT 운영팀에서 서비스를 구성하는 모든 컴포넌트를 볼 수 있게 해주며, 이들이 서비스를 어떻게 지원하고 있는지를 보여줄 것이다. n티어 요소들을 모니터링하기 위해 우리는 e헬스 어베일러빌러티 에이전트(eHealth Avai-lability Agents)라고 하는 별개 조각들용의 능동적 모니터를 타깃 서버에 배치해야 했다.
콘코드는 웹스피어 전용 모니터링을 제공하지 않는다. 이 회사는 웹스피어 실행파일과 같은 시스템 프로세스는 운영팀에서 모니터링을 하고, 세부적인 PMI 작업은 애플리케이션 서버 관리자와 애플리케이션 개발자들의 몫으로 남겨두는 게 좋다는 입장이다. 다른 모든 제품들의 심도 있는 모니터링 능력을 감안할 때 이러한 태도는 납득이 되지 않았다.
하지만 e헬스에는 좋은 스레숄드 관리 능력이 있다. 이것은 우리가 일정 시간 동안 네트워크를 베이스라이닝함으로써 정적 스레숄드를 설정할 수 있게 해준다. 두 번째 방안을 이용하면 일별, 주별, 혹은 시간별로 정상적인 활동에서 벗어나는 표준 편차를 적용시킬 수 있다. 프로액티브네트에서처럼 위반되는 것으로 고려될 쓰레숄드용의 주파수와 일관성을 지정할 수도 있었다.
HP와 CA 제품을 제외한 모든 제품에서처럼, 이번 대규모 네트워크 모니터링에 대한 요구로 e헬드의 가격은 매우 높아졌다.

넷아이큐
애프매니저 스위트
애프매니저는 한번씩 접할 때마다 성장한 모습을 보여주었다. 처음에는 그 밀집된 작업관리 지향적 인터페이스와 에이전트를 설치하고 서버와 커뮤니케이팅시키는 데 있어서의 어려움 때문에 마음에 상처를 입었다. 그러나 얼마 후 이 제품의 논리적인 작업 패러다임은 우리를 압도했다. 우리는 이것이 에이전트의 상태를 관리하고 추적하기 위한 좋은 방안이라고 확신한다. 게다가 이 제품은 많은 정밀한 시스템 통계와 함께 이들을 적용시킬 수 있는 유연한 방안을 제공하고 있다.
애프매니저는 전용 시스템 에이전트가 있는 시스템 성능 관리기라고 할 수 있다. 각각의 에이전트에는 장비 유형별로 다양한 기능이 있으며, 이러한 기능들은 사전 정의된 지식 스크립트를 돌림으로써 결정된다. 우리에게 보내진 기본 패키지인 넷아이큐에 포함된 스크립트의 수와 깊이는 좋은 의미에서 압도적이었다. 의사만 있다면 복제를 하거나 처음부터 자기 것을 만들 수 있으며, 넷아이큐에는 이용할 수 있는 사용자 제출한 스크립트들이 수업이 많이 포함돼 있다.
일단 에이전트를 설치시키고 기본적인 시스템 탐색을 실시한 다음, 단순히 서버나 그룹 객체로 지식 스크립트를 드래깅함으로써 웹스피어 탐색을 시작할 수 있었다. 그러면 스크립트가 자동으로 대기열에 올라 배치(batch) 작업 콘솔로부터 실행이 되었다. 완료가 되자 작업 상태와 에러 데이터가 이벤트 콘솔 안에서 사용 가능했다. 모든 콘솔들은 하나의 윈도 혹은 웹 인터페이스안에서 규정됐다.
경쟁 제품들에서와 마찬가지로 애프매니저는 웹스피어 모니터링용으로 정밀한 PMI 성능 통계를 이용하고 있다. 그러나 에이전트 통합은 매우 타이트하며, 애프매니저는 우리 시스템 자원의 포괄적인 뷰를 제공했다.
네트워크 장비 모니터링은 엠피릭스 원사이트나 프로액티브 에이전트와 마찬가지로 하나의 프록시처럼 설정이 된다. 한 가지 큰 차이점이 있다면 대부분의 로봇 트랜잭션들이 타깃 웹 서버에 대해 클라이언트의 역할을 맡는 곳에서 넷아이큐의 애프매니저 네트워크 에이전트는 방대한 수의 사전 지정된 시뮬레이티드 트랜잭션을 이용해 클라이언트와 서버의 역할을 둘 다 할 수 있다는 것이다. 따라서 예를 들어 두 개의 애프매니저 네트워크 에이전트들(하나는 클라이언트로, 하나는 서버로 작동)은 네트워크에서 트랜잭션을 전달할 수 있다. 실질적인 생산 트래픽에는 영향을 받지 않는 성능의 일관성 때문에, 작업처리량에 있어서의 어떠한 변동도 네트워크에 직접적으로 범인으로서 지목이 된다.
애프매니저에는 사전 지정된 유용한 뷰들이 함께 하고 있다. 에이전트는 우리의 시스템과 네트워크 장비에서 역동적으로 파퓰레이팅이 되기 때문에, 우리가 원하는 특정 뷰에 대한 필요조건을 충족시키는 관리 서버 인벤토리로 할당이 된다. 이것은 네트워크 장비나 웹스피어 서버와 같은 요소들을 추가할 때 이들이 자동으로 소팅이 되기 때문에 유용한 기능이다.
단순히 서비스의 상태를 파퓰레이팅하는 기본적인 장비들에게 서비스 뷰를 갖추는 데는 얼마간의 작업이 필요하다. 결국 주주들로 소시지가 만들어지고 있는 것을 볼 수 있게 할 방법이 없다. 그러나 엔드유저가 보는 뷰가 운영팀에서 볼 수 있었던 것과 같다는 점은 마음에 들었다. 이는 컴퓨터 어쏘시에이츠나 콘코드에서 제공하는 것과 같이 서비스에 관한 정보의 하우스 영역에 별개의 뷰가 만들어지는 것과는 대조적이었다. 애프매니저에서는 적용되는 액세스 제어와 함께 이런 뷰가 통합이 돼 있다.
시스템 및 장비로의 액세스와 사용자 및 역할 기반의 인증은 보안 관리 툴을 이용해 지정된다. 우리는 액세스 역할을 설정한 다음, 각각의 역할이 액세스를 해야 할 장비 그룹을 지정했다. 애프매니저는 또한 우리가 네트워크, 시스템 및 애플리케이션의 다른 조각들을 만들 수 있게 해주었다. 우리는 두 개의 애플리케이션에 정렬이 된 뷰를 만들고, 이런한 뷰들로 읽기/쓰기 및 읽기 전용 액세스를 가진 사용자를 만들어냈다.
있었으면 더 좋았을 한 가지는 그룹에 네트워크 장비 액세스를 설정할 수 있는 능력이었다. 예를 들어 우리는 각각의 네트워크 프록시 애프매니저 에이전트에 SNMP 커뮤니티 스트링을 설정해야 했는데, 이보다는 이들을 그루핑하고 전체 그룹용으로 하나의 디폴트값을 설정할 수 있었다면 더 좋았을 것이다.
에이전트 설치 프로세스는 관리 서버와 타깃 서버가 같은 액티브 디렉토리 도메인에 있을 경우 서버에서 윈도 서버로 원격 푸싱될 수 있다. 도메인이 없이 시도하자 실패했는데, 이는 곧 다른 제품들에서처럼 멀리 있는 서버에는 대해자를 수동으로 설치해야 한다는 것을 의미한다.
넷아이큐는 또한 애프매니저가 이렇듯 큰 네트워크에서는 사용되지 않을 것이며, 따라서 그 가격은 더 낮아질 것이라고 말하면서, 우리의 네트워크 모니터링 가격 요건에서 예외를 두었다.

HP
오픈뷰
이 스위트는 테스트한 제품들 가운데 가장 침투력이 높은 모니터링을 제공했는데, 그 이유는 이 제품의 트랜잭션 모니터링이 가장 진보된 모습이기 때문이다. 만약 이것이 성능 모니터링에 한정된 것이 아니라 운영팀에서 데이터베이스 관리자에 이르기까지 모든 사람이 사용하게 될 일괄 시스템에 대한 리뷰였다면, 이 제품이 우승을 차지했을 것이다.
CA 유니센터나 넷아이큐 애프매니저와 마찬가지로, HP의 오픈뷰는 우리의 웹스피어 서버에 전용의 에이전트를 배치해서 성능 데이터를 수집했다. 그런 다음 오픈뷰 트랜잭션 어낼러시스(OpenView Transaction Analysis)와 인터넷 서비스(Internet Service) 컴포넌트가 함께 작동해서 방화벽 외부로부터 웹 서버 티어에서 애플리케이션 서버 티어를 거쳐 데이터베이스 티어로, 그리고 다시 역으로 특정 트랜잭션을 추적했다.
이것은 독립된 로봇 트랜잭션으로 이 모든 층들을 모니터링했던 다른 제품들과는 대조적으로 각각의 지정된 층의 가용성에 초점을 맞춰 모니터링을 했다. 오픈뷰는 이것도 또한 잘 해냈지만, 티어들을 통과하는 각각의 페이로드에 시리얼 ID를 추가했다. 이 같은 마술은 클래스 로드 콜백 후크(Class loader call-back hook)를 이용해 수행되는데, 이 인터페이스는 시작 및 중단 호출로 로더를 래핑하는 작은 삽입물로서, 웹스피어 및 웹로직 애플리케이션 서버 모두가 지원하고 있다.
우리는 웹스피어, SQL 및 윈도 서버 SPI(smart plug-ins)를 설치했다. SPI는 특정 OS, 서비스 및 애플리케이션을 모니터링하는 전문 에이전트로서, 개선점 제안을 탑재하고 있는 스마트한 이벤트 진단을 제공한다. 정말이지 매우 스마트했다.
그다지 스마트하지 않은 부분은 재부팅을 시켜야 했던 웹스피어 기계에서 트랜잭션 분석 에이전트 셋업을 마무리해야 하는 것이었다. 디폴트로, 에이전트는 포트 135을 이용해 커뮤니케이션을 하게 돼 있지만, 포트 135는 우리 호스트에의해 차단이 되기 때문에 HP의 도움을 받아 다른 포트로의 통신을 재설정해야 했다(간단한 일이 아니다). 오픈뷰는 웹스피어 PMI로의 HTTPS와 SOAP 통신을 지원하지만, SOAP는 윈도 플랫폼에서 지원되지 않는다.
HP가 1년의 보증기간을 포함시켰다는 점은 마음에 들었다. 경쟁 제품들의 90일 보증기간을 이 수준으로 업그레이드하려면 5만달러는 지불해야 할 것이다. 하지만 HP는 제품을 이행하는 데 전문가 서비스가 필요하지 않다고 얘기해준 유일한 업체기도 했다.

컴퓨터 어쏘시에이츠
유니센터
이 제품 스위트에는 한때 설치 및 학습을 했던 요소들이 포함이 돼 있으며, 컴퓨터 어쏘시에이츠는 테스트한 제품들 가운데 가장 낮은 가격을 불렀다. 이번 리뷰를 위해 이 회사는 웹 서버용 유니센터 매니지먼트 5.0(Unicenter Mana-gement for Web Servers 5.0), 웹 스피어용 유니센터 매니지먼트 3.5(Unicenter Management for WebSphere 3.5), 유니센터 네트워크 및 시스템 매니지먼트 3.1(Uni-center Network and Systems Management 3.1), 유니센터 서비스 레벨 매니지먼트 3.5(Unicenter Service Level Management 3.5), 그리고 유니센터 매니지먼트 포털 3.1(Unicenter Management Portal 3.1) 등을 보내왔다. 그러나 많은 TLC가 필요하기 때문에 막대한 전문가 서비스와 자체 자원들이 있어야 할 것이다.
CA에는 복잡한 인터페이스와 제품이 있다. 그 레거시 설치 기반에서는 회사에서 너무 많은 인터페이스를 끌어오도록 요구하지만, 최근에는 보다 새로운 자바 기반의 유니센터 익스플로러(Unicenter Explorer)를 추가시켰다. 내부적으로 브라우저를 실행하지는 않기 때문에 비트가 설치돼야 하며, 인터페이스가 그다지 직관적이지 않았지만 이는 분명히 확실한 진보다. 새 인터페이스는 사업팀 사용자가 아니라 운영팀과 서비스 데스크 관리팀을 위해 만들어진 것이다.
사업팀 사용자들은 유니센터 매니지먼트 포털(Unicenter Management Portal)을 통해 유니센터로 액세스할 것이다. 이 포털은 예상하다시피 CA의 서비스 전략에서 가장 우선 순위에 올라 있는 것으로, 액세스 제어, 개인화, 그리고 가장 중요한 역할로 널리 퍼진 CA 유니센터 데이터와 애플리케이션들을 한 자리에 모아주는 등, 포털에서 기대할 수 있는 모든 것을 해준다.
CA는 서로 다른 관리 역할을 위한 디폴트 대시보드를 포털에서 제공하고 있다. 우리는 플랜트스토어와 펫스토어 서비스의 사업팀 및 IT 사용자들을 추적하기를 원했으며, 이를 위해 몇 개의 포털 작업공간을 만들고 이를 나타내는 수치들을 선택했다. 예를 들어 우리는 유니센터 SLM(Service Level Managemt)과 웹 리스판스 모니터, 그리고 웹스피어 에이전트와 CA의 네트워크 및 시스템 관리 플랫폼을 이용해 웹 서버를 모니터링했다.
SLM은 에이전트를 갖고 있으며, 핑, SNMP 질의 및 HTTP 다운로드뿐만 아니라 테스트한 다른 제품들과 마찬가지로 많은 다른 방안들을 돌려서 데이터를 수집했다. 우리는 SML과 포털 안에서 볼 수 있는 보고서들을 통해 성능 데이터를 퍼블리싱했다. 비즈니스 프로세스 뷰(모니터링되고 있는 관련 시스템과 네트워크 프로세스의 정적 및 동적 그루핑)는 불행히도 SML 모니터와 통합이 되지 않는다. 이벤트 상호연관을 통해 서비스 관리를 수행할 수 있긴 했지만, 이렇게 하기는 쉽지가 않으며, SML이 제공하는 종단간 측정법 만큼 효과적이지도 못하다.
에이전트 설치는 수동 프로세스다. 원격 기계에 모든 배포 파일을 설치하기 위해서는 CD를 그린베이로 보내야 했다. 우리는 CA에게 에이전트가 설치용으로 필요로 하는 서브디렉토리를 달라고 부탁했지만, CA는 모든 종속성들이 무엇인지 확인하지 못했다. 원격 설치는 느린 연결에서는 너무 오래 걸릴 것이다. 설치 스크립트는 원격 서버에 에이전트만 설치하는 데 필요한 것이 무엇인지를 밝혀내 주었다. 하지만 CA는 웹 서버 모니터링 에이전트, 웹스피어 모니터링 에이전트, 그리고 시스템 모니터링 에이전트용으로 별도의 제품을 사용하기 때문에, 우리는 두 개의 테스트 서버 모두에서 이 세 개에 대한 별개의 설치를 돌려야 했다. 이것은 확장된 기능성을 얻기 보다는 기본적인 에이전트를 갖는 것으로, 다른 업체들이 사용했던 보다 직관적인 프로세스보다 바람직하지가 못했다.
설치 프로세스는 불안정했으며, 서버 측의 소프트웨어 컴포넌트는 성공적으로 설치되지 않았다(안내문에는 어떠한 오류도 언급돼 있지 않았다). 결국 처음부터 다시 설치를 하고 다시 시도를 해야 했으며, 이번에는 보다 성공적이긴 했지만 여전히 약간의 문제가 있었다. 예를 들어 우리의 웹스피어 서버들은 둘 다 우리 포털에서는 보였지만, 이들을 익스플로러로 로케이팅할 수가 없었다. 따라서 비즈니스 소유주들이 운영팀에서 발견할 수 없는 서비스에 대해 알기에는 좋지가 못하다. 우리는 결국 CA 지원팀의 도움을 받아 웹스피어 서버를 찾았는데, 이것은 탐색시 에러로 인해 ‘Unplaced Objects’ 그룹 안에 들어 있었다.

공정한 가격 비교를 위하여

지나치게 밀접한 관리의 세계에서 타 제품들에 의존하거나 서로간에 통합되는 일은 드물지 않지만, 가격까지 맞추려하자 혼란이 일어났다. 이번 리뷰에서는 그 영향이 가중되었는데, 통합 모델 업체들(콘코드, 엠피릭스, 프로액티브네트)은 분명히 CA나 HP에서 제공하는 것과 같은 덩치 큰 네트워크 관리의 직무를 다시금 만들어낼 필요가 없다. 그리고 이들은 네트워크의 숲을 모니터링하는 비용을 부과하기를 꺼려하고 있다(특히 비교 리뷰와 같은 공식적인 식으로는)
일부 업체들은 우리가 설정한 가격안 시나리오에 반발을 했지만, 우리는 이러한 시나리오야 말로 공정한 비교를 할 수 있는 유일한 방법이라는 판단을 내렸다. 그리고 업체들과 가격 이야기를 주고 받는 동안, 우리는 독자들이 미리 피할 수 있는 사실들을 밝혀 냈다. 가격을 밝혀내기가 완전히 고통스럽기만 한 과정은 아니었다. 예를 들어 업체들은 일반적으로는 엄중한 MSRP 가격을 제시해야 한다는 우리의 요구조건을 존중해 주었다. 이는 채널과 소비자 사이에서 이들의 협상의 위치가 보호받을 수 있게 해준다. 하지만 그때든 지금이든 언제나 우리가 얼마나 이 공간을 평평하게 만들기 위해 열심히 애를 썼던간에, 우리는 사방에서 열기를 감지했다.
이번도 그런 때에 속했다. 우리의 가격 수수께끼는 심지어 HP 오픈뷰로까지 확장되었는데, 그 이유는 이 제품의 고급 트랜스 n티어 트랜잭션 추적 기능 때문이었다. 다른 모든 제품이 각각의 티어를 독립적으로 측정한 다음, 문제가 있을 때는 오류난 티어의 모니터에 의해 오류가 등록됨으로써 오류난 티어가 표시된다는 점을 감안하라. 이에 반해 HP는 각각의 티어로 로봇 트랜잭션을 돌릴 필요 없이 웹 서버에서 시작하기 때문에, 다른 모든 제품들만큼 많은 별개의 인조 트랜잭션들이 필요치 않았다. 우리 가격 시나리오는 모든 업체들이 각각 10개의 엘리먼트를 모니터링하는 100개 로케이션에서의 측정에 대한 가격을 제시할 것을 요구했으며, 이로 인해 HP의 가격은 크게 올라갔다.
이번 경우 우리는 한 가지 외부 공개용 가격을 요청했다. IT와 사업팀의 관심을 함께 모으기 위해 다양한 고객을 지원하는 데 대한 우리의 관심을 설명했다. 업체들로 하여금 필요시될 전문가 서비스는 어떤 것이든 포함을 시키도록 설득을 시켰다. 그리고 대부분의 업체들이 모니터링 되는 인프라 요소의 수와 종류에 따라 가격을 부과하기 때문에, 모니터링돼야 하는 것들의 목록도 만들었다. 우리는 하나의 분산 네트워크에 100개의 분산 로봇 에이전트와 1천개의 수동적 모니터링 에이전트면 된다고 가정했다.
일부 제품들은 넷아이큐, CA, HP 및 콘코드 제품과 같은 스위트들로, 네트워크 모니터링과 같은 다양한 모듈에 대한 옵션 가격도 있었다. 엠피릭스와 프로액티브네트는 거의 모든 것을 포함하고 있지만, 전체 네트워크가 아니라 핵심 경로와 백본 네트워크 장비를 추적하는 용도로 설계되고 가격이 책정돼 있다.
별도의 네트워크 모니터링 옵션이나 포털을 제공치 않는 업체들의 경우, 가격은 처음에는 밝혀지지 않았는데, 그 이유는 우리가 지시한 규모의 네트워크를 완전히 모니터링하기 위해서는 네트워크 관리 제품이 필요했기 때문이다. 모든 업체들이 가격을 완전히 공개하기 위해 최선을 다했다고 생각하지만, 경우에 따라 가격은 상당히 차이가 날 수 있다. 한 업체의 말을 빌자면, ‘이 정도 규모면 제법 큰 할인을 받을 수 있을 것’이기 때문이다.

▶ 리뷰 시나리오
네트워크: 라우팅, 스위칭, 부하조절되는 이기종 네트워크. 방화벽, VPN, 그리고 1만 개 이상의 포트와 2천500개 장비 및 7천500명 사용자; 20개 웹 서버; 아파치, 듀얼 제온 2.4GHz, 2GB 램; 4 웹스피어 서버; 썬 파이어 6800; 두 개의 데이터베이스 서버; 오라클을 돌리는 썬 파이어 E4900; SAN 스토리지; 썬 스토리지 에지 6920; 클라이언트 측 측정; 마이크로소프트 윈도 XP; 100개 합성 에이전트, 각각 10개 트랜잭션 실행(적용 가능한 경우); 1천개 수동적 클라이언트(적용 가능한 경우) 포함.

웹 애플리케이션 성능 모니터 테스트 방법

우리는 본지 시러큐스 대학 리얼월드 랩에 모든 관리 스테이션을 설치하고, 위스콘신주 그린베이의 리얼월드 랩 안에 있는 NWC 비즈니스 애플리케이션 랩에서 IBM 웹스피어 애플리케이션을 테스트했다.
이 테스트를 위해 우리는 각각 아파치 IBM 버전을 돌리는 두 개의 F5 부하조절 윈도 2000 박스에서 실행되는 웹스피어의 디폴트 플랜트스토어와 펫스토어 애플리케이션을 사용했다. 그린베이의 방화벽 뒤에 있는 별개의 기계에뿐만 아니라 웹스피어 서버에서도 모니터를 설치했다. 이런 에이전트들은 우리의 네트워크 장비와 시스템, 웹 서버 및 애플리케이션 서버들을 모니터링했다.
우리는 시러큐스 랩에 에이전트를 설치해 로봇 트랜잭션을 돌리고 네트워크 인프라를 모니터링했으며, 그린베이에 있는 애플리케이션으로 가는 기간 네트워크 경로를 추적했다. 이를 위해 우리는 웹스피어 애플리케이션을 통해 로봇 트랜잭션을 돌렸으며, 네트워크 장비에서 핑과 SNMP gets를 수행했다.
이러하 모니터링외에도 우리는 두 개의 애플리케이션 서비스를 대표하는 그루핑을 오버레이시켰다. 이를 위해서는 두 애플리케이션 모두에 일상적인 장비와 시스템이 네스팅돼야 했으며, 애플리케이션 서비스의 가용성을 확인하기 위한 애플리케이션 전용 웹스피어 빈(WebShpere Beans)도 있어야 했다.
그런 다음 우리는 웹스피어 애플리케이션 서버들 가운데 하나가 고장이 났음을 알리는 경보 작동 방안을 살펴 보았다. 서버는 부하조절 풀에 있었기 때문에 서버 하나의 오류가 비즈니스 소유주에게 전달되는 서비스 보고서의 상태에 영향을 미치는 일은 없기를 바랬다.