IOT(FDC)등의 초당 수억건의 시계열 데이터 적재 및 처리 성능 극대화

서론

 산업 현장의 생산성 향상을 위해 인공지능, ML, IoT(Internet of Things) 등 다양한 기술이 융합된 자율화된 공장을 통해 위해 설비의 고장이나 이상을 예측하고 생산성 향상을 위해 스마트 팩토리 도입 추진이 가속되고 있습니다. 하지만 반도체와 같은 제조 현장에서 비정상적 이벤트 감지를 통해 수율증대, 예지 정비 등의 생산 효율성과 안전성 등을 높이기 위한 ML/딥러닝 모델 적용을 하는데 있어 생산 현장에서 발생되는 센서 데이터의 양이 폭발적으로 증가하고 있어 이를 실시간으로 모델에 제공하고 이를 분석하는데 많은 기업들이 한계에 봉착하여 많은 고민과 다양한 시도를 하고 있는 것이 현실입니다. 이에 SingleStore를 통해 실시간으로 데이터를 적재하고 적재된 데이터를 실시간으로 분석하는 테스트를 진행하였습니다. 이것이 산업 현장의 고민에 대해 조금이나마 도움이 되었으면 합니다.

위의 다이어그램에 보는 바와 같이 요구조건은 하나의 생산 장비 안에 3,000개 센서가 있고, 개별 센서가 0.1초 단위로 데이터를 발생시키는데, 여기서 발생되는 모든 시계열 데이터를 DBMS에 적재하고 다수의 동시 사용자가 쿼리를 수행해야 합니다. 최대 5,000대에서 발생되는 센서 데이터를 일정한 시스템 사용률을 유지하면 안정적인 데이터 적재 및 쿼리 수행을 위해 SingleStore의 노드의 수를 예상하고자 합니다.

​

일단 전체 5,000대 중 5%인 250대 장비 수용을 위해 클라우드 환경에서 SingleStore 노드를 구성해 보고자 합니다. 개별 장비(Equipment)의 수를 순차적으로 증가 시킬 때, SingleStore의 Leaf 노드를 추가함에 따라 선형적으로 생성되는 센서 데이터를 모두 수용할 수 있어야 합니다. 그리고 시계열 데이터를 적재하는 상황에서 동시접속자(200명, 50명)가 쿼리를 수행해야 합니다.

 

테스트 환경 및 시나리오

​테스트 서버 사양

​테스트 서버(AP 서버/Leaf 노드)의 사양은 아래와 같습니다.

​> CPU : 24 OCPU(2.0 GHz Platinum 8167M)

> MEM: 192 GB( 320 GB 중)

> DISK: 25.6 TB NVMe SSD(RAID 0)

> N/W: 24.6 Gbps

> OS : Centos 7.6 / SingleStore 7.0(columnstore)

​

데이터 생성을 위한 AP 서버

장비의 개별 센서별로 0.1초 단위로 시계열 데이터 생성하고, 생성된 시계열 데이터를 Kafka로 전송하는 어플리케이션(AP)을 JAVA로 개발하였습니다. 0.1초 당 생성되는 시계열 데이터(하나의 Row)는 16개 컬럼(170~180 byte)으로 구성이 됩니다. 또한 AP 옵션 값을 통해 부하 조정(장비 수, 센서 수, 토픽 수 등)이 가능하도록 했습니다.

​

생성 데이터 예제

테스트 환경 구성

AP서버와 Kafka는 하나의 호스트에 구성을 하였고, AP서버에서 데이터가 생성이 되면 Kafka로 전송을 하도록 구성하였습니다. 또한 금번 시나리오에서는 마스터 어그리게이터의 자원 활용률이 적지만 SingleStore의 마스터 어그리게이터와 리프 노드는 개별 노드로 구성하였습니다. SingleStore는 인메모리기반의 로우스토어와 디스크 기반의 컬럼스토어를 갖고 있는데 금번 시나리오에서와 같이 대량의 데이터를 적재함에 있어 메모리 사용의 효율성을 높이고, 압축을 통해 디스크 용량 절감이 가능하면서 빠른 쿼리 수행에 유리한 컬럼스토어를 사용하였습니다. Kafka의 토픽별로 생성되는 시계열 데이터를 SingleStore의 테이블에 적재하기 위해 SingleStore에 내장된 Kafka 파이프라인*을 활용하였습니다. 또한 적재되는 데이터는 컬럼스토어 인덱스 기반으로 샤딩해서 분산 저장하도록 하였습니다. 이때 Kafka 파티션 수와 파이프라인 파티션 수 그리고 DB 파티션 수는 동일하게 설정하였습니다.

