KR20070038637A

KR20070038637A - 자바 바이트 코드의 데이터 모니터링 시 모니터링된데이터의 호출관계 규명 방법

Info

Publication number: KR20070038637A
Application number: KR1020050093795A
Authority: KR
Inventors: 전재성
Original assignee: (주)아이피엠에스
Priority date: 2005-10-06
Filing date: 2005-10-06
Publication date: 2007-04-11
Also published as: KR100750834B1

Abstract

자바 어플리케이션에서 성능 데이터 추출을 위한 모니터링 방법 및 호출 관계 추적 방법이 개시된다. 본 발명에 따른 모니터링 방법은, 자바 클래스로더가 디스크 혹은 네트워크상에서 클래스 바이트 스트림을 메모리에 로드하여 클래스를 생성하기 직전, 로딩된 바이트 스트림의 자바 버추얼 머신 바이트 코드 인스트럭션 셋 분석을 통해 모니터링 대상이 되는 클래스 및 메소드를 식별할 수 있으며 또한 모니터링 대상 클래스 메소드에 추가적인 성능 추출코드를 삽입함으로써 클래스 및 메소드의 호출정보를 수집할 수 있다. 또한, 모니터링 대상이 되는 클래스를 실행한 자바 스레드 및 스택, 링크된 리스트의 자료구조를 이용하여 특정 스레드가 수행한 모든 클래스 및 메소드의 호출 관계를 규명할 수 있다.

자바 바이트 코드, 데이터 모니터링, JVM, 자바 바이트 코드 인스트루먼테이션

Description

자바 바이트 코드의 데이터 모니터링 시 모니터링된 데이터의 호출관계 규명 방법{A method of data call stack tracing in data monitoring of JAVA byte code}

도 1은 본 발명에 따른 데이터 추출을 위한 모니터링 방법을 대략적으로 나타낸 흐름도이다.

도 2는 성능 정보 추출 코드를 삽입하는 구체적인 단계를 나타낸 흐름도이다.

도 3은 일반적인 웹 상에서 운영되는 어플리케이션의 클래스 구성도를 나타낸다.

도 4는 도 3의 클래스 구성에 따른 어플리케이션 실행 순서를 나타낸 구성도이다.

도 5는 도 3의 어플리케이션을 실행하여 본 발명에 따라 성능 정보를 추출하여 모니터링한 결과를 예시적으로 나타낸다.

도 6은 본 발명에 따른 클래스 실행 과정을 나타낸 블록도이다.

도 7은 본 발명에 따른 데이터 모니터링 정보의 추적 방법을 나타낸 흐름도이다.

도 8은 본 발명에 따른 트리 구조 형성 단계를 나타내는 흐름도이다.

도 9는 도 3 및 도 4에 도시된 클래스 구성을 갖는 어플리케이션을 본 발명을 이용하여 호출 관계를 트리 구조로 나타낸 결과이다.

도 10은 본 발명의 호출 관계 추적 방법을 이용한 호출 관계를 디스플레이 하는 일 예를 나타낸다.

본 발명은 자바 프로그래밍 방법에 관한 것으로, 구체적으로는 자바 바이트 코드 조작을 통해 필요한 데이터를 모니터링하는 방법에 관한 것이다.

자바(JAVA)는 처음에는 가전 제품에서 운영된 소프트웨어 플랫폼을 개발하기 위해 만들어진 언어이다. 플랫폼에 독립적이고 네트웍을 통해 실행가능 코드를 다운로드하여 JVM이 실행할 수 있는 이점과 인터넷의 발전으로 인해, 1995년 썬 마이크로시스템즈(Sun Microsystems)에서 자바(Java) 언어와 핫자바(HotJava)를 발표하면서 세상에 나오기 시작했다. 핫자바(HotJava)는 자바 언어로 만든 웹브라우저를 말한다. 그리고 네스케이프(Netscape)와 라이센스 계약을 통해 Netscape 브라우저에서 자바가 시행됨으로써 전 세계로 자바가 확산되었다.

한편, 안정적인 어플리케이션 운영을 위해 각 어플리케이션의 각종 모니터링 정보 예를 들어, 응답 속도에 대한 정보, 어플리케이션이 어느 정도 메모리를 차지 하고 있는 지에 대한 정보, 클래스 정보, 메소드 정보 및 각종 변수에 대한 정보를 파악할 필요가 있다.

