본문 바로가기
엑셈 경쟁력/전문가 기술기고

[기술기고/인터맥스] 운영중인 트랜잭션의 성능 분석, ‘상시 프로파일링’

by EXEM 2011. 4. 19.

 

# 운영중인 트랜잭션의 성능 분석은 어떻게 하는가

성능 분석은 주어진 일을 달성 하기 위해 소요된 시간으로 이해된다. (일단 필요한 자원사용에 대해서는 잠시 무시 하도록 하자.) 이와 다르게 장애 분석은 주어진 미션을 달성 하지 못할 경우 그 경로와 원인을 파악 하는 것이다.
‘운영중인 트랜잭션의 성능 분석’이란 이 둘을 동시에 지속적으로 수행 하는 것으로 보아야 한다.

지속적으로 성능 분석을 하기 위해서는 관련 데이터 수집이 운영시스템에 부하를 주지 않으면서 일상적으로 이루어 져야 하고 수집된 성능 데이터를 바탕으로 조회와 보고서가 매일 작성 될 수 있어야 한다.

개발중인 프로그램의 성능분석과 대비되는 운영중인 시스템의 성능분석이 가지는 차이점 몇 가지를 나열해 보자,

- 디버깅 툴을 사용 할 수 없다
- Stack trace 또는 profiling을 상시 사용 할 수 없다.
- 고객이 불만을 표하기 전에 문제를 알 수 있는 경우가 드물다
- Exception의 발생이 트랜잭션 성능 분석 과 연결 되지 못하는 경우가 많다.

트랜잭션의 성능 분석이 운영중인 환경 하에서라고 하더라도 개발환경에서 구할 수 있는 데이터 즉 모든 실행 경로를 추적하고 그 수행 시간을 수집함으로써 쉽게 가능해진다. 이 보다 더 트랜잭션의 성능을 알 수 있는 데이터는 없다고 보아야 하기 때문이다. 즉 개발단계에서 사용하는 디버깅툴과 프로파일링에서 제공되는 데이터를 운영상황에서도 제공 받을 수 있다면 트랜잭션의 성능분석을 위한 최선의 환경이라고 할 수 있다.

지금까지 몇몇 was 모니터링 툴에서 부분적인 기능으로 제공되었지만 대부분 부하문제로 운영환경에서는 이런 기능을 상시 사용 할 수 없었다. 그래서 문제가 있거나 오래 수행되는 METHOD를 찾아서 분석 하기 위해서는 먼저 문제가 보고 되고 나서 트랜잭션을 특정한 뒤에 부분적으로 사용하였다.

Stack trace의 경우 thread의 call stack을 텍스트 형태로 나열 하고, 특정한 한 번의 실행에 대한 정보로서 해당 경로에 있는 call stack만 제공 하기 때문에 종합적인 판단을 내리기 위해서는 2차 가공작업을 별도로 수행 해야 하는 번거로움이 발생 한다.


# InterMax에서 수집되는 프로파일링 정보

이제부터는 실제로 운영환경에서 사용가능한 수준의 프로파일링 기능이 제공되는 InterMax를 통해서 프로파일링 기능이 제공되었을 경우 이의 유용성 및 활용예를 살펴 보도록 하자.

"Call tree"

아래 화면은 InterMax에서 제공 하고 있는 call tree화면으로 수집된 프로파일링 데이터를 tree형태로 한 눈에 파악 할 수 있게 한다.

 

기존의 stack trace와 차별 적인 특징은 수집된 method의 사용 내역이 tree형태로 제공된다는 점이다. 따라서 분석을 위해서 마우스 클릭 만으로 모든 call 관계를 파악 할 수 있으며 또한 수행횟수, 수행시간, exception발생여부 등이 개별 실행 뿐만 아니라 summary된 형태로 볼 수 있어 장기 분석도 용이 하게 할 수 있다. 또한 TOP트랜잭션에서 즉시 해당 트랜잭션의 CALL TREE를 조회 할 수 있어 가장 오래 수행 되는 METHOD를 즉시 파악 할 수 있으며 해당 CLASS의 소스를 볼 수 있도록 되어 있다.
성능 분석이 트랜잭션->CALL TREE ->METHOD->CLASS SOURCE로 자연스럽게 흘러 가는 점은 상당한 장점이라 할 것이다.


