왜 제니퍼인가?

왜 제니퍼 인가?

왜 사람들은 제니퍼를 이야기 하는가? 적지않은 자바 어플리케이션 모니터링 솔류션들이 존재하는 속에서도 제니퍼가 유독 돋보이는 것은
나름의 사상을 담고 있기 때문이다. 실제 필드에서 성능튜닝을 수행하던 엔지니어들이 모여서 만들어낸 제니퍼는
다른 솔류션들이 가지고 있지 않은 것들이 포함되어 있다.

1. 실시간 모니터링

모니터링에서 실시간은 중요한 의미를 가지고 있다. 실시간 모니터링이라 함은 수집되는 각종 성능 데이터가 즉시 관찰 가능하다는 것을 의미한다. 그런 의미에서 대부분의 성능 모니터링 제품들은 실시간 개념이 있다고 할 수있다.

그런데 유독 제니퍼가 실시간 모니터링에 탁월하다고 주장하는 이유는 무엇인가? 그것은 제니퍼가 제공하는 실시간 모니터링 항목이 남다르기 때문이다.

제니퍼는 서비스 상태, 사용자, 처리량, 자원 상태등을 실시간으로 모니터링 할 수 있도록 제공하고 있다. 특히 실시간 모니터링 관점에서 타 제품과 가장 차별되는 점은 현재 진행중인 서비스(액티브 서비스)의 개수와 상태를 모니터링 한다는 점이다. 액티브 서비스의 개수의 변화는 제니퍼가 보는 가장 중요한 시스템의 상태이다. 액티브 서비스의 개수가 급작스럽게 증가 한다는 것은 사용자 요청을 현 시점에서 처리하고 있는 서비스 개수가 많아진다는 의미인데, 이는 (경우에 따라 다르지만 대부분의 경우) 요청량이 증가했다기 보다는 어떠한 연유에 의하여 처리 응답시간이 상대적으로 느려지면서 아직 끝나지 않고 처리 중인 서비스의 개수가 상대적으로 증가한다는 것에 더욱 비중이 높다. 이는 곧 서비스가 원할하지 않다는 반증이기도 하다. 액티브서비스 개수는 요청량과 단순한 정비례관계를 갖고 있지 않다.(사실 수학적으로는 분수함수식으로 굴곡 비례하다.) 요청량이 아무리 높더라도 서비스의 응답속도가 한없이 0에 가까우면 액티브서비스개수는 0에 가깝게 나타나며, 요청량이 그다지 높지 않더라도, 응답속도가 상대적으로 많이 느리면 액티브서비스개수는 동시단말사용자수 만큼이나 높아진다. 이처럼 액티브 서비스는 시스템의 상태를 가장 직관적으로 판단할 수 있는 기준이다.

제니퍼는 액티브 서비스를 직관적으로 모니터링할 수있으며 각 서비스의 진행 상태,로드 벨런싱 상태를 실시간으로 확인 할 수있다. 이점은 종료된 서비스의 응답시간혹은 에러를 실시간으로 모니터링 하는 방식의 솔류션과는 효과 측면에서 크게 다르다고 할 수있다

실시간 모니터링에서 중요한 점은 직관적인 분석가능이다. 수십/ 수백개의 모니터링 데이터를 실시간으로 보여준다고해서 사용자가 시스템의 상태를 실시간으로 판단할 수는 없다. 모니터링 담당자가 문제를 실시간으로 분석할 수 있게 쉽고 직관적인 뷰를 제공해야만 실시간 모니터링에 의미가 있다. 여기에는 실시간으로 모니터링 하고자 하는 항목에 대한 단일 뷰와 최소 클릭에 의한 상관정보 조회등이 제공되어야 한다.

혹자는 실시간 대시 보드를 사용자가 임의로 정의할 수 있는 화면을 통해서 구성해야 한다고 주장하기도 한다. 하지만 이것은 반대로 모니터링 솔류션이 시스템을 직관적으로 모니터링 하기 위한 단일 뷰를 가기고 있지 않다는 의미로 해석될 수있다.

제니퍼는 대시 보드에서 최대 3회 클릭 이내에 모든 실시간 모니터링 항목을 배치하고 있으며 직관적인 판단이 가능하도록 필요한 정보를 배치하고 있다. 사용자는 시스템 엔지니어용 대시보드에서 제니퍼가 실시간 모니터링을 위한 생각을 확인할 수 있다

