태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[기술기고/인터맥스] 통합된 알람 관리

 


통합 알람 (alarm)

 APM툴에서 제공되는 핵심적인 기능중의 하나는 실시간으로 발생하는 각종 알람에 대한 설정 기능이 될 것이다. 문제가 되거나 알고 있어야 되는 EVENT에 대한 정의를 등록 하고 발생된 알람이 관련 담당자에게 즉시 통보 되는 시스템은 모든 사이트에서 필수적으로 요구 되는 기능인데, 현실적인 문제는 각각의 툴에서 독자적인 알람을 관리하고 단지 알람의 발생 사실만을 통보하는 방식으로 구축 되어 있다는 점이다.

 일반적으로 관리자가 데이터베이스 또는 WAS등의 각각의 시스템에서 알람 설정을 하고, 알람이 발생하면 사이트의 SMS툴로 전송되어 담당자들에게 통보 되는 방식을 주로 사용 한다. 이 방식의 단점은 WAS담당자 또는 DB담당자에게 알람의 원인을 규명하기 위해서 필요한 모든 정보를 가지고 있지 않은 경우가 있다는 점이다.
 

 




 예를 들어서 WAS담당자에게 Connection Pool이 부족하다는 알람이 오는 경우 원인을 분석하기 위해서는 데이터 베이스 쪽 정보도 같이 있어야 완전한 분석이 가능해 진다. Was쪽 connection pool부족이 db에서 발생된 문제 때문인지를 파악 해야 하기 때문이다. 즉 DB의 active session의 수 와 lock 대기중인 세션의 수 등에 대한 정보가 필요하다. DB에서 계속해서 세션이 묶여 있는 경우( 일을 하거나 대기 중이거나 어떤 경우라도 ) 해당 세션은 다른 트랜잭션에서 사용 할 수 없게 되고 따라서 Connection Pool부족 문제를 발생 하게 된다.

따라서 WAS 쪽 Connection pool의 수를 참조 해서 DB쪽 Active session에 대한 알람 설정이 필요하고 lock 대기에 대한 알람 설정도 마찬가지다.

또 다른 예로는 트랜잭션 elapse time에 대한 알람 설정은 sql elapse time에 대한 모니터링 기준으로 작용 하게 된다.

인터맥스의 통합 알람 구현

WAS또는 DB담당자 상호간의 원활한 협업과 투명한 정보공유를 위해서는 동일한 하나의 작업환경 하에서 동일한 방식 또는 뷰를 사용하면서 협업을 위한 분석 데이터가 충분하게 제공 되는 툴이 필수가 된다. 이는 제대로 된 APM툴이 제공해야 할 환경이 된다. WAS따로 DB따로 되어 있다면 협업을 하기 위한 정보의 투명한 제공에 추가적인 노력과 시간이 필요하게 된다. 애플리케이션이 WAS와 DB를 포괄 하는 것처럼 이를 모니터링 하는 APM툴은 당연히 WAS와 DB에 대한 모니터링 관리 기능을 함께 제공 해야 한다.

InterMax는 기존의 was 모니터링 툴보다 향상된 기능을 제공한다. 국산 툴 중에서 최초로 was와 db에 대한 실시간 모니터링 및 사후 분석기능을 통합하여 제공 한다. 따라서 알람 관리도 was와 DB에 대해서 통합적으로 제공 된다.
 
InterMax에서 제공 되는 통합 알람 기능 중 중요한 기능은 아래와 같다.
- WAS, OS, 데이터베이스(오라클,DB2)에 대한 충분한 알람 설정 기능
- 달력기능 제공
- 알람의 복사 기능