이 경우, 종래에는 자바 프로그래밍에서 클래스(Class) 및 메소드(Method)를 모니터링하기 위해서는 어플리케이션의 소스 코드에 모니터링을 위한 성능 정보 추출 코드를 삽입하는 방법을 사용하였다.

즉, 어플리케이션의 개발 단계에서부터 어플리케이션의 소스 코드에 성능 정보 추출 코드를 삽입하여 추출 코드가 삽입된 채로 컴파일을 한 후, 프로그램을 구동한다. 그리고 나서 프로그램을 구동하는 경우에는 성능 정보 추출 코드를 통해 필요한 정보를 모니터링하게 된다.

예를 들어, 어플리케이션 소스 코드 내에 특정 클래스가 동작을 시작하는 CPU 시간과 상기 특정 클래스가 동작을 끝내는 CPU 시간을 추출하도록 하는 타이밍 정보 추출 코드를 통해, 상기 특정 클래스가 실행되는 시간을 측정할 수 있다.

이와 같은 경우, 불필요한 소스 코드의 추가로 인해 어플리케이션의 크기가 늘어나게 되는 문제가 있다. 또한, 모니터링 대상이 되는 클래스(Class) 및 메소드(Method)는 동적으로 관리가 되어야 하나, 어플리케이션의 소스 코드를 수정하게 되면 매번 모니터링 정보를 수집하는 코드를 추가/삭제하게 재컴파일을 해야하는 반복적이고 소모적인 작업들이 필요하게 된다.

본 발명이 이루고자 하는 기술적 과제는, 모니터링 정보를 얻기 위해 소소 코드를 어플리케이션 개발 단계에서 삽입하지 않고도 용이하게 정보를 추출할 수 있는 방법을 제공하는 것이다.

본 발명이 이루고자 하는 다른 기술적 과제는 어플리케이션의 소스 코드를 매번 수정하여 재컴파일하는 소모적인 작업 없이도 모니터링 정보를 추출하는 방법을 제공하는 것이다.

본 발명이 이루고자 하는 다른 기술적 과제는 모니터링된 자바 클래스 및 메소드의 호출관계를 규명하는 방법을 제공하는 것이다.

상술한 바와 같은 본 발명의 목적을 달성하기 위해, 본 발명의 특징에 의하면, 자바 바이트 코드 조작을 통해 성능 데이터를 추출하기 위한 모니터링 방법은, 어플리케이션 실행 명령이 인가되는 단계, 자바 버추얼 머신이 클래스 바이트 스트림을 로드하는 단계, 로딩된 바이트 스트림 판독 및 모니터링 바이트 코드를 삽입하여 변조하는 단계, 상기 모니터링 코드가 삽입된 변조 바이트 코드에 해당하는 클래스 생성 단계, 및 모니터링 대상 정보를 추출하는 단계를 포함한다.

성능 데이터는 응답 시간, 클래스 정보, 메소드 정보, 및 각종 파라미터 정보를 포함하며, 모니터링 대상은 환경 파일로 지정되어 동적으로 변경이 가능하다.

바람직하게는, 상기 모니터링 코드 삽입 단계는 모니터링 대상 메소드의 시작 부분과 끝 부분에 시작과 끝 메소드를 삽입하는 단계를 포함한다. 상기 모니터링 코드 삽입 단계는, 파라미터가 있는 경우 상기 모니터링 코드는 상기 파라미터 를 수집하도록 자동코딩된다.

더욱 바람직하게는, 모니터링 코드 삽입 단계는, 자바 클래스 파일의 포맷을 분석하는 단계, 모니터링 대상이 되는 메소드의 바이트 코드 인스트럭션 셋(byte code instruction set)을 변경하는 단계, 및 성능 정보 추출 코드를 삽입하는 단계를 포함한다. 이때, 성능 정보 추출 코드 삽입 단계는, 자바 바이트 코드 인스트루먼테이션을 통해 삽입될 수 있다.

본 발명의 다른 특징에 의하면, 자바 바이트 인스투르먼테이션(Java byte instrumentation)을 통해 모니터링된 클래스 및 메소드의 호출 관계를 규명하는 방법은, 모니터링 대상이 되는 클래스를 실행한 자바 바이트의 스레드(thread) 별로 스택을 생성하는 단계, 시작 메소드 호출 시 모니터링된 데이터를 상기 스택에 푸시(Push)하는 단계, 끝 메소드 호출 시 모니터링된 데이터를 상기 스택에서 팝(Pop)하는 단계, 및 각 실행되는 클래스 및 메소드의 링크 구조를 이용하여 호출 관계를 추적하는 단계를 포함한다.

