"E2E Monitor 프로젝트"가 끝난 후 고도화 작업이 진행되었습니다. 

 "E2E Monitor 프로젝트 회고"포스팅을 보면, 프로젝트 진행 당시 빠른 시간 안에 결과물을 만들어서 검증하기 위해 추적 정보 생성기를 "수동 추적 방식"으로 개발하였습니다. 하지만 "수동 추적 방식"은 모니터링 대상 시스템에 바로 적용이 어렵기 때문에 E2E Monitor의 최우선 과제로 "자동 추적 방식"을 꼽았습니다. 따라서 자연스럽게 Back-end 고도화는 "BCI(Byte Code Instrumentation)기법을 사용한 자동 추적 정보 생성기 개발" 이 되었습니다.


고도화 부분

E2E Monitor 프로젝트는 아래 <그림1.>처럼 크게 3가지의 구성요소로 나뉘는데요,


<그림 1. E2E Monitor 구성요소>


이 중에 추적 정보 생성기에 대해 "자동 추적 방식"을 사용할 수 있도록 고도화를 진행하였습니다. 


추적 정보 생성기 개발

자동 추적 방식을 도입하기 위해 BCI 기법을 사용한 여러 가지 모니터링 툴을 조사하던 중 ASM 기반으로 구현되어있는 Java Agent 프로그램인 Byteman을 접하게 되었습니다.

Byteman은 재컴파일이나 재구동 없이 실행 중인 어플리케이션에 Bytecode를 변형, 주입 및 제거 가능한 기능을 가지고 있습니다. Byteman에서 사용하는 DSL(Domain-Specific Language)로 "Rule" base script를 생성하여 동적으로 디버깅 코드를 디버깅 대상 Application에 적용 가능합니다. 

즉, Byteman을 도입하면 "Rule" Script를 통해 E2E Monitor에서 필요한 정보를 모을 수 있는 추적정보 생성기를 모니터링 대상 Application에 동적으로 적용 가능한 것입니다. 이러한 이점 때문에  Byteman을 도입, 자동 추적 정보 생성기를 개발하였습니다. 


자동 추적 정보 생성기가 수집하는 정보

기존에 개발했던 수동 추적 정보 생성기에서 생성한 정보들을 전부 수집 및 생성할 수 없었지만, 사용자 프로그램에 표시하기 위한 기본정보가 추출됨을 확인하였습니다.

자동 추적 정보 생성기에서 추출할 수 있었던 정보는 다음과 같습니다.

1. 하나의 네트워크 통신의 시작과 끝

2. 하나의 네트워크 통신을 처리하는 데 걸린 시간

3. 네트워크 Request 종류, URI, 파라미터 이름, 파라미터값 -> 고도화에서 추가된 정보

4. 현재 모니터링 하고 있는 Application의 이름

5. 네트워크 통신 처리 시 수행된 Method 이름

6. 네트워크 통신 시퀀스 정보(네트워크 통신 또는 DB 질의가 발생한 경우 Call Stack처럼 수집) -> 고도화에서 추가된 정보

7. DB 쿼리와 수행 시간 -> 고도화에서 추가된 정보

8. E2E Monitor에서 추적에 필요한 필수 정보를 HTTP 통신 시 사용하는 Client 헤더에 자동으로 Inject

9. Throw된 Exception 기록


Emulator에 자동 추적 정보 생성기를 실행하여 E2E Monitor의 사용자 프로그램이 어떻게 표현해 주는지 확인해 보았습니다. 

먼저 수동 추적 생성기를 적용한 경우 사용자 프로그램은 아래와 같이 표현됩니다.

<그림 1. 수동 추적 정보 수집기를 사용한 경우 볼 수 있는 정보>

다음은 자동 추적 정보 수집기를 사용한 경우 표현입니다.

<그림 2. 자동 추적 정보 수집기만을 사용한 경우 볼 수 있는 정보>

수동 추적 정보 수집기가 보여주는 정보에 비해서 빈약한 정보를 보여주고 있지만, 자동으로 수집된 정보는 사용자에게 대략적인 네트워크 플로우를 보여줄 수 있는 수준입니다. 


마무리

