김성진 대표, 마크베이스

 

우리는 이미 4차 산업혁명의 중심에 서 있다. 많은 이들에게 회자되는 스마트 시티나 스마트 팩토리 등 우리 삶을 혁신적으로 바꾸고 있는 스마트-X 산업은 IoT 데이터 폭증이라는 또 다른 도전을 우리에게 던져주고 있는 상황이다. 이러한 문제를 해결하기 위해 탄생한 마크베이스의 시계열 데이터베이스(TSDB)는 지난 2019년 이후 3년 연속 국제성능평가협회인 TPC에서 IoT 부문 1위를 매년 갱신하면서 IoT 데이터 처리의 세계 최강자임을 증명해오고 있다.

 

이 글에서는 지구상의 다양한 산업계 중에서도 가장 많은 IoT 데이터를 생산해 내는 반도체 분야의 대규모 데이터 실시간 처리 기술을 통해, 상상을 넘어선 그 성능이 어디까지 도달했는지에 대한 성과를 생생하게 확인할 수 있다. 폭증하고 있는 IoT 데이터의 처리에 대한 고민과 더불어 이에 대한 새로운 해결책을 찾는 분들께 희망찬 소식이 될 수 있기를 희망한다.

 

Smart-X 시대 : IoT 데이터의 폭발적 증가

 

1. 데이터 증가 원인

우리는 현재 IoT 센서 데이터를 분석해 인공지능(AI)을 이용하는 시대에 살고 있다. IoT 센서 데이터란 온도, 습도, 전류, 전압, 진동과 같이 우리의 일상 속에 공기처럼 존재하는 수많은 데이터를 의미한다. 이러한 스마트-X 시대에서 발생하는 센서 데이터의 양은 가히 폭발적이다. 그 원인을 크게 세 가지 측면에서 살펴볼 수 있다.

 

첫 번째는 하나의 센서가 하나의 데이터만 처리했던 과거와는 달리 요즘에는 다양한 종류의 데이터를 생성하고 있다. 두 번째는 우리가 사는 세상이 스마트해지면서 도시, 건물을 비롯해 물류, 집, 자동차 등에 센서가 설치되면서 센서의 개수 자체가 많아지고 있다. 마지막으로 기업에서 AI를 가동하기 위해서는 데이터를 수집하여 분석하고 예측을 통한 위험 방지를 해야 하는데, 이 과정에서 엄청난 양의 데이터가 쌓이는 것이다.

 

데이터와 비즈니스 위협 : IoT 데이터 처리 한계

 

이처럼 폭증하는 데이터를 적절하게 처리하지 않을 경우 실제로 맞닥뜨리는 비즈니스 현장의 큰 문제는 다음과 같다.

 

1. 실시간 저장 불가

첫 번째 문제는 발생하는 데이터를 실시간으로 저장하지 못한다는 것이다. 실시간으로 발생하는 데이터 중 일부 데이터만 저장하게 될 경우 데이터 유실이 발생하게 된다. 이는 추후 문제가 생겼을 때 정확한 원인 파악이 불가능하다.

 

2. 실시간 추출 불가

대량의 시계열 데이터를 실시간으로 저장하기 위해서 텍스트 파일 형태로 저장하는 경우도 많다. 그런데 만약 텍스트 파일 형태로 저장을 하게 되면 특정 일자에 대한 데이터 분석을 요청할 경우, 데이터를 추출해서 분석하는데 많은 시간이 소요된다. 이렇게 데이터 발생 시점과 데이터 분석 시점 간의 시간적 갭이 발생하게 되면 그만큼 빠른 대응을 할 수 없기 때문에 산업 현장에서는 엄청난 손실이 아닐 수 없다.

 

3. 실시간 확장 불가

데이터가 계속 축적되어 가면서 스토리지 확장을 해야 하는 경우가 발생한다. 이때 실시간 확장이 어려울 경우 과거 데이터를 삭제하고 최근 데이터를 저장해야 되는데, 이는 과거 데이터에 접근할 수 없기 때문에 장기적인 분석이 불가능해진다.

 

 

IoT 데이터 전쟁의 서막

 

그리하여 IoT 시장에서의 데이터 전쟁이 시작됐다. 누가 가장 빨리 그리고 효율적으로 폭증하는 데이터를 처리하느냐가 전쟁에서의 승패를 가늠하는 중요한 잣대가 된 것이다. 이 IoT 데이터 전쟁에서 승리하기 위해 뛰어든 주요 도전자를 살펴보자.

 

