E2E-Monitor 개발 프로젝트 회고(1/3), 새로운 프로젝트의 시작

얼마전에 마무리 했던 프로젝트에 대한 글을 적어 볼까 합니다.

이번 프로젝트는 사내에서 진행한 것이 아니라 외주를 받아 진행한 것이기 때문에 고객사에 대한 정보와, 보안과 관련된 부분들은 당연히 모두 빼고, 일반적인 내용들과 공개된 오픈소스, 알고리즘, 솔루션에 대한 내용만 다루도록 하겠습니다.

프로젝트에 대한 소개부터 시작하는게 좋겠죠? ^^

그럼 시작합니다.

Application Transaction Monitoring System, E2E-Monitor

개발할 시스템의 이름은 "E2E-Monitor" 였습니다.

공식 문서에서나 쓰이는 딱딱한 문장(?)으로 표현하자면,

"E2E-Monitor는 애플리케이션을 구성하고 있는 서버간의 통신 흐름을 운영자가 화면을 통해 쉽게 파악하고 모니터링 할 수 있는 일종의 관제 플랫폼입니다."

Request를 받은 순간부터 Response를 보내는 순간까지의 모든 처리 과정을 운영자가 한눈에 파악 할 수 있도록 Diagram으로 보여주는 프로그램입니다.

(E2E는 End to End의 약자로 여기서는 Request에서부터 Response까지를 의미합니다.)

Request에서부터 Response까지를 하나의 Transaction이라고 보면, "E2E-Monitor"는 결국 "Application Transaction Monitoring System"이라고 할 수 있을 것 같습니다.

[1. E2E-Monitor Dashboard 화면]

프로젝트 배경

고객사는 최근 신규 서비스를 개발해 운영중이었습니다. 

서비스의 규모가 어느정도 되다 보니, 여러 종류의 Application들과 여러대의 서버들이 운영되고 있는 상태였습니다.

하나의 Request는 최소 3단계에서 최대 10단계가 넘는 처리 과정(서버간 네트워크 통신)을 거쳐서 최종 Response를 내려주고 있습니다.

그런데 간헐적으로 정상적이지 않은 Response들이 발생하기 시작합니다. 

Application이나 서버 자체의 장애일 수도 있고, 비즈니스 로직 상의 문제일 수도 있습니다. 

문제가 발생한 위치만 알 수 있다면, 해당 Module의 담당자가 원인을 분석해서 문제를 해결 할 수 있을 것입니다.

하지만, 문제는 어느 서버의 어느 Application에서 문제가 발생했는지 추적이 힘들다는 점이 었습니다.

전체 서비스를 관제하고 있는 운영자는 문제의 시발점을 찾기 위해 해당 Request가 어떤 처리 과정들을 거치는지 파악해서 해당 과정들을 순서대로 점검해야 할겁니다. 문제의 시발점을 찾을 때까지요...

운영자가 하나의 서비스만 담당하고 있으며, 문제가 자주 발생하지 않는다면, 그리고 시간이 넉넉하다면.... 그냥 하면 됩니다.

그러나 실제로 그런 업무 환경에서 일하는 운영자는 거의 없겠죠?

운영자는 여러개의 서비스를 담당하고 있으며, 문제는 자주 발생하고, CS 담당자는 빨리 문제들을 해결해 달라고 재촉을 해댈겁니다.

운영자는 문제가 발생하면 그 위치와 문제점의 종류를 즉시 알 수 있는 "관제 시스템"이 필요하다는 결론을 내립니다.

요구사항

운영자의 요구 사항은 간단합니다.

"운영중인 시스템에서 문제(Error)가 발생하면 바로 어떤 문제가 어디에서 발생했는지를 알려주는 시스템이 필요합니다."

운영자의 요구 사항을 들어주기 위해 개발팀은 여러가지 관제 솔루션들을 찾아보기 시작합니다.

그러다가 요구 사항과 가장 근접한 오픈소스를 찾게 됩니다.

바로 Naver에서 개발한 Pinpoint입니다.

[2. pinpoint Dashboard 화면]

Pinpoint UI를 보시면 아시겠지만, Server Map이라는 Diagram이 화면의 대부분을 자체하고 있습니다. 

Server Map은 서버들을 노드로, 네트워크 연결을 간선으로 표시하고 있으며, 간선에는 단위 시간동안 발생한 네트워크 통신의 횟수가 적혀 있습니다.

Server Map을 보고 있으면 시스템의 전체적인 흐름를 한눈에 알 수 있을것 같습니다.

하지만, Pinpoint를 실무에 도입하기 위해서는 풀어야 될 숙제들이 너무 많았습니다.

가장 큰 문제는 고객사의 시스템은 Message Queue가 중요한 구성요소중에 하나 인데, Pinpoint로는 Message Queue를 거치는 처리 과정은 추적이 불가능하다는 것이었습니다.

그 외, Pinpoint 적용을 위한 추가 공수가 예상외로 많이 들어간다던지 하는 문제점들이 많았습니다.