"Call tree의 활용"

- Method의 elapse time 분석
 위의 화면은 가장 기본적인 call tree의 활용법이 될 만하다. 특정 트랜잭션에서 가장 오래 수행 되는 method를 즉시 파악 할 수 있으며 위의 예에서는 sql 수행이 가장 오래 동안 실행 되어 전체 트랜잭션의 대부분을 차지함을 알 수 있다.

 


- Method에서 thread 생성 여부
  자주 발생 하는 경우는 아니지만 was운영시 트랜잭션에서 다른 트랜잭션을 call 하는 방식으로 업무를 연계하지 않고 직접 thread를 실행해서 문제를 일으키는 경우가 있다면 이를 파악 하기가 쉽지 않았다. 하지만 InterMax에서 제공하는 Method의 속성 정보를 이용 하면 위의 예에서 처럼 thread를 사용하는 트랜잭션을 간단하게 파악 할 수 있다.
InterMax에서 제공하는 method의 속성은 loop, synchronized, new alloc, exit, gc, arraycopy, classloader, thread, reflect, io, net, nio, enumeration, iterator, strbuffer, strtoken, blob, clob, xml 등으로 시스템 운영에 영향을 줄만한 주목해서 보아야 할 대표적인 속성들이다.

 

 

- Commit/rollback의 실제 실행 여부
 간혹 예외 처리가 잘못되어 commit 또는 rollback이 실행 되지 않아 DB에서 LOCK 이 발생 되는 경우가 있다. 개발자가 사용하는 FRAMEWORK에서는 COMMIT을 실행 하는 METHOD가 실행 되었지만 어떤 이유로 실제 JDBC를 통해서는 COMMIT이 실행 되지 않는 경우도 있다.

아래 예제 화면을 통해서 보면 실제로 COMMIT이 JDBC를 통해서 실행 되었는지 아닌 지를 확인 할 수 있다. 이 기능은 DB Lock을 유발하는 트랜잭션을 찾을 때 아주 유용하게 사용 할 수 있다.

 

 

 

- Method의 exception 분석
 운영시스템에서도 끊임없이 exception은 발생하고 이를 log로 남기지만 로그 양이 너무 많아서 분석하기 곤란한 경우가 대부분이다. 따라서 트랜잭션의 성능 분석을 위해서 call tree를 활용 할 경우 method에서 발생되는 exception을 같이 볼 수 있다면 문제 분석에 많은 도움을 받을 수 있다.
InterMax에서는 이를 위해서 아래의 화면에서 보는 바와 같이 call tree에서 exception을 동시에 분석 할 수 있도록 하고 있다.

 





- Dependency 분석
 개발환경에서 method의 사용관계는 쉽게 파악이 되고 이를 바탕으로 class유지 관리를 하고 있지만 소스상에서가 아니라 실제 운영상황에서 사용관계를 파악 하는 기능도 필요 하다. 이를 통해 실제적인 사용통계를 바탕으로 소스의 유지 관리를 좀 더 실질적으로 조절 가능 할 것으로 보인다.
아래는 InterMax에서 제공 되는 화면으로 특정 method을 사용 하는 트랜잭션, class method 그리고 해당 method가 사용하는 method의 call tree를 한 눈에 볼 수 있다.

 

 


 이상으로 운영상황에서 프로파일링 기능이 제공 되었을 때 유용 하게 사용 할 수 있는 call tree와 그 활용에 대한 예를 살펴 보았다. 위의 활용에서 살펴보았듯이 상시 프로파일링 기능은 WAS모니터링에서 트랜잭션의 성능 분석을 위한 필수 기능으로 InterMax 의 특장점이라 할 수 있겠다.                                             <다음호에 계속>





기고:
박 락 빈  (주) 엑셈 부사장  

 

댓글