모니터링

액티브 모니터링은 서버에서 수행 중인 모든 서비스들의 정보를 얻는다. 해당 기능은 시스템 서비스 형태로 제공되기 때문에 서버에 ProObject 서비스를 호출한다.

서비스 호출에 필요한 URL 및 입력값은 다음을 참고한다.

액티브 모니터링 서비스는 현재 수행 중인 서비스의 정보를 담은 리스트를 응답으로 돌려준다.

다음은 test.main.LoopCall 서비스가 수행 중일 때 액티브 모니터링 서비스의 응답의 예제이다.

다음은 서비스의 응답에 담긴 키 값에 대한 설명이다.

통계 모니터링은 관제 대상인 서버에서 발생하는 Request, Response, Queueing Count를 수집해서 서버의 부하를 모니터링하는 기능이다.

이 기능을 사용하게 되면 초당 몇 개의 요청이 들어왔고 몇 개의 요청을 처리했으며, 아직 처리하지 못한 이벤트가 얼마나 큐에 남아있는지 등에 대한 정보를 알 수 있다. 이러한 정보를 바탕으로 운영 서버의 Scale Out 여부를 판단하는데 사용한다.

다음은 통계 모니터링의 정보 수집 구조에 설명이다.

E2E 모니터링을 위해서는 서비스가 수행되는 구간의 시작과 끝 지점마다 모니터링 정보를 HyperLoader를 사용해서 DB에 저장한다.

다음은 HyperLoader를 통해 모니터링 정보 수집과 런타임 엔진에서 HyperLoader에게 모니터링 정보를 전송하는 구조에 대해서 설명한다.

위의 그림을 보면 통계 모니터링과는 다르게 모니터링 정보를 마스터 서버가 저장하는 것이 아니라 운영 서버가 HyperLoader를 통해 직접 DB에 저장하는 것을 볼 수 있다. 통계 모니터링의 경우에는 초당 저장하는 데이터의 양이 일정하지만 E2E의 경우에는 서비스가 수행되는 구간의 시작과 끝 지점마다 모니터링 정보를 DB에 저장할 뿐만 아니라 대량 거래 상황에서는 DB에 저장하는 작업이 크게 늘어나기 때문에 동일한 방식으로 E2E 모니터링 정보를 저장하면 마스터 서버의 작업 스레드가 Blocking될 수 있기 때문에 대용량 데이터를 저장하는데는 적합하지 않은 구조이다. 이러한 문제를 해결하기 위해 운영 서버가 직접 DB에 모니터링 정보를 저장하게 하고, 마스터 서버는 저장된 데이터를 엮어서 의미있는 데이터를 관리자 UI에서 보여주는 구조를 가진다.

운영 서버에서 모니터링 정보를 저장하는 DB 작업이 매우 빈번하게 일어나기 때문에, JDBC 보다는 대용량 데이터를 처리하는데 적합한 고속 처리 데이터베이스 시스템인 HyperLoader를 사용한다. 만약에 JDBC를 사용하면 DB에 적재할 때마다 쿼리를 파싱하고 바인딩하는 작업 시간이 걸리지만, HyperLoader는 이와 같은 작업들을 생략하고 전달받은 byte 형태의 데이터를 미리 정의해둔 테이블에 직접 쓰는 방식이기 때문에 성능적으로 훨씬 더 빠른 속도를 보장한다.

다음은 모니터링 스레드의 구조이다.

두 번째로는 런타임 엔진에서 HyperLoader에게 모니터링 데이터를 지속적으로 전송해야 하는데, 이를 모니터링 스레드를 별도로 운용해서 처리하고 있다. 별도로 모니터링 스레드를 운용하는 이유는 EM(Event Manager)은 Blocking되면 안되므로 EM에서 처리할 순 없고, 서비스 워커 스레드에서 DBIO 작업을 늘리는 것이 부담되기 때문이다. 따라서 모든 E2E 모니터링 정보는 모니터링 스레드가 HyperLoader에게 직접 전송하고, 실제 데이터는 EM을 거쳐서 모니터링 스레드로 전달하는 중앙처리 방식 구조를 취하고 있다.

