KR20190061247A - 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템 - Google Patents

Abstract

본 발명은 관리되는 자원 데이터를 스토리지에 저장하여 분석/예측을 통해 플랫폼에 자원이 필요한 만큼 제공할 수 있는 실시간 자원 사용률 모니터링 시스템에 관한 것이다.

Description

빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템{REAL TIME RESOURCE USAGE RATIO MONITORING SYSTEM OF BIG DATA PROCESSING PLATFORM}

본 발명은 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템에 관한 것으로, 관리되는 자원 데이터를 스토리지에 저장하여 분석/예측을 통해 플랫폼에 자원이 필요한 만큼 제공할 수 있는 실시간 자원 사용률 모니터링 시스템에 관한 것이다.

빅데이터 처리 플랫폼에서도 모니터링을 지원하기도 하지만 보통은 다른 모니터링 툴을 이용해야 한다.

종래의 모니터링 기술은 오픈소스 모니터링 기술 측면에서 연구되고 발전되어 왔다. 오픈 소스 모니터링 기술은 툴 형태로 사용되고 있으며, 대표적인 툴로는 나기오스(Nagios), 제노스(Zenoss), 자빅스(Zabbix)가 있다.

나기오스(Nagios)는 Free Software Foundation이 발표한 GNU 일반 공중 사용 라이센스(GPL) 버전 2의 조건에 따라 배포되는 무료 소프트웨어이다. 다양한 사용자 커뮤니티를 구성하고 설치하기 쉬운 플러그인들을 보유하며 웹 프론트 엔드에서 사용하기 편리하다는 장점이 있지만 수집된 모니터링 데이터를 그래프로 만들 수 없는 경우가 있어 다른 툴을 이용해야 하는 경우가 있고 대부분의 체크가 Nagios 서버에서 이뤄지므로 서버에 부하가 걸리는 등 다양한 단점이 있다.

제노스(Zenoss)는 시스템 관리자가 가용성, 목록, 구성, 성능 및 이벤트를 모니터링 할 수 있는 웹 인터페이스를 제공하며 GPL 버전 2의 조건에 따라 무료로 배포되고 있다. 구글 맵등을 통해 설치된 서버의 위치를 지도에서 표현할 수 있다거나 윈도우를 모니터링 할 수 있는 장점이 있지만 웹 인터페이스가 느리며 한 개만 지원되는 대시보드, 제한적인 오픈 소스 버전이라 풀 버전을 이용하려면 제품 구매가 필요하다는 단점이 있다.

마지막으로 자빅스(Zabbix)는 네트워크 및 애플리케이션에 대한 오픈소스 모니터링 솔루션으로 다양한 네트워크 서비스와 서버, 네트워크의 하드웨어의 상태를 감시하고 추적할 수 있도록 설계되었다. 자빅스(Zabbix)는 데이터를 저장하기 위해 MySQL, PostgreSQL, SQLite, Oracle, IBM DB2를 사용하며, 백엔드는 C로 작성되었고 웹 프론트엔드는 PHP로 작성되었다. 다양한 모니터링 옵션을 제공하며 GPL 버전 2의 조건에 따라 배포되는 무료 소프트웨어이다. 강력한 모니터링 기능과 그래프를 하나의 도구로 결합시켰고, 알림에 완벽하게 사용자 정의 메시지를 이용할 수 있으며, 빠른 웹 인터페이스, 데이터 저장 기간을 자유롭게 구성, 자빅스(Zabbix) 프록시를 사용하여 원격 모니터링 등 수많은 장점이 있지만 알림 설정에서 다량의 임계치 설정이 필요하며 웹 인터페이스 기능이 많고 복잡하며 디버깅을 하기 어렵다는 단점이 있다.