1. RDBMS

RDBMS는 IoT 데이터 처리를 위한 기존 솔루션 중 가장 오래되고 전통적인 데이터베이스다. 대부분의 IT 관련자가 학교에서 혹은 기업에서 사용하고 배우는 거의 모든 데이터베이스가 이 종류다. 대표적으로 오라클, MySQL, MariaDB, MS-SQL 등이 있다. 이러한 RDMBS의 익숙함에도 불구하고 오늘 IoT 데이터를 처리하기에는 많은 제약 사항이 있다.

 

RDBMS는 금융 거래 트랜잭션을 목적으로 개발되었다. 예를 들면 은행의 송금 혹은 비행기 예약과 같은 복잡하고, 어려우면서 연속적인 비즈니스 업무를 하나의 온전한 업무 단위로서 처리하기 위해 고안된 기술인 것이다.

 

이 비즈니스 환경에서는 처리의 신뢰도가 매우 중요하기 때문에 데이터의 처리 비용과 관계없이 이론적으로 완벽하게 보장되는 방향으로 기술개발이 이루어졌다. 따라서 현재의 하드웨어 성능으로는 초당 수백 혹은 수천 건을 처리하는 것이 그 한계이다. 이러한 트랜잭션을 지원하기 위해서, RDBMS는 아래와 같이 성능을 희생하는 큰 비용을 지불하고 있다.

 

첫째, 연산 복구비용이다. 트랜잭션의 중요한 속성 중 하나로 원자성(Atomicity)을 들 수 있는데, 이는 수행 중인 트랜잭션은 완벽하게 끝나거나, 혹은 수행되기 이전의 상태로 완벽하게 복원이 되어야 한다는 것이다. 트랜잭션의 중간 상태는 존재할 수 없는데, 이를 위해서 RDBMS는 모든 트랜잭션의 변경 연산(입력, 수정, 삭제)에 대해서 로그(Log)라는 2차 저장 매체에 기록을 수행한다.

 

사용자가 특정 데이터를 입력하면, 단순히 데이터를 입력하는데 그치는 것이 아니라, 그 데이터가 저장되는 데이터 파일의 변경된 영역을 기록하고 그 데이터를 가리키는 인덱스의 변경 부분도 기록한다. 만일 생성된 인덱스가 10개라면, 10개 모두에 대한 변경 내역을 기록한다. 즉, 배보다 배꼽에 더 큰 경우가 발생하는데, 검색 성능을 높이기 위해 다양한 인덱스를 생성하면 할수록 입력 성능이 떨어지는 트레이드오프(Trade-off)가 발생한다. 이러한 로깅 비용이 전체 데이터베이스 성능을 저하 시키는 가장 중요한 이유이다.

 

둘째, 잠금(Locking) 비용이다. 실제 데이터베이스에서는 하나의 트랜잭션은 다수의 테이블에 대해서 접근하고, 그 트랜잭션이 동시에 여러 건 수행되어야 한다. 이러한 환경에서 높은 동시성을 제공하고, 잠금으로 인한 교착상태(Deadlock)를 방지하기 위해, 매번 모든 데이터 접근에 대해서 이 잠금을 수행하게 되는데, 이 비용이 매우 크다. 특히 대부분의 RDBMS는 테이블 단위가 아닌 레코드 단위의 잠금을 지원하기 때문에 내부적으로 복잡하고, 높은 비용의 잠금 비용을 지불해야 한다.

 

셋째는 일반화된 데이터 저장 구조 및 인덱스 구조의 복잡성으로 인한 비효율성이다. 앞에서도 잠깐 언급한 바와 같이 트랜잭션 기반의 RDBMS는 느릴 수밖에 없는 한계를 스스로 인식하고 이를 극복하기 위하여 노력하여 왔다. 그리고 그 결과로 데이터베이스는 매우 복잡한 구조로 진화하였다.

 

특히 당시에는 하드디스크가 가장 대중적인 저장매체였기 때문에 읽기 성능을 향상시키기 위해 디스크 관리자, 버퍼 관리자 등을 통해서 최악의 상황에서도 나름 평균적인 성능을 보장하도록 설계하였고, 이로 인해 전체적인 코드의 복잡성이 더 커진 것이다. 이 복잡성은 단순한 연산(입력)에 대해서도 복잡한 내부 로직을 수행할 수밖에 없는 구조적인 한계를 가지게 되었다.

 