호출 관계 추적 단계는, 상기 스택에서 푸시 및 팝되는 데이터에 대응되는 클래스 및 메소드의 순서에 기초하여 상기 모니터링된 데이터를 트리 구조로 형성하는 단계를 더 포함한다.

바람직하게는, 상기 트리 구조 형성 단계는, 상기 스택으로 데이터를 푸시하는 경우에, 현재 메소드에 대응하는 트리 아래에 새롭게 호출된 메소드에 대응하는 하위 트리를 형성하는 단계, 상기 생성된 하위 트리에 모니터링된 데이터를 매핑하는 단계, 및 상기 스택으로 데이터를 팝하는 경우에, 현재 호출된 메소드에 대응하 는 트리의 상위 트리로 이동하는 단계를 포함할 수 있다.

본 발명과 본 발명의 동작성의 이점 및 본 발명의 실시에 의하여 달성되는 목적을 충분히 이해하기 위해서는 본 발명의 바람직한 실시예를 예시하는 첨부 도면 및 첨부 도면에 기재된 내용을 참조하여야만 한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 설명함으로써, 본 발명을 상세히 설명한다. 각 도면에 제시된 동일한 참조부호는 동일한 부재를 나타낸다.

도 1을 참조하면, 본 발명에 따른 데이터 추출을 위한 모니터링 방법은, 우선, 어플리케이션 실행 명령이 인가되어 어플리케이션을 실행하면(S100), 자바 버추얼 머신(JAVA Virtual Machine)의 클래스 로더가 바이트 스트림을 메모리에 적재한다(S200). 자바 버추얼 머신(JAVA Virtual Machine; JVM)은 자바로 작성된 프로그램이 어떤 환경에서든지 작동할 수 있도록 해주는 기능을 한다. 이때 자바 버추얼 머신에 의해 판독되는 어플리케이션 소스 코드에는 성능 정보 추출을 위한 코드는 삽입되지 않는 상태의 오리지널 어플리케이션 소스 코드만이 존재한다.

그런 다음, 자바 버추얼 머신은 모니터링 대상 클래스 및 메소드를 식별하고 성능 정보 추출 바이트 코드를 판독된 어플리케이션 소스 코드에 삽입한다(S300). 그리고, 자바 버추얼 머신이 변경된 바이트 코드를 가지고 클래스를 생성하고 (S400), 어플리케이션을 재실행한다(S500). 그리고, 실행되는 어플리케이션을 통해 필요한 성능 정보가 추출될 수 있다(S600).

도 2는 성능 정보 추출 바이트 코드를 삽입하는 구체적인 단계를 나타낸 흐름도이다.

도 2를 참조하면, 성능 정보 추출 바이트 코드 삽입 단계(S300)는, 우선 자바 클래스 파일의 포맷을 분석하고(S301), 모니터링 대상이 되는 메소드의 바이트 코드 인스트럭션 셋(byte code instruction set)을 변경한다(S302). 그리고, 성능 정보 추출 코드를 어플리케이션 소스 코드 내의 필요한 위치에 삽입한다(S303).

이때, 상기 성능 정보 추출 코드를 삽입하는 단계는 자바 바이트 코드 인스트루먼테이션(Java Byte Code Instrumentation)이라 불리는 바이트 코드 분석 및 조작기술을 통해 삽입한다.

자바 바이트 코드 인스트루먼테이션은 기존 어플리케이션 소스 코드의 수정 없이 자바 어플리케이션의 런타임(Runtime) 시에 모니터링 대상이 되는 클래스 및 메소드를 선별하여 모니터링 관련된 바이트 코드 인스트럭션(Byte Code Instruction)을 추가하는 일련의 코드 분석 및 조작기술이다.

다수의 클래스로 구성된 자바 어플리케이션이 실행되기 위해서는 커스텀 클래스 로더(Custom Class Loader) 및 JDK(Java Development Kit)의 내부 클래스 로더가 디스크 혹은 네트워크를 통해 해당 클래스를 구성하는 바이트 코드 인스트럭션 셋들로 구성된 바이트 스트림을 메모리에 로드한 후, 자바 버추얼 버신(Java Virtual Machine)이 제공하는 네이티브 메소드(Native Method) 즉, defineClass0() 호출을 통해 어플리케이션에서 사용할 수 있는 클래스를 생성하는 과정을 반드시 거치게 된다.