​

*Kafka 파이프라인 : Kafka consumer기반으로 제작되어 별도의 코딩없이 Kafka 토픽에 쌓이는 데이터를 병렬로 적재(ETL)가 가능한 SingleStore의 내장 기능

​

DB 스키마

CREATE TABLE sensor_data_table ( timestamp timestamp(6), name char(13), chid char(2), lotid char(15), ppid char(15), recipeid char(15), chstep char(15), stepseq char(13), partid char(15), status char(3), slotno tinyint, sensor char(28), value double, lcl double, ucl double, SHARD KEY(name, sensor), KEY (timestamp) USING CLUSTERED COLUMNSTORE );

 

동시 접속자 쿼리

​동시 접속자(200, 50명)에 대한 안정적인 성능 보장 여부를 확인하기 위해 Jmeter를 통해 아래의 쿼리 조건을 적용하였습니다.

​

§ Short term 쿼리

​데이터가 적재되고 있는 상황에서 최근 1초 동안의 센서 데이터를 200명의 동시 사용자가 각각 2초 간격으로 100회씩 쿼리를 수행합니다.​

§ Long term 쿼리

​데이터가 적재되고 있는 상황에서 최근 30초 동안의 센서 데이터를 50명의 동시 사용자가 각각 2초 간격으로 100회씩 쿼리를 수행합니다.

 

SELECT * FROM sensor_data_table WHERE timestamp > current_timestamp() - interval 1(or 30) SECOND and name='eq17531_0008' and sensor ='kafkaExample.Sensor@4a0ed9b' and ppid ='7ycyk3' and recipeid ='733l' and chstep ='qwpe39fw' and stepseq ='qpuoldxlpcipd' and partid='55ay7rmgc’ ;

 

성공 요건

​데이터가 적재 되는 상황에서 Short/Long term 쿼리에 동시 접속자들에게 안정적인 성능을 제공해야 합니다.

 

 

데이터가 적재 되는 상황에서 Short/Long term 쿼리에 동시 접속자들에게 안정적인 성능 제공해야 합니다. 여기서 Short/Long term 쿼리 성능은 어플리케이션(Jmeter)에서 Fetch 시간을 포함해서 측정해야 합니다.

​

테스트 결과

​대량의 시계열 데이터를 적재 중에 동시접속자(200, 50명)에 대한 안정적인 쿼리 성능(30~50ms)을 보여 주었습니다.

                                                                                                            * 결과는 평균 수행 시간과 사용률

 

                                                                                     [범례]

                                                                                       - EQ(장비)에서 0.1초당 3,000개 Row 데이터 생성(30,000/초)

                                                                                       - 적재 건수(Row) = EQ x 30,000

                                                                                       - 적제 데이터 사이즈 = 적재 건수 x 175 bytes

​

상기의 결과 표에서 보시는 바와 같이 SingleStore 싱글 노드에서 50%미만의 자원을 사용하면서 초당 900,000 Row 이상의 적재와 빠른 쿼리 성능을 보여주었습니다. 또한 적재 상황에서도의 Short/Long term 모두 30~50ms내에 응답속도를 보여주었고, SingleStore 노드 증가에 따라 적재 성능이 선형적으로 증가하고 안정적인 쿼리 성능을 제공하는 것을 확인하였습니다. 추가로 디스크 기반 컬럼스토어를 통해 메모리 사용의 효율성을 높였고, 90% 압축을 통한 디스크 절감 효과도 보았습니다.

 