이러한 이유로 인해서 IoT 데이터의 입력 성능이 최대인 경우라도 초당 수천 건으로 제한될 수밖에 없고, 더 큰 문제는 저장된 대규모의 데이터에 대해(예를 들어, 수억 건) 질의를 수행하면 때때로 대답 없는 함흥차사가 되어 개발자를 괴롭히는 원흉이 되어버린 것이다.

 

2. Hadoop

하둡은 구글의 내부 데이터 처리 엔진인 빅테이블과 동일한 자바 기반의 오픈소스 버전이라고 정의할 수 있다. 하둡은 빅데이터 문제를 해결하기 위해, 저렴한 다수의 PC를 조합해서 가상의 디스크를 구성하고, 각각의 PC가 병렬로 일하게 만들면 1년 걸릴 작업을 하루 만에 할 수 있게 된다. 이를 위해 하둡이 개발되었고, “빅데이터 솔루션”이라는 별명을 가지게 되었다. 하둡이 바라보는 데이터에 대한 철학은 이렇다.

 

“모든 데이터는 완벽한 비정형 텍스트 데이터이다. 따라서 이런 데이터를 분석하기 위해서는 모두 읽어서 처리하는 순차적 방식으로 할 수밖에 없고, 빠르게 하기 위해서는 동원할 수 있는 모든 하드웨어를 병렬로 수행해야 한다.”

 

즉, 하둡에서는 데이터 분석에 필요한 전략이 그냥 모두 읽는 것이고, 컴퓨터 개수를 필요한 만큼 늘려서 성능을 높이라는 것이다. 여기에 활용되는 알고리즘이 우리가 잘 알고 있는 맵리듀스(Map-Reduce)이고, 기반이 되는 하둡 파일 시스템(Hadoop File System)이라는 공유 파일 시스템이다.

 

하둡의 장점은 오픈소스라서 무료라는 점, 그리고 누구나 설치하여 사용할 수 있으며, 빠른 빅데이터 처리 속도를 제공한다는 것이다. 더구나 RDBMS처럼 SQL도 사용할 수 있다고 하니 사용자들에게는 좋은 선택지였다. 반면 단점도 여러 가지 존재한다.

 

첫째, 하둡은 최소 4대 이상의 클러스터로 구성해야 한다. 빅데이터 서비스를 하기 위한 포털 수준의 기업이라면 확장성(Scale-out)과 고가용성(High Availability)을 고려해야 한다.

 

둘째, 모든 처리할 데이터를 하둡 파일 시스템에 저장하도록 되어 있으며, 파일의 부분 변경이 불가능하다. 즉, 정교한 데이터 처리를 위한 세밀한 조작이 불가능한 것이다.

 

셋째, 데이터 분석을 위해 기본적으로 맵리듀스를 수행하게 되며, 이는 클러스터 준비시간에만 몇 초 이상의 시간이 걸린다. 다시 말해 데이터양이 적어도 절대적인 처리 시간이 필수적이라는 것이다.

넷째, 동시 사용자 처리가 거의 불가능하다. 기본적으로 하둡은 단일 사용자를 기준으로 모든 데이터를 검색하는 구조이다. 다수의 사용자가 동시에 맵리듀스를 수행하는 것은 시스템 재난 수준의 부하를 생성시키는 것이다.

 

다섯째, 생각 외로 높은 비용이 든다는 점이다. 많은 기업고객이 라이선스가 무료라고 도입했다가 유지보수에 들어가는 높은 비용에 놀라는 경우가 많다. 그 이유는 이 하둡이라는 생태계의 복잡성에 기인한다. 최소한 10개 이상의 오픈소스 스택을 설치해야 할 뿐만 아니라, 장애가 발생했을 때 그 원인과 대처 방법을 찾기가 쉽지 않다.

 

이런 사실을 통해 실시간으로 처리해야 하는 센서 데이터 영역에서 하둡을 도입하는 것이 매우 어렵다는 것을 이해할 수 있을 것이다.

 

3. No-SQL

No-SQL이라는 용어는 ‘Not Only SQL’이라는 의미로 관계형 처리 언어인 SQL이 지원되지 않는 새로운 DBMS라는 뜻을 담고 있다. 가장 유명한 제품이 카산드라(Cassandra)와 인 메모리(In-Memory) 기반의 키-밸류 데이터베이스(Key-Value Database)인 레디스(Redis)일 것이다.

 

