2018.02.26

김진철의 How-to-Big Data | 빅데이터와 클라우드 기술 (6)

김진철 | CIO KR

CMS 온라인 데이터 수집 시스템의 모니터링 문제
흔히 모니터링하면 어떤 시스템의 상태를 관찰하고 운영하기 위해 필수적으로 만들어야 하는 기능이기도 하면서, 왠지 첨단 기술이 들어가지 않는 허드렛일이라는 생각을 많이 하게 되는 것 같다. 하지만, LCG와 같이 전 지구에 걸쳐 모니터링할 시스템이 흩어져 있어 모니터링할 시스템의 정보를 모아 수집하기가 어려운 경우, XDAQ이 운영되는 CMS 온라인 데이터 수집 시스템과 같이 그 시스템의 요구사항 수준이 높고 구성이 복잡하다. 구성하는 노드 수가 많은 시스템 같은 경우에는 시스템의 문제를 쉽게 발견하고, 해결하여 장애 없는 운영을 지원할 수 있는 효과적인 모니터링 시스템을 만드는 것 자체가 큰 기술적인 난제가 된다. 왜 그런지 한번 같이 생각해보자.

XDAQ 미들웨어가 운영되었던 CMS 온라인 데이터 수집 시스템에서의 모니터링 문제를 같이 한번 생각해보기로 하자. 이 문제는 필자가 XDAQ 개발팀에서 일할 때 해결하기 위해 노력했던 문제 중의 하나로, 운영 지원 시스템(Operation Support System; OSS)에서 운영 지능화(operation intelligence) 시스템을 구축하는 것이 왜 중요한지 생각해보는 좋은 예가 될 것으로 생각한다.

필자가 XDAQ 팀에서 일했던 당시 CMS 온라인 데이터 수집 시스템 개발에서 풀어야 했던 문제 중의 하나가 CMS 온라인 데이터 수집 시스템 응용 프로그램을 개발하는 소프트웨어 엔지니어들이 어떻게 XDAQ을 이용해서 모니터링과 상태 진단 기능을 쉽게 개발하느냐는 것이었다. 데이터베이스에 저장된 시스템 상태 정보값만을 가져다가 시간값과 함께 그래프나 차트 소프트웨어를 이용해서 그냥 그려주면 되지 않겠어라고 생각하는 독자가 있을지 모르겠지만, 그렇게 간단한 문제가 아니라는 것을 같이 생각해보자.

첫번째로, XDAQ 응용 프로그램의 모니터링 정보가 하나의 서버에 모여 있지 않는다는 것이다. 지난 열세번째 글에서 필자가 설명했듯이 XDAQ은 클라이언트-서버 구조가 아니라 P2P(peer-to-peer) 방식으로 서로 통신하는 방식의 미들웨어였다. XDAQ 응용 프로그램이 시스템의 상태값이나 모니터링하는 파라미터값을 저장할 때는 지연 문제 때문에 XDAQ 내부의 플래시리스트(flashlist)라고 하는 데이터 구조를 사용해서 메모리에 저장하면서 업데이트하게 된다. 이 플래시리스트라는 데이터 구조는 물론 플래시리스트 내의 값을 오랜 기간 보관할 필요가 있다면 데이터베이스로 저장(serialize)할 수 있는 기능도 가지고 있다.

문제는 이 플래시리스트가 한 서버에 모두 모여 있지 않다는 것이다. XDAQ 응용 프로그램이 1,000대가 넘는 CMS 온라인 데이터 수집 시스템의 모든 노드에 걸쳐 실행되고 있고, 각각의 XDAQ 응용 프로그램이 실행되고 있는 각 노드의 메모리와 데이터베이스에 노드별 XDAQ 응용 프로그램 상태 정보가 각각 저장되어 있다. CMS 온라인 시스템이 온전하게 동작하고 있는지 확인하려면 분산된 플래시리스트들의 값을 모아 적절한 가공과 분석, 계산을 통해서 CMS 온라인 데이터 수집 시스템 전체의 상태를 진단할 수 있는 정보로 바꾼 후 이를 쉽게 이해할 수 있는 형식으로 가시화하여 운영자가 관찰하고 모니터링할 수 있어야 한다.