이러한 다양한 오픈소스 모니터링 기술은 본래 컴퓨팅 서버를 모니터링 하는 것을 주로 하였기에 클라우드 환경의 물리자원 및 가상자원의 사용률은 모니터링 할 수 있으나, 가상머신의 정보와 상태 변화를 파악하지 못하는 단점을 가지며 사용자의 서버 운용 환경에 맞춰 모니터링 툴을 이용하여야 편리한 서버 환경을 가질 수 있다. 또한 클라우드 환경에서는 가상머신이 실행되는 물리 서버인 컴퓨팅 장치(노드)의 수가 증가될 수 있으므로 모니터링 데이터 전송의 효율을 높여야 하는 문제도 있는데, 이를 해결하기 위해 대한민국 특허 제1630088호는 RESTful API에 기반하여 가상머신의 라이프사이클을 모니터링함으로써 데이터 전송의 효율을 높일 수 있는 가상머신의 라이프사이클 모니터링 방법 및 그 장치를 개시하고 있다.

한편, 빅데이터 플랫폼 안에서 자원은 보통 CPU와 메모리(Memory)를 뜻한다. 플랫폼 안에서 사용할 자원의 양을 설정할 수 있지만 설정한 값보다 적게 사용되는 경우도 있다. 최댓값으로 설정된 자원보다 애플리케이션이 동작하면서 사용되는 자원이 현저히 적게 사용되면서 불필요한 자원의 낭비가 발생하게 된다.

또한, 스파크(spark) 내에서 지원하는 동적 할당의 경우 애플리케이션마다 최적화된 값을 지원하지는 못한다. 그리고 서버에서 사용되는 자원과 플랫폼의 자원 기준, 애플리케이션 동작 시 사용되는 자원 사용량을 실질적으로 모니터링 하기는 어렵다. 유저가 애플리케이션을 동작시키기 위해 필요한 자원의 양을 판단하기 어려울 뿐더러 최적의 기준을 찾기도 힘들다. 그로 인해 불필요한 자원의 낭비가 발생하게 된다.

본 발명은 아파치 스파크와 같은 빅데이터 처리 플랫폼 환경에서 실시간으로 자원 사용률을 모니터링 하는 시스템을 제공하는 것을 목표로 한다.

본 발명은 서버, 플랫폼, 그리고 애플리케이션의 자원의 양을 모니터링하여 애플리케이션의 자원 사용률을 최소화하고 최적화된 기준을 알려줄 수 있도록 하는 모니터링 모듈 및 예측 시스템을 제공하는 것을 목표로 한다.

상기한 목적을 달성하기 위한 본 발명의 일 실시예에 따르면, 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템은,

스파크의 마스터 서버와 워커 서버가 부팅되어 동작함과 동시에 모니터링 모듈을 동작시키고,

데이터를 수집하기 위해, 애플리케이션이 동작하기 전에 모니터링 모듈을 데이터베이스와 연결하고,

애플리케이션 A가 실행된 후, 애플리케이션 A의 정보와 Memory 사용률, CPU 사용률을 데이터 저장소에 저장하고,

애플리케이션 B를 실행하려 할 때, 데이터 저장소에 쌓인 애플리케이션 A의 Memory 사용률과 CPU 사용률을 검색하고, 애플리케이션 B가 동작한 후 애플리케이션 B의 정보, Memory 사용률, CPU 사용률을 데이터 저장소에 저장하고,

데이터 저장소에 저장된 정보를 이용해서 애플리케이션에 따라 필요한 Memory와 CPU의 사용률을 비교 분석하고 예측하여 유저에게 알림으로써, 유저의 목적에 따른 애플리케이션의 최적화된 자원 상태를 지원할 수 있다.

본 발명에 따르는 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템은 아파치 스파크와 같은 빅데이터 처리 플랫폼 환경에서 실시간으로 자원 사용률을 모니터링 할 수 있다.

본 발명에 따르는 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템은 스파크 애플리케이션에서 실제 사용하는 만큼 Executor의 Memory와 CPU의 자원을 최적화된 값으로 자동으로 바꾸어 주고 요구되는 자원을 예측하여 자원의 효율성을 높일 수 있다.

도1은 본 발명에 따르는 아파치 스파크의 실시간 자원 모니터링 시스템의 구성을 나타내는 블록도이다.
도2는 일반적인 스파크의 라이브러리 아키텍처를 나타내는 블록도이다.
도3은 아파치 스파크의 마스터/슬래이브 개념도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

