Posting

Machbase의 최신 소식을 지금 만나보세요

TPCx-IoT- 센서 데이터 처리 BMT와 그 한계

들어가면서

마크베이스 CTO 심광훈

최근, 시계열 센서 데이터를 처리하기 위한 HW/SW의 성능을 공정하게 비교하기 위한 테스트 방법론이 요구되고 있습니다. 고객이 갖고 있는 데이터 처리 문제를 해결하기 위해서 어느 정도의 하드웨어를 이용하여 어떤 소프트웨어를 설치해야 하는가, 전체 비용이 어느정도 소요되는가에 대한 공정한 비교 방법론이 있다면 요구 사항에 맞는 하드웨어 및 소프트웨어를 마련하는데 큰 도움이 될 것입니다.

데이터 처리관점에서 이를 위해서 공정한 테스트 방법론을 설정하고 실행된 테스트 보고서 및 테스트 진행과정을 조사하여, 테스트 결과를 인증하고 게시하는 역할을 수행하는 비영리 기관으로 TPC(transaction processing performance council)가 있습니다. 이 기관에서 아주 유명한 테스트들을 많이 만들었고, 테스트도 많이 인증해서 TPC 홈페이지에 게시하고 있습니다. 대표적인 TPC의 벤치마크 테스트로는 여러분들 많이 알고 계실 TPC-C, TPC-H등의 테스트가 있습니다. 자세한 내용은 적지 않겠습니다만 TPC-C는 대량의 OLTP성 데이터 처리를 TPC-H는 분석 통계 데이터 처리(OLAP)를 각각 다루고 있습니다.

TPC 테스트의 문제점과 새로운 해결 방법

TPC의 테스트들은 매우 정확하고 실제 상황을 반영하여 작성되어 고객이 원하는 성능목표치와 TPC 테스트 결과가 잘 매치됩니다. 하지만, 간단해 보이는 TPC-C 테스트도 살펴보면 상당히 구현이 어려운 문제가 있습니다.

여러 클라이언트 세션을 이용하여 데이터를 입력하고, 갱신하고, 삭제하는 도중에 지정된 TPC-C용 질의들이 동시에 실행됩니다. 실행해야 하는 질의문과 결과값의 검증 과정도 쉽지 않습니다. 테스트가 복잡하고 어렵기 때문에 테스트 결과를 보고 심사하고 인증하는 것도 쉽지 않습니다. 이로 인해서 테스트에 너무 많은 비용이 소모되므로 저희 회사와 같은 작은 회사의 제품으로는 테스트가 쉽지 않지요.

그리고 기존 TPC테스트만으로 테스트하기 어려운 분야에 대한 테스트 방법론의 추가 필요성도 있습니다. TPC-C만 해도 테스트 방법이 1992년에 최초로 확립되었고 이때만 해도 모든 데이터 처리는 RDBMS를 기준으로 한 데이터 처리에 맞추어져 있었습니다. 그 이후 BigData 처리 제품들에 대한 테스트 방법론의 필요성이 증가하여 TPC에서는 BMT방법을 추가로 제정하게 되었습니다.

이때, BMT구현의 어려움을 해결하기 위해서 추가로 제정되는 BMT는 테스트를 위한 JAVA binary를 TPC에서 제공하고, DBMS등의 데이터 처리 제품용 드라이버를 추가로 구현하도록 하는 방법이 제시되었습니다. 이렇게 BMT binary를 TPC에서 제공하는 테스트들은 TPCx(Express)라는 이름을 붙이고 등장하였습니다. 이런 테스트들 중에 TPCx-IoT 라는 BMT가 있으며 이 포스트에서는 이에 대해서 자세하게 다루어 보겠습니다.

TPCx-IoT

BMT의 대상

TPCx-IoT는 사물 인터넷(IoT) 게이트웨이 시스템의 성능을 측정하기 위한 BMT입니다. 

TPCx-IoT가 설정한 게이트웨이 시스템은 대규모 데이터센터도 아니고 장비에 직접 부착되어 있는 (혹은 매우 가깝게 배치되어 있는) Edge 단말도 아닙니다. Gateway는 위 그림에서 설명하듯, 1) 고속 입력, 2) 단기간 입력되는 데이터를 저장함 3) 실시간 분석의 특징과 기능을 갖고 있습니다.

TPC BMT들은 실제 응용과 유사한 상황을 테스트 방법으로 만들어 왔으며, TPCx-IoT 또한 발전소의 센서 데이터 처리를 시뮬레이션 하고 있습니다. TPCx-IoT가 모사하는 발전소의 상황은 다음과 같습니다.