2. 2. 응답시간 분포도

시스템의 장애는 서비스의 응답시간으로 표출된다. 특정 어플리케이션의 수행 에러가 아니라면 성능상의 문제는 반드시 서비스 응답시간의 비정상적인 변화로 표현된다. 그래서 응답시간을 모니터링하는 것은 수행이 지연된 서비스에 대해서 지연 원인을 판단하고 개선하는데 목적이 있다. 지연된 서비스를 개선하기 위해서는 반드시 수행 내역(서비스 프로파일링)을 추적할 수 있어야 한다. 따라서 서비스 응답시간을 모니터링 한다는 것은 응답시간 + 수행 내역을 모니터링 한다는 것을 의미한다.

제 니퍼의 서비스 응답시간에 대한 관점은 한마디로 모두를 개별로(all & each) 모니터링해야 한다는 것이다. 상대적으로 다른 툴에서는 그룹핑에 의한 응답시간 모니터링 방식을 사용하고 있다. 업무별 혹은 단위 시간(30초 혹은 이상)당 수행된 서비스를 지정한 단위로 그룹핑하여 응답시간과 서비스 수행내역을 모니터링 하는 방식을 말한다. 제니퍼가 서비스 응답시간을 개별로 해야 한다는데는 몇가지 이유가 있다.

• 먼저 동일 서비스가 여러 번 수행될 때 특정 Transaction만 응답시간이 지연될 수있다. 어떤 단위로 그룹핑을 하든지 개별 수행 시간은 다른 서비스들과의 평균치에 의해 희석될것이기 때문이다.
  
• 두 번째로 응답시간과 프로파일과의 맵핑문제이다. 그룹핑이 서비스 명 단위로 이루어 진다면 어느정도 연결이 되겠지만 그룹핑이 업무단위로 된다면 프로파일과 그룹핑된 서비스 응답시간 간의 맵핑이 어렵게 될것이고 이것은 지연의 원인을 파악하기 어렵게 한다.
  
• 세번째로 서비스를 명확히 구분하기 어렵다. 서비스 명은 최초 요청(통상적으로 URL) 에 근거하여 정해지기 때문에 내부 조건에 의해 발생하는 로직의 변화를 충분히 반영하기 어렵다. 이렇게 다양하게 변화되는 서비스를 이름이 같다고 해서 하나로 묶는 그룹 기반의 응답시간 모니터링은 장애해결관점에서 효과적이지 못하다

제니퍼의 응답시간 분포도(X-View)는 직관적이면서도 강력한 수단을 제시한다. 하나의 뷰에서 전체 서비스의 개별 응답시간을 보면서 문제에 접근해 가는 것은, 다른 몇 개의 그래프를 통합하여 문제에 접근하는 것보다 쉽고 강력하다.

특정자원의 부족은 응답시간의 지연으로 나타나게 되며 그러한 개별 서비스의 응답시간 분포는 다양 패턴으로 형상화되면서 기존의 모니터링 기법에서 볼 수 없었던 강력한 뷰를 얻을 수 있다.

X- View는 개별 서비스의 응답시간에 해당 서비스의 프로파일링 정보를 연결시킨 개념의 JenniferSoft가 개발한 독특한 개념의 모니터링 기법이다. 특히 X-View는 응답시간을 개별 단위로 모니터링하는데다 해당 서비스의 프로파일링 정보를 즉시 파악할 수 있기 때문에 개별 서비스의 특성에 의한 문제인지 혹은 프레임웍 혹은 WAS엔 진의 문제인지를 즉시 판별할 수 있기 때문에 문제의 해결시간을 수시간/수십분에서 수분/수십초로 줄일 수있다. X-View의 효과는 실시간 모니터링에서 매우 극명하게 느낄 수 있다. 운영중에 혹은 테스팅 중에 발생하는 성능상의 이슈를 빠르고 효과적으로 판단할 수잇게 함으로써 시스템 운영자의 불필요한 작업시간을 드라마틱하게 줄여줄 수있다.

3. 엔터프라이즈 관점(사용자, File,Socket, SQL param 등등…)의 모니터링 사상

