비즈니스 중심적인 트랜잭션 모니터링 및 관리, Part 4: E2E 클라이언트를 이용한 비즈니스 중심 관점으로 전환

박용우 yongwoopark@paran.com 건국대학교 전자계산학과와 동대학원 박사과정을 졸업하고 펜타시스템테크놀러지, XCE 등에서 XML 및 모바일 분야 개발에 전념해 왔다. 신한은행 차세대 프로젝트에서 통합운영관리 거래추적 시스템을 개발했으며 최근 현대해상 차세대 프로젝트에 참여해 ITSM 기반 통합운영관리 시스템을 개발했다. JCO 초대 회장을 역임했고 현재 JCO 고문으로 활동하고 있으며 '이클립스 SWT: 리치 클라이언트 개발을 위한', '프로그래머 그들만의 이야기', 'BREW Mobile Programming', '모바일 자바 프로그래밍' 외 여러 권의 책을 썼다. 난이도 : 중급 2008년 4월 8일

[오픈 디벨로퍼웍스]는 여러분이 직접 필자로 참가하는 코너입니다. 이번 회 역시 지난 회 E2E 에이전트 구현과 같은 방식으로 E2E 클라이언트를 구현하는 방법에 대해 하나씩 살펴보겠습니다.

시스템 관점 vs. 비즈니스 관점

IBM Tivoli, BMC 패트롤(patrol), CA 유니센터(Unicenter), HP 오픈뷰(Openview) 같은 시스템 관리 솔루션들은 서버, 서비스, 자원 등에 대해 시간 흐름에 따른 순차적이고 개별적인 모니터링, 관리에 초점을 맞추고 있다. 이러한 기존 도구들은 한 트랜잭션이 어떤 흐름으로 수행되는지에 관계없이 시스템 또는 애플리케이션 중심으로 특정 시간대의 CPU, 메모리, 디스크 등 시스템 자원의 상태 모니터링, 네트워크 트래픽 모니터링, 웹 서버 또는 애플리케이션 서버의 정상 동작 여부 모니터링, 데이터베이스 부하 모니터링 등 개별적인 모니터링 정보만을 제공한다.

다시 말하면 기존 SMS/NMS, APM, DB 성능 관리 솔루션이 시스템 관점에서 시스템 및 애플리케이션의 모니터링을 제공했다면 E2E 시스템의 궁극적인 목적은 사용자 또는 운영자가 쉽게 이해하고 효율적으로 판단할 수 있는 거래(transaction) 중심의 사용자 관점인 비즈니스 관점으로 변환하여 보여주는 것이다. 또한 하나의 거래가 어떤 시스템들을 통해 수행되었고, 각각의 구간에서 얼마만큼의 시간이 소요되었으며, 비정상 거래가 수행되었을 때 거래에 참여하는 각 시스템, WAS, 애플리케이션, 데이터베이스 등의 상태가 어떤지에 대해 바로 확인할 수 있도록 하는 것이다.

E2E 시스템에서 비즈니스 중심적인 사용자 관점의 업무별/채널별 거래 모니터링, 구간별 거래 추적 등의 기능을 제공하는 것이 바로 E2E 클라이언트다. 이를 위해 E2E 클라이언트에서는 업무별/채널별 거래 모니터링을 위한 종합상황판, 구간별 성능 분석을 위한 차트 뷰, 구간별 흐름 분석을 위한 플로우 뷰, 정상/비정상 거래 및 긴(long) 트랜잭션 분석을 위한 사후 분석 기능들을 제공한다. 또한 기존 SMS/NMS, APM, DB 성능 관리 솔루션 등 성능 관리 솔루션들과 연동해 사용자가 보고자 하는 거래의 특정 구간에서의 시스템, 네트워크, WAS, 애플리케이션, 데이터베이스 등의 상태를 바로 확인할 수 있도록 한다. 필자는 이러한 E2E 시스템에 대해 물 위에 떠 있기 위해 무수히 많은 발길질을 하면서도 보는 사람으로 하여금 우아함만을 느끼게 하는 백조와 같다고 하여 백조 시스템이라 얘기하곤 한다.

위로

E2E의 클라이언트의 차트 뷰 및 플로우 뷰 개념도