각 에지 단말은 센서데이터를 읽어서 Gateway에 데이터를 입력하고, 이 BMT는 입력 데이터가 Gateway에 잘 입력되는지, 실시간 분석 질의는 잘 실행되는지를 체크하고, 입력성능을 기준으로 테스트 결과치를 만듭니다.

이제 입력 데이터와 그 특징에 대해서 살펴보겠습니다.

입력 데이터와 그 특징

TPCx-IoT가 처리하는 데이터는 게이트웨이에 연결된 각 에지 장비에서 전송한 센서 데이터입니다. 이 센서 데이터는 어느 에지의 어느 센서인지를 표시하는 Power Substation Key, Sensor key와 데이터 입력 시간인 Timestamp, 그리고 센서 값과 단위, 기타 추가 데이터로 약 1k정도의 데이터 길이를 갖습니다. 마크베이스와 대부분의 RTDB가 제공하는 센서 데이터는 <센서 식별자, 시간, 값>의 단순한 데이터에 비해서 이상할 정도로 쓸데없는 데이터가 많습니다.

이렇게 규격을 만든 이유는 아마도 ycsb(yahoo cloud service benchmark)를 기반으로 이를 수정하여 BMT를 구현하였기 때문이 아닌가 합니다. 그리고 입력 키도 칼럼 단위로 분류되어 있지 않고 센서 식별자, 시간을 하나로 합한 키값으로 사용되고 있습니다. 키 값을 이와 같이 설정한 이유로는, ycsb에서 지원하는 HDB등의 빅데이터 처리제품이 NO-SQL 제품들이며 이들 key-value pair에 대해서만 동작하기 때문이 아닌가 합니다.

BMT 표준에 맞춰 이와 같이 센서 데이터 처리를 하면 불필요하게 긴 센서 데이터 레코드를 저장하고 검색하기 위하여(실 상황에서는 있을 수 없는) 대량의 디스크 I/O가 발생합니다. 문자열로 기록되어 다른 쓸데없는 데이터와 같이 기록된 센서값에 대한 통계가 불가능하며, 이를 가능하게 하려면 실시간 문자열 파싱등의 불필요한 오버헤드가 발생합니다. 물론 BMT상황에서는 수행하지 않는 연산이지만, 실 상황에서는 거의 대부분 실시간 통계를 수행하고 있습니다.

또한 모든 입력값이 유일키를 갖게 되므로, 대량의 데이터 입력시 B+Tree의 구조에 의한 입력 성능 저하도 피할 수 없습니다.

결론

이 문서에서는 센서 데이터 처리를 위한 BMT인 TPCx-IoT의 성립 배경 및 그 특징에 대해서 살펴보았습니다. 이 BMT는 실제 산업현장에서 겪고 있는 센서 데이터 처리를 위한 성능/용량 산정에 있어서 매우 유용해 보입니다. 그러나 데이터 처리에 필요하지 않은 센서 단위(매 센서값마다 저장할 필요는 없죠)문자열, 매우 긴 padding 데이터를 추가햐여 처리하며, 시계열 데이터 처리의 핵심적인 부분인 Timestamp를 key의 일부로 합하여 사용하는 점등은 시계열 데이터 처리 제품에서 받아들이기 힘든 부분이 많습니다.

또한 마크베이스와 같은 관계형 데이터 모델을 갖는 제품은 구조화된 데이터를 입력시에 칼럼별로 분류하여 처리해야 효율적으로 동작하는데, 여러 가지 칼럼 값을 하나의 key, value 쌍으로 처리하는 것은 문제가 많은 부분입니다. 보다 현실적인 BMT를 위하여 이와 같은 부분의 개정이나, 추가 보완이 필요한 것 또한 알 수 있었습니다.

참고문헌

(1) TPCx-IoT spec http://www.tpc.org/tpcx-iot/documents/introducing_tpcx-iot.pdf

(2) Meikel Pöss, “Methodologies for a Comprehensive Approach to Measuring the Performance of Decision Support Systems”, Technischen Universität München

연관 포스트

Deep Anomaly Detection in Time Series (2) : 이상 감지 모델

개요 안녕하세요, 마크베이스의 Cloud개발본부 연구원 양창은입니다. 지난 게시글 Deep Anomaly Detection in Time Series (1) : Time Series Data에서는 시계열 데이터와 이상치(Anomaly)의 종류에 대해 알아보았습니다. 그리고

IIoT를 위한 Data Lake – machlake

Data Lake 란, 대규모의 다양한 원시 데이터 세트를 기본 형식으로 저장하는 데이터 리포지터리 유형입니다. 원시 데이터는 특정 목적을 위해 처리되지 않은 데이터를 뜻합니다. 산업 IoT