 |
비즈니스 중심적인 트랜잭션 모니터링 및 관리, Part 2: E2E 에이전트 구현
|
|
 박용우 yongwoopark@paran.com
건국대학교 전자계산학과와 동대학원 박사과정을 졸업하고 펜타시스템테크놀러지, XCE 등에서 XML 및 모바일 분야 개발에 전념해 왔다. 신한은행 차세대 프로젝트에서 통합운영관리 거래추적 시스템을 개발했으며 최근 현대해상 차세대 프로젝트에 참여해 ITSM 기반의 통합운영관리 시스템을 개발했다. JCO 초대 회장을 역임했고 현재 JCO 고문으로 활동하고 있으며 '이클립스 SWT: 리치 클라이언트 개발을 위한', '프로그래머 그들만의 이야기', 'BREW Mobile Programming', '모바일 자바 프로그래밍' 외 다수의 저서를 보유하고 있다.
난이도 : 중급
2008년 2월 19일
|
|
|
|
[오픈 디벨로퍼웍스]는 여러분이 직접 필자로 참가하는 코너입니다 .이번 기사에서는 종단간 구간별 거래 추적 시스템을 구현하는 방법에 대해 하나씩 알아봅시다. 먼저 E2E 에이전트를 어떻게 구현했는지 살펴보겠습니다.
토론(討論)과 논쟁(論爭)
지난 회에 비즈니스 중심적인(business-centric) 트랜잭션 모니터링 및 관리 시스템을 제안하고, 핵심 기술로서 종단간 구간별 거래 추적(End to End Transaction Tracking) 기술을 소개했다. 그 후 며칠이 지나 지인으로부터 이메일이 한 통 왔다. 이메일은 다분히 공격적이면서도 자신의 기대를 저버리지 않아 뿌듯한 듯 했다. 그러면서도 자신이 지금까지 그려오고 실천해온 생각과 사뭇 다르지 않을까 하는 기대 반 우려 반의 애정어린 충고도 잊지 않았다. 다음은 지인으로부터 온 이메일의 주요 내용이다.
“비즈니스 중심적”이라고 표현했으나 사실은 “트랜잭션 추적”의 한계를 개념적으로 뛰어 넘지 못한 듯 하고, 웹 서버•WAS•외부 EAI 시스템 혹은 백엔드 시스템 등 외부 시스템과 연계시에 GUID를 전달하는 기술에 대한 코어 기술에 대해서는 언급하고 있지 않은 듯 하네요.
E2E가 현재는 차세대 시스템을 중심으로 성공적으로 개념적 접근을 하고 일부 각광을 받고 있기는 하나 “효과적인 성능/장애 리소스 모니터링을 동반하지 않은 채, E2E 트랜잭션 추적”만으로는 “어디서(where), 어떤(what) 리소스가, 왜(why)?”에 대한 답변을 제시하지 못하여 한번 시장에서 반짝하는 사상누각/절름발이 신세가 되지 않을까 추정해 봅니다만, 물론 APM 솔루션이 뒤에서 성능 모니터링 및 관리 기능을 지속적으로 받쳐 준다면 상호간 시너지를 내지 않을까 생각해 봅니다.
시장의 마케팅 논리를 내던지고 진지하게 기술적으로만 고민해 보면, 그 동안 상대적으로 레이어별/리소스별 횡단으로만 접근하던 것을 트랜잭션이라는 티어(tier)별/종단적인 접근이 일부 의미 있는 접근으로 여기지는 것은 비단 E2E에서만은 아닌 듯 합니다. 범위와 목적이 다를 뿐, APM 솔루션에서도 끊임없이 트랜잭션 중심적 모니터링을 강조해 왔던 것이 분명합니다.
진지하게 생각해 보면 기존의 하향(top-down), 상향(bottom-up)이라는 다소 편향된 이중적 접근을 버리고, 1차적으로는 응답시간을 기반으로 한 트랜잭션 중심적인 종단적인 접근 방법을 통해 전체 숲을 보고, 궁극적으로 횡단적인 측면에서 구체적으로 어떤 리소스가 병목의 원인인지를 찾아내는 것까지를 아울러야 할 것으로 보입니다.
전체 숲을 보는 방법도 전 거래의 응답시간 분포를 통해 보는 것이 1차적으로 효과적이며, 2차적으로는 E2E처럼 구간별/티어별 통계적 접근도 나쁘지 않습니다. 그 다음 단계가 무엇이겠느냐는 화두를 던져 본다면 그것은 “광의의 의미에서 효과적인 리소스 병목 모니터링/프로파일링”이 될 것입니다. 고객 요구사항에 대해 궁극적으로 들어가다 보면 해답은 어떤 형태로든지 “리소스 병목”으로 귀결되거든요. 여기서 리소스는 최근 제니퍼소프트의 김성조 이사가 이야기했듯이(http://www.jennifersoft.com/31/article/show/ko/3582.html) 소프트웨어적인 논리적 리소스(소프트웨어 프레임워크, 코드 등)를 함께 아우르는 논리적/물리적, 내부/외부 리소스로 확대 해석/정의해야 하고, 이를 효과적으로 찾아내는 것까지겠지요.
저는 시장에 권고하는 바가, 두 솔루션 제품 간에 개념적 접근 차이가 있어야 한다면 E2E 거래 추적은 진정으로 비즈니스적인 관점에서 “효과적인 전문거래 로그(이름이 뭐였든)” 방향으로 개념적 진화를 이루어 내고, APM은 성능/장애/모니터링을 위한 리소스 병목 추적 방향으로 시장에서 분화되어 발전하는 것이 바람직하다는 것입니다.
|
지인이 보낸 이메일은 필자에게 기대 이상의 활력을 주기에 충분했다. 현재 필자가 고민하고 만들어가고 있는 기술에 대해 이미 고민해 오던 사람들이 있었다는 반증이고, 앞으로 더 많은 토론과 논쟁을 통해 더 발전적인 기술의 진일보를 통해 이상의 실용화가 가능할 것이라는 흥분 때문이다. 물론 위와 같은 이메일을 보낸 지인 역시 필자의 얘기가 무척 반갑고 또 점점 잊혀져 가는 자신의 엔지니어적인 욕심과 본성을 다시 일깨우는 계기가 되었기에 다분히 공격적이면서도 최대한 절제한 내용의 장문을 필자에게 보내지 않았을까 싶다. 그러나 필자는 다음과 같이 지난 회에서 밝힌 내용을 다시 언급하는 차원에서 간단 명료하게 답장을 보냈다.
|
종단간 구간별 거래 추적 시스템은 기존 성능관리 솔루션에 대한 대체 솔루션이 아니라 아교(glue) 솔루션이라는 것입니다. 그리고 말씀하신 GUID 생성 및 유지 메커니즘이 E2E의 가장 핵심이자 중요한 기술로서 이 글의 범위와 분량을 초과한다고 생각해 언급만 하고 넘어갔습니다. 역시 예리하시네요.
|
지금까지 많은 지면을 할애해 위와 같은 내용을 소개한 것은 지인으로부터 온 내용이 필자가 고민하고 있는 것들이면서도 필자가 생각하지 못한 것이기 때문이다. 따라서 이 글을 읽은 독자들 역시 필자와 같은 주제로 고민하던 것들이 있다면 함께 얘기를 했으면 하는 것이다. 필자는 화두만 던진 것이지, 그 해답을 제시하는 것은 아니기 때문이다. 이제 엔터프라이즈 시스템에 대한 모니터링 및 성능 관리 기술들이 하나씩 공론화되기를 바란다.
이제 본론으로 돌아와 종단간 구간별 거래 추적 시스템을 구현하는 방법에 대해 하나씩 알아보자. 먼저 E2E 에이전트를 어떻게 구현했는지 살펴보자.
E2E 에이전트
E2E 에이전트는 E2E 대상 시스템에 설치되어 실행되면서 E2E 대상 시스템이 생성하는 모든 E2E 로그 데이터를 수집하여 E2E 서버에 전송한다. 모든 E2E 대상 시스템에서는 트랜잭션 하나를 수행할 때 각 구간별로 실행되는 서비스 시작과 종료시에 정의된 포맷의 E2E 로그 데이터를 생성한다. 이 때 E2E 대상 시스템은 E2E 에이전트가 읽어갈 수 있도록 파일, 공유 메모리, TCP/IP 네트워크, 데이터베이스, 시스템 큐, 메시지 큐 등 한 가지 방식을 이용하여 생성한 E2E 로그 데이터를 남긴다. E2E 에이전트는 E2E 대상 시스템에서 생성한 E2E 로그 데이터를 하나씩 읽어와 E2E 에이전트에서의 처리 시간, 각 서비스 시작/종료 로그의 시간차를 이용한 서비스 소요 시간 등의 데이터를 추가한다. 그리고 이렇게 두 개의 데이터를 추가한 E2E 로그 데이터를 TCP/IP 네트워크를 이용하여 E2E 서버에 전송한다.
이러한 E2E 에이전트의 작업을 효율적으로 수행하기 위해 다음과 같이 로그 파서(Log Parser), 타임아웃 관리자(Timeout Manager), 로그 전송자(Log Sender), 메인 쓰레드 등 작업별로 나누어 쓰레드 단위로 구현하였다.
- 로그 파서: 로그 파서는 E2E 대상 시스템에서 생성한 E2E 로그 데이터를 읽어 들여 에이전트 처리 시간을 추가하고, 타임아웃 관리자를 이용하여 소요 시간을 자동으로 계산하여 종료 로그에 추가하는 등의 작업을 수행한다. 이렇게 수정된 E2E 로그 데이터가 E2E 서버에 전송될 수 있도록 로그 전송자의 큐에 추가한다.
- 타임아웃 관리자: 타임아웃 관리자는 내부적으로 해시 테이블을 이용하여 서비스의 타임아웃을 체크하는 작업을 수행하고, 로그 파서가 서비스의 소요 시간을 계산할 수 있도록 해 준다. 이 때 어떤 서비스에서 타임아웃이 발생했을 경우 그에 대한 타임아웃 에러 로그를 생성한 후, E2E 서버에 전송될 수 있도록 로그 전송자의 큐에 추가한다.
- 로그 전송자: 로그 전송자는 로그 파서 및 타임아웃 관리자가 자신의 큐에 추가한 E2E 로그 데이터를 TCP/IP 네트워크를 이용하여 E2E 서버에 전송하는 작업을 수행한다.
- 메인 쓰레드: 로그 파서, 타임아웃 관리자, 로그 전송자 등의 쓰레드를 생성하여 시작하고 각 쓰레드가 정상적으로 동작하는지 주기적으로 체크하는 작업을 수행한다. 이렇게 체크한 쓰레드의 실행 여부를 프로세스 로그로 만들어 로그 전송자를 이용해 E2E 서버에 전송한다.
지금까지 설명한 E2E 에이전트의 구성도를 살펴보면 다음과 같다.
그림 1. E2E 에이전트 구성도
지금부터 로그 파서, 타임아웃 관리자, 로그 전송자, 메인 쓰레드 등을 어떻게 구현하였는지에 대해 자세히 살펴보자.
로그 파서 쓰레드 구현
E2E 대상 시스템에서는 서비스 시작/종료시에 정의한 E2E 로그 데이터를 생성하여 E2E 로그 파일에 저장한다. 먼저 로그 파서는 주기적으로 프레임워크와 같은 E2E 대상 시스템에서 생성한 E2E 로그 파일 내에 새로운 로그 데이터가 존재하는지 체크한다. 새로운 E2E 로그 데이터들에 대해서는 STX(0x02) 및 ETX(0x03) 문자를 구분자로 하여 바이트 블록 단위로 읽어 들여 각각의 로그 항목들을 파싱하여 E2E 로그 객체를 생성한다. 새로운 데이터가 없을 경우에는 주어진 시간 동안 sleep한다.
이렇게 생성된 E2E 로그 객체에 에이전트 처리 시간을 추가하고, 시작 로그의 경우에는 타임아웃 관리를 위해 타임아웃 관리자의 해시 테이블에 추가하고, E2E 서버에 전송될 수 있도록 로그 전송자의 큐에 추가한다. 정상 종료 또는 에러 종료 로그의 경우에는, 타임아웃 관리자에서 해당 시작 로그를 제거하여 가져와 소요 시간을 계산하여 종료 로그에 추가한 후, E2E 서버에 전송될 수 있도록 로그 전송자의 큐에 추가한다. 정보성 로그의 경우에는 곧바로 로그 전송자의 큐에 추가한다. 이러한 로그 파서를 구현하기 위한 수행 흐름도를 살펴보면 다음과 같다.
그림 2. 로그 파서의 수행 흐름도
로그 파서는 어떤 서비스의 소요 시간을 계산하기 위해, 서비스의 정상 종료 또는 에러 종료 로그가 발생하면 타임아웃 관리자의 해시 테이블에 저장되어 있는 해당 서비스의 시작 로그를 제거하여 가져온다. 그리고 종료 로그의 로그 시간에서 시작 로그의 로그 시간을 뺀 값이 해당 서비스의 소요 시간이 된다.
이와 달리 로그 파서는 정보성 로그에 대해서는 타임아웃 관리자에 저장된 해당 서비스의 시작 로그를 제거하지 않고 참조만 하여 소요 시간을 계산한 후, 해당 정보성 로그에 설정한 후 로그 전송자를 이용하여 E2E 서버에 전송한다. 정보성 로그는 거래가 끝났다는 것을 의미하는 것이 아니고, 이후에 종료 또는 에러 로그가 발생할 경우에만 서비스 수행이 끝났다고 할 수 있기 때문이다.
타임아웃 관리자 구현
타임아웃 관리자는 내부적으로 해시 테이블을 이용하여 어떤 서비스의 타임아웃을 체크하고, 로그 파서가 서비스의 소요 시간을 계산을 계산할 수 있도록 해 준다. 이를 위해, 타임아웃 관리자가 사용하는 메커니즘은 아주 단순하다.
로그 파서는 어떤 서비스의 시작 로그가 발생하면 타임아웃 관리자의 해시 테이블에 추가하고, 그 서비스의 종료 로그가 발생하면 타임아웃 관리자의 해시 테이블에서 제거하기만 하면 된다. 반면 타임아웃 관리자는 자신의 해시 테이블에 시작 로그가 추가될 때 해당 서비스의 타임아웃 값(초 단위)을 시작 로그에 설정한 후 1초마다 한번씩 시작 로그의 타임아웃 값을 1씩 감소시킨다.
이때 어떤 서비스의 시작 로그의 타임아웃 값이 0이 된다면 해당 서비스는 타임아웃이 발생한 것이다. 로그 파서에서는 어떤 서비스의 정상 종료 또는 에러 종료 로그가 발생하면 타임아웃 관리자의 해시 테이블에 저장되어 있는 해당 서비스의 시작 로그를 제거하기 시작한다. 따라서 타임아웃 관리자의 해시 테이블 내에 있는 시작 로그의 타임아웃 값이 0이 되었다면, 타임아웃이 발생할 때까지 그 서비스가 종료되지 않았음을 의미한다. 이렇게 타임아웃이 발생한 시작 로그를 해시 테이블에서 제거한 후, 타임아웃 에러 로그 데이터로 변환하여 로그 전송자의 큐에 추가해 준다. 이러한 타임아웃 관리자의 수행 흐름도를 살펴보면 다음과 같다.
그림 3. 타임아웃 관리자의 수행 흐름도
예를 들면, 어떤 서비스의 타임아웃 값이 30초일 경우, 이 서비스의 시작 로그가 해시 테이블에 저장될 때 시작 로그와 함께 타임아웃 값으로 30이 설정된다. 타임아웃 관리자는 저장하고 있는 서비스의 타임아웃을 체크하기 위해 1초마다 한번씩 실행되면서 서비스의 타임아웃 값을 1씩 감소시킨다. 이렇게 반복하여 타임아웃 값이 0이 될 때까지 이 시작 로그가 해시 테이블에서 제거되지 않고 남아 있다면, 이 서비스는 타임아웃이 발생한 것이다. 타임아웃 값이 0이 될 때까지 타임아웃 관리자의 해시 테이블 내에 남아 있었다면, 해당 서비스의 종료 또는 에러 로그가 발생하지 않았다는 것이고 즉 서비스가 종료되지 않았다는 것을 의미하기 때문이다. 만약 이 서비스가 종료되면서 종료 또는 에러 로그가 발생했다면, 로그 파서가 타임아웃 관리자의 해시 테이블에서 해당 서비스의 시작 로그를 제거했을 것이다.
로그 전송자 쓰레드 구현
로그 전송자는 로그 파서 및 타임아웃 관리자가 자신의 큐에 추가한 E2E 로그 데이터를 TCP/IP 네트워크를 이용하여 E2E 서버에 전송하는 역할을 한다. 이를 위해, 로그 전송자는 E2E 서버에 대한 TCP/IP 연결을 생성하여 유지하고 있다. 이러한 로그 전송자의 수행 흐름도를 살펴보면 다음과 같다.
그림 4. 로그 전송자의 수행 흐름도
로그 파서 또는 타임아웃 관리자는 E2E 서버에 전송하고자 하는 E2E 로그 데이터를 로그 전송자의 전송 큐에 추가한다. 로그 전송자는 자신의 전송 큐에 E2E 로그 데이터가 있을 경우, 하나씩 꺼내와 E2E 서버와의 TCP/IP 연결을 이용하여 E2E 서버에 전송한다. 만약, TCP/IP 연결이 끊어졌을 경우에는 내부적으로 유지하는 임시 파일에 E2E 로그 데이터를 저장한다. TCP/IP 연결이 다시 이루어지면 임시 파일 내의 모든 E2E 로그 데이터를 한꺼번에 전송한 후 E2E 로그 데이터가 더 이상 존재하지 않을 경우 로그 전송자 쓰레드는 주어진 시간만큼 sleep한다.
E2E 에이전트 메인 쓰레드 구현
E2E 에이전트의 메인 쓰레드에서는 로그 파서, 타임아웃 관리자, 로그 전송자 등의 쓰레드를 생성하여 시작하고, 주기적으로 각 쓰레드의 상태를 체크하여 그 상태를 약속한 프로세스 로그로 만들어 로그 전송자를 이용하여 E2E 서버에 전송하는 작업을 수행한다. 이러한 메인 쓰레드의 수행 흐름도를 살펴보면 다음과 같다.
그림 5. 메인 쓰레드의 수행 흐름도
E2E 에이전트의 메인 쓰레드는 명령행 매개변수로 전달 받은 프로퍼티 파일에서 각 프로퍼티 값에 따라 E2E 에이전트에 대한 환경설정 작업을 수행한다. 다음으로, 프로퍼티 값을 참조하여 E2E 서버에 대한 TCP/IP 연결을 생성한 후 로그 파서, 타임아웃 관리자, 로그 전송자 등의 쓰레드를 생성하고 시작한다. 그리고 주기적으로 로그 파서, 타임아웃 관리자, 로그 전송자 등의 상태를 체크하고 프로세스 로그를 생성하여 로그 전송자를 이용하여 E2E 서버에 전송한다. 쓰레드가 종료될 때는 로그 파서, 타임아웃 관리자, 로그 전송자 쓰레드를 정지하는 작업을 수행한다.
마치며…
이번 호에서는 종단간 구간별 거래 추적 시스템을 구성하는 E2E 에이전트의 아키텍처와 함께 각 모듈을 어떻게 구현할지에 대해 그 수행 흐름을 살펴보았다. 종단간 구간별 거래 추적 시스템의 소스 코드가 함께 소개되기를 원한 독자들은 다소 실망할 수도 있을 것 같다. 그러나 필자가 소스 코드를 공개하지 않은 이유는 이 페이즈를 통해 소스 코드를 소개하기에는 그 양이 너무 방대하고, 아직은 종단간 구간별 거래 추적 시스템에 대한 공감대가 전혀 형성되지 않은 시점에서 소스 코드까지 공개한다는 것은 의미가 없다고 생각했기 때문이다. 그렇지만, 종단간 구간별 거래 추적 시스템을 고민하고 있는 독자들에게는 필자가 소개한 아키텍처 및 수행 흐름도가 구현을 위한 하나의 참조 모델이 되었으면 하는 바람이다. 다음 회에는 E2E 서버, E2E 클라이언트에 대해 차례로 하나씩 살펴보자.
|
| 이제 전문가의 글을 단순히 ‘보는 것’에서, 직접 여러분이 developerWorks의 필자가 될 수 있습니다. IBM developerWorks를 통해 공유하고 싶은 지식이 있으신 분들은 원고 기획안을 접수해주세요. 채택되신 분께는 소정의 원고료를 드립니다. |
|
|
|
 [지난 Open dW 보기] |
|
|
|