제공 되는 기능은 아래의 화면을 통해서 볼 수 있다.

 


 위 화면에서는 WAS와 DB 에 대한 알람 설정 화면으로, WAS 그룹에 대한 알람 설정과 이를 상속받아서 개별 WAS별로 알람을 설정 할 수 있다.  DB 도 마찬가리고 그룹으로 알람을 설정하고, 개별 DB 에 대한 알람은 그룹설정에서 상속받아 별도로 설정할 수 있다. 
 

 


 위 화면은 달력기능으로 알람 설정을 위한 특정 일자와 시간대를 지정해서 SCHEDULE을 등록 하는 기능으로 WORKING/NON-WORKING으로 구분해서 시스템작업등이 있을 경우 불필요하게 알람이 발생 하는 것을 막을 수도 있다. 


 



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



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

 

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

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

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

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

- 디버깅 툴을 사용 할 수 없다
- 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 의 특장점이라 할 수 있겠다.                                             <다음호에 계속>





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

 

[기술기고/인터맥스] APM을 말하다

 



APM은 WIKI의 문구를 빌리면 Application Performance management란 애플리케이션 모니터링, 성능관리, 서비스 가용성에 대한 조직내 정책(?)이라고 한다.

Application performance management, or APM, refers to the discipline within systems management that focuses on monitoring and managing the performance and service availability of software applications.

APM can be defined as process and use of related IT tools to detect, diagnose, remedy and report application’s performance to ensure that it meets or exceeds end-users’ and businesses’ expectations. Application performance relates to how fast transactions are completed on behalf of, or information is delivered to the end user by the application via a particular network, application and/or web servicesinfrastructure.

여기서 중요 한 것은 사용자 관점 그리고 비즈니스 관점에서 성능이 평가 되어야 한다는 점이 되겠다.

 

 IT 환경은 on-line ENTRY + BATCH JOB 시대, CLIENT – SERVER 시대를 거쳐 현재의 비즈니스 시대( IT가 아니라 비즈니스다)에 이르렀다.
과거 성능 관리는 BATCH JOB의 SCHEDULING과 시스템의 안정성이 주요 관심사였고 따라서 ON-LINE 시간대 BATCH JOB 최소화, CPU BOUND JOB과 IO BOUND JOB의 조화, 그리고 시스템의 안정성을 위한 주기적인 유지관리 작업이 주된 성능관리였다. 이때 결코 관과 할 수 없는 중요한 관리 포인트가 또 하나 있었는데, 그것은 트랜잭션 처리량과ELAPSE TIME의 체계적 관리이다.
Clinet-server시대가 오면서 성능관리는 데이터 모델링과 이에 따른 SQL 튜닝, 그리고 Client와 Server로 분산하여 데이터 처리 등으로 변하면서 과거 중요한 지표였던 트랜잭션이란 개념이 상대적으로 사라졌다. 

 


하지만 24시간 비즈니스 시대인 현재, 언제 어디서든 트랜잭션을 즉시 처리해야 하는 기업의 환경아래, 성능관리측면에서 다시 트랜잭션의 개념이 명확하게 되 살아나고 있으며, 이전 보다 훨씬 복잡한 시스템을 24시간 모니터링하고 관리해야 하는 필요성이 대두되고 있다.


비즈니스의 핵심이 고객이 원하는 트랜잭션을 지체 없이 실행 할 수 있도록 하는 것이라면, APM은 분명 이 트랜잭션의 가능한 모든 측면을 모니터링하고 성능관리 할 수 있어야 한다.
WAS 중심의 모니터링은 자칫하면 트랜잭션처리에서 한가지 측면만을 보게 될 수 있다. 트랜잭션 처리에 관련 되는 중요 요소들을 좀 더 구체적으로 살펴보아야 한다.

 


트랜잭션 처리의 중요 요소들은 사용자-N/W-WEB SERVER-WAS-TP-DATABASE등이 있을 것이다. 환경에 따라 TP등은 빠지는 등 다를 수 있겠지만, 전체적인 관점에서 틀리지는 않을 것이다.
결과적으로 대부분의 시스템에서 사용자체험, WAS, DB 가 최소한의 APM 성능관리 주요 항목 된다고 할 수 있다.
 

 