두번째로, P2P 방식으로 통신하는 응용 프로그램들이다 보니 모니터링 정보가 수집될 응용 프로그램 인스턴스가 어느 노드에 어떤 방식으로 실행되고 있는지 찾아볼(look-up) 마스터(master) 서버가 없다는 것이다. 마스터 서버가 없기 때문에 데이터 가공, 처리, 분석에 필요한 플래시리스트나 데이터가 어느 노드에 있는지 찾고, 해당하는 플래시리스트나 파라미터값을 가지고 오거나 해당 노드에서 필요한 처리나 연산을 하여 돌려주는 역할을 담당할 마스터 응용 프로그램이나 분산 컴퓨팅 프로토콜을 디자인하여 이를 기반으로 데이터를 가공하는 분산 XDAQ 응용 프로그램을 만들어야 했다.

세번째로, 모니터링 변수의 시간에 따른 그래프나 노드에 따른 분포, 상태 등 손쉽게 모니터링 정보를 가시화할 수 있는 기능이 필요했다. 모니터링에서 가장 중요한 것 중의 하나가 시스템의 상태를 표현하는 모니터링 변수를 시간이나 노드 번호, 위치 등 여러 독립 변수에 대비하여 적절하게 가시화(visualize)해 표현하는 것이다. 이러한 모니터링 변수 가시화를 마이크로소프트 엑셀에서 몇 번의 마우스 클릭만으로 차트를 손쉽게 만들 듯이 개발자들이 만들게 하고 싶었다.

CMS 온라인 데이터 수집 시스템과 같이 노드가 1,000여 대가 넘어가는 분산 컴퓨팅 시스템이 되면, 시스템의 정보를 보여주는 모니터링 그래프나 가시화의 종류와 양도 많아지게 된다. 노드별로 수집한 데이터를 처리하는 과정도, 한 대의 노드에서 처리할 수 있는 경우도 있지만, 데이터의 양이 많아 여러 노드에서 처리해서 합치거나, 하둡 같은 분산 컴퓨팅 프레임워크를 써서 병렬 처리해야 할 수도 있다.

이뿐만이 아니라, 이미 만들어진 모니터링 그래프나 가시화 정보를 이용해 해결할 수 있는 시스템의 장애나 문제도 있지만, 시스템을 디자인, 개발할 때 미처 예측하지 못해 확인하고 해결할 수 없는 돌발적인 장애도 있을 수 있다. 이런 경우에는, 시스템 상태 변수와 파라미터를 주문형(on-demand)으로 필요에 따라 임시로(ad-hoc) 그래프를 그리거나 가시화하여 시스템 장애의 원인을 대화식으로(interactive) 분석해야 한다. 이렇게 대화식으로 시스템의 문제를 조사하고 찾아낼 수 있으려면 모니터링 그래프나 가시화를 손쉽게 만들어낼 수 있어야 한다.

마지막으로, 장애를 해결하는데 사용되었던 모니터링 그래프나 가시화, 정보 처리 방법이 장애 해결 후에 자산화되어 같은 종류의 문제를 지속해서 해결할 수 있도록 시스템에 손쉽게 통합될 수 있어야 했다. 장애를 해결하기 위해 임시로 사용했던 모니터링 변수 및 정보와 이를 처리, 분석하는 데에 사용했던 로직이 CMS 온라인 데이터 수집 시스템의 정식 모니터링 기능이 되어서 모니터링 시스템에 손쉽게 통합이 될 수 있어야 같은 종류의 장애가 반복되는 것을 막을 수 있었기 때문이다.

위와 같이 CMS 온라인 데이터 수집 시스템 자체를 운영하는 문제도 복잡한 빅데이터 문제가 된다. 그렇기 때문에 CMS 온라인 시스템의 OSS도 빅데이터 처리 시스템이 되어야 했다. 그뿐만 아니라, CMS 온라인 데이터 수집 시스템에서 어느 한 노드라도 데이터를 잘못 처리하거나 지연이 길어져 데이터가 유실되면 그 데이터 셋은 분석에 쓸 수 없게 되므로, 시스템 전체가 통합된 상태를 유지하고 있는지, 문제가 있다면 어느 노드와 응용 프로그램에서 문제가 있는지 신속, 정확하게 파악할 수 있어야 했다.