이 과정에서 네이티브 메소드 호출로 클래스를 생성하기 직전, 로딩된 바이트 스트림의 자바 버추얼 머신 바이트 코드 인스트럭션 셋 분석을 통해 모니터링 대상이 되는 클래스 및 메소드를 식별할 수 있다. 또한, 성능 및 실행정보를 위한 바이트 코드 인스트럭션 셋을 동적으로 해당 클래스 및 메소드 내 즉, 메소드의 시작 및 종료 시점에 추가할 수 있다.

예를 들어, 다음과 같은 원본 소스 코드가 존재하는 경우,

public void monitorMethod()

{

system.out.println("monitorMethod() called..");

}

성능 데이터를 추출하기 위해 소소 코드 레벨에서 성능 정보 추출 코드를 추가하지 않고, 어플리케이션 실행 시 동적으로 성능 수집 코드를 삽입한다. 즉, 자바 버추얼 머신이 로딩된 바이트 스트림으로 클래스를 생성하기 전에 성능 정보 추출 코드를 동적으로 삽입한다.

성능 정보 추출 코드가 삽입되면, 소소 코드는

public void monitorMethod()

{

J2EECallStackTracer.startGenMethod(this,"monitorMehtod");

system.out.println("monitorMethod() called..");

J2EECallStackTracer.endGenMethod(this,"monitorMethod");

}

가 된다.

위와 같이, 모니터링 대상 메소드의 시작 부분과 끝 부분에 start Method(즉, PerColllector.startGenMethod) 와 end Method (즉, PerCollector.endGenMethod) 가 삽입된다.

또한, 성능 정보에는 메소드의 아규먼트(argument)로 넘어가는 파라미터(Parameter)가 있을 경우 경우에 따라 파라미터도 성능수집 정보에 포함시킬 수 있다.

예를 들어, 다음과 같은 원본 소스 코드가 존재하는 경우,

public void monitorMethod(Object param1)

{

system.out.println("captureMethod() called..");

}

자바 버추얼 머신이 파라미터 정보를 포함하는 성능 정보 추출 코드를 삽입하면, 소소 코드는

public void monitorMethod(Object param)

{

J2EECallStackTracer.startGenMethod(this,"monitorMehtod", parameter);

system.out.println("captureMethod() called..");

J2EECallStackTracer.endGenMethod(this,"monitorMethod", parameter);

}

가 된다.

도 3의 어플리케이션 클래스 구성도는 WAS 의 스레드 풀(Thread Pool) 내의 개별 스레드(Thread)가 특정 URL의 요청(request)를 받아서 다양한 자바 클래스를 수행하고 최종적으로 JDBC를 통해 데이터베이스에서 데이터를 질의한 후 결과를 클라이언트에게 보내주는 웹 어플리케이션(Web application)을 클래스 구성도로 나타낸 것이다.

도 3을 참조하면, 어플리케이션은 메인서블렛(MainServlet; 301)이 세션파사드 클래스(SessionFacad; 302)를 호출하고, 세션파사드클래스는 비즈니스 오브젝트(BusinessObject; 303), 비즈니스 엔티티(BusinessEntity; 304), 데이터 억세스 오브젝트(DataAccessObject; 305), 및 비즈니스 세션(BusinessSession; 306)을 호출한다. 데이터 억세스 오브젝트(305)는 JDBC(Java Database Connectivity) 클래스(307) 호출을 통해 DBMS 관련 작업을 수행한다.

도 4는 도 3의 클래스 구성에 따른 어플리케이션 실행 순서를 나타낸 구성도 이다.

도 4를 참조하면, 특정 URL을 받은 후 WAS 내의 스레드(thread)가 메인서블렛(301)을 실행하고, 메인서블렛(301)은 세션파사드(302)를 실행하고, 세션파사드(302)는 비즈니스 엔티티(304)를 실행한다. 이러한 순서로, 비즈니스 엔티티(304)로의 제1 억세스(401)가 종료된다.

또한, 메인서블렛(301)은 세션파사드(302)를 실행하고, 세션파사드(302)는 비즈니스 세션(306)을 실행하고, 비즈니스 세션(306)은 비즈니스 엔티티(304)를 다시 실행한다. 이러한 순서로, 비즈니스 세션(306)으로의 제2 억세스(402)가 종료된다.

