CMS 온라인 데이터 수집 시스템의 모니터링 문제 흔히 모니터링하면 어떤 시스템의 상태를 관찰하고 운영하기 위해 필수적으로 만들어야 하
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 기술이 충분히 성숙하지 않아서 실현되지 못한 아쉬운 아이디어였다.
빅데이터 시스템 운영의 복잡성을 어떻게 해결할 것인가? – 운영 지능화
빅데이터 비즈니스 시스템은 기본적으로 분산 시스템이기 때문에 아무리 작은 규모로 구축하더라도 일반 비즈니스 애플리케이션보다 복잡할 수밖에 없다. 최근 비즈니스 애플리케이션들은 n-tier 아키텍처에 기반을 둔 웹 응용 프로그램들이 많고 이들도 분산 컴퓨팅 시스템들이지만, 꽤 오랜 기간 아키텍처가 어느 정도 체계적으로 발전되어 왔고, 이를 위한 표준이나 미들웨어 기술들도 많이 개발되어 발전해왔다. 그렇지만, 빅데이터 처리를 위한 요구사항이 일반 비즈니스 애플리케이션용 분산 컴퓨팅 시스템보다 다양하고 성능 요구사항이 까다로워 디자인과 구성에서 더 복잡하고 구축이 더 어려운 경우가 많다.
빅데이터 비즈니스를 기민하게 지원할 수 있도록 빅데이터 정보 시스템을 만드는 것인데, 이 빅데이터 시스템의 요구 사항 복잡도가 높기 때문에 빅데이터 시스템을 운영하는 문제도 어려운 문제가 된다. 특히 빅데이터 시스템의 운영 상태에 대한 정보들도 빅데이터가 되는데, 이때문에 빅데이터 시스템을 중단없이 모니터링하고 운영하는 문제도 빅데이터 문제가 된다.
예를 들어 시스템 로그 데이터만 하더라도, 한 노드에 16개의 가상 머신이 운영되는 10,000대의 물리 노드에서 하루에 생성하는 로그 데이터는 1.7TB이고, 1년이 되면 620TB에 이른다. 빅데이터 시스템 운영을 위해서는 시스템 로그 데이터뿐만이 아니라, 시간에 따른 하드웨어 시스템 상태 값, 시간에 따른 자바 가상 머신, 아파치 웹 서버(Apache Web Server), 하둡 등의 빅데이터 분산 시스템 통합을 위해 사용하는 미들웨어와 분산 컴퓨팅 소프트웨어들의 성능 지표 수치 등도 수집하여야 하므로, 빅데이터 인프라의 운영을 자동화, 지능화하는 데 필요한 운영 정보 데이터가 빅데이터가 된다는 것은 간단한 계산만으로도 확인할 수 있다.
규모 있는 빅데이터 시스템을 모니터링하고 장애없이 운영하기 위해서는 운영자들이 단순히 시스템 상태를 모니터링하면서 장애만 해결해서 될 일이 아니라, 시스템 전반의 상태를 일관성 있게 관리하고 많은 노드에 걸친 관리 작업을 자동화, 지능화하여 빅데이터 시스템이 최대한 자율적(autonomous)이고 효율적으로 운영될 수 있도록 체계를 갖추어야 한다.
이렇게 빅데이터 시스템을 비롯한 정보 시스템의 운영을 데이터를 기반으로 자동화, 지능화하하려면, 첫째 빅데이터 시스템의 테크니컬 아키텍처(technical architecture)를 고려하여 시스템 성능 저하와 장애에 취약한 요인들을 먼저 정의하여야 한다. 이것은 필자가 강조했던 빅데이터 비즈니스와 시스템의 구축 목적을 분명히 하라는 조언과 같은 맥락의 말이다. 빅데이터 시스템 운영을 위해 눈여겨보아야 할 운영 변수들을 미리 생각하지 않는다면 운영 빅데이터 처리와 운영 지능화를 위한 시스템을 어떻게 구축해야 할지 구체적으로 생각할 수 없을 것이다.
둘째, 위와 같이 시스템 성능 저하와 장애에 취약한 주요 요인들에 대한 사전 정의를 바탕으로 어떤 운영 데이터를 먼저 수집할 것인지를 생각해야 한다. 운영 지능화 시스템을 구성하기 위해 어떤 데이터 소스가 있고, 각 데이터 소스의 데이터 표현 형식이 비정형 데이터인지, 정형 데이터인지 고려하여 데이터 처리에 적합한 형식과 가공 과정을 설계하는 것이다. 이 또한 필자가 이전의 다섯번째, 여섯번째 글에서 설명한 바와 같이 데이터 수집 과정과 표현 형식을 잘 설계하라는 것과 같은 맥락이다.
셋째, 빅데이터 시스템에서도 데브옵스 체계를 잘 갖추어야 한다. 데브옵스 체계가 잘 갖추어져야 빅데이터의 양이 늘어나거나 처리 속도가 빨라져 빅데이터 시스템을 확장해야 할 경우에도 쉽게 대처할 수 있는 지능적인 시스템을 만들 수 있는 기반을 갖추게 된다. 사람의 수작업이 최소화되도록 운영 지능화 시스템이 수집된 운영 데이터를 바탕으로 지능화된 운영 의사 결정을 내리고 이 판단에 따라 자동으로 시스템 운영이 되도록 운영 지능화 시스템을 통해 빅데이터 시스템에 피드백을 주기 위해서는 기본적으로 빅데이터 시스템 운영 전반이 프로그래머블(programmable)하도록 유연하게 구축이 되어 있어야 하는데, 이렇게 해주는 것이 바로 데브옵스 체계다.
클라우드 컴퓨팅이나 일반 분산 컴퓨팅 시스템과 달리 빅데이터 시스템의 데브옵스 체계에서는 한 가지 더 중요하게 갖추어야 할 것이 있는데, 바로 데이터 품질 모니터링(Data Quality Monitoring; DQM)과 관리를 위한 데브옵스 체계다. 데이터의 품질이란 결국 원시 데이터에서 비즈니스에 필요한 정보만을 얼마나 효과적으로 정확하게 추출했느냐로 볼 수 있다. 만약 필요한 정보 외에 비즈니스에 도움이 되지 않는 노이즈 데이터가 많다면 이런 노이즈 데이터를 다시 재처리하느라 비즈니스의 신속성과 기민함이 떨어질 수밖에 없다.
현재는 데이터 품질을 일정 수준으로 유지하도록 빅데이터 시스템이 빅데이터 처리를 지능적으로 자동화하려면 데이터 엔지니어가 데이터의 품질을 모니터링하면서 빅데이터 시스템의 데이터 처리 자동화 로직을 점진적으로 개선해 나가는 방법이 최선이다. 사람과 같은 데이터 맥락 해석과 품질 검토가 가능한 인공지능 기술이 아직 개발되지 않았기 때문에 현재로서는 빅데이터 시스템 구축 초기에 이와 같은 시행착오는 어쩔 수 없이 겪을 수밖에 없다. 데이터의 맥락을 이해하고 품질을 평가할 수 있는 인공지능 기술이 발전하면 데이터 품질 관리 방법도 점차 더 발전할 것으로 보인다.
넷째, 운영 빅데이터 분석과 가시화를 위한 표준 플랫폼이 정의되어야 한다. 앞에서 소개한 엑스큐브의 사례에서는 필자가 만든 엑스큐브와 엑스그래프메이커, 그리고 엑스큐브가 기반을 둔 MOLAP 엔진이었던 PALO(https://sourceforge.net/projects/palo/)가 표준 플랫폼이었다. 운영 빅데이터 분석과 가시화를 위한 표준 플랫폼이 정의되어야 이를 위한 데이터 표현을 구체적으로 정의할 수 있고, 운영 빅데이터 분석 과정과 결과가 이 표준 플랫폼을 통해 만들어진 소프트웨어 소스 코드와 모듈들을 통해 자연스럽게 자산화될 수 있기 때문이다.
운영 빅데이터 분석과 가시화를 위한 표준 플랫폼으로는 일반적으로 사용되는 파이썬 기반의 분석 플랫폼인 넘파이(Numpy), 싸이파이(SciPy)나 R, 그리고 CERN 빅데이터 분석에 사용된 ROOT(https://root.cern.ch/)와 같은 플랫폼을 사용하면 된다. 다만 고려할 것은 운영 데이터 소스에 쉽게 접근할 수 있는 플러그인 형식의 모듈이 지원되는지와 운영 빅데이터 분석을 위한 하둡, 스파크 등의 빅데이터 처리 프레임워크와의 연동이 쉬운지 꼭 확인해야 한다. 넘파이, 싸이파이는 파이둡(Pydoop), 파이스파크(PySpark) 등의 하둡과 스파크 연동을 위한 라이브러리가 있고, ROOT의 경우에는 병렬 처리를 위한 PROOF라는 프레임워크와 연동할 수 있는 모듈을 가지고 있다. (ROOT에서 병렬 처리를 위해 사용하는 PROOF에 대해서는 이후에 기고할 글에서 좀더 자세하게 소개하기로 한다.)
다섯째, 장애나 시스템 운영 문제를 해결한 운영 빅데이터 분석과 모니터링 그래프, 가시화 결과 등의 소프트웨어 자산이 운영 문제 해결에 만들어져 사용되고 난 후에 운영 지능화 시스템의 모듈로서 다시 통합되어 실 운영에서 동일한 문제를 진단, 검출하고 예방하는데 사용될 수 있어야 한다. 이를 위해 장애나 시스템 운영 문제를 해결한 운영 빅데이터 분석과 모니터링 그래프, 가시화 결과 등의 소프트웨어 자산은 빅데이터 시스템 운영을 자동화하는 모듈로서 완성되어 운영 지능화 시스템에 최종 통합되어야 한다.
이 연재의 일곱번째 글에서 빅데이터 비즈니스에서 인공지능 기술을 활용할 때 분석보다는 자동화에 초점을 맞추는 것이 좋다고 조언한 바 있다. 빅데이터 비즈니스를 위한 비즈니스 지원 시스템(BSS)이나 OSS에서 빅데이터를 통해 분석한 결과물은 반드시 비즈니스 프로세스 자동화나 운영 프로세스 자동화를 위한 소프트웨어 모듈로서 완성되어 결국 빅데이터 시스템의 자동화율을 높이고 빅데이터 비즈니스의 지능화와 기민성(agility)을 높이는 데 쓰여야 한다.
빅데이터 시스템의 궁극적인 목적은 빅데이터 비즈니스를 지원하여 비즈니스의 가치를 높이고 기업의 수익을 높이는 것이다. 빅데이터 시스템이 빅데이터 비즈니스를 효과적으로 지원한다는 것은 빅데이터를 다룸으로써 인해 생기는 다양한 문제들을 해결하여 빅데이터 비즈니스가 원활하게 수행되도록 지원하는 것이다. 빅데이터 비즈니스 시스템의 문제 해결 과정과 그 산출물이 소프트웨어화가 되어 빅데이터 시스템 일부로서 자율적으로 작동하지 않고 사람들의 머릿속에만 남아 있거나 문서로만 남아있다면 빅데이터 비즈니스 문제 해결의 경험이 시스템 일부로서 살아 움직이는 것이 아니라 제대로 활용되지 못하고 사장되기 쉽다.
빅데이터 분석의 결과물은 반드시 소프트웨어화되어 빅데이터 비즈니스 프로세스와 시스템 운영을 자동화하는 요소로서 최종 통합되어야 한다. 빅데이터 분석의 결과물을 빅데이터 시스템의 소프트웨어 모듈로서 쉽고 빠르게 통합할 수 있도록 하는 표준 분석 플랫폼이 중요한 이유가 바로 이것 때문이다. 표준 분석 플랫폼의 언어로 빅데이터 분석의 내용을 기술하고, 이 표준 분석 플랫폼의 언어를 통해 기술된 데이터 분석의 내용과 논리가 큰 수정 없이 바로 빅데이터 시스템의 한 모듈로서 빅데이터 처리 및 비즈니스, 운영 프로세스 자동화에 통합될 수 있도록 빅데이터 시스템을 디자인하고 구축해야 한다. 이런 자동화에 초점을 맞춘 빅데이터 표준 분석 플랫폼 통합과 빅데이터 시스템 디자인은 운영 지능화를 위한 운영 빅데이터 시스템에도 똑같이 적용되어야 한다.
마지막 여섯번째로, 빅데이터 시스템의 운영 지능화 시스템이나 모니터링 시스템은 운영 빅데이터 가시화나 큐레이션을 유연하고 효과적으로 할 수 있는 시스템이 되도록 설계되어야 한다.
빅데이터 문제가 떠오르면서 데이터 가시화에 대한 얘기가 간간이 나타나고는 있지만 깊게 다루어지지는 않고 있다. 데이터 가시화를 위한 오픈소스 D3.js나 태블로(Tableau) 같은 상용 데이터 가시화 소프트웨어가 인기가 높아지기는 했지만, 빅데이터 가시화에 맞게 활용되기보다는 마이크로 소프트 엑셀의 차트 기능을 좀더 복잡하게 사용한다는 느낌 정도로 활용하는 것처럼 보인다.
운영 지능화 시스템의 운영 빅데이터도 역시 빅데이터이기 때문에, 시스템 운영과 문제 해결에 관련된 정보만 선별하기 위해서도 빅데이터 처리와 가공이 필요하다. 데이터 가시화를 위해서도 많은 컴퓨팅 자원이 필요할 수 있기 때문에, 가시화하려는 운영 데이터의 양과 복잡도에 따라서 운영 빅데이터 가시화를 위한 빅데이터 시스템을 별도로 구축해야 할 수 있다.
운영 빅데이터 가시화의 또 다른 중요한 문제는 큐레이션 문제이다. 운영 빅데이터 가시화에서 중요한 것 중의 하나는, 장애나 시스템의 문제를 해결하고자 할 때 문제 해결에 필요한 정보만을 주문형으로 가시화하면서 문제 해결을 도와야 한다는 것이다. 가시화할 수 있는 운영 빅데이터가 적절하게 미리 가공되어 큐레이션되어 있지 않으면, 운영 빅데이터의 양이 많고 복잡할 경우 주문형으로 가시화하는 것이 어렵고 문제 해결에 불필요한 시간과 노력을 낭비하게 된다. 앞에서 소개한 엑스큐브와 엑스그래프메이커가 만들어진 이유 중의 하나가 바로 복잡한 CMS 온라인 시스템의 장애와 문제를 주문형으로 가시화하면서 빠른 시간에 해결하기 위함이었다.
운영자의 필요에 따라 주문형으로 운영 빅데이터를 큐레이션하기 위해서는 운영 빅데이터를 표현하고 가공하는 과정이 표준 분석 플랫폼을 통해서 체계적으로 조직되어 있어야만 한다. 이 운영 빅데이터 큐레이션은 단순히 데이터 조직 측면뿐 아니라, 운영 빅데이터를 가시화하는 방식에도 필요하다. 같은 데이터를 가시화하더라도, 가시화해서 보여주는 방식, 즉 가시화된 정보를 나열하거나 배치하는 방식에 따라 운영자가 시스템의 문제를 쉽게 발견할 수도 있고, 발견하기 매우 어려울 수도 있기 때문이다.
대용량 그래프 데이터를 예로 들어보면, 그래프 자체를 시각화해서 보여준다고 해서 복잡한 그래프에서 원하는 노드나 클러스터를 육안으로 찾아내기는 쉽지 않다. 대용량 그래프 데이터를 특정한 조건에 따라 선별하여 강조하여 부각하거나, 두 개의 그래프 데이터를 비교할 수 있게 하거나, 그래프 구조를 줌인, 줌아웃하면서 다양한 방식으로 데이터와 상호작용하면서 탐색할 수 없다면 탐색이 쉽지 않다.
이렇게 테이블 형태로 표현된 그래프 데이터를 노드와 에지로 시각적으로 연결된 그래프 형태로 가시화하는 방식이라든가, 그래프 구조를 줌인, 줌아웃하면서 상호작용하는 것과 같은 가시화된 데이터와 운영자가 상호작용하는 방식, 두 개의 그래프 데이터를 비교하게 하는 방식 등으로 가시화 데이터를 효과적으로 배치하는 방법에 대한 고민이 없이는 운영 빅데이터를 이용해 쉽게 문제 해결하기는 매우 어렵다.
미술관에서 큐레이터가 미술 작품을 큐레이션하는 방식에 따라 미술 작품에 대한 이해가 쉬워지거나 달라지고 전체적인 전시회의 색깔이 달라지는 것처럼, 가시화한 운영 빅데이터를 배치하고 나열하는 방식에 따라 빅데이터 시스템의 문제를 쉽게 해결할 수도 있고, 오히려 문제의 해결책을 찾는 데 방해가 될 수 있다. 빅데이터 시스템의 운영을 위한 모니터링 시스템도 가시화된 빅데이터의 큐레이션 문제로 볼 수 있다. 처음부터 완벽한 빅데이터 큐레이션 방식을 찾을 수 없으므로, 최소한의 시행착오를 거치면서 시스템에 맞는 빅데이터 큐레이션 방식을 점진적으로 개선해 나갈 수 있는 소프트웨어 도구가 필요하다.
빅데이터 비즈니스를 위한 정보 시스템을 운영하는 문제가 다시 빅데이터 문제가 된다는 것은 참으로 아이러니하면서도 흥미로운 문제이다. 결국은 빅데이터 비즈니스를 잘 하기 위해 구축하게 되는 빅데이터 시스템을 효과적으로 운영하기 위한 운영 시스템도 빅데이터 시스템이 되는 것이다.
그렇지만, BSS에서 요구되는 것과 OSS에서 요구되는 것은 분명히 다르다. BSS는 시장과 비즈니스를 관찰하면서 시장과 비즈니스의 추세를 예측하여 비즈니스의 방향을 설정하고 기업의 미래를 준비할 수 있게 해주는 시스템이 되어야 하지만, OSS는 시스템의 상태를 신속하게 파악하고 장애나 문제 발생 시 신속하게 해결할 수 있게 돕는 시스템이어야 하기 때문이다.
스플렁크(Splunk)라는 걸출한 소프트웨어로 인해 운영 지능화 시스템을 위한 빅데이터 문제가 IT 업계에서 주복받았던 것을 기억한다. 뉴렐릭(New Relic), 클라우드피직스(CloudPhysics) 같은 SaaS 형태의 새로운 운영 지능화 서비스도 많은 기업들에게 성공적으로 서비스를 확장해나가고 있다. 운영 지능화 시스템 기술 분야는 빅데이터 비즈니스를 하는 기업 본연의 문제이기도 하지만, 빅데이터 비즈니스를 위한 또 하나의 유망한 시장이기도 하다. 빅데이터 비즈니스 시장이 성숙해지면서 운영 지능화 문제 해결을 위한 수요도 더욱 높아질 것이므로, 기업이 본연의 빅데이터 비즈니스를 효과적으로 운영하기 위한 측면에서, 그리고 빅데이터 비즈니스를 통해 수익을 낼 수 있는 또 하나의 빅데이터 블루오션 시장으로서 운영 지능화 기술에 대해 더욱 관심을 가지고 역량을 축적해 나가는 것이 좋겠다.
[참고문헌]
[1] 김진철, “LHC에서 배우는 빅데이터와 machine learning 활용 방안”, 2016년 9월 28일, A CIO Conversation for Technology Leadership – Breakfast Roundtable 발표 자료
[2] Jincheol B. Kim, Johannes Gutleber, Luciano Orsini, Sergio Cittolin, Dongchul Son, Guinyun Kim, Gerry Bauer, Vincent Boyer, James Branson, Angela Brett, Eric Cano, Andrea Carboni, Marek Ciganek, Samim Erhan, Dominique Gigi, Frank Glege, Robert Gomez-Reino, Michele Gulmini, Claude Jacobs, Elliot David Lipeles, Juan Antonio Lopez Perez, Gaetano Maron, Frans Meijers, Emilio Meschi, Roland Moser, Esteban Gutierrez Mlot, Steven Murray, Alexander Oh, Christoph Paus, Andrea Petrucci, Marco Pieri, Lucien Pollet, Attila Racz, Hannes Sakulin, Matteo Sani, Philipp Schieferdecker, Christoph Schwick, Konstanty Sumorok, Ichiro Suzuki, Dimitrios Tsirigkas, Joao Varela, “OLAP-based online monitoring application for high-energy particle detector DAQ system,” Nuclear Instrument and Methods A, unpublished.
* 김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. dl-ciokorea@foundryco.com