이하에서, 본 발명에 따른 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다.

실시간 자원 사용률 모니터링 시스템

본 발명에 따르는 빅데이터 처리 플랫폼인 아파치 스파크(Apache Spark)의 실시간 모니터링 시스템 구성은 도1과 같이 간략하게 표현될 수 있다. 실시간 모니터링 시스템은 아파치 스파크의 한 대의 마스터(Master) 서버와 다수의 워커(Worker) 서버로 노드가 구성되며, 데이터 저장소인 데이터베이스, 모니터링 모듈, 그리고 유저(user)의 애플리케이션으로 구성되어 있다. 아파치 스파크의 마스터(Master) 서버는 노드 구성의 총 지휘 역할로 스파크 내에서 main이며 실질적 명령을 내린다. 모든 시스템 자원을 효율적으로 관리할 수 있도록 모든 서버에 모니터링 모듈과 데이터 저장소를 별도 구성하며, 각 블록의 역할은 다음과 같다.

아파치 스파크(Apache Spark)

아파치 스파크는 In-memory 연산을 이용하여 대량의 데이터를 분산처리 하는 플랫폼이며, 도2에 도시된 바와 같이, SQL, Streaming, Machine Learning, GraphX와 같이 다양한 컴포넌트를 지원하고 있다. 스파크는 여러 분산 노드에 걸쳐 저장되는 변경이 불가능한 집합인 RDD(Resilient Distributed Dataset)를 이용하여 데이터를 분산처리 한다.

아파치 스파크는 도3에 도시된 바와 같이, 크게 마스터(Master)인 드라이버(Driver)와 슬래이브인 워커(Worker)가 클러스터 매니저(Cluster Manager)에 의해 마스터/슬래이브(Master/Slave) 구조를 이루고 있다. 드라이버(Driver)는 프로그램의 main 메소드를 실행하고 스파크 안에서 RDD가 연산을 이용할 수 있게 하는 SparkContext를 생성한다. 또한 드라이버는 Executor가 태스크를 실행할 수 있도록 스케줄링하며 Worker 사이를 조정하는 역할을 한다. Worker는 실제 연산을 수행하는 노드이며 Executor를 가지고 있다. Executor는 태스크를 실행하는 Worker 노드의 프로세스이며, BlockManager를 통해 애플리케이션에 캐시된 RDD를 위한 Memory 저장소를 제공한다.

스파크 마스터

Master 서버는 스파크를 구성하고 관리하는 main이며 시스템의 스케줄과 자원을 관리한다. 다수의 Worker 서버를 관리하며 요청 받는 스케줄을 처리한다. 스파크 내부의 상태 정보를 수집하고 연산을 처리하는 기능을 제공한다.

스파크 Master 서버는 RDD 연산을 리니지 기법을 이용하여 연산을 쌓아놓고 실질적으로 필요한 경우에 연산 처리를 함으로써, 메모리의 사용을 줄이고 데이터의 손실이 일어났을 때 복제 및 복구 등의 기능을 제공한다.

스파크 워커 서버

워커(Worker)는 실제 Executor가 실행되는 서버이다. 스파크 워커 서버는 Executor를 이용하여 스케줄링에 따라 태스크를 처리하는데, 이때 필요한 자원이 메모리와 CPU이며, Master 서버와 통신을 하며 주어진 연산을 스케줄링에 맞춰 처리하는 핵심 역할을 한다.

모니터링 모듈