또한, 메인서블렛(301)은 세션 파사드(302)를 실행하고, 세션파사드(302)는 데이터 억세스 오브젝트(305)를 실행하고, 데이터 억세스 오브젝트(305)는 JDBC(307)를 실행한다. 이러한 순서로, 데이터 억세스 오브젝트(305)로의 제3 억세스(403)가 종료된다. 그리고, 메인서블렛(301)은 이러한 순서대로 각 클래스를 실행한 결과를 클라이언트(즉, 웹 브라우저)로 전송한다.

도 3의 어플리케이션의 개략적인 소스 코드는 다음과 같이 표현될 수 있다.

(기존 소스 - MainServlet)

public void doPost(HttpRequest req, HtpResponse resp)

{

.....

SessionFacad sesseionFacad = new SessionFacad()

ret1 = sessionFacad.getEntity1();

ret2 = sessionFacad.getBusinessSession();

ret3 = sessionFacad.seletMain();

.....

}

그리고, 본 발명에 따라 자바 버추얼 머신이 원본 소스 코드를 판독한 뒤 메모리에 로딩하기 전 모니터링 코드가 삽입된 모습은 다음과 같다.

public void doPost(HttpRequest req, HtpResponse resp)

{

J2EECallStackTracer.beginServlet(this,"doPost", req);

.....

SessionFacad sessionFacad = new SessionFacad()

ret1 = sessionFacad.getEntity1()

ret2 = sessionFacad.getBusinessSession();

ret3 = sessionFacad.selectMain();

.....

J2EECallStackTracer.endServlet(this, "doPost", req);

}

즉, 모니터링 대상 메소드의 시작과 종료 시점에 성능 데이터 수집에 관련된 method(위 예에서는, begin, end)를 추가하여 beginServlet()으로부터 endServlet() 까지의 응답시간 및 CPU 시간을 측정할 수 있다.

도 5를 참조하면, 서블렛(SERVLET) 카테고리의 메인서블렛(MainServlet; 501)이 전체 2000ms 동안 수행된다. 이는 메인 서블렛(MainServlet) 아래의 세션파사드(SessionFacad)라는 세 개의 EJB(Enterprise JavaBeans) 카테고리(502, 503 및 504)가 수행되는 시간의 합이 된다. 도 5의 예에서는, SessionFacad의 EJB의 getEntity1(), getBusinessSession()을 호출하는 데 각각 500ms 가 걸리고, SessionFacad의 selectMain()이 1000ms 동안 수행됨을 쉽게 파악할 수 있게 된다.

한편, 상술한 바와 같이, 모니터링 대상은 응답 시간뿐만 아니라, 각종 파라미터, 클래스 정보, 메소드 정보가 될 수도 있다. 이러한 모니터링 대상은 환경 파일로 저장될 수 있다.

이때, 모니터링 코드를 통한 클래스 및 메소드의 호출 시, 모니터링 대상 클래스 정보는 자바의 클래스 자체를 가리키는 키워드를 통해 호출하고, 수집하는 클래스에서는 넘겨받은 클래스 정보를 통해 대상 클래스 명을 추출할 수 있다. 그리고, 모니터링 대상 메소드 이름은 자바 클래스 파일의 Methods, Constant Pool 영역을 분석함으로써 추출할 수 있다. 또한, 모니터링 대상 메소드의 파라미터(parameter)는 추가된 바이트 코드 인스트럭션 셋(byte code instruction set)을 통해 파라미터를 추출할 수 있다. 그리고, 모니터링 대상 클래스의 메소드를 실행한 스레드(Thread) 정보는 JDK(Java Development Kit) 의 API(Application Program Interface)를 통해 추출가능하다.

예를 들어 성능 정보를 수집하는 클래스에서는 현재 시간을 추출하는 메소드와 CPU 타임을 측정하는 JDK API 호출을 통해서 모니터링 대상 메소드의 시작과 종료 시점의 차이를 통해 응답 시간과 CPU 시간을 측정할 수 있게 된다.

도 6을 참조하면, 본 발명에 따른 클래스 실행 과정은, 먼저 자바 프로그램을 최초로 구동하게 하는 자바 스레드(601)가 실행된다. 그리고, 나서 모니터링 코드가 삽입된 자바 클래스, 즉 바이트 코드 인스투르먼테이션 된 자바 클래스(602)가 실행된다.