NoSQL은 세상의 모든 데이터가 유일키(Unique Key)를 가지고 있으며, 이 유일 키를 기반으로 나머지 데이터가 연결되어 있다고 본다. 이런 세상에서 NoSQL이 가장 잘할 수 있는 영역으로 객체 인증 혹은 데이터 캐시 서비스를 들 수 있겠다.

 

세상을 이렇게 유일키를 가진 대상으로 보게 되면, 이에 따라오는 소프트웨어적인 장점이 있는데, 바로 확장성과 고가용성이다.

 

확장성 관점에서는 모든 데이터(혹은 엔트리)에는 반드시 유일키가 존재하기 때문에 자신이 속할 서버를 쉽게 지정할 수 있고, 이 서버의 개수를 무제한으로 늘림으로써 사용자 요청의 증가에 대한 유연한 대처가 가능하다.

 

고가용성 관점에서는 자신의 데이터를 두 개 이상의 서버에 복제해 둠으로써 만일 하나의 서버에 장애가 발생하더라도 나머지 서버가 대신할 수 있도록 하여, 장애에도 큰 어려움 없이 서비스를 수행할 수 있다.

 

이러한 장점에도 불구하고, NoSQL은 센서 데이터 처리를 위해서 몇 가지 약점이 존재하는데, 이것이 왜 Key-Value 데이터베이스가 센서 데이터 처리에 부적합한지에 대한 이유일 것이다.

 

첫째는 집계 함수(Aggregation)를 사용하기가 힘들다는 점이다. 통계를 얻기 위해 다수의 유일 키를 조합하는 경우에는 사실상 불가능한 경우가 많다. 예를 들어 특정 주소를 가진 사용자들의 평균 나이를 구한다고 생각해보자. 데이터가 주민등록번호를 기준으로 서버에 분산되어 있기 때문에 모든 데이터를 검색하는 것 외에는 방법이 없다. 이는 2차 인덱스 생성이 불가능하기 때문이다.

 

둘째는 시계열 데이터 저장이 구조적으로 용이하지 않다. 센서의 태그 번호를 기준으로 서버에 저장하는 것은 좋은 전략이지만, 구조적으로 센서의 시계열 데이터 처리는 쉽지 않다. 하나의 센서가 하나의 키를 가진다고 볼 때, 해당하는 센서의 데이터를 시간으로 계속 추가하면서 변경하게 되고 결과적으로 하나의 레코드 크기가 수십 기가가 될 수도 있다.

 

셋째는 시계열 데이터의 추출이 매우 느리다는 것이다. 위의 방법대로 센서 데이터를 저장했다고 하더라도 해당 컬럼에 시간 및 값이 쌍으로 연결된 수백만 개의 연속된 데이터가 있을 때, 이를 시간 범위로 추출하기 위해서는 선형적으로 탐색해야 하는 문제가 존재한다. 설상가상으로 만일 입력되는 특정 태그의 시간이 역전된다면 추출한 이후에 다시 정렬해야 하는 상황도 발생하기 때문에 최악의 경우 아무것도 할 수 없는 지경에 이르게 된다.

 

이렇듯 다양한 데이터베이스 엔진들은 각각의 목적이 있다. 과거 범용적인 목적에서 2010년대 이후부터 전문화 되고 있는 중이다. 이때 새로운 데이터베이스가 등장한다.

 

시계열 데이터베이스의 출현과 세계 1위 마크베이스

 

1. Global DBMS Trend

그림 1은 DB-Engines.com라고 하는 글로벌 데이터베이스 트렌드 사이트의 지표다. 여기에서 2019년부터 2021년도까지 전 세계에서 많이 찾는 데이터베이스 트렌드가 바로 시계열 데이터베이스라는 것을 확인할 수 있다. 다른 DB와 비교해서 관심도가 월등하게 높은 메가트렌드인 것이다. 시계열 데이터베이스가 주목받는 이유는 머신러닝, AI 등에 전문적으로 적용하기 위한 기업들과 다양한 데이터 처리에 어려움을 느끼는 엔지니어들의 니즈에서 기인한다.

 

 

2. TPCx-IoT 세계 1위 DBMS