중앙처리 방식이 아닌 서비스 워커 스레드가 EM을 거치지 않고 직접 모니터링 스레드로 전송한다면 서비스 워커 스레드마다 모니터링 스레드와 파이프로 연결해야 한다. 그러면 하나의 파이프를 여러 스레드가 경쟁하기 때문에 Lock 문제가 생기게 되고 이 문제를 해결하기 위해 여러 개의 파이프를 모니터링 스레드에 붙이면 너무 많은 FD를 쓰게 되며, 모니터링 스레드에서 멀티플렉싱(Multiplexing)을 처리해야 하기 때문에 복잡한 구조가 된다. 따라서 ProObject에서는 위의 그림과 같은 구조로 모니터링을 진행한다.

모니터링 모듈에서는 E2E 모니터링 정보를 데이터 타입별로 구분해서 서로 다른 테이블에 저장한다.

그 이유는 기본적으로 사용자가 거래 단위로 얼마만큼 오래 걸렸는지를 확인하는 경우 트랜잭션 정보만 필요하므로 트레이스 정보까지 조회할 필요가 없기 때문이다. 따라서 모니터링 스레드 또한 데이터 타입별로 분리해서 HyperLoader에게 독립적으로 데이터를 전송한다. (실제로 모니터링 스레드는 2개)

다음은 E2E 모니터링 정보를 저장하는 트랜잭션 테이블과 트레이스 테이블의 각 컬럼에 대한 설명이다.

서버들 간에 GUID를 통해 같은 거래임을 식별했다 할지라도 실제 수행 구간들의 흐름을 정렬하는데 문제가 있다. 만약에 서비스의 수행 흐름을 시간 순으로 정렬하게 되면, 서버들 간에 시간이 동기화되어 있지 않아 실제 실행 순서와 다를 수 있다. 이러한 문제를 해결하기 위해 식별된 거래들을 시간이 아닌 시퀀스(Sequence)를 바탕으로 정렬 처리한다.

시퀀스 정책은 다음과 같다.

다음은 하나의 서비스(거래) 요청이 발생했을 때 시퀀스를 사용해서 서비스의 흐름을 추적하는 예제이다.

최초 거래 발생했을 때 트랜잭션 타입의 정보를 저장한다. 이때 발급한 시퀀스가 1이라고 한다면, 트레이스 정보의 최초 시작 시퀀스는 트랜잭션 시퀀스에 depth를 추가한 1.1이 되며, 다른 컴포넌트로 이동할 때마다 시퀀스의 depth를 추가한다. 또한 두 번째 ServiceObject 컴포넌트에서 BizObject를 수행한 다음에 DOF를 수행할 때 시퀀스가 1.1.1.1에서 1.1.1.2로 증가하는 것처럼 같은 컴포넌트 내에서는 시퀀스의 마지막 값을 1씩 증가시킨다.

결과적으로 위의 예제는 1(START) → 1.1(START) → 1.1.1(START) → 1.1.1.1(START) → 1.1.1.1(END) → 1.1.1.2(START) → 1.1.1.2(END) → 1.1.1(END) → 1.1(END) → 1(END)의 흐름대로 서비스를 실행하고 있음을 알 수 있다.

모니터링 데이터 타입별로 수집은 정보는 아래 파일에 설정한다.

다음은 system.propertie 파일의 주요 설정항목에 대한 설명이다.

다음은 모니터링 데이터 수집 정보를 설정한 예이다.

ProObject 서버의 JVM 옵션에 HyperLoader와 커넥션을 맺기 위해 JEUS의 domain.xml 파일에 설정을 해야 한다.

JVM 옵션은 JEUS의 WebAdmin을 통해 설정하거나, domain.xml 파일을 수정한다.

[참고]

HyperLoader를 대체해서 SysMaster를 사용해 모니터링 정보를 수집하는 경우 JEUS의 domain.xml 파일에 SysMaster 전용 JVM 옵션을 설정한다.

모니터링 스레드를 중지시키려면 모니터링 정보를 전송할 대상과 연결을 끊는다.

다음은 서비스 호출에 필요한 URL이다.

모니터링 스레드를 재시작시키 려면 모니터링 정보를 전송할 대상과 연결을 맺는다.

다음은 서비스 호출에 필요한 URL이다.

거래 제어는 특정 서비스가 돌아가는 서비스 워커 스레드를 종료시키는 기능이다. 모니터링 화면을 통해 비정상적으로 오래걸리거나 장애가 발생했다고 판단했을 때 해당 서비스를 수행 중인 스레드 아이디 값을 통해 스레드를 종료시킨다.

다음은 서비스 호출에 필요한 URL 및 입출력이다.