E2E 클라이언트는 E2E 로그 데이터들을 수집해 GID에 따라 각각의 거래 단위로 분류해 보여준다. 예를 들어, 하나의 거래가 수행될 때 다음 그림과 같이 여러 구간으로 나뉘어 수행되도록 프레임워크를 구현하였다고 하자. 이 때, 각 구간을 수행하는 서비스에서는 시작과 종료 시에 각각 E2E 로그를 남긴다. 종료 로그는 정상 종료 및 비정상 종료 로그가 발생 가능하며, 비정상 종료 로그의 경우에는 스택 트레이스 메시지를 포함할 수 있다.

위와 같은 흐름으로 실행되는 트랜잭션의 경우, E2E의 로깅 메커니즘에 따라 트랜잭션이 실행되면서 각 서비스의 시작/종료 시에 다음과 같은 동일 GID를 갖는 E2E 시작/종료 로그들이 발생할 것이다.

S(Client), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
S(ActionServlet), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
S(BusinessLogic), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
S(DBAdapter), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
F(DBAdapter), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
S(EAIAdapter), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
F(EAIAdapter), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
F(BusinessLogic), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
F(ActionServlet), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …
F(Client), GID#1, LDATE, LTIME, TRANCODE, SYSTEM, SERVICE, …

위와 같은 하나의 트랜잭션에 해당하는 E2E 로그들에 대해 시작/순서 쌍을 이용해 수행된 모듈 단위로 사각형 형태로 그려보면 다음과 같이 나타난다.

(a) 차트 뷰	(b)플로우 뷰

먼저 (a)차트 뷰를 살펴보면, 각 사각형은 각 서비스의 E2E 시작/종료 로그에 있는 로그 시간에 대해 시작 시간을 시작점으로 하여 종료 시간을 끝으로 하는 사각형을 그린다. 어떤 서비스 내에서 다른 서비스를 호출하였다면, 해당 서비스의 사각형은 자신을 호출한 서비스의 사각형보다 Y 축이 조금 들어가게 그려줌으로써 사용자로 하여금 두 개의 서비스가 호출 관계에 있음을 알 수 있도록 해 준다. 그리고 각 서비스의 시작/종료 E2E 로그의 로그 시간에 따라 사각형을 그려보면, 위의 그림처럼 “Browser” 서비스의 사각형 내부에 ActionServlet 서비스의 사각형이 위치하고, 호출 관계에 따라 Y 축이 조금 들어가게 그려진다. 마찬가지로, ActionServlet 서비스의 실행 사각형 내부에는 MainLogic 서비스의 사각형이 나타나고, MainLogic 사각형 내에는 DBAdapter 서비스 및 EAIAdapter 서비스의 사각형이 같은 Y 위치에 그려진다.

이렇게 분석하고자 하는 거래에 대한 구간별 성능 분석을 위해 차트 뷰를 그려 보면, 각 서비스의 실행 소요 시간은 물론 각 서비스 간 호출 관계를 알 수 있다. 또한 거래의 전체 소요 시간 중에서 어떤 구간의 서비스에서 상대적으로 많은 시간을 소요했는지도 직관적으로 알 수 있다. 또한, 비정상적으로 종료된 서비스의 경우 종료 로그에 스택 트레이스 메시지를 포함하고 있으며, 사용자는 차트 뷰를 통해 스택 트레이스 내용을 확인함으로써 어느 구간에서 왜 장애가 생겼는지 바로 알 수 있다.

다음으로, (b)플로우 뷰는 하나의 거래에 대해 구간별 흐름을 분석할 수 있다. 하나의 거래를 수행하기 위해 각 서비스의 시작/종료 시에 발생한 E2E 로그들에 대해 호출 관계에 따라 인덴트를 주어 시작과 종료 로그들을 모두 사각형으로 표현한 것이다. 하나의 서비스에서 다른 서비스를 호출하면 인덴트를 1 증가시키고, 실행되고 나서 서비스가 종료되면 인덴트를 1 감소시키는 방식이다. 또한, 각 사각형은 이전 사각형과 로그 시간차만큼 상대적으로 거리를 두어 그려준다. 이렇게 플로우 뷰를 봄으로써 하나의 거래에 대한 수행 흐름을 분석하고, 각 로그가 발생할 때의 시간차를 확인할 수 있다.

위로

E2E의 클라이언트의 세 가지 뷰

E2E 클라이언트에서는 로그 뷰, 차트 뷰, 플로우 뷰 등 세 가지 형태의 뷰를 제공한다. 먼저, 로그 뷰는 하나의 트랜잭션을 수행하면서 발생한 모든 시작/종료 로그에 대해 각 서비스의 호출 관계에 따라 인덴트를 주어 모든 E2E 로그 데이터를 그대로 보여준다.