TPC(국제성능평가협회)는 IoT 데이터 처리를 위한 TPCx-IoT라는 벤치마크를 도입하였는데, 여기에서 마크베이스가 2019년도부터 3년 동안 세계 1위를 기록 하고 있다. 마크베이스는 TTA와 함께 벤치마킹을 수행해 3년 연속 매년 1위를 갱신하며 1위뿐만 아니라 2위, 3위, 5위까지 랭크 중이다(표1). 시스템 소프트웨어 분야에서 마크베이스가 유일하다. 이전에는 Cloudera의 Hbase, 하둡이 IoT 데이터 분야의 1위를 기록 하고 있었지만, 현재는 마크베이스가 압도적인 성능으로 1위를 차지하고 있다.

 

 

3. TSDB 세계 1위, 한국의 마크베이스

마크베이스는 한국에서 개발된 시계열 데이터베이스 제품이다. 초고속으로 시계열 데이터를 저장, 추출, 분석하기 위한 목적으로 개발되었다. 특히, 마크베이스는 고성능의 데이터 처리를 목적으로 하기 때문에 컴파일 언어인 C를 기반으로 개발되었고, 전통적인 데이터베이스 엔진의 구조와는 차별화되는 새로운 아키텍처로 설계되었다.

 

그러나 기존의 데이터베이스 사용자가 쉽게 배우고, 활용할 수 있도록 사용성 측면에서는 전통적인 데이터베이스 인터페이스를 그대로 유지하고, 내부 엔진은 시계열 데이터베이스를 고속으로 처리할 수 있는 혁신적인 구조로 설계되었다.

 

따라서 오라클 혹은 MySQL에서 활용하던 익숙한 인터페이스인 SQL 및 ODBC, JDBC, Restful API 등을 그대로 사용할 수 있으며 저장된 시계열 데이터에 대해서는 기존 데이터베이스보다 월등한 성능으로 처리할 수 있는 특징을 가지게 되었다.

 

특히 마크베이스 시계열DB는 IoT 센서 데이터에 최적화 되어 있다. IoT에 특화되었다는 것은 센서가 ID, Time, Value로 구성돼 있는데, 이 데이터를 빠르고 쉽게 압축해서 저장할 수 있는 테이블을 별도로 제공한다는 의미다. 이러한 이유로 글로벌 메가트렌드인 시계열DB 분야에서 한국의 마크베이스가 글로벌 기업을 제치고 1위를 기록한 것이다.

 

IoT Data Lake 구성에 최적화된 ‘마크베이스 클러스터 에디션’

 

1. 마크베이스 클러스터 에디션

마크베이스는 데이터 처리 한계에 도전하기 위해 클러스터 에디션(Cluster Edition)이라는 제품을 개발하였다. 클러스터 에디션은 생성 속도와 규모를 예측하기 어려운 산업용 사물 인터넷을 위해 유연한 확장성을 제공하는 제품이다.

 

클러스터 에디션의 특징은 크게 5가지가 있다.

 

· 선형적 확장

· 고가용성

· 고성능 입력

· 고성능 추출

· 서버에서 장애 발생 시 데이터 유실 방지

 

2. 클러스터 아키텍쳐

그림 2와 같이 클러스터의 구조는 의외로 심플하다. 클라이언트가 SQL 메시지를 처리할 때 작업을 하는 Broker Node가 있고, 그 뒤에 실제로 데이터를 저장하는 다수의 Warehouse가 있다. 그래서 확장을 하게 되면 Warehouse가 계속 늘어나게 된다. 이 전체가 하나의 데이터베이스처럼 동작하고 실제로 오라클이나 MS-SQL 쓰는 것처럼 SQL92가 제공되는 것이다.

 

 

반도체 분야의 대규모 데이터 실시간 처리 기술

 

지금부터는 이 클러스터 에디션을 통한 반도체 분야의 대규모 데이터 실시간 처리 기술 데모를 보며 상상을 넘어선 그 성능이 어디까지 도달했는지에 대한 성과를 확인해보고자 한다.

 

많은 IoT 데이터들이 통신, 금융, 제조 등 여러 분야에 있지만 그중에서 반도체 공정 데이터를 선택한 이유는 태그 데이터 또는 센서 데이터라고 하는 IoT 데이터들이 가장 많이 발생하는 곳이 반도체 공정이기 때문이다.

 

