E2E-Monitor 개발 프로젝트 회고(3/3), 시스템 구성과 기술들

"E2E-Monitor 개발 프로젝트 회고" 마지막 글이 되겠네요.

마지막으로 다룰 내용은 E2E-Monitor의 Back-end 부분에 대한 이야기 입니다.

초기에 설계했던 시스템 구조에서부터 프로젝트 완료 당시의 변화된 시스템 구조까지, 그 변화 과정을 살펴 보면서 왜 구조가 이렇게 변경되어 왔는지, 그리고 거기에 사용했던 솔루션들은 어떤 기준으로 도입했는지에 대해서 이야기해 볼까 합니다.

E2E-Monitor의 시스템 구성과 사용했던 기술들

처음에 고객사로부터 받은 요구 사항은 상당히 구체적인 것처럼 보이면서도 한편으로는 모호한 것들이 많은 상태였습니다.

가장 먼저 필요했던 것은, 고객의 요구 사항에 대해서 저희가 정확하게 이해하고 있는지에 대한 확인 작업이었습니다.

그래서 일단, 1차적으로 분석한 요구 사항을 바탕으로 "시스템 구조도"를 작성해 보기로 했습니다.

모호했던 부분들은 우선 나름대로의 상상력을 동원해 가며 채워 넣고, 나중에 고객사에게 확인을 받기로 했습니다.

첫번째 시스템 구조도

아래의 그림이 E2E-Monitor의 첫번째 시스템 구조도 입니다.

[그림 1. E2E-Monitor 시스템 구조도 - v1]

Log Transmission Layer는 모니터링 대상이 될 시스템으로부터 추적 정보를 전달 받는 부분입니다.

구조도를 보시면 Log Collector와 Polling Processor가 각각 Message Queue로 데이터를 보낼 수 있도록 연결되어 있는 것을 보실 수 있습니다.

Log Collector와 Polling Processor를 함께 둔 이유는, 당시에는 대상 시스템에서 어떤 방식으로 추적 정보를 전달받을 수 있을지 몰랐기 때문입니다.

그래서 일단 Push 방식과 Polling 방식 두가지 모두를 처리할 수 있는 구조를 생각하게 되었습니다.

그리고, Message Queue를 임시 저장소로 사용함으로써 여러가지 전달 방식에 따라 유동적으로 대처할 수 있도록 설계했습니다.

Log Process Layer는 수집된 추적 정보를 분석하고 재가공해서 저장소에 저장하는 부분입니다.

Log Pre-processor는 Message Queue에서 추적 정보를 가져와 저장소에 저장하고 CEP Engine으로 데이터를 전달 하는 역할을 합니다.

CEP Engine(실시간 이벤트 분석, 처리 솔루션)은 Log Pre-processor로부터 전달 받은 데이터에서 특정 이벤트 또는, 이벤트 패턴이 발견되면 데이터를 Log Post-processor로 전달합니다.

Log Post-processor는 CEP Engine으로 부터 전달 받은 데이터의 유형에 따라 사용자에게 바로 메세지를 보내거나 저장소에 저장하는 역할을 담당하게 됩니다.

그리고 웹 클라이언트에게 화면에 보여줄 데이터를 전송하는 API 서버도 이 Layer에 두었습니다.

그 외 데이터를 저장소하기 위한 Data Layer, 사용자가 웹브라우저를 통해 접근할 수 있는 Presentation Layer를 분리 시켜놓았습니다.

첫번째 시스템 구조도는 비록, 이 후 많은 변경이 이루어지긴 했지만, 고객사의 요구사항 분석이나, 고객사와의 업무 범위를 조율하는데 많은 도움이 되었고, 시스템의 골격을 잡는 데 큰 역할을 했습니다.

두번째 시스템 구조도

다음에 있는 구조도는 고객사와의 업무 범위 조율 및 요구 사항 협의가 어느정도 마무리 된 다음에 작성된 것으로, E2E-Monitor의 두번째 시스템 구조도 입니다.

[그림 2. 요구 사항 협의 후 수정된 시스템 구조도 - v2]

첫번째 구조도와 달라진 점을 찾아볼까요?

우선 첫번째 시스템 구조에 있던 Polling processor가 없어졌습니다.

기존 대상 시스템들을 확인한 결과, 모든 시스템들이 Log Collector를 통해 Message Queue로 추적 정보를 보내는데 문제가 없는 것으로 확인되었습니다.

그래서 추적 정보를 수집하는 것은 Log Collector로 단일화 하기로 하고, Polling processor는 구조도에서 제외했습니다.

다음으로 달라진 점은 CEP Engine을 빼고 그자리에 Log Filter와 WebSocket 모듈이 추가된 부분입니다.

CEP Engine을 추가하는 것은, 필요 이상으로 개발 비용 및 기간이 증가할 수 있다는 점과 CEP Engine 운영 인력 부제등의 문제가 주요 이유로 작용했습니다.