이번 고도화에서 모니터링 대상 시스템에 BCI 기법을 도입한 자동추적 정보 수집기를 동적으로 적용 할 수 있게 하였습니다. 기본적인 정보를 자동 수집하여 사용자 프로그램에서 표현이 가능했지만, 추가로 모은 정보를 표현하지 못한 부분이 있었습니다. 이는 추적정보 처리기와 사용자 프로그램이 같이 개발 되어야 했기 때문입니다. 이 부분은 향후 개발 계획에 넣어 놓고 이번 고도화를 마무리 지었습니다.

E2E Monitor는 이제 기존의 수동 정보 수집 방식에 더하여 자동 정보 수집 방식까지 갖추게 되었습니다. E2E Monitor v3.0을 기대하며 이번 포스팅을 마칩니다.


Posted by 알 수 없는 사용자
,

얼마전에 마무리 되었던 E2E Monitor 프로젝트의 고도화 작업이 있었습니다. 이 작업에 제가 참여하게 되었는데요.

(*혹시 E2E Monitor에 대해 궁금하시다면 다음 링크를 참조해 주세요!)

E2E Monitor 고도화 작업은 크게 두가지로 나뉘었습니다. 


첫번째, BCI(Byte Code Instrument) 작업

두번째, E2E Monitor UI 고도화 → 저랑 종민씨가 담당했던 부분


이번 글에는 저랑 종민씨가 담당했던 E2E Monitor UI 고도화 작업에 대한 이야기를 풀어볼까 합니다. 

E2E Monitor UI 고도화 작업의 목표는 Dashboard 개인화였습니다. Dashboard 개인화란 운영자마다 또는 시스템 마다 보고 싶은 정보가 조금씩 다를 수 있기 때문에 사용자들이 원하는 데로 Dashboard를 편집 할 수 있도록 하는 것입니다.

본격적으로 작업을 시작하기 전에 Dashboard UI와 관련된 자료를 찾아 보기 시작 했고 Dashboard 개인화를 하는데 참고한 오픈소스는 아래와 같습니다.


1. http://nickholub.github.io/angular-dashboard-app/#/

이 오픈 소스의 경우에는 사용자들이 원하는 위젯을 추가 삭제할 수 있도록 구현 되어있었습니다. 아쉬운 점이라면 정렬이 되지 않아 다소 산만해 보이는다는 점입니다. 


[nickholub - angular-dashboard-app]



2. http://angular-dashboard-framework.github.io/angular-dashboard-framework/#/sample/01

이 오픈 소스의 경우에는 사용자가 위젯을 추가 삭제 할 수 있고, 일정한 비율로 정렬 할 수 있으며 , 원하는 위치로 drag&drop 할 수 있도록 구현되어 있었습니다. 


[angular-dashboard-framework]


위 2가지 오픈소스의 장점을 참고해 만들었던 E2E Monitor의 대략적인 스토리보드 중 하나는 아래와 같습니다.



[E2E Monitor  스토리보드]


이렇게 스토리 보드를 작성하고, 약 1개월 동안 개발을 하였습니다. 

E2E Monitor 2.0에는 Responsive Web, Dashboard Customizing, Widget Modularization 등의 기능을 추가로 개발하였는데요.

Dashboard Customizing에서는 편집모드에서 Dashboard 하나 하나를 이루고 잇는 그래프들을 하나의 위젯이라 생각하고 Drag&drop을 하는 기능이 필요했고, 이 와 관련된 라이브러리로 사용했던 것이 SortableJS입니다.

angular-dragdropng-sortable 같은 라이브러리도 고려 하였으나 가장 많이 사용하기도 하고, 사용하기도 쉽고, 문서도 잘 되있어 SortableJS를 사용하게 되었습니다. 


그래서 Dashboard를 Customizing할 수 있는 E2E Monitor는 다음과 같습니다. 




Demo는 http://e2edemo.embian.com/#/e2emDashboard 에서 확인 하실 수 있습니다.