결국 고심끝에 고객사는 자신들이 운영하는 시스템에 딱맞는 관제 시스템을 새로 만들기로 결정하고, 저희에게 개발을 의뢰하게 됩니다.

고객사의 요구사항을 정리하면 간단하게 이렇습니다.

1. Server Map Diagram을 통해 모든 시스템의 연결 상태 모니터링 (HTTP 통신 뿐만 아니라 TCP, Message Queue등 운영중인 시스템에서 사용되고 있는 모든 통신 수단 포함)

2. 에러 발생시 화면 출력과 소리, E-mail, SMS 등의 수단으로 운영자에게 알림

3. 에러 발생 위치를 Server Map에 표시

4. 특정 검색 조건으로 원하는 Transaction 정보 검색

5. HTTP 통신 이외에, TCP 통신, Message Queue 통신에 대해서도 모니터링 

4. 운영 시스템의 개발자가 추적 정보를 쉽게 생성할 수 있도록 최대한 사용이 간단한 Library와 친절하고 상세한 가이드 문서

프로젝트를 2단계로 분리하다

프로젝트는 일단 파일럿팅 개념으로 작게 시작하기로 합니다.

관제 시스템의 효용성에 대한 검증이 우선이라고 생각한 것입니다. 

관제 시스템은 크게 3가지 구성요소를 가지고 있습니다.

1. 각 Application에서 추적을 위한 정보를 생성하는 "추적정보 생성기"

2. 생성된 추적 정보를 수집해서 Transaction 별로 묶어서 저장소에 저장하는 "추적정보 처리기"

3. 저장소에 있는 추적정보를 사용자가 쉽고 볼 수 있도록 화면에 출력해주는 "사용자 프로그램"

"추적정보 생성기"는 두가지 방식이 있습니다.

첫번째 방식은 "수동 추적 방식"입니다.

추적 정보 생성을 위한 코드를 개발자가 Legacy System에 추가해주는 방식입니다.

관제 시스템 개발자 입장에서는 가장 쉽고 편한 방법입니다. 추적 정보에 대한 스팩만 정의하고 실제 추적 정보는 운영 시스템의 개발자가 알아서 잘 생성해 줄거라 믿고 관제 시스템을 개발하기만 하면 되죠.

하지만, 운영 시스템의 개발자 입장에서는 마른 하늘에 날벼락 같은 상황 일겁니다.

잘 돌아가고 있는 시스템에 비지니스 로직과는 상관도 없는 코드를 추가하라고 할 때 좋아할 개발자는 아마 없을 겁니다.

설령 억지로 코드를 추가 했다고 해도 새로 들어간 코드 검증을 위해 모든 시스템에 대한 테스트, 검증, 검수 등의 복잡한 단계를 다시 거쳐야 할 수도 있습니다.

반면, 두번째 방식은 "자동 추적 방식"으로 추적 정보를 수집해 주는 Agent가 System Low Level에서 돌아가면서 알아서 정보를 수집해 주는 방식입니다.

자동으로 추적 정보를 생성할 수만 있다면, 운영 시스템의 개발자는 추가로 해야될 일이 없습니다. 물론 기존 코드를 수정할 필요가 없기 때문에 위험 부담도 적고, 운영 시스템에 적용하기도 쉬울 겁니다.

이 경우 문제는 관제 시스템을 개발하는 쪽에 있습니다.

운영 시스템에서 사용되고 있는 통신관련 기술, 솔루션등을 모두 수집해야 하고, 각 요소마다 어떤 식으로 추적정보를 남길지 결정하고, 요소별로 따로 개발을 해줘야 합니다.

빠른 시간안에 결과물을 만들어서 검증을 하기 위해 "자동 추적 방식"을 버리고 "수동 추적 방식"을 선택합니다.

사실 "자동 추적 방식"을 버린다는 것은 운영 중인 시스템에 새로 개발한 관제 시스템을 바로 적용 시키는 것을 거의 불가능 합니다.

하지만, 새로 개발되는 서비스에서는 초반 개발단계에서 부터 "추적정보"를 의무적으로 생성하도록 하는건 상대적으로 쉽습니다.

이번 프로젝트의 전략은 일단 수동방식으로 빨리 개발하고, 신규 서비스나 상대적으로 규모가 적은 기존 서비스에 관제 시스템을 먼저 적용해 보고 운영하면서, 관제 시스템을 고도화 하는 것입니다.

그 대신 "추적 정보 처리기"와 "사용자 프로그램"은 추후에 추적 방식을 자동으로 바꾸기 용이하도록 Pluggable한 구조로 개발하기로 합니다.

E2E-Monitor Architecture

E2E-Monitor는 모니터링 대상 시스템의 Scale 변경에 유연하게 대처하기 위해 Scale-out이 가능한 구조로 설계했으며, 각 모듈들은 최대한 느슨하게 연결되도록 신경을 썼습니다.