차트 뷰는 하나의 트랜잭션에 대해 구간별로 소요된 시간뿐만 아니라 하나의 트랜잭션을 처리하기 위해 각 구간별로 어느 정도의 비율로 시간이 소요되었는지를 한눈에 파악할 수 있도록 해 준다. 타임아웃이 발생한 비정상 트랜잭션에 대해 차트 뷰를 확인하면 어느 구간에서 시간이 많이 걸렸는지를 알 수 있고, 에러 트랜잭션에 대해서는 어느 구간에서 에러가 발생했는지 확인할 수 있다. 차트 뷰의 이러한 특징은 각 트랜잭션에 대해 구간별 거래 추적이 가능하고, 비정상 트랜잭션에 대해서는 비정상 구간만을 분리하여, 장애가 발생한 구간만 집중적으로 더 세밀하게 분석할 수 있게 함으로써, 장애 발생부터 문제 해결까지 과정을 단순화해 주고 장애 처리 시간을 최소화한다.

마지막으로, 플로우 뷰는 하나의 거래에 대해 구간별 흐름을 분석할 수 있도록 해 준다. 플로우 뷰는 하나의 거래에 대한 또 다른 형태의 표현으로서, 트랜잭션을 바라보는 관점의 형식만 다를 뿐 차트 뷰와 동일한 기능과 특징을 제공한다. 그런데 필자가 사용자들에게 직접 차트 뷰 및 플로우 뷰를 보여주었을 때, 사용자들은 차트 뷰보다는 플로우 뷰를 더 쉽게 이해하였다. 결과적으로, 플로우 뷰가 거래 흐름을 보여주기 때문에 사용자에게는 더 직관적이지 않았나 싶다.

위로

E2E 클라이언트의 실시간 모니터링 및 성능 관리 솔루션 연계

E2E 클라이언트는 두 가지 형태의 실시간 모니터링 기능을 제공한다. 하나는 이클립스 SWT를 이용해 개발한 윈도우 기반 실시간 모니터링 클라이언트이고, 다른 하나는 플렉스를 이용해 개발한 웹 기반 실시간 모니터링 클라이언트다.

먼저 이클립스 SWT를 이용해 개발한 윈도우 기반 실시간 모니터링 클라이언트는 E2E 서버, 로컬 E2E 로그 파일, E2E 데이터베이스 등에서 실시간으로 발생한 E2E 로그 데이터에 대해 서비스별 거래 목록, 거래별 로그 목록, E2E 로그 데이터에 대한 상세 뷰 등의 기능을 제공한다. 기본적인 실행 화면은 다음과 같다.

윈도우 기반 실시간 모니터링 클라이언트는 E2E 로그들을 각각의 거래 단위로 구분하고, 해당 거래가 수행된 구간별 성능 분석을 할 수 있도록 차트 뷰를 통해 보여주고, 수행 흐름을 분석할 수 있도록 플로우 뷰를 통해 보여준다. 이러한 관계도를 그리면 다음 그림과 같다.

예를 들어 에러가 발생한 비정상 거래 또는 타임아웃이 발생한 거래에 대해 차트 뷰를 통해 거래가 수행될 때의 각 구간별로 어느 정도 소요 시간이 걸렸는지를 확인하고, 장애가 발생한 구간을 분리할 수 있다. 또한, 플로우 뷰에서 하나의 트랜잭션이 어떤 구간들을 통해 수행되었고, 어느 구간에서 상대적으로 오래 걸렸는지, 어느 구간에서 장애가 발생했는지를 바로 확인할 수 있다. 이렇게 비정상 트랜잭션에 대해 문제가 되는 구간을 분리하고, 문제의 구간이 수행될 때 관련 시스템의 CPU, 메모리, 디스크 I/O, 네트워크 I/O 등의 자원 상태에 대해 SMS/NMS 솔루션을 연계하여 확인할 수 있고, WAS 및 애플리케이션의 실행 상태에 대해서는 APM 솔루션을 연계하여 데이터베이스 상태에 대해서는 DB 성능 관리 솔루션 연동을 통해 확인할 수 있다.

반면, 플렉스를 이용해 개발한 웹 기반 실시간 모니터링 클라이언트는 업무별/채널별 거래에 대한 실시간 모니터링이 가능하며, 특정 거래에 대한 구간별 성능 분석 및 구간별 흐름 분석은 물론, 각 성능 관리 솔루션과 연동하는 방법 역시 윈도우 기반 실시간 모니터링 클라이언트와 동일하다.