위와 같은 운영 빅데이터 문제를 풀기 위해 필자와 XDAQ 코어 개발팀에서는 엑스큐브(XCube)라는 XDAQ 컴포넌트를 만들게 되었다. 엑스큐브는 모니터링 및 운영 데이터를 OLAP(On-Line Analytical Processing) 큐브(Cube)형태로 변환, 저장하고, 이 OLAP 규브 형태로 저장된 데이터를 이용해 데이터를 가시화하고 분석하는 XDAQ 컴포넌트다.

비즈니스 인텔리전스(Business Intelligence) 업무와 소프트웨어 경험이 많은 분들이라면 OLAP이 무엇인지는 잘 알고 있을 것이다. OLAP은 마이크로소프트 엑셀을 다차원 데이터 구조로 확장한 개념으로, 엑셀에서 하는 테이블 단위의 데이터 분석을 좀더 일반적으로 확장한 것으로 보면 된다. OLAP의 기본이 되는 다차원 데이터 구조인 큐브를 이용해 수집된 데이터를 다양한 차원(dimension)에서 연관된 형식으로 손쉽게 분석할 수 있다. 무엇보다도 마이크로소프트 엑셀에 있는 차트마법사와 같이 모니터링 그래프나 가시화를 손쉽게 만들어보자는 엑스큐브의 원래 개념에도 잘 맞는 데이터 구조다.



엑스큐브는 XDAQ의 모니터(Monitor)라는 응용 프로그램에 플래시리스트라는 데이터구조로 저장된 데이터들을 주기적으로 큐브로 변환하여 다차원 데이터로 만든다. XDAQ의 모니터 응용 프로그램은 CMS 온라인 데이터 수집 시스템각 노드에서 실행되면서 노드별 XDAQ 응용 프로그램과 시스템 상태 파라미터를 수집하여 플래시리스트 형태로 만들어 메모리나 데이터베이스에 저장한다. 엑스큐브에서 큐브를 만들 때는 연산 속도 때문에 관계형 OLAP(Relational OLAP; ROLAP)이 아닌 인메모리 OLAP(Memory OLAP; MOLAP)을 사용하였다.

큐브 형태로 저장된 시스템 운영 데이터들은 노드마다 존재하거나, CMS 온라인 데이터 수집 시스템 서버 팜 내부의 특정한 기능을 담당하는 클러스터 단위의 데이터를 수집해서 저장하는 수집기라는 노드에 모여 있는 형태로 존재하게 된다. 이렇게 수집기나 각 노드에 분산되어 저장된 큐브들에 사용자는 자신이 필요한 데이터나 데이터 가공 과정과 요청 사항을 기술한 질의를 특정 수집기 내의 엑스큐브 서비스 인스턴스를 통해 요청하게 된다. 요청을 받은 엑스큐브 서비스 인스턴스는 XDAQ 노드 곳곳에 있는 엑스큐브 서비스 인스턴스에 전달하여 필요한 데이터를 모아 받아 가공한 후, 사용자의 질의에 대한 결과를 역시 큐브 형태로 사용자가 질의를 요청한 수집기나 노드에 저장하게 되고, 큐브가 생성되었다는 알람(alarm)을 사용자에게 보내게 된다. [2018. 2. 14. 06:40]

자신이 요청한 데이터가 큐브 형태로 수집되었다는 알람을 받으면 사용자는 이 큐브에서 관찰하고 싶은 차원(dimension)과 측정값(measure)을 선택해 모니터링 가시화로 표현하게 된다. 이렇게 큐브 형태로 저장된 시스템 모니터링 데이터를 그래프나 가시화할 수 있게 해주는 XDAQ 응용 프로그램을 필자와 XDAQ 개발 동료들은 엑스그래프메이커(XGraphMaker)라고 불렀다. 이렇게 해서 엑스그래프메이커 XDAQ 응용 프로그램을 통해 생성된 모니터링 그래프나 가시화를 이용해 XDAQ 노드와 서브시스템의 모니터링을 대화식으로 하는 것이 가능해졌다.