그러면, 본 발명에 따른 호출 정보 추적부(603)를 통해, 호출된 데이터의 상호 호출 관계를 판단한다. 이때, 본 발명에 따르면, 호출 정보 추적부(603)는 호출된 메소드 스택(stack)을 구성하고 데이터 호출 순서를 추적하는 메소드 스택 구성부(604)와 클래스 및 메소드 트리를 구성하는 클래스 및 메소드 트리 구성부(605)를 포함한다.

메소드 스택 구성부(604)는 자바 바이트의 스레드별로 스택을 구성하여, 시작 메소드 호출 시 모니터링된 데이터를 스택에 입력(즉, 푸시; push)하고, 끝 메소드 호출 시 모니터링된 데이터를 스택에서 출력(즉, 팝; pop)하는 기능을 한다. 메소드 스택 구성부(604)에서의 데이터 호출 순서 및 메소드 및 클래스 트리 구성부(605)에서의 트리 구조는 디스플레이부(606)에서 사용자에게 디스플레이 될 수 있다.

도 7을 참조하면, 본 발명에 따른 모니터링 정보 추적 방법은, 먼저 모니터링 코드가 삽입된 자바 클래스가 실행되면(S701), 자바 바이트의 스레드(thread) 별로 스택을 생성한다(S702). 그리고, 모니터링 코드에 의해 시작 메소드가 호출 되면 모니터링된 데이터를 생성된 스택에 푸시(push)한다(S703). 또한, 모니터링 코드에 의해 끝 메소드가 호출되면 대응되는 메소드의 모니터링된 데이터를 스택에서 팝(pop)한다(S704). 그리고 나서 상기 스택에 푸시 되거나 팝 되는 데이터를 그 순서에 따라 정리하여 호출 관계를 트리 구조로 형성한다(S705). 그런 다음, 트리 구조와 트리 구조에 대응되는 모니터링 정보를 사용자에게 디스플레이 한다(S706).

스택 구조는 FILO(First In Last Out)의 구조를 갖는다. 즉, 맨 처음 입력된 데이터는 맨 마지막에 출력되고, 맨 마지막에 입력된 데이터부터 출력되는 구조를 갖는다. 호출된 데이터를 이와 같은 스택 구조로 저장하고 이를 트리 구조로 생성하면 모든 클래스 및 메소드의 호출 관계를 추적할 수 있다.

도 8을 참조하면, 트리 구조 형성 단계는, 모니터링 코드가 삽입된 자바 클래스가 실행되어 데이터를 호출하면(S801), 시작 메소드 호출에 의해 스택에서 데이터를 푸시 하는 경우, 현재 메소드에 대응하는 트리 아래에 새롭게 호출된 메소드에 대응하는 하위 트리를 형성하고(S802), 생성된 하위 트리에 모니터링된 데이 터를 매핑한다(S804). 그리고, 끝 메소드 호출에 의해 스택에서 데이터를 팝하는 경우, 현재 호출된 메소드에 대응하는 트리의 상위 트리로 이동한다(S803). 그리고, 다시 다음 호출된 메소드의 데이터를 호출하는 것을 반복하여 트리 구조를 완성한다.

이러한 트리 구조는, 모니터링 대상이 되는 클래스를 실행한 자바 스레드 및 스택, 링크된 리스트의 자료구조가 되며, 이를 이용하여 특정 스레드가 수행한 모든 클래스 및 메소드의 호출 관계를 규명할 수 있다..

이하, 도 3, 도 4 및 9를 참조하여, 본 발명에 따른 모니터링 정보의 호출 관계 추적 방법 및 이를 이용한 트리 형성 과정을 구체적으로 설명한다.

자바의 콜 스레드가 실행되면, 도 4의 제1 억세스 단계(401)에 나타낸 바와 같이, MainServlet 클래스(301)를 호출하여 MainServlet(301)에서 모니터링된 데이터를 스택에 입력한다(S901). 그리고, MainServlet(301)은 SessionFacad 클래스(302)를 호출한다(S902). 그러면, SessionFacad(302)에서 모니터링된 데이터가 스택에 입력된다. 그리고, SessionFacad(302)는 BusinessEntity(304)를 호출하고(S903), BusinessEntity(304)에서 모니터링된 데이터가 스택에 입력된다. 그런 다음, 끝 메소드 호출에 의해 BusinessEntity(304)에서 모니터링된 데이터를 스택에서 출력하고, 그런 다음 SessinFacad(302)에서 모니터링된 데이터를 스택에서 출력한다.