한편, 플렉스 기반 실시간 모니터링 클라이언트는 통합운영관리를 위한 종합상황판의 일부분으로서 사용할 수도 있다.

위로

E2E 클라이언트의 사후 분석 및 성능 관리 솔루션 연계

E2E 시스템에서는 E2E 대상이 되는 시스템에서 발생하는 모든 E2E 로그 데이터를 E2E 에이전트에서 수집해 E2E 서버에 취합하며, 이렇게 모은 E2E 로그는 모두 E2E 데이터베이스에 저장된다. 이렇게 하는 이유는 사후 분석 및 보고서 작업을 하기 위한 것이다.

E2E 클라이언트의 사후 분석 기능을 통해 정상/비정상 트랜잭션을 조회하거나 긴 트랜잭션 및 구간별 소요 시간 등을 확인할 수 있다. 이렇게 조회하고자 하는 트랜잭션에 대해서는 실시간 모니터링에서와 같이 차트 뷰를 통해 구간별 소요 시간을 분석하거나, 트랜잭션의 수행 흐름을 플로우 뷰를 통해 분석할 수 있다. 물론, 차트 뷰 또는 플로우 뷰를 통해 비정상 트랜잭션에 대해 문제가 되는 구간을 분리하고, 문제의 구간이 수행될 시간대의 해당 시스템의 CPU, 메모리, 디스크 I/O, 네트워크 I/O 등의 자원 상태에 대해 SMS/NMS 솔루션을 연계하여 확인할 수 있고, WAS 상태에 대해서는 APM 솔루션을 연계하고, 데이터베이스의 상태에 대해서는 DB 성능 관리 솔루션의 연동을 통해 확인하는 것이 가능하다. 다음 그림은 이러한 관계를 잘 보여준다.

위로

마치며…

지금까지 ‘Business-centric End To End Transaction Tracking’이라는 주제를 4회에 걸쳐 살펴보았고, 그 핵심 기술로서 E2E 시스템에 대해 소개했다.

눈치가 빠른 독자라면 E2E 시스템은 하부에 있는 IT 솔루션들이 얼마나 복잡하고 바쁘게 수행되는지와 상관없이 사용자는 필요한 정보에 대해서만 자신의 관점으로 볼 수 있도록 하는 백조 시스템을 구축하는 것이 궁극적인 목표라는 것을 알 수 있을 것이다. 이러한 백조 시스템은 장애가 발생했거나 비정상 종료된 거래에 대해 어느 구간에서 어떤 문제가 발생했고, 그 구간에서 문제가 발생한 시점의 시스템, 네트워크, 애플리케이션 서버, 데이터베이스 등의 상태가 어떠한지를 확인할 수 있도록 해 준다. 즉 비정상 트랜잭션에 대해 문제의 원인이 되는 구간을 분리하여 그 구간만 집중적으로 좀 더 세밀하게 분석함으로써, 장애 발생부터 문제 해결까지 과정을 단순화해 장애 처리 시간을 최소화하는 주는 것이다.

그뿐 아니라 SMS/NMS, APM, DB 성능 관리 등의 솔루션과 연동해 장애가 발생한 시점의 CPU, 메모리, 디스크 I/O, 네트워크 I/O 등의 시스템 자원의 상황, WAS 및 애플리케이션 상황, 데이터베이스 상황 등에 대해서도 확인할 수 있도록 해 준다는 것이다. 이러한 이유로 E2E 시스템은 SMS/NMS, APM, DB 성능 관리 솔루션 등 기존 성능 관리 솔루션에 대한 대체 솔루션이 아니라 아교(glue) 역할을 하는 솔루션이라 할 수 있다.

필자는 E2E 클라이언트를 통합운영관리 시스템에 들어가기 위한 관문이 된다는 의미에서, E2E 클라이언트를 골든 게이트(Golden Gate)라 명명했다. 결국 하부단에서 어떤 복잡한 일들을 하더라도, 사용자에게는 단순하고 명료한 뷰만 제공함으로써 관점 변화를 이룰 수 있다는 것, 이의 시작이 바로 골든 게이트가 되지 않을까.

mar.gar.in

naver

eolin

del.icio.us

이제 전문가의 글을 단순히 ‘보는 것’에서, 직접 여러분이 developerWorks의 필자가 될 수 있습니다. IBM developerWorks를 통해 공유하고 싶은 지식이 있으신 분들은 원고 기획안을 접수해주세요. 채택되신 분께는 소정의 원고료를 드립니다.

필자 지원하기

[지난 Open dW 보기]