특히나 반도체 제조 기업들은 불량이 나게 되면 수천억의 손해가 발생하다 보니 수율 향상을 위해 많은 비용을 투자하고 있다. 다양한 방법들을 강구하고 있으며 복잡한 공정을 관리하기 위한 모니터링 및 시스템을 도입하여 데이터를 빨리 처리할 수 있는 부분이 필요한 영역이다. 반도체 관련 공개된 데이터와 실제 현업에서 만난 반도체 기업의 관련 정보를 통해 시뮬레이션을 한 것이다.

 

물리적인 하드웨어는 AWS EC2 인스턴스를 이용하여 시연 환경을 구성하였다. 마크베이스 BROKER 노드를 위한 3개의 인스턴스와 데이터 저장을 위한 WAREHOUSE 노드를 위한 20개의 인스턴스를 생성하였고 각각의 인스턴스 사양은 표2와 같다.

 

 

마크베이스 클러스터는 총 6개의 BROKER 노드, 60개의 WAREHOUSE GROUP으로 구성하였다. 각 노드에 대한 관리 및 모니터링을 웹기반의 Cluster Admin 화면에서 확인할 수 있다. 그림 3과 같이 각 노드별 CPU, MEMORY, Network, Disk 사용량에 대해서 확인할 수 있고 각 인스턴스별 노드 구성 현황에 대해서 쉽게 확인할 수 있다.

 

 

반도체 공정 시뮬레이션 조건은 300대의 설비가 있고, 설비당 1000개의 센서가 있어서 전체 30만 태그가 있다. LOT당 25개의 웨이퍼 공정이 있으며 데이터 생성 프로그램이 최대한 입력 가능하게 데이터를 시뮬레이션해서 생성하여 전송한다.

 

 

이러한 환경에서 데이터 입력을 수행한 결과 초당 1억 건의 데이터를 안정적으로 입력하였다.

입력이 진행되는 동안 최대 초당 107,778,022 건을 입력하였다. 그림 4에서 초당 입력 건수 차트인 EPS Chart를 보게 되면 데이터 입력 속도가 큰 편차 없이 거의 일정하게 유지되는 것을 볼 수 있다(그림 5).

 

 

약 3천억 건의 데이터가 입력된 상황에서 초당 1억 건씩 데이터를 입력하면서 데이터를 조회하였다. 센서 데이터이므로 데이터를 추출하여 차트 형태로 가시화해서 표시하게 되는데 이때 데이터 추출에 걸리는 반응 속도가 빨라야 업무를 진행함에 있어 불편함이 없게 된다.

 

마크베이스 클러스터를 구성하여 데이터 입력과 데이터 추출 성능을 알아본 결과 초당 1억 건의 데이터를 빠르고 안정적으로 입력하면서 동시에 수백 만 건의 데이터를 추출하더라도 수 초 이내 조회가 가능한 것을 확인하였다.

 

· IoT 데이터 처리 Game Changer

· TPC 세계 1위의 초당 처리량 성능과 안정성 검증

· 순수 국내 기술로 설계/개발 → 책임 있는 기술 지원 가능

· ESG 시대에 맞는 초고효율 솔루션

· 타 솔루션 대비 탁월한 TCO 보장

 

마무리

 

마크베이스는 IoT 데이터 처리 관점에서 기존의 솔루션으로 성취 불가능한 성능을 달성했기에 IoT 데이터 게임의 룰을 바꾸는 ‘게임 체인저’라고 볼 수 있다. 새로운 제품이라 안전성이나 다른 문제가 있다고 생각할 수 있지만, 이미 마크베이스는 TPC 세계 1위의 초당 처리량 성능과 안정성이 검증된 상품이며 이미 국내의 많은 대기업들이 사용하고 있다. 또한, 순수 국내 기술로 개발되었기 때문에 고객의 문제를 최상의 소스 레벨에서 해결하고 기능을 개발할 수 있는 역량도 가지고 있다.

 

마지막으로 마크베이스는 ESG 시대에 맞는 초고효율 솔루션을 제공하고 있다. 데모할 때 20대로 1억 건의 데이터를 처리했는데 만약 천만 건만 필요하다면 3-4대, 백만 건만 필요하다면 Fog로 1대 하더라도 충분히 빠른 속도를 구현한다. 이렇게 데이터를 해결하는 것이 훨씬 더 높은 TCO(총소유비용, Total Cost of Ownership)를 보장하는 것이다. 따라서 기업에서 IoT Data Lake 구축할 때 마크베이스를 이용한다면 분석가 혹은 데이터를 서비스하는 곳에서 훨씬 빠르게 데이터를 처리할 수 있다.