[E2E-Monitor v1.0 

 [E2E-Monitor v2.0]   


추후 고려해야 할 사항 


개발 완료 후 회사 분들과 함께 논의를 한 결과 좀 더 개선 해야 할 사항과 의견들이 있었습니다. 

첫번째, Performance 측면에서 문제가 없을까?

두번째,활용의 측면에서 Widget에 대한 설명이 명확하지 않다.

세번째,Dashboard에서 한번에 여러 서비스를 관제하게 될 경우를 고려해 보자 

.

.


 이러한 사항은 추후 E2E-Monitor v3.0에서 적용해 볼 계획입니다.  


Posted by 알 수 없는 사용자
,

E2E-Monitor와 Pinpoint를 비교한 Slide자료 입니다. 비교시 사용한 Pinpoint 버전은 1.5.0 입니다.

더불어, 아래 데모 사이트에서 E2E-Monitor를 체험 해 보실 수 있습니다.

데모 사이트 바로가기 : http://e2edemo.embian.com/



참고 자료: 

https://github.com/naver/pinpoint

http://d2.naver.com/helloworld/1194202


Posted by 알 수 없는 사용자
,

"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 데모"를 방문하시면 확인하실 수 있습니다.



Posted by 알 수 없는 사용자
,

이번 글에서는 E2E-Monitor 개발에 사용했던 웹기술들에 대해서 적어 볼까합니다.

기술적인 내용 보다는 해당 기술들을 사용하기 전까지 어떤 고민들을 했고, 그 고민들을 해결하기 위해서 어떤 기술들을 살펴봤는지, 그리고 최종적으로 왜 해당 기술을 사용하기로 결정했는지 등의 도입 배경 및 사용 후 소감 등을 중점적으로 다루도록 하겠습니다.


E2E- Monitor에 사용했던 웹기술들


E2E-Monitor 중에서도 운영자가 실제로 사용하게 되는 User Client는 Web Application으로 구현되었습니다.

개발에 사용했던 기술들은 다음과 같습니다.

1. jQuery
2. AngularJS
3. RequireJS
4. Bootstrap (for AngularJS)
5. D3.js
6. Dagre-D3
7. C3
8. Big Scatter Chart



1. jQuery


jQuery는 워낙 유명한 JavaScript Framework이기 때문에 따로 설명이 필요없을 것 같습니다.

이번에는 주로 간단한 DOM 제어 기능과 애니메이션 효과등을 구현하는데 사용했습니다.

기본 Framework로 사용한 AngularJS에서도 jqLite(jQuery 호환 API)를 지원합니다만, jqLite 대신 Original jQuery를 사용하는 것이 프로젝트를 진행하는게 더 효율적이겠다고 판단했습니다. 

아무래도 필수 기능 몇가지만 지원하는 jLite 보다는 jQuery의 모든 기능을 다 쓸 수 있는 환경이 개발에는 더 도움이 될것 같았고, jQuery 기반의 UI Component들을 사용해야 되는 상황이 있을 수도 있겠다고 생각했었던 것 같습니다.


결과적으로는 역시 jQuery를 사용하기로 했던 것이 좋은 결정이었다고 생각됩니다.

지금 코드를 보면 jQuery 구문이 사용된 코드가 실제로는 그렇게 많지는 않습니다.

하지만 jQuery로 작성된 부분을 AngularJS나 다른 방식으로 처리를 해야 했다면 지금 보다 훨씬 더 복잡한 코드가 되지 않았을까 생각합니다.



2. AngularJS


이번 프로젝트를 진행하면서 처음으로 접했던 Javascript Framework 입니다.

(사실 jQuery와 D3, Bootstrap 말고는 다 처음 접한 기술들 입니다.)

고객사의  Admin Application이 AngularJS를 기반으로 만들어져 있었기 때문에, 시스템 통합을 위해서는 선택의 여지가 없었죠.

AngularJS는 MVC  또는 MVVM 을 위한 Web Application Framework 입니다.

Data와 View, 그리고 둘사이를 연결해주는 Control를 분리함으로써 Application을 모듈화하고 체계적으로 설계할 수 있도록 도와주는 Library라고 생각하시면 될것 같습니다.

AngularJS에 대한 보다 자세한 기술적인 내용은 저희 개발팀 막내가 작성한 글, "주니어의 개발자 경험기 [1편-AngularJS]"을 참고하시기 바랍니다.

다른 대부분의 IT 기술들도 그렇겠지만 AngularJS를 처음에 접했을 때는 참 쉽다는 인상을 받았는데, 역시 사용하면 할수록, 파고 들면 들수록 어려워지면서도 어느순간 폭 빠져있는 저를 발견하게 되었습니다.

익숙해지기만 한다면, 속된 말로 "떡이 되기 쉬운" Web Application Code를 어느 정도 정리하고 체계화 시킬 수 있는 좋은 Library인것 같습니다. (개발 속도 향상은 덤?)

jQuery와 더불어 Web Application 개발에 꼭 사용해야 될 Javascript Library를 꼽는 다면, 저는 앞으로 AngularJS를 선택하겠습니다.

하지만 Application의 성능이라는 측면에서 본다면, 다수의 접속자를 위한 Web Application에는 적합하지 않은 기술 일 수 있습니다. 

필요한 곳에만 부분 적용하는 것도 가능하긴 하지만, 기본적으로 AngularJS를 기반으로 개발된 Web Application들은 Javascript Engine이 HTML DOM을 실시간으로 생성하는 방식이기 때문에, Core HTML Page보다 느릴 수 밖에 없습니다.

개발 속도와 코드 관리의 효율성을 선택할 것인가, 서비스의 품질(특히 반응속도)를 선택할 것인가를 잘 분석하고 판단한 다음, AngularJS 도입에 대해 고려하는 것이 좋을 것 같습니다. 




3. RequireJS


사실 RequireJS는 프로젝트 중간에 필요에 의해서 사용했다가 마지막 통합 단계에서 RequireJS 때문에 통합이 불가능하게 되면서 다시 모두 걷어낸 Library 입니다. (전문 용어로 삽질이라고 하죠)

RequireJS는 AMD(Asynchronous module definition) 스팩을 실제로 구현한 Library입니다. 

Javascript의 범용성과 표준안을 확립하기 위한 여러 활동 중에서도 Browser 환경(Asynchronous 환경)에 집중해 표준안을 만드는 곳이 AMD라는 곳이구요. 거기에서 내놓은 표준안을 그대로 구현한 Library가 RequireJS입니다.

보다 자세한 내용을 알고 싶으신 분들은 "Javascript 표준을 위한 움직임: CommonJS와 AMD"를 읽어보시는게 좋을 것 같습니다.

프로젝트 중간에 RequireJS를 고려하게 된 이유는 Javascript 파일들의 로딩 순서에 문제가 발생했기 때문입니다.

Web Application을 개발하다 보면 수많은 Javascript 파일들이 생기게 되고 이 js 파일들은 HTML에 <script> 태그를 통해 Web Application에 추가 되게 됩니다.

Browser는 HTML 적혀 있는 순서대로 js 파일 로딩을 시작하게 됩니다.

하지만 네트워크 환경에서는 반드시 시작 순서대로 로딩이 끝난다는 보장이 없죠.

여기서 문제가 발생하게 됩니다. 필요한 js파일의 로딩이 늦어지는 경우가 불특정하게 발생하게 되고, 이런 현상은 바로 에러 상황으로 이어지게 됩니다.

결국 사용자는 잘 되다 안 되다 하는 불안한 Web Application을 접하게 되겠네요.

이런 문제를 해결하기 위해 도입했던 기술이 RequireJS였습니다.

RequireJS는 비동기 방식으로 필요한 js파일을 로딩하는 것이 가능합니다.

각각의 js 파일마다 dependency를 설정할 수 도 있습니다.

RequireJS를 사용하면 HTML문서에서 <script>태그를 이용하는 대신, 필요한 js파일을 Javascript code에서 require() 함수를 이용해 추가할 수 있습니다.

Javascript code에 집중할 수 있으며, 모듈화가 가능하게 되는 잇점을 가질 수도 있습니다.

하지만, 자칫 잘못하면 Callback의 수렁에 빠지는 수도 있으니 조심해야 합니다.

개인적인 느낌으로는 Code 가독성도 상당히 나빠지는 것 같습니다.


프로젝트 마지막에 RequireJS를 다시 모두 걷어 내야 했던, 이른바 "삽질"을 하게 된 이유는 어이 없게도 RequireJS로 인해 통합이 불가능하게 되었기 때문입니다.

RequireJS 기반 Application은 모든 코드가 RequireJS 베이스에서 작성되고 작동되어야 합니다. 그래서 RequireJS 기반이 아닌 Legacy System과는 통합이 불가능 했던 것입니다.

어쩔수 없이 RequireJS를 걷어내는 삽질을 할 수 밖에 없게 됩니다.

그래서 모든 문제가 해결이 되었을까요?

당연히 아니죠....

RequireJS를 도입해서 해결했던 문제(간헐적 에러 발생)가 다시 발생합니다.

결국 해결은 마음에 들진 않지만, 무식한 방법을 사용했습니다. Dependency 가 있는 js 파일들을 하나의 파일로 통합해 버렸습니다. ㅡㅡ;;;;

지금 생각해 보면 lazy load 같은 기법을 사용했으면 깔끔했을 것 같은데, 그 때 당시는 맨붕상태였기 때문에 일단 가능한 쉽고 빠른 방법을 찾을 수 밖에 없었습니다.

그 때 당시의 삽질이 기억나 다소 감정적인 글이 되어 버렸는데, 혹시나 저희와 비슷한 상황에서 RequireJS를 고려하시는 분들이 혹시라도 계신다면 이 글이 조금이나마 도움이 되길 바랍니다. 

 



4. Bootstrap(for AngularJS)


Bootstrap은 반응형, 모바일 웹앱을 위한 HTML, CSS, JavaScript 통합 Framework라고 소개 되고 있지만, 저는 개인적으로 HTML계의 jQuery 정도의 위치를 가지는 기술이라고 생각합니다.

jQuery의 모토인 "최소한의 Javascript code로 최대의 효과를 내기 위한 Framework (Write less, do more)"에서 "Javascript"라는 단어를 "HTML"로 바꾸면 딱 Bootstrap에 어울리는 설명이 되는 것 같거든요.

실제로 Bootstrap을 사용하면 적은 HTML 코드로 훌륭한 Web UI를 구현할 수 있습니다.

그리고, 미적 감각이 상대적으로 떨어지는 개발자라도 Bootstrap을 사용하는 것 만으로도 어느 정도 그럴듯한(?) 결과물을 얻을 수 있기 때문에, 요즘 Web Application 개발자들 사이에서는 거의 필수 요소가 되어가고 있는것 같습니다.

이번 프로젝트에서도 디자이너의 부제 및 개발 기간 단축을 위해 사용하게 되었는데, AngularJS를 기본으로 사용하는 Application에서는 Original Bootstrap를 사용할 수 없는 문제가 있었습니다.

다행히도 AngularJS용 BootStrap이 따로 있어서 그걸 사용하게 되었는데, 일반 Bootstrap의 사용법과는 약간 다른 부분들이 있기 때문에 익숙해 지는데 시간이 조금 필요했던것 같습니다.


프로젝트 마지막 통합 과정에서 RequireJS와 함께 Bootstrap도 문제가 되었습니다.

RequireJS 같은 경우는 하루 정도의 삽질로 끝이 났지만, Bootstrap 같은 경우는 해결하는데는 사흘이 넘는 시간이 걸렸던것 같습니다.

문제가 되었던 부분은 고객사가 사용하는 UI Library와 Bootstrap과의 총돌이었는데, 고객사에서는 Bootstrap 코드를 약간 수정해서 고객사 전용 UI Component를 사용하고 있었습니다.

그런데 고객사가 사용했던 Bootstrap의 버전과 저희가 사용했던 Bootstrap의 버전이 서로 달랐던것 같습니다.

저희 Bootstrap용 js 파일을 추가하면 다른 화면들이 모두 깨지고, 고객사의 Bootstrap 파일을 그대로 사용하면 우리가 만든 Application의 화면이 깨지는 문제가 발생했습니다.

버전따라 사용법이 서로 달랐던 것 같습니다.

결국 고객사의 UI용 js파일을 사용하고 저희 Application은 수정하기로 결정하고, 고객사의 bootstrap.js 소스코드를 분석하면서 깨지는 UI Component들을 하나씩 수정하는 삽질을 했습니다.

충돌나는 부분을 jQuery UI로 변경하는 것으로 해결 할 수도 있었는데, 그렇게 하면 Lock & Feel 이 안 맞을 수 있기 때문에 그 때 당시에는 선택할 수 없었습니다.

결국은 프로젝트 완료 후 코드 관리의 효율성을 위해 Bootstrap UI 중에서 충돌이 났던 Component들을 모두 jQuery UI로 변경하는 작업을 다시 한번 수행하게 됩니다.




5. D3.js


D3.js는 Data Visualization Javascript Framework입니다.

단순하게 Web에서 Graph를 그리기 위한 Library라고 생각하실 수도 있지만, 그것보다는 훨씬 강력한 기능들을 가지고 있는 Framework입니다.

가령, 전국의 현재 기온을 한눈에 볼 수 있는 Bar Chart가 있다고 생각해 봅시다. 전국의 현재 기온을 표로 보는 것보다는 Bar Chart로 보는 것이 휠씬 보기도 좋기 이해도 잘 될거라고 생각합니다.

여기서 조금만 발전 시켜 보죠. 

기존 Bar Chart에 하룻동안의 기온 변화를 애니메이션로 표현하는 기능을 추가해 보면 어떨까요?

원래는 지역과 기온, 이렇게 두가지의 정보를 가지고 있던 그래프에 시간이라는 정보를 추가하는 거죠.

Bar Chart 하단에 시간을 선택할 수 있는 스크롤바가 있고, 그 스크롤바를 마우스로 드래그 할때 마다 Bar Chart가 변하게 하면 될 것 같습니다.

전국의 기온을 한눈에 볼수 있을 뿐만 아니라 하룻동안의 기온차를 시각적으로 볼수 있는 새로운 Graph가 탄생했습니다. 

Data Visualization이라는 것은 알고 보아왔던 형태의 그래프 뿐만 아니라, 다양한 아이디어와 기술을 적용해 새로운 정보를 재생산하는 기술입니다.

그리고 D3.js는 이러한 Data Visualization을 실제로 웹에서 구현할 수 있도록 다양한 API를 제공하는 Library입니다.


이번 프로젝트에서는 사실 D3.js를 직접적으로 사용하지는 않았습니다.

D3.js를 기반으로 한 다른 Library들을 사용하기 위해서 프로젝트에 포함한 거라서, 사실 사용 소감이라고 적을만 한 것이 없네요.

그래도 개인적으로 관심있는 분야라 D3.js에 대해서는 따로 카테고리를 만들어서 연재해 볼까 생각하고 있습니다.





6. Dagre-D3


Dagre-D3는 Directed Graph(방향 그래프)를 쉽게 그릴 수 있는 Javascript Library 입니다. D3 기반으로 작성되어 있기 때문에 D3.js가 기본으로 필요합니다.

Server Map을 Directed Graph로 그려야 해서 도입한 기술입니다.

Directed Graph를 지원하는 Javascript Library가 몇가지 있었지만, 대부분 범용으로 Diagram을 그릴 수 있는 것들이었고, 저희는 Directed Graph만 그리면 되었기 때문에 Directed Graph에 특화된 Dagre-D3를 선택하게 되었습니다..

Dagre-D3를 사용함으로써, 쉽고 빠르게 일정 수준 이상의 퀄리티를 가지는 결과물을 얻을 수 있었던 것 같습니다.

Directed Graph가 프로젝트의 메인 기능이었기 때문에 전체 프로젝트에서 작업 시간도 가장 많이 할당했었고, 삽질도 가장 많이 한 기능이긴 합니다.

하지만, 여전히 고객사의 다양한 요구사항을 모두 충족시키기에는 기능이 부족했던 것도 사실입니다.

(예를 들어 그룹핑 되어 있는 노드를 펼쳤을 때 노드의 배치가 이쁘지 않다던지 하는....)


결국 요구사항을 모두 충족 시키기 위해서는 D3.js를 사용해 직접 Directed Graph를 구현할 수 밖에 없을 것 같습니다.

물론 시간과 비용이 그만큼 더 들어가겠죠.

현실적으로는 여러 Library들의 기능들을 파악 한 다음에 요구사항을 타협해서 적당한 Library를 선택해서 사용하는 것이 개발사나 고객사 모두에게 좋지 않을까 생각합니다.


Dagre-D3의 장단점을 나열 하자만 다음과 같습니다.

1. 장점

- 안정적인 Rendering 속도

- 사용법이 간단하다.

- Layout만 지정해 주면 노드들은 알아서 배치해 준다.

- 원하는 대로 수정할 수 있을 만큼 충분히 다양한 디자인 요소를 제공해 준다.

- 노드를 Group으로 묶는 것이 가능하다. ()

2. 단점

- 사용자가 마음대로 노드를 움직할 수 없다.

- 실시간으로 Layout을 바꾸는 것은 불가능하다.

- 노드를 그룹핑하고 푸는 것도 당연히 가능하지만, 풀었을 때 노드들의 배치가 엉망이다. (이쁘지 않다)

- 노드들의 위치를 고정할 수 없다. (새로운 노드가 추가되거나 기존 노드가 삭제되면 전체적인 배치가 다 바뀌어 버린다)

 

더 자세한 내용은  "주니어 개발자의 경험기 [2편 - Javascript 시각화 라이브러리]" 를 보시면 될 것 같습니다.



7. C3


D3 기반 Chart 지원 Library 입니다.

선그래프, 막대그래프,파일그래프 등 일반적인 형태의 Chart들을 그리기 위해 사용했습니다.

C3.js에 대한 내용은 "주니어 개발자의 경험기 [2편 - Javascript 시각화 라이브러리]" 를 읽어보시는게 더 좋을 것 같네요.




8. Big Scatter Chart


Scatter Chart(분산,분표도 그래프)는 API Call의 응답 시간을 한눈에 보기 위한 용도로 사용했습니다.

X축은 시간(24시간), Y축은 응답시간으로 호출 하나 마다 그래프에 점을 하나씩 찍어 그리는 그래프 입니다.

원래는 Jennifer에서 X-View라는 이름으로 동일한 기능을 지원하는 Library를 제공하고 있습니다.

Jennifer 뿐만 아니라 Scatter Chart를 지원하는 Library는 몇가지 있었는데, 그 Library들의 공통된 문제점은 HTML5의 그래픽 요소인 Canvas와 SVG중 상대적으로 느린 SVG를 사용한다는 것이었습니다.

백터 기반의 SVG는 다양한 그래픽 요소를 자유롭게 표현하기에 적합하지만, CPU 연산에 의존해 이미지를 생성하기 때문에 픽셀 기반의 Canvas 보다 느린 문제점이 있습니다.

실제로 SVG 기반의 Scatter Chart Library를 사용해 본 결과 고객사의 요구사항을 충족하긴 힘들었습니다.

(하룻동안의 데이터를 모두 출력하기 위해서는 Scatter Chart는 약 8천만건의 Dot를 한번에 찍어야 함)

그래서 구글링중 발견한 것이 Big Scatter Chart 입니다. 

찾고 보니 Pinpoint에서도 사용하고 있는(사실은 Pinpoint에서 사용할려고 만든) Library 더군요.

Canvas기반의 Library로 다양한 사용자 Interaction을 지원하지는 못하지만, 대량의 데이터를 표현하는데는 훌륭한 성능을 보였습니다.


Dagre-D3.js에 대한 기술적인 내용은 "주니어 개발자의 경험기 [2편 - Javascript 시각화 라이브러리]" 에 잘 정리되어 있습니다.


이번 프로젝트를 진행하면서 전체적으로 느꼈던 점은, 이제 정말 데이터 레이어와 프리젠테이션 레이어가 확실히 분리되어 가고 있으며, 프리젠테이션 레이어쪽 기술들이 많이 정리가 되어가고 있는 것 같다는 인상을 받았습니다.

PHP로 데이터에서부터 HTML문서까지 모두 작업하던 시대와는 참으로 많이 달라진것 같습니다.

아마 AngularJS를 통해 Javascript code 단이 깔끔하게 정리되는 것을 보면서 더 그렇게 느꼈던 것 같습니다.


항상 Javascript와 관련된 새로운 기술들을 접하면 두렵기도 하면서 한편으로는 신나기도 하는 것는 것이, 역시 저는 Javascript 오덕이었던 듯 합니다.

(그래도 Callback의 수렁은 정말 싫습니다.)


다음 글은 E2E-Monitor의 Back-end 기술들을 살펴 보도록 하겠습니다.

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



Posted by 알 수 없는 사용자
,

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

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

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

그럼 시작합니다.



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 기술들에 대한 소개를 하겠습니다.






Posted by 알 수 없는 사용자
,