그런 다음, 도 4의 제2 억세스 단계(402)에 나타낸 바와 같이, 다시 MainServelt(301)은 SessionFacad(302)를 다시 호출하고(S904), SessionFacad(302)에서 모니터링된 다른 데이터가 스택에 입력된다. 그리고, SessionFacad(302)는 BusinessEntity(304)를 다시 호출한다(S905). 그리고, BusinessEntity(304)에서 모니터링된 데이터가 스택에 입력된다. 그런 다음, 각 클래스의 실행이 종료되면, BusinessEntity(304), SessionFacad(302)의 순으로 스택에서 데이터가 출력된다.

그리고, 도 4의 제3 억세스 단계(403)에 나타낸 바와 같이, 다시 MainServlet(301)은 SessionFacad(302)를 다시 호출하고(S906), SessionFacad(302)에서 모니터링된 또 다른 데이터가 스택에 입력된다. 그리고, SessionFacad(302)는 BusinessDAO(DataAccessObject)(305)를 호출한다 (S907). 그러면, BusinessDAO(305)에서 모니터링된 데이터가 스택에 입력된다. BusinessDAO(305)는 JDBC(307)를 호출하고, JDBC(307)에서 모니터링 된 데이터가 스택에 입력된다(S908). 그리고, JDBC(307)의 실행이 완료되면, JDBC(307), BusinessDAO(305) 및 SessionFacad(302)의 순으로 스택에서 데이터가 출력된다.

이와 같은 과정을 끝내면 도 9에 도시된 트리 구조가 완성될 수 있다.

도 10은 본 발명의 호출 관계 추적 방법을 이용한 호출 관계를 디스플레이하는 일 예를 나타낸다.

도 10을 참조하면, 넘버(No.) 2번의 Servlet 카테고리를 보면 모두 597ms의 시간이 걸리는 것을 볼 수 있다. Servlet의 하위 클래스 중에서는 5번에 표시된 Servlet 카테고리가 589ms 로 그 중에서 가장 많은 시간을 차지하고 있으며, 이 중 에서도 7번의 Servlet 카테고리가 528ms를 차지하여 가장 많은 시간을 소비하고 있다.

이런 식으로 본 발명에 따른 호출 관계 추적 방법을 이용한 호출 관계 및 응답 시간 등의 모니터링 데이터를 통해 성능저하의 주 원인이 되는 어플리케이션 및 병목 구간을 쉽게 찾아 낼 수 있다. 이러한 성능저하의 원인을 찾을 수 있으면, 용이하게 이에 대한 대응방안도 찾을 수 있고 이에 따라 전산 시스템의 안정적이 운영과 기업 이미지 향상에도 크게 기여 할 수 있을 것이다.

도 10에 도시된 일 예에서는 11번 JDBC CONN 카테고리, 즉 java.sql.connection#prepareStatement 클래스가 성능 저하의 주 원인 임을 쉽게 찾을 수 있다

이렇게 모니터링된 응답 시간, 각종 파라미터, 클래스 및 메소드 정보를 통해 해당 어플리케이션 코드의 각 정보를 파악하고 프로그램의 최적화 및 각종 문제를 적절하게 해결할 수 있게 된다.

본 발명은 도면에 도시된 일 실시예를 참고로 설명되었으나, 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

본 발명에 따른 모니터링 방법에 따르면, 모니터링 코드를 어플리케이션 개 발 단계에서 삽입하지 않고 각종 모니터링 대상을 검출할 수 있어 어플리케이션 소스 코드를 매번 수정하여 컴파일하는 소모적인 작업을 없앨 수 있다.

또한, 본 발명에 따른 호출 관계 추적 방법을 이용하면, 수많은 클래스 및 메소드들로 이루어진 자바 어플리케이션의 병목 구간을 쉽게 파악하여 해당 클래스 및 메소드들 그리고 SQL 등을 수정함으로써 어플리케이션의 성능향상에 기여할 수 있다.

Claims

자바 바이트 코드 조작을 통해 성능 데이터를 추출하기 위한 모니터링 방법에 있어서,

어플리케이션 실행 명령이 인가되는 단계;

자바 버추얼 머신이 바이트 코드 스트림을 메모리에 로딩하는 단계;