모니터링 모듈은 스파크 내부에서 동작하며 스파크 서버와 스파크 애플리케이션을 모니터링하는 모듈이다. 이 모듈은 스파크 서버가 부팅될 때 같이 실행되며 24시간 계속 감시하는 기능을 제공한다. 또한, 내부의 상태가 전이될 경우 태그를 다는 기능을 제공하여 전이될 때마다 태깅을 하여 데이터 저장소에 태깅 정보를 저장한다. 그리고 서버 또는 애플리케이션의 상태 정보를 데이터 저장소에 저장한다. 여기서 말하는 상태 정보는 자원 사용률을 의미하며 CPU와 메모리의 사용률을 말한다. 모니터링 모듈은 마스터 서버뿐만 아니라 Worker 서버 등 모든 서버에서 동작하며 최종 결과를 마스터가 데이터 저장소에 전달하는 형식이다. 모니터링 모듈은 스파크 내부에서 동작하므로 스파크의 스칼라에 종속되며 스레드를 이용하여 데이터를 주고 받는 형태이다. 모니터링 모듈은 멈추지 않고 애플리케이션이 동작하지 않을 때도 계속 실행되며 상태가 전이될 때 데이터를 수집한다. 이때 태깅된 데이터는 수집하여 추후 예측할 때 사용된다. 모니터링 모듈은 데이터 저장소에 수집한 데이터를 애플리케이션이 동작할 때 기존의 정보와 비교하여 사용될 것으로 예측되는 자원의 양으로 바꾸어준다. 그리고 애플리케이션의 동작이 끝나면 자원의 상태 정보가 다시 데이터 저장소에 수집된다.

데이터 저장소

데이터 저장소는 스파크 내부에서 동작하는 모니터링 모듈이 수집한 데이터를 저장한다. 일반적으로 모니터링 모듈에 수집되는 데이터는 애플리케이션의 동작 시간, 메모리 사용량, CPU 사용량, 메모리 사용률, CPU 사용률, 태그 정보 등이다.

스파크 유저 (user)

스파크의 유저는 스파크에서 애플리케이션을 실행함으로써 원하는 결과를 얻을 수 있다. 스파크는 보통 두 가지의 방법으로 애플리케이션을 실행한다. 첫 번째는 스파크의 쉘 기능을 이용하는 것이고 두 번째는 submit으로 jar 파일을 실행하는 방법이다. 유저는 모니터링 모듈에 맞춰 실시간으로 모니터링되는 결과를 보고 애플리케이션을 더욱 효율적으로 실행할 수 있다.

본 발명의 일 실시예에 따르면, 백데이터 처리 플랫폼에서 애플리케이션을 실행시키는 경우에 24시간으로 모니터링 모듈이 동작하며 감시함으로써 현재 자원 사용량을 알려주는, 빅데이터 처리 플랫폼의 실시간 모니터링 시스템을 제공한다.

여기에서, 모니터링 모듈은 계속해서 동작하여 서버의 자원 상태 정보를 수집한다. 모니터링 모듈은 애플리케이션이 동작하면 대기하다 애플리케이션의 실행이 종료된 후, 사용된 메모리의 양과 CPU의 양을 계산하고 사용률을 데이터 저장소에 저장한다. 그리고 유저에게 A라는 애플리케이션이 동작하였을 때 사용된 자원의 상태 정보와 현재의 자원 상태를 알려준다. 유저는 알림을 보고 추후 애플리케이션을 재실행하거나 다른 스케줄링을 하여야 할 때 자원 상태 정보를 쉽게 참고할 수 있다. 따라서, 스파크 애플리케이션을 이용할 때 쉽게 알기 힘든 자원의 상태 정보를 실시간으로 알려줌으로써 유저의 접근성을 높인다.

본 발명의 다른 실시예에 따르면, 빅데이터 처리 플랫폼의 실시간 모니터링 시스템은 빅데이터 처리 플랫폼에서 애플리케이션을 실행시키는 경우에 수집된 데이터를 통해서 현재 애플리케이션이 실제 필요한 자원의 사용량을 예측하여 제공할 수 있다. 스파크 애플리케이션을 이용할 때 목적에 따라 사용하는 자원의 사용량이 애플리케이션마다 다르기 때문에, 유저의 목적에 맞게 애플리케이션이 사용할 자원을 예측하여 최적화함으로써 자원의 효율성을 높인다.

이상 설명한 바와 같은 빅데이터 처리 플랫폼의 실시간 모니터링 시스템의 동작은 다음과 같이 이뤄질 수 있다.

1) 스파크의 마스터 서버와 워커 서버가 부팅되어 동작하기 시작하며 모니터링 모듈도 같이 동작하기 시작한다. 유저가 스파크 애플리케이션 A를 실행할 때 10초 동안 50MB의 Memory를 사용한다.