그대신 간단하게 CEP Engine의 역할을 할 수 있도록 간단하게 Log Filter를 구현하고 실시간 서비스를 위해 WebSocket 모듈을 추가해 놓았습니다.

그리고 데이터 저장소 부분은 MySQL이나 PostgreSQL같은 RDBMS가 아닌 Elastic Search을 사용하기로 했습니다.

Elastic Search 도입 이유

Elastic Search를 사용하기로 한 가장 큰 이유는 데이터 분산 저장 때문이었습니다.

E2E-Monitor는 대상 시스템에 종속적인 시스템입니다.

대상 시스템에서 발생하는 모든 이벤트를 저장해야 하고, 시스템 Scale-out 가능성에 대비해야 합니다.

이러한 특성을 만족시키기 위해 가장 신경썻던 부분은 데이터 저장소 부분이었습니다.

원활한 Scale-out을 위해서는 늘어나는 데이터량에 대응할 수 있는 Write 성능과 데이터 분산 저장이 필요했습니다.

MySQL이나 PostgreSQL같은 오픈소스 DB로는 Write 성능도 일정 수준 이상 높이기 힘들었고(스토리지를 SSD를 쓰면 될것 같은데 비용이 문제), 데이터도 분산해서 저장할 수 없었습니다.

결국 Data Sharding 기술을 이용하는 솔루션을 사용해야 했는데, 오픈소스 진영을 솔루션들 중에서 Data Sharding을 지원하는 솔루션으로 고려 대상이 되었던 것이 MongoDB와 Elastic Search였습니다.

두가지 솔루션 모두 시스템 Scale-out과 데이터 Sharding을 지원합니다.

이제 두가지 솔루션 중 어떤 것이 E2E-Monitor에 더 적합한 솔루션인지 이것저것 고려해보고 결정하는 일이 남았습니다.

두가지 솔루션중 Elastic Search를 선택한 이유는 E2E-Monitor가 주로 사용해야 할 쿼리 패턴 때문이었습니다.

E2E-Monitor에서 사용해야 할 쿼리의 대부분은 Grouping, Sorting, Searching 기능들이었습니다.

관제를 위해 필요한 데이터는 넉넉하게 잡아도 두달치 정도면 충분 할 것으로 예상했습니다. 

옛날 데이터까지 모두 저장할 필요가 없었습니다. 

최근 데이터만 저장하고 있으면서 데이터 Aggregation과 Searching 쿼리를 주로 사용 하기에는 MongoDB보다는 Elastic Search가 더 적합한 솔루션이라고 판단했습니다.

시스템 구조도 최종본

두번째 시스템 구조도가 완성된 시점에는 요구사항 수집 및 분석은 거의 마무리 된 상태였습니다.

시스템 구조도의 최종본은 시스템 설계를 완료하면서 함께 완성되었습니다.

불확실했던 부분들이 확실히 지고, 구체적인 기능들이 명세화 되면서 실제 구현해야 될 시스템의 모습이 Diagram위에 그 모습을 드러내기 시작했습니다.

완성된 시스템의 구조도는 다음과 같습니다.

[그림 3. 최종 시스템 구조도 - v3]

마지막 시스템 구조도에서는 일단 Log Pre-processor가 MQ Consumer로 이름이 바뀌었습니다.

실제 기능에 맞는 직관적인 이름을 주는 것이 개발중에 이루어지는 커뮤니케이션에 더 효율적일 것이라는 판단때문이었습니다. 

그리고 두번째 시스템 구조도에 있었던 Log Filter와 WebSocket 모듈을 모두 빠졌습니다.

실시간 이벤트 패턴 검색 기능 및 알람 기능은 개발 비용 및 일정 때문에 우선순위에서 계속 밀리다가 결국에는 기능 자체를 없에는 것으로 결정되었습니다. (고도화 계획에 포함)

초기에 계획에 없다가 마지막에 추가된 모듈도 있습니다.

새로 추가된 Log Composer는 Transaction에 대한 통계를 내기 위한 모듈입니다. 

이 모듈이 추가되기 전까지 E2E-Monitor는 하나의 Request에 대한 처리 결과를 하나의 데이터로 취급했었습니다.

예를 들어 "/user/join"이라는 하나의 Request에 대한 처리 과정을 span이라고 부르고, 이 span에 대한 통계 데이터를 보여주기로 했습니다.

하지만, 여러차례 논의 과정을 거치면서 span에 대한 정보만으로는 전체적인 서비스의 흐름을 파악하기 힘들다는 결론을 내리게 됩니다.

이제 E2E-Monitor는 하나의 논리적인 Action을 구성하는 여러개의 span을 하나의 Transaction으로 보고, 이 Transaction을 기준 데이터로 사용하기로 합니다.

Transaction이라는 것이 여러개의 span들로 구성되어 있기 때문에 span들을 Grouping하고 Transaction에 대한 정보를 추가로 생산해 내기 위해서는 새로운 모듈이 필요하게 되었고, 그래서 추가된 모듈이 Log Composer입니다.