엑스큐브와 엑스그래프메이커가 만들어지기 전에는 시스템 모니터링 항목을 일일이 C++이나 자바를 이용해 하나하나 개발하여 XDAQ 모듈로 일일이 빌드(build)하고 응용 프로그램 서비스 인스턴스로 만들어주어야 모니터링을 할 수 있었다. 이때문에, 새로운 모니터링 기능 개발에 시간이 걸리고 장애가 생겼을 때나 새로운 모니터링 수요가 생겼을 때 신속하게 대응하기 어려웠다. 하지만, 엑스큐브와 엑스그래프메이커를 이용하면 모니터링하는 운영자는 자신이 보고 싶은 시스템 운영 데이터를 마이크로소프트 엑셀과 비슷한 사용자 인터페이스를 통해 보면서 필요에 따라 선택하고, 차트 마법사와 유사한 방식으로 시스템 모니터링 그래프와 가시화 사용자 인터페이스를 만들 수 있게 됐다. 그에 따라 모니터링 기능을 손쉽게 추가하거나 대화식으로(interactive) 운영자의 직관에 따른(ad hoc) 시스템 장애 해결도 가능해졌다.

엑스큐브와 엑스그래프메이커에서는 이렇게 운영자가 시스템 장애나 문제 해결을 위해 만든 운영 데이터 큐브와 모니터링 그래프 셋을 재활용할 수 있도록 파일 형태로 저장했다가 XDAQ 서비스 인스턴스와 함께 엑스큐브와 엑스그래프메이커가 함께 실행될 때 기본 모니터링 기능으로 실행할 수 있다. 이 운영 데이터 큐브와 이를 가시화하는 모니터링 그래프 셋을 일컬어 모니터링 케이스(monitoring case)라고 불렀다(그림 5 참고). 이 모니터링 케이스에는 운영자가 데이터 분석을 위해 사용한 데이터 큐브를 외부 데이터베이스와 XDAQ의 모니터 응용 프로그램의 플래시리스트에서 어떻게 가져오는 정의하는 데이터 수집 로직과, 이 수집된 데이터를 가지고 문제 해결을 위한 OLAP 분석을 어떻게 수행하는지에 대한 로직, 그리고 OLAP 분석을 통해 얻은 모니터링 그래프와 가시화에 대한 구성 정보를 포함하고 있다.



모니터링 케이스를 통해 운영자가 문제 해결을 위해 사용했던 데이터 소스 및 데이터 큐브, OLAP 데이터 분석, 그리고 모니터링 그래프와 가시화 내용을 재활용하고 자산화할 수 있고, 별도의 모니터링 모듈 개발을 위한 시간과 노력을 들일 필요 없이 이렇게 자산화된 모니터링 케이스를 바로 새로운 모니터링 기능으로 사용할 수 있었다. 이렇게 운영자들이 만들어낸 운영 데이터 분석 내용과 모니터링 가시화 내용을 바로 시스템 모듈화할 수 있는 기능 때문에, 엑스큐브와 엑스그래프메이커를 이용한 시스템 운영 프로세스를 통해 XDAQ으로 개발한 시스템의 신뢰성과 문제 해결 역량이 반복적으로 높아지게 되어 운영의 안정성이 점진적으로 개선될 수 있다(그림 5 참고).
 


엑스큐브와 엑스그래프메이커의 아이디어와 프로토타입은 처음 시연을 했을 때 많은 XDAQ 개발자들에게 좋은 평을 받았다. 기술적으로 어렵고 의미 있는 일은 아니었으나 시스템 운영을 위해 꼭 만들어야 했고, 시간과 노력이 많이 필요했던 모니터링 시스템 개발 시간과 주기를 단축할 수 있었으며, 새로운 모니터링 수요에 유연하게 대응할 수 있었기 때문이다. 그러나, 당시 CMS 온라인 시스템의 요구 사항에 맞는 인메모리OLAP(MOLAP) 소프트웨어가 없었고, 직접 MOLAP 소프트웨어를 만들기에는 규모가 큰 프로젝트였기 때문에 XDAQ의 공식 컴포넌트로 채택이 되지 않고 관계형 OLAP을 이용한 비실시간 모니터링을 위한 아이디어로 바뀌어 다시 만들어졌다. 당시 MOLAP 기술이 충분히 성숙하지 않아서 실현되지 못한 아쉬운 아이디어였다.


 

 


