# 트랜잭션 관리란?
프로파일링과 call tree에 이어 이번에는 트랜잭션 관리에 대해서 알아 보고자 한다. 트랜잭션 이란 하나의 완결된 요청 처리로서 사용자의 처리요청이 여러 구성요소 및 절차를 거쳐 완료 되는 것이다. 절차 및 구성요소에 대해서 모두 처리 되거나 모두 안되거나 두 가지 경우 밖에는 없다.
일반적으로 시장에 나와 있는 APM툴은 트랜잭션 관리와 관련해서 세가지 정도로 구분 해 볼 수 있다. 트랜잭션에 대해서 WAS쪽에서의 처리만을 관리 하는 툴, 데이터 베이스 처리 상황을 보여 주는 툴, 그리고 WAS와 DB를 동시에 관리하지만 트랜잭션을 보는 시야(visibility)가 단절된 상태로 보여주는 툴들로 구분 할 수 있을 것 같다.
트랜잭션이란 관점에서 보면 WAS와 데이터베이스를 모두 거치는 한 개 단위이므로 APM툴은 트랜잭션이 흘러 가는 구간을 전부 관리 할 수 있어야 한다. 좀 더 구체적으로 보면 HTTP Request, servlet processing, database call 이 주요 트랜잭션 구성 단계로 만일 이런 요소들이 개별 모니터링 된다면 문제 분석 시에 추가적인 노력이 더 필요하게 될 수 밖에 없다.
연구 자료에 의하면 성능문제 해결을 위해서 소요되는 시간의 약80%가 문제지점을 파악하는 데 사용된다고 한다. 그렇다면 툴은 이 시간을 줄일 수 있도록 관련 정보를 즉시 제공 할 수 있어야 한다.
<Flow of Transaction>
# 트랜잭션 관리를 위해서는 어떤 정보가 필요할까?일반적인 경우 was에서 실행 되는 servlet에서는 1개 이상의 database call이 있다. 즉 사용자 요청에 의해서 실행 되는 servlet과 여기에서 요청 하는 database call이 하나의 트랜잭션으로 보여 지는 것이 기본적으로 필요하다.
사용자 요청(트랜잭션이름) + 실행중인 class method + 데이터 베이스 요청(sql실행) + target database + database의 sql 실행 상태, 이런 정보가 항상 동시에 보여 질 수 있어야 detection, alerting, correction의 관리 작업을 원활하게 할 수 있지 않을까 한다.
이런 정보를 바탕으로 관리요소가 was에 있을 경우 was에서 수집된 프로파일데이타,call tree를 활용한 분석으로 진행 되고 데이터베이스에 있을 경우 수집된 세션, sql, 각종 통계정보를 바탕으로 sql 튜닝 등을 진행 해야 한다.
수집되는 정보들은 기본적으로
트랜잭션이름, class method, sql , target database, 데이터베이스 처리 상태가 항상 동시에 보이고,
프로파일링 정보, call tree등이 항상 수집되고,
데이터베이스의 세션, 통계정보, sql 등이 항상 수집 되어야 한다.
이를 바탕으로 was-> 트랜잭션 -> call tree -> java source 로 트랜잭션 분석이 진행 되거나, db-> 세션 -> sql 처럼 데이터베이스 분석을 진행 할 수 있다.
이상 위에서 언급된 내용을 요약하자면, APM툴이 반드시 제공해야 하는 기능은 바로
Comprehensive visibility of transaction!
# InterMax 의 트랜잭션 관리
이제 이를 구체적으로 구현한 InterMax의 화면을 통해서 실제 사용 예를 간단히 보자.
TOP DOWN방식 접근법을 적용한 InterMax에서 상위의 tier들을 함께 보여주는 화면이 아래에 있다. 여기서는 web server, was, database의 개별 요소들의 전체적인 상태를 한 눈에 볼 수 있게 배치 되어 있다.
예를 들어 실행 되는 트랜잭션이 갑자기 증가하면서 대기 상황이 WAS쪽에서 보일 때 DB쪽에서 LOCK이 발생한 것이 보인다면 원인이 DB쪽임을 즉시 파악 할 수 있을 것이고 DB쪽에서 LOCK을 해소 하면 장애상황도 따라서 해결 될 것이다.
아래는 LOCK으로 인한 트랜잭션 증가 현상을 캡쳐한 화면으로 TREE구조로 LOCK상황을 볼 수 있어 즉시 LOCK HOLDER에 대한 정보를 파악 할 수 있다.
화면 아래에 있는 것이 현재 실행 중인 트랜잭션의 목록이다. 여기서 특징적으로 보이는 점은 바로 트랜잭션, CLASS METHOD, DB INSTANCE, DB SID, SQL TEXT, DB SESSION WAIT 정보가 동시에 표현 된다는 점이다.
이 화면 만으로도 문제 상황에서 WAS쪽인지 DB쪽인지 해당 원인을 기본적으로 파악 할 수 있어 문제 구간을 찾기 위해 관련 담당자들이 모이는 등의 시간을 상당히 줄일 수 있다.
TOP LEVEL 모니터링에서 WAS와 데이터베이스가 동시에 모니터링 되고 트랜잭션은 WAS에서 실행 상태와 데이터베이스에서 SQL 실행 상태가 연결되어 하나의 뷰로 모니터링 된다면 트랜잭션관리라는 목표를 쉽게 달성 할 수 있을 것이다.
기고: 박 락 빈 (주) 엑셈 부사장
'엑셈 경쟁력 > 전문가 기술기고' 카테고리의 다른 글
척척박사 윤박사가 들려주는 AI | 첫 번째, 인공지능의 현재와 미래 (2) | 2017.01.24 |
---|---|
박재호의 IT 이야기| 소프트웨어 개발과 창의력 vol.1 창의력의 본질 (3) | 2016.02.23 |
[기술기고/인터맥스] 애플리케이션 성능관리의 절대 기준 – 사용자 응답 시간 (0) | 2014.03.13 |
[기술기고/인터맥스] 통합된 알람 관리 (0) | 2011.06.20 |
[기술기고/인터맥스] 운영중인 트랜잭션의 성능 분석, ‘상시 프로파일링’ (0) | 2011.04.19 |
댓글