Log Composer는 Span 데이터를 Grouping하고 재구성해서 새로운 Transaction 정보를 만들어내서 저장소에 저장하는 역할을 합니다.

PostgreSQL 도입 이유

Log Composer가 사용하는 저장소를 보시면 Elastic Search와 함께 PostgreSQL이 있는 것을 보실 수 있습니다.

두번째 시스템 구조에서는 없던 PostgreSQL을 새로 추가한 이유는 통계 데이터를 저장하기 위해서 입니다.

단순 환경 설정 값들과, 영구적으로 보관해야 하는 Transaction 통계 데이터를 저장하기 위한 공간으로, 고객사에서 기존에 사용하고 있던 PostgreSQL사용하기로 했습니다.

최종 시스템 구조도에서는 변경된 구조를 반영한 것 뿐만 아니라, 각 모듈에서 실제로 사용할 구체적인 솔루션들에 대한 내용도 추가되었습니다.

LogStash 도입 이유

Log Collector에서 사용한 LogStash는 대상 시스템과의 Coupling을 최소화하기 위해 사용했습니다.

대상 시스템에서 바로 다른 저장소로 데이터를 전송하는 것보다는, 대상 시스템은 추적 정보를 파일에 적게 하고, 파일에 적힌 데이터는 다른 프로그램이 읽어서 전송하게 함으로써, E2E-Monitor와 대상 시스템간의 Coupling이 줄 수 있도록 설계했습니다.

그리고 Log파일을 읽어서 Message Queue로 전송하는 일은 LogStash가 하도록 했습니다.

LogStash는 Fleuntd나 기타 다른 솔루션으로 대체가 가능한데, 저희에게는 가장 손이 익은 솔루션이 LogStash라서 선택하게 되었습니다.

Kafka 도입 이유

Message Queue는 Kafka를 사용하기로 했는데, 가장 많이 사용되고 있는 Rabbit MQ 대신 Kafka를 사용한 이유는, Kafka가 실시간 대용량 분산 Message 처리에 특화되어 있기 때문이었습니다.

그리고 이미 고객사에서 Message Queue로 Kafka를 사용하고 있기 때문에 도입하는데 아무런 문제가 없었습니다.

시스템 구조도 최종본은 실제 시스템 개발이 들어가기 바로 전에 완성되었습니다.

그리고 다행히도 실제 개발 중에 구조도가 바뀌진 않았습니다. 

만약 개발 도중 시스템 구조가 바뀌었다면, 아마도 개발 일정을 맞추지 못하는 사태가 생겼을 것 같습니다.

마무리, 진짜 프로젝트 회고

이 글을 마지막으로, E2E-Monitor 개발 프로젝트 회고 글을 모두 마쳤습니다.

이번 프로젝트는 2개월이라는 짧은 시간 동안 개발 인력 5명이라는 투입된 프로젝트였습니다.

당초 예상했던 MM이 9MM이었던 점을 감안하면, 결론적으로는 1MM이 초과되었는데, 이부분은 신입 인력 교육에 투자한 것으로 생각하기로 했습니다. (손해난 부분을 이런식으로 대충 퉁치고 넘어가기로.... ㅠ.ㅠ)

사실 3명이서 3개월 정도로 예상한 프로젝트인데, 기간이 2개월로 줄면서 어쩔 수 없이 인력을 추가 투입한 케이스라고 보시면 될 것 같습니다.

여러가지 프로젝트를 많이 해보셨던 분들은, "3개월에 3명이서 할 일"을 "5명을 투입해서 2개월만에 끝내라"는 것이 그렇게 계산대로 쉽게 되는 일이 아니라는 것을 잘 아실겁니다.

Man-Month의 함정이라고도 하죠.

어찌되었건 기간은 촉박한데, 인력은 충분한 상황이었습니다.

그래도 어찌어찌 해서 기간안에 프로젝트를 일정대로 진행하고 완료 할 수 있었던 것은, 무리한 일정과 개발 계획 때문에 매일 매일 새벽까지 야근하면서도 웃으면서 즐겁게 일했던, 똑똑하면서도 오덕스럽고, 그리고 순박했던 우리 개발자들 때문이라고 생각합니다.

이 글을 빌려서, 함께 했던 우리 개발자들에게 감사의 뜻을 전하고 싶습니다.

김민기 부장 <smoon@embian.com>: Back-end 설계 / 개발

김정 대리 <jung@embian.com>: Back-end / API 개발

조석현 과장 <zoe@embian.com>: Front-end 개발 / 산출 문서 작성

한종민 사원 <hjm@embian.com>; Front-end 개발

그리고 저는 (주)엠비안 개발2본부장 박재영 <yam@embian.com> 이었습니다.

지금까지 긴글 읽어 주셔서 감사합니다. 

* E2E-Monitor가 실제 작동되는 모습을 보시고 싶으신 분들은 "E2E 데모"를 방문하시면 확인하실 수 있습니다.