2018.02.26

김진철의 How-to-Big Data | 빅데이터와 클라우드 기술 (6)

김진철 | CIO KR

CMS 온라인 데이터 수집 시스템의 모니터링 문제
흔히 모니터링하면 어떤 시스템의 상태를 관찰하고 운영하기 위해 필수적으로 만들어야 하는 기능이기도 하면서, 왠지 첨단 기술이 들어가지 않는 허드렛일이라는 생각을 많이 하게 되는 것 같다. 하지만, LCG와 같이 전 지구에 걸쳐 모니터링할 시스템이 흩어져 있어 모니터링할 시스템의 정보를 모아 수집하기가 어려운 경우, XDAQ이 운영되는 CMS 온라인 데이터 수집 시스템과 같이 그 시스템의 요구사항 수준이 높고 구성이 복잡하다. 구성하는 노드 수가 많은 시스템 같은 경우에는 시스템의 문제를 쉽게 발견하고, 해결하여 장애 없는 운영을 지원할 수 있는 효과적인 모니터링 시스템을 만드는 것 자체가 큰 기술적인 난제가 된다. 왜 그런지 한번 같이 생각해보자.

XDAQ 미들웨어가 운영되었던 CMS 온라인 데이터 수집 시스템에서의 모니터링 문제를 같이 한번 생각해보기로 하자. 이 문제는 필자가 XDAQ 개발팀에서 일할 때 해결하기 위해 노력했던 문제 중의 하나로, 운영 지원 시스템(Operation Support System; OSS)에서 운영 지능화(operation intelligence) 시스템을 구축하는 것이 왜 중요한지 생각해보는 좋은 예가 될 것으로 생각한다.

필자가 XDAQ 팀에서 일했던 당시 CMS 온라인 데이터 수집 시스템 개발에서 풀어야 했던 문제 중의 하나가 CMS 온라인 데이터 수집 시스템 응용 프로그램을 개발하는 소프트웨어 엔지니어들이 어떻게 XDAQ을 이용해서 모니터링과 상태 진단 기능을 쉽게 개발하느냐는 것이었다. 데이터베이스에 저장된 시스템 상태 정보값만을 가져다가 시간값과 함께 그래프나 차트 소프트웨어를 이용해서 그냥 그려주면 되지 않겠어라고 생각하는 독자가 있을지 모르겠지만, 그렇게 간단한 문제가 아니라는 것을 같이 생각해보자.

첫번째로, XDAQ 응용 프로그램의 모니터링 정보가 하나의 서버에 모여 있지 않는다는 것이다. 지난 열세번째 글에서 필자가 설명했듯이 XDAQ은 클라이언트-서버 구조가 아니라 P2P(peer-to-peer) 방식으로 서로 통신하는 방식의 미들웨어였다. XDAQ 응용 프로그램이 시스템의 상태값이나 모니터링하는 파라미터값을 저장할 때는 지연 문제 때문에 XDAQ 내부의 플래시리스트(flashlist)라고 하는 데이터 구조를 사용해서 메모리에 저장하면서 업데이트하게 된다. 이 플래시리스트라는 데이터 구조는 물론 플래시리스트 내의 값을 오랜 기간 보관할 필요가 있다면 데이터베이스로 저장(serialize)할 수 있는 기능도 가지고 있다.

문제는 이 플래시리스트가 한 서버에 모두 모여 있지 않다는 것이다. XDAQ 응용 프로그램이 1,000대가 넘는 CMS 온라인 데이터 수집 시스템의 모든 노드에 걸쳐 실행되고 있고, 각각의 XDAQ 응용 프로그램이 실행되고 있는 각 노드의 메모리와 데이터베이스에 노드별 XDAQ 응용 프로그램 상태 정보가 각각 저장되어 있다. CMS 온라인 시스템이 온전하게 동작하고 있는지 확인하려면 분산된 플래시리스트들의 값을 모아 적절한 가공과 분석, 계산을 통해서 CMS 온라인 데이터 수집 시스템 전체의 상태를 진단할 수 있는 정보로 바꾼 후 이를 쉽게 이해할 수 있는 형식으로 가시화하여 운영자가 관찰하고 모니터링할 수 있어야 한다.