결과적으로 250대의 장비 수용을 위해서는 SingleStore 리프 노드 약 8대가 필요했고, 데이터 증가와 안정적인 성능 제공을 위해서 스케일 아웃을 통해 확장이 가능함을 확인 할 수 있습니다.

​

결론

​SingleStore는 ANSI SQL기반의 인 메모리와 디스크 기반 분산된 아키텍처를 사용하는 트랜잭션과 분석을 위한 실시간 표준 관계형 데이터베이스입니다. X.86기반 범용 하드웨어에 설치되는 Aggregator 와 Leaf 노드로 구성된 2계층(Tier) 아키텍처로 운영이 됩니다. Aggregator 노드는 분산 시스템에 대한 게이트웨이 역할을 하는 클러스터 인식 쿼리 라우터입니다. 이들은 메타데이터와 참조 데이터만 저장합니다. Aggregator는 클라이언트에 전송되는 결과를 집계하고 Leaf 노드에 걸쳐 쿼리를 지능적으로 배포합니다.

Leaf 노드는 스토리지 및 컴퓨팅 노드의 역할을 합니다. 데이터는 자동으로 Leaf 노드에 걸쳐 파티션으로 분산되어 병렬화된 쿼리 실행을 가능하게 합니다. Leaf 노드 수를 늘리면 클러스터의 전체 용량이 증가하고 쿼리 실행 속도도 빨라질 것이며, 특히 대형 테이블 스캔과 집계가 필요한 쿼리는 더욱 빨라질 것입니다. 또한 Leaf 노드 추가를 통해 클러스터가 더 많은 쿼리를 병렬로 처리할 수 있습니다. 이는 오라클이 엑사데이터의 Cell server의 Smart Scan, Storage index 기능을 통해 쿼리 성능을 높이고자하는 개념과 유사합니다.

​

SingleStore 메모리에 최적화된 로우스토어 테이블과 디스크 기반 컬럼스토어 테이블이 있습니다. 로우스토어 테이블은 대기 시간이 매우 짧은 트랜잭션과 소량의 데이터에 대해 빠르게 분석할 때에 사용되고, 디스크에 최적화된 컬럼스토어 테이블은 페타 바이트(Peta Byte) 규모를 지원합니다. 컬럼스토어는 내장된 압축 기능으로 압축된 데이터에 대한 쓰기, 분석 및 쿼리를 고성능으로 처리합니다.

​

SingleStore는 다양한 데이터 소스로부터 대량의 데이터와 스트리밍 데이터를 매우 빠르게 수집 할 수 있는 파이프 라인(Kafka, Hadoop, HDFS, Amazon S3 등)을 제공 합니다. 예를 들어, SingleStore의 Kafka 파이프라인으로 Kafka로 부터 전달받은 실시간 데이터를 SingleStore에 적재 할 수 있습니다; 데이터를 Kafka 큐에 덤프하기만 하면 SingleStore는 이 큐에 접근하며 따로 코드를 작성하지 않고도 실시간으로 데이터를 변환하여 테이블에 로드할 수 있습니다.

 

​또한 일반적인 insert구문 , upsert구문, 로드 또는 파이프라인을 통해 매우 빠른 시계열 이벤트 수집이 가능합니다. 시계열에 적합한 강력한 SQL Window 함수를 지원하며 유연성을 제공을 위해 사용자 정의 함수(UDF), 사용자 정의 집계 함수(UDAF)와 스토어드 프로시저를 사용하여 시계열 데이터 처리를 조금 더 쉽게 처리할 수 있습니다.

​

마지막으로 SingleStore는 분산 SQL DBMS의 모든 기능을 제공을 통해 시계열 응용 프로그램을 비롯한 범용 응용 프로그램을 용이하게 구축 할 수 있습니다. 시계열 데이터베이스의 한계인 SQL 트랜잭션, 백업 및 복원, 클러스터 관리, 로우스토어, 컬럼스토어, 인덱스, 동시성, 고가용성과 같은 추가 이점을 활용 할 수 있습니다.

​

​※ www.a-platform.biz | info@a-platform.biz