가장 기본적인 조건은 당연히 안정적이면서 가벼워야 한다는 점이다. 시스템에 부하를 주지 않는 것이 최선이지만 이것은 현실적으로 불가능 하다. 따라서 여기에도 경제법칙이 적용 되어야 한다. 최소의 부하로 최대한 관련 정보를 수집할 수 있어야 한다. 경제성의 기준치는 사이트 마다 다를 수 있지만 최소/최대의 기본은 반드시 지켜져야 한다.

기능적으로 중요한 몇 가지를 살펴보면,

 

1. 사용자 체험 시간
당연한 것이지만 비즈니스 시스템의 최종평가는 사용자의 것이며 이 중에 편의성 등 과 같은 주관적인 요소가 개입되는 평가는 어렵겠지만 가용성과 체감시간은 객관적으로 수집 ,평가 가능한 요소 이므로 이에 대한 정보를 제공 할 수 있어야 한다.




2. 트레이스 기능 


개발자의 프로그램에 대한 profiling 또는 tracing에 대한 정보를 수집 제공 할 수 있어야 한다. 기본적으로 모든 사용되는 class, method에 대한 사용관계가 call tree형태로 수집되어야 하며, 운영환경에서는 현실적으로 수집의 부하와 데이터 보관의 어려움이 있으므로 최소한 개발된 class에 대해서는 method call tree가 수집 되어야 한다.



3. Change 추적 
 정상운영 되던 시스템에서 장애가 발생 했을 경우 무엇을 가장 먼저 하는 가? 통상적으로는 새로 변경 적용된 것이 있는 지를 빨리 파악 하는 것이다. 그렇다면 APM에서 기본적으로 갖추어야 할 기능은 변경이력 관리이다. 대상은 아주 광범위 한데, 프로그램소스, JAVA설정, WAS설정, OS 환경변수, OS 시스템 설정, DATABASE 설정, DATABASE OBJECT 등이 될 것이다.              
                           

 

 

4. Tier 연계 분석
장애상황분석 또는 예측되는 장애를 방지 하기 위해서는 취약한 곳이 어디에 있는 지 알 수 있어야 한다. WAS가 문제인지 DB가 문제인지 이를 인지하고 해당하는 곳의 무엇이 장애를 유발 했는지 객관적으로 알 수 있는 정보가 제공 되어야 한다. 단지 트랜잭션의 시간을 TIER별로 나누어서 보여주는 것은 단지 현상을 보여주는 것이다. 문제의 원인을 추적 할 수 있는 정보가 없다면 또다시 많은 노력을 들여야만 한다. 반드시 관련 정보를 충분히 제공할 수 있어야 한다.


 

 


 대부분의 운영시스템에는 이미 각각의 TIER에 대한 성능 관리 솔루션이 도입되어 있을 것이다. 또한 이들 각각의 TIER 정보를 종합하는 상위의 관제 솔루션 역시 구축 되어 있는 것이 일반적이다. 이들 관리를 위해서 기업은 많은 예산과 인력을 투여하는 것이 불가피하다.
 하지만 만약 단일 솔루션으로 이들 대부분을 처리 할 수 있다면 어떨까? 최소한 솔루션 통합을 위한 더 이상의 노력은 들이지 않아도 되지 않을까?
트랜잭션과 각 TIER에서 일어 나는 일이 한 곳에서 오해 없이 깔끔하게 제시 되면, WAS 담당자와 DB 담당자가 각자의 데이터를 준비하고 서로에게 제시하는 일은 더 이상 불필요할 것이다. 또한 각 TIER에서 별도로 관리 되는 알람 설정도 한 곳에서 일목요연하게 관리 된다면 각 담당자들의 오해의 소지를 줄이게 될 것이다. 

엑셈은 기존의 틀을 벗어나 APM을 새롭게 정의하여 진정한 APM 통합관리를 위한 단일 솔루션 InterMax를 개발하였다. 앞으로 InterMax 의 진가를 발휘하는 기능들을 소개해 보도록 하겠다.
(다음호에 계속)        
                                          

 


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