두번째로, P2P 방식으로 통신하는 응용 프로그램들이다 보니 모니터링 정보가 수집될 응용 프로그램 인스턴스가 어느 노드에 어떤 방식으로 실행되고 있는지 찾아볼(look-up) 마스터(master) 서버가 없다는 것이다. 마스터 서버가 없기 때문에 데이터 가공, 처리, 분석에 필요한 플래시리스트나 데이터가 어느 노드에 있는지 찾고, 해당하는 플래시리스트나 파라미터값을 가지고 오거나 해당 노드에서 필요한 처리나 연산을 하여 돌려주는 역할을 담당할 마스터 응용 프로그램이나 분산 컴퓨팅 프로토콜을 디자인하여 이를 기반으로 데이터를 가공하는 분산 XDAQ 응용 프로그램을 만들어야 했다.

세번째로, 모니터링 변수의 시간에 따른 그래프나 노드에 따른 분포, 상태 등 손쉽게 모니터링 정보를 가시화할 수 있는 기능이 필요했다. 모니터링에서 가장 중요한 것 중의 하나가 시스템의 상태를 표현하는 모니터링 변수를 시간이나 노드 번호, 위치 등 여러 독립 변수에 대비하여 적절하게 가시화(visualize)해 표현하는 것이다. 이러한 모니터링 변수 가시화를 마이크로소프트 엑셀에서 몇 번의 마우스 클릭만으로 차트를 손쉽게 만들 듯이 개발자들이 만들게 하고 싶었다.

CMS 온라인 데이터 수집 시스템과 같이 노드가 1,000여 대가 넘어가는 분산 컴퓨팅 시스템이 되면, 시스템의 정보를 보여주는 모니터링 그래프나 가시화의 종류와 양도 많아지게 된다. 노드별로 수집한 데이터를 처리하는 과정도, 한 대의 노드에서 처리할 수 있는 경우도 있지만, 데이터의 양이 많아 여러 노드에서 처리해서 합치거나, 하둡 같은 분산 컴퓨팅 프레임워크를 써서 병렬 처리해야 할 수도 있다.

이뿐만이 아니라, 이미 만들어진 모니터링 그래프나 가시화 정보를 이용해 해결할 수 있는 시스템의 장애나 문제도 있지만, 시스템을 디자인, 개발할 때 미처 예측하지 못해 확인하고 해결할 수 없는 돌발적인 장애도 있을 수 있다. 이런 경우에는, 시스템 상태 변수와 파라미터를 주문형(on-demand)으로 필요에 따라 임시로(ad-hoc) 그래프를 그리거나 가시화하여 시스템 장애의 원인을 대화식으로(interactive) 분석해야 한다. 이렇게 대화식으로 시스템의 문제를 조사하고 찾아낼 수 있으려면 모니터링 그래프나 가시화를 손쉽게 만들어낼 수 있어야 한다.

마지막으로, 장애를 해결하는데 사용되었던 모니터링 그래프나 가시화, 정보 처리 방법이 장애 해결 후에 자산화되어 같은 종류의 문제를 지속해서 해결할 수 있도록 시스템에 손쉽게 통합될 수 있어야 했다. 장애를 해결하기 위해 임시로 사용했던 모니터링 변수 및 정보와 이를 처리, 분석하는 데에 사용했던 로직이 CMS 온라인 데이터 수집 시스템의 정식 모니터링 기능이 되어서 모니터링 시스템에 손쉽게 통합이 될 수 있어야 같은 종류의 장애가 반복되는 것을 막을 수 있었기 때문이다.

위와 같이 CMS 온라인 데이터 수집 시스템 자체를 운영하는 문제도 복잡한 빅데이터 문제가 된다. 그렇기 때문에 CMS 온라인 시스템의 OSS도 빅데이터 처리 시스템이 되어야 했다. 그뿐만 아니라, CMS 온라인 데이터 수집 시스템에서 어느 한 노드라도 데이터를 잘못 처리하거나 지연이 길어져 데이터가 유실되면 그 데이터 셋은 분석에 쓸 수 없게 되므로, 시스템 전체가 통합된 상태를 유지하고 있는지, 문제가 있다면 어느 노드와 응용 프로그램에서 문제가 있는지 신속, 정확하게 파악할 수 있어야 했다.