• 시스템 모니터링 관점
  엔터프라이즈 시스템에서 사용자에 대한 추적은 업무적/시스템적으로 중요하다, 하루 몇명이나 방문했는지.. 현재 몇 명이 대상 시스템을 사용하고 있는가? 혹은 몇 명이나 동시에 Service Request를 발생시키고 있고, 얼마나 서비스가 처리되고 있는가? 이런 것들을 종합하여 분석해야만 시스템의 용량을 정확히 판별할 수 있고 시스템의 용량이 판별이 되어야만 튜닝을 해야 할지 용량을 늘려야 할지를 판별할 수 있다. 제니퍼는 이러한 질문에 답하는 가장 최상의 툴이다. 제니퍼의 강점은 시스템에 대한 판단을 단순히 자바 시스템의 관점이 아닌 엔터프라이즈 시스템 관점에서 판단할 수 있도록 도와 주고 있다는 것이다.
  성능이론에 기반한 사용자 추적, 개별 CPU기반의 CPU모니터링 등등을 보면 제니퍼의 자원 모니터링의 효율성을 느낄 수있다.

• Transaction 프로파일링 관점
  기업 정보 시스템은 게임 프로그램이나 PC 어플리케이션과는 성격이 다르다. 사용자가 많고 속도와 안정성이 중요하며 Critical 데이터를 처리하는 경우가 대 부분이다. 이것을 모니터링 한다면 당연히 개별 코드 보다는 서비스 흐름(Transaction flow)관점에서 나아가 전체 시스템관점에서 중요한 항목 위주로 모니터링 되어야 한다. 제니퍼는 Transaction을 모니터링할 때 코드에 대한 추적 보다는 파일 소켓 SQL등 연계 위주의 추적을 중시 하고 있다. 제니퍼는 Transaction을 추적할 때 SQL문, SQL파라미터, SQLException을 중심으로 추적한다. JDBC 자원 미반환에 대해서 철저히 모니터링하고 있으며 또한 다양한 수단으로 Application명을 지정할 수 있도록 하는 수단을 제공하고 있다. 이러한 것들이 바로 제니퍼가 엔터프라이즈 시스템에 강하다는 것을 보여주고 있는 것들이다.

4. Easy & Powerful

• EASY
  모니터링 솔루션은 쉬워야 한다. 이것은 어떤 소프트웨어에도 해당되는 이야기 이지만 모니터링 관련 솔류션에서는 특히나 중요하다. 운영을 위해 담당자는 수많은 S/W와 H/W에 익숙해져야 한다. 모니터링을 위해 또다른 툴을 장시간 익혀야 한다는 것은 현실적이지 않으며 쉽고 빠르게 이해하고 사용할 수 있어야 한다.
  제니퍼는 관리자(CIO)와 운영자(개발자)가 같이 보는 툴이다. 실제로 그러한 고객들이 존재하고 있으면 이것는 제니퍼가 그만큼 직관적이라는 것을 의미한다. 처음 사용하는 사용자도 단 몇분의 설명을 통해서 제니퍼를 활용할 수있다.

• POWERFUL
  모니터링 솔류션이 쉽기만 해서는 부족하다. 초급 사용자에게는 직관적이며 쉽게 접근할 수있어야하지만 전문가를 위해서는 보다 깊이있는 정보를 제공해야만 문제해결에 직접적으로 활용할 수있을 것이다.
  제니퍼는 APM솔류션에서는 중요시 되지 않던 정보들을 제공하고있다. 제니퍼는 Socket OPEN, File 접근과 같은 정보 혹은 JDBC자원 추적에 대한 상세한 정보들, TP연계에 대한 서비스 명을 제공하고있으며 나아가 서비스 수행내역에서 특정 메소드의 파라미터값등을 모니터링 할 수있을 뿐만 아니라, 사용자 정의형 로직을 AOP개념으로 추가할 수 있는 기능들이 제공된다.,
  특히나 제니퍼는 사용자가 임의의 모니터링 항목을 추가할 수 있는 모니터링 프레임웍(ADF)을 포함하고 있어, 전문가는 이론적으로 제니퍼를 통해 시스템,DB등을 통합 모니터링 할 수 있다.
  그래서 전문적인 어플리케이션 성능 컨설턴트들이 가장 선호하는 모니터링 제품이 바로 제니퍼이다.