로딩된 클랫의 바이트 코드 인스트럭션을 분석하여 상기 로딩된 소스 코드에 성능 데이터의 모니터링을 위한 모니터링 코드를 삽입하여 변조하는 단계;

상기 모니터링 코드가 삽입된 바이트 코드로 클래스를 생성하는 단계; 및

모니터링 대상 정보를 추출하고 가공하는 단계를 포함하는 것을 특징으로 하는 모니터링 방법.
제 1 항에 있어서,

상기 성능 데이터는 응답 시간, 클래스 정보, 메소드 정보, 및 각종 파라미터 정보를 포함하는 것을 특징으로 하는 모니터링 방법.
제 2 항에 있어서,

상기 모니터링 대상은 환경 파일로 지정될 수 있는 것을 특징으로 하는 모니 터링 방법.
제 1 항에 있어서,

상기 모니터링 코드 삽입 단계는 모니터링 대상 메소드의 시작 부분과 끝 부분에 시작과 끝 메소드를 삽입하는 단계를 포함하는 것을 특징으로 하는 모니터링 방법.
제 4 항에 있어서,

상기 모니터링 코드 삽입 단계는,

파라미터가 있는 경우 상기 모니터링 코드는 상기 파라미터를 수집하도록 자동코딩 되는 것을 특징으로 하는 모니터링 방법.
제 1 항에 있어서,

상기 모니터링 코드 삽입 단계는,

자바 클래스 파일의 포맷을 분석하는 단계;

모니터링 대상이 되는 메소드의 바이트 코드 인스트럭션 셋(byte code instruction set)을 변경하는 단계; 및

성능 정보 추출 코드를 삽입하는 단계를 포함하는 것을 특징으로 하는 모니터링 방법.
제 6 항에 있어서,

상기 성능 정보 추출 코드 삽입 단계는, 일반적으로 자바 바이트 코드 인스트루먼테이션이라 불리는 바이트 코드 분석 및 조작기술을 통해 삽입하는 것을 특징으로 하는 모니터링 방법.
제 1 항에 기재된 모니터링 방법을 이용한 알고리즘을 통해 자바 어플리케이션의 각종 성능 데이터를 추출하기 위한 컴퓨터 판독 가능한 기록 매체.
자바 바이트 인스투르먼테이션(Java byte instrumentation)을 통해 모니터링된 데이터의 호출 관계를 규명하는 방법에 있어서,

모니터링 대상이 되는 클래스를 실행한 자바 바이트의 스레드(thread) 별로 스택을 생성하는 단계;

시작 메소드 호출 시 모니터링된 데이터를 상기 스택에 푸시(Push)하는 단계;

끝 메소드 호출 시 모니터링된 데이터를 상기 스택에서 팝(Pop)하는 단계; 및

각 실행되는 클래스 및 메소드의 링크 구조를 이용하여 호출 관계를 추적하는 단계를 포함하는 것을 특징으로 하는 호출 관계 추적 방법.
제 9 항에 있어서,

호출 관계 추적 단계는, 상기 스택에서 푸시 및 팝되는 데이터에 대응되는 클래스 및 메소드의 순서에 기초하여 상기 모니터링된 데이터를 트리 구조로 형성하는 단계를 더 포함하는 것을 특징으로 하는 호출 관계 추적 방법.
제 10 항에 있어서,

상기 트리 구조 형성 단계는,

상기 스택으로 데이터를 푸시하는 경우에, 현재 메소드에 대응하는 트리 아래에 새롭게 호출된 메소드에 대응하는 하위 트리를 형성하는 단계;

상기 생성된 하위 트리에 모니터링된 데이터를 매핑하는 단계; 및

상기 스택으로 데이터를 팝하는 경우에, 현재 호출된 메소드에 대응하는 트리의 상위 트리로 이동하는 단계를 포함하는 것을 특징으로 하는 호출 관계 추적 방법.
제 9 항에 있어서,

상기 호출 관계 추적 방법은, 상기 스택에서 푸시되고 팝되는 데이터를 그 순서에 따라 사용자에게 디스플레이 하는 단계를 더 포함하는 것을 특징으로 하는 호출 관계 추적 방법.
제 10 항에 있어서,

상기 호출 관계 추적 방법은, 상기 호출된 데이터를 상기 트리구조의 형태로 사용자에게 디스플레이 하는 단계를 더 포함하는 것을 특징으로 하는 호출 관계 추적 방법.