위와 같은 운영 빅데이터 문제를 풀기 위해 필자와 XDAQ 코어 개발팀에서는 엑스큐브(XCube)라는 XDAQ 컴포넌트를 만들게 되었다. 엑스큐브는 모니터링 및 운영 데이터를 OLAP(On-Line Analytical Processing) 큐브(Cube)형태로 변환, 저장하고, 이 OLAP 규브 형태로 저장된 데이터를 이용해 데이터를 가시화하고 분석하는 XDAQ 컴포넌트다.

비즈니스 인텔리전스(Business Intelligence) 업무와 소프트웨어 경험이 많은 분들이라면 OLAP이 무엇인지는 잘 알고 있을 것이다. OLAP은 마이크로소프트 엑셀을 다차원 데이터 구조로 확장한 개념으로, 엑셀에서 하는 테이블 단위의 데이터 분석을 좀더 일반적으로 확장한 것으로 보면 된다. OLAP의 기본이 되는 다차원 데이터 구조인 큐브를 이용해 수집된 데이터를 다양한 차원(dimension)에서 연관된 형식으로 손쉽게 분석할 수 있다. 무엇보다도 마이크로소프트 엑셀에 있는 차트마법사와 같이 모니터링 그래프나 가시화를 손쉽게 만들어보자는 엑스큐브의 원래 개념에도 잘 맞는 데이터 구조다.



엑스큐브는 XDAQ의 모니터(Monitor)라는 응용 프로그램에 플래시리스트라는 데이터구조로 저장된 데이터들을 주기적으로 큐브로 변환하여 다차원 데이터로 만든다. XDAQ의 모니터 응용 프로그램은 CMS 온라인 데이터 수집 시스템각 노드에서 실행되면서 노드별 XDAQ 응용 프로그램과 시스템 상태 파라미터를 수집하여 플래시리스트 형태로 만들어 메모리나 데이터베이스에 저장한다. 엑스큐브에서 큐브를 만들 때는 연산 속도 때문에 관계형 OLAP(Relational OLAP; ROLAP)이 아닌 인메모리 OLAP(Memory OLAP; MOLAP)을 사용하였다.

큐브 형태로 저장된 시스템 운영 데이터들은 노드마다 존재하거나, CMS 온라인 데이터 수집 시스템 서버 팜 내부의 특정한 기능을 담당하는 클러스터 단위의 데이터를 수집해서 저장하는 수집기라는 노드에 모여 있는 형태로 존재하게 된다. 이렇게 수집기나 각 노드에 분산되어 저장된 큐브들에 사용자는 자신이 필요한 데이터나 데이터 가공 과정과 요청 사항을 기술한 질의를 특정 수집기 내의 엑스큐브 서비스 인스턴스를 통해 요청하게 된다. 요청을 받은 엑스큐브 서비스 인스턴스는 XDAQ 노드 곳곳에 있는 엑스큐브 서비스 인스턴스에 전달하여 필요한 데이터를 모아 받아 가공한 후, 사용자의 질의에 대한 결과를 역시 큐브 형태로 사용자가 질의를 요청한 수집기나 노드에 저장하게 되고, 큐브가 생성되었다는 알람(alarm)을 사용자에게 보내게 된다. [2018. 2. 14. 06:40]

자신이 요청한 데이터가 큐브 형태로 수집되었다는 알람을 받으면 사용자는 이 큐브에서 관찰하고 싶은 차원(dimension)과 측정값(measure)을 선택해 모니터링 가시화로 표현하게 된다. 이렇게 큐브 형태로 저장된 시스템 모니터링 데이터를 그래프나 가시화할 수 있게 해주는 XDAQ 응용 프로그램을 필자와 XDAQ 개발 동료들은 엑스그래프메이커(XGraphMaker)라고 불렀다. 이렇게 해서 엑스그래프메이커 XDAQ 응용 프로그램을 통해 생성된 모니터링 그래프나 가시화를 이용해 XDAQ 노드와 서브시스템의 모니터링을 대화식으로 하는 것이 가능해졌다.