2) 모니터링 모듈은 애플리케이션이 동작하기 전에 데이터베이스와 연결되어 데이터를 수집할 준비를 한다.

3) 애플리케이션 A가 실행된 후 A의 5MB/sec의 정보와 Memory 사용률, CPU 사용률 등이 데이터 저장소에 저장된다.

4) 애플리케이션 B를 실행하려 할 때 데이터 저장소에 쌓인 애플리케이션의 Memory와 CPU 사용률 등의 정보를 검색한다. 애플리케이션 B는 10초 동안 100MB의 Memory를 사용하였다. 애플리케이션 B가 동작한 후 10MB/sec의 정보, Memory, CPU 사용률이 데이터 저장소에 저장된다.

5) 이렇게 데이터를 수집하여 애플리케이션이 실행되기 전에 기존의 정보를 이용해서 애플리케이션에 따라 필요한 Memory와 CPU의 사용률을 비교 분석하고 예측하여 유저에게 알림으로써 유저의 목적에 따른 애플리케이션의 최적화된 자원 상태를 지원할 수 있다.

Memory와 CPU의 최적화된 값을 구하는 기준은 최대 Bandwidth를 산출하는 경우의 CPU 크기(A)와 메모리 크기(B)와, 모니터링 시스템이 측정한 CPU의 가용량 크기(mon(CPU)), 메모리의 가용량 크기(mon(mem))를 비교하여 다음과 같이 결정한다.

CPU = min { max (A), mon(CPU) }

Mem = min { max (B), mon(mem) }

이상과 같이 본 발명에서는 구체적인 구성 요소 등과 같은 특정 사항들과 한정된 실시예 및 도면에 의해 설명되었으나 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다. 따라서, 본 발명의 사상은 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등하거나 등가적 변형이 있는 모든 것들은 본 발명 사상의 범주에 속한다고 할 것이다.

Claims (4)

1. 드라이버 서버와 워커 서버의 동작과 동시에 각각의 모니터링 모듈을 동작시키는 단계;
   애플리리케이션이 실행되기 전에, 각각의 모니터링 모듈을 해당 데이터 저장소와 연결하는 단계;
   애플리케이션 A가 실행된 후, 애플리케이션 A의 정보, 메모리 사용률, 및 CPU 사용률을 각각의 데이터 저장소에 저장하는 단계;
   애플리케이션 B를 실행하려 할 때, 해당 데이터 저장소에 저장된 애플리케이션 A의 메모리 사용률과 CPU 사용률을 검색하는 단계;
   애플리케이션 B가 실행된 후, 애플리케이션 B의 정보, 메모리 사용률, 및 CPU 사용률을 해당 데이터 저장소에 저장하는 단계;
   해당 데이터 저장소에 저장된 정보를 이용하여, 각각의 애플리케이션에 대한 최적의 메모리 크기 및 최적의 CPU 크기를 결정하는 단계를 포함하는
   빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 방법.
   
2. 제1항에 있어서,
   최적의 메모리 크기는 최대 대역폭(Bandwidth)를 산출하는 경우의 메모리 크기(B)의 최대값과 모니터링 모듈이 측정한 메모리의 가용량 크기(mon(mem))를 비교하여 그 중 작은 값으로 결정되는
   빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 방법.
3. 제1항에 있어서,
   최적의 CPU 크기는 최대 대역폭(Bandwidth)를 산출하는 경우의 CPU 크기(A)의 최대값와 모니터링 모듈이 측정한 CPU의 가용량 크기(mon(CPU))를 비교하여 그 중 작은 값으로 결정되는
   빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 방법.
   
4. 아파치 스파크의 한 대의 드라이버 서버를 포함하는 드라이버 노드;
   1대의 워커(Worker) 서버를 각각 포함하는 다수의 워커 노드; 및
   유저 애플리케이션을 포함하고,
   상기 드라이버 노드 및 워커 노드에는 데이터 저장소 및 모니터링 모듈이 각각 별도로 구성되는
   빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템.
   

Images