[기술기고/인터맥스] 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 의 진가를 발휘하는 기능들을 소개해 보도록 하겠다.
(다음호에 계속)        
                                          

 

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