[3. E2E 구조도]

 

A. 추적 정보 수집기

추적 정보 생성기에 해당하는 부분입니다.

모니터링 대상 시스템에서 추적에 필요한 정보를 생성해서 파일에 적는 일을 합니다.

Log Collector가 생성한 정보는 최종적으로는 Search Engine에 저장되게 됩니다. 그런데 구조도를 보면 Search Engine에 저장되기 전까지 몇단계를 거치도록 되어 있는걸 보실 수 있습니다.

단계는 다음과 같습니다.

1. Log Collector는 정보를 일단 파일에 적습니다.

2. Log Stash는 로그 파일을 감시하고 있다가 Log Collector가 정보를 파일에 적으면, 그걸 바로 읽어서 Message Queue로 실어보냅니다.

3. Message Queue Consumer는 Message Queue를 감시하고 있다가 Message가 들어오면 바로 읽어서 Search Engine에 저장합니다.

Log Collector가 바로 Search Engine에 저장하지 않고 여러 단계를 거치는 이유는 모듈간의 느슨한 연결과 Pluggable한 구조를 위해서 입니다.

일단 정보를 파일에 우선 적음으로써 모니터링 대상 시스템이 무슨언어로 만들어지던지 상관이 없어집니다.

어찌되었던 정해진 포멧대로 파일에 정보를 적을 수만 있으면 되니까요.

Log Stash가 파일에서 읽어들인 정보를 바로 Search Engine에 넣지 않고 Message Queue에 태우는 이유는 System Performance 때문입니다. 

보통 읽기 성능은 Scale-out을 통해 쉽게 향상이 가능하만, 쓰기 성능은 크게 향상되지 않습니다. 가장 쉽게 쓰기 성능을 향상 시킬수 있는 방법은 Bulk Write 방식을 사용하는 것이라고 판단했습니다.

그래서 일단 Message Queue에 정보를 쌓아두고, 일정 조건에 맞춰 대량의 정보를 한번에 Search Engine에 쓰기로 했습니다. 또한 1차 가공 단계를 거치기 때문에 무리하게 모니터링 대상 시스템에서 작동하는 Log Stash에 비지니스 로직을 추가할 필요가 없게 되는 장점도 있습니다.

B. 추적 정보 처리기

일련의 단계를 거쳐 Search Engine에 저장된 정보는 다시 주기적인 배치작업을 통해 Transaction 별로 분류되고, Transaction 관련 통계 정보를 생성하는 과정을 거치게 되는데, 이런 일을 하는 모듈이 바로 Log Composer 입니다.

Log Composer는 1분에 한번씩 기초 데이터(Log Collector에서 생성되 Search Engine에 저장된 원시데이터)들을 읽어 들여서 분류 및 재가공 과정을 수행합니다.

재가공된 정보는 다시 용도에 따라 Search Engine과 RDB에 나누어 저장됩니다.

C. 사용자 프로그램

운영자가 사용하는 프로그램입니다.

Search Engine과 RDB에 저장되어 있는 정보를 가져와 Web Client로 전송해 주는 API Server와 Web Client로 구성되어 있습니다.

API Server는 Java로 구현되어 있고, Web Client는 AngularJS를 사용했습니다.

앞으로 해야 할 일들

현재 E2E-Monitor에서 가장 선행되어야할 추가 작업은 추적정보 수집 방식 변경입니다.

모니터링 대상 시스템의 개발자가 직접 추적 정보 수집을 위해 기존 코드에 손을 대는것은 참으로 위험하고 힘든 작업일 것입니다. 

현실적으로는 정말 작은 시스템이거나 새로 개발되는 시스템이 아니라면, 적용이 거의 불가능한 방식이라고 생각합니다.

그래서 E2E-Monitor의 생명력은 자동으로 추적정보를 수집하는 기능을 갇추느나 마느냐가 결정할 것으로 보고 현재 이 부분을 최우선 과제로 삼고 있습니다.

그 외 운영자 마다, 또는 시스템 마다 보고 싶은 정보가 조금씩 다를 수 있기 때문에 Customizing이 가능한 Dashboard를 구상중에 있습니다.

 

범용성

E2E-Monitor는 특정 회사의 요구사항에서 시작했지만, 다양한 구성의 어떠한 시스템에도 적용 가능하도록 설계하고 개발되었습니다.

물론 서비스 고유의 기능등 추가적으로 필요한 부분들은 추가적인 공수가 들어가겠지만, 최소한의 공수만으로 추가 가능하도록 설계했습니다.

혹시라도, 운영 중인 시스템에 적용할 관제 시스템을 찾고 계시거나, System Trouble Shooting에 애를 먹고 계신다면 저희에게 연락 주시면 도와드리겠습니다.

프로젝트에 대해 간단하게 설명드릴려고 했는데 생각보다 글이 길어졌네요.

다음 글에서는 E2E-Monitor에 사용했던 Web 기술들에 대한 소개를 하겠습니다.