엑스큐브와 엑스그래프메이커가 만들어지기 전에는 시스템 모니터링 항목을 일일이 C++이나 자바를 이용해 하나하나 개발하여 XDAQ 모듈로 일일이 빌드(build)하고 응용 프로그램 서비스 인스턴스로 만들어주어야 모니터링을 할 수 있었다. 이때문에, 새로운 모니터링 기능 개발에 시간이 걸리고 장애가 생겼을 때나 새로운 모니터링 수요가 생겼을 때 신속하게 대응하기 어려웠다. 하지만, 엑스큐브와 엑스그래프메이커를 이용하면 모니터링하는 운영자는 자신이 보고 싶은 시스템 운영 데이터를 마이크로소프트 엑셀과 비슷한 사용자 인터페이스를 통해 보면서 필요에 따라 선택하고, 차트 마법사와 유사한 방식으로 시스템 모니터링 그래프와 가시화 사용자 인터페이스를 만들 수 있게 됐다. 그에 따라 모니터링 기능을 손쉽게 추가하거나 대화식으로(interactive) 운영자의 직관에 따른(ad hoc) 시스템 장애 해결도 가능해졌다.

엑스큐브와 엑스그래프메이커에서는 이렇게 운영자가 시스템 장애나 문제 해결을 위해 만든 운영 데이터 큐브와 모니터링 그래프 셋을 재활용할 수 있도록 파일 형태로 저장했다가 XDAQ 서비스 인스턴스와 함께 엑스큐브와 엑스그래프메이커가 함께 실행될 때 기본 모니터링 기능으로 실행할 수 있다. 이 운영 데이터 큐브와 이를 가시화하는 모니터링 그래프 셋을 일컬어 모니터링 케이스(monitoring case)라고 불렀다(그림 5 참고). 이 모니터링 케이스에는 운영자가 데이터 분석을 위해 사용한 데이터 큐브를 외부 데이터베이스와 XDAQ의 모니터 응용 프로그램의 플래시리스트에서 어떻게 가져오는 정의하는 데이터 수집 로직과, 이 수집된 데이터를 가지고 문제 해결을 위한 OLAP 분석을 어떻게 수행하는지에 대한 로직, 그리고 OLAP 분석을 통해 얻은 모니터링 그래프와 가시화에 대한 구성 정보를 포함하고 있다.



모니터링 케이스를 통해 운영자가 문제 해결을 위해 사용했던 데이터 소스 및 데이터 큐브, OLAP 데이터 분석, 그리고 모니터링 그래프와 가시화 내용을 재활용하고 자산화할 수 있고, 별도의 모니터링 모듈 개발을 위한 시간과 노력을 들일 필요 없이 이렇게 자산화된 모니터링 케이스를 바로 새로운 모니터링 기능으로 사용할 수 있었다. 이렇게 운영자들이 만들어낸 운영 데이터 분석 내용과 모니터링 가시화 내용을 바로 시스템 모듈화할 수 있는 기능 때문에, 엑스큐브와 엑스그래프메이커를 이용한 시스템 운영 프로세스를 통해 XDAQ으로 개발한 시스템의 신뢰성과 문제 해결 역량이 반복적으로 높아지게 되어 운영의 안정성이 점진적으로 개선될 수 있다(그림 5 참고).
 


엑스큐브와 엑스그래프메이커의 아이디어와 프로토타입은 처음 시연을 했을 때 많은 XDAQ 개발자들에게 좋은 평을 받았다. 기술적으로 어렵고 의미 있는 일은 아니었으나 시스템 운영을 위해 꼭 만들어야 했고, 시간과 노력이 많이 필요했던 모니터링 시스템 개발 시간과 주기를 단축할 수 있었으며, 새로운 모니터링 수요에 유연하게 대응할 수 있었기 때문이다. 그러나, 당시 CMS 온라인 시스템의 요구 사항에 맞는 인메모리OLAP(MOLAP) 소프트웨어가 없었고, 직접 MOLAP 소프트웨어를 만들기에는 규모가 큰 프로젝트였기 때문에 XDAQ의 공식 컴포넌트로 채택이 되지 않고 관계형 OLAP을 이용한 비실시간 모니터링을 위한 아이디어로 바뀌어 다시 만들어졌다. 당시 MOLAP 기술이 충분히 성숙하지 않아서 실현되지 못한 아쉬운 아이디어였다.


 

 


X