마크베이스 대표 김성진
이 글이 처음이신 분은 아래 글을 읽으시고, 다시 방문하시는 것을 권장드린다.
들어가며
이 글에서는 실제 마크베이스가 구현한 실제 동작하는 "마이크로 데이터레이크"와 그 관련된 아키텍처 구성요소에 대해 설명하고자 한다. 실제 이를 활용한 고객의 사례를 기술하면 가장 좋은 것이겠으나, 보안 및 관련 정보 유출에 대한 제약으로 이는 불가능하게 되었다. 이 대신에, 유사한 구조의 "마이크로 데이터레이크"를 구축한 실제 동작 중인 곳을 대상으로 삼아 향후 설명하고자 한다. 그리고, 실제 사례를 살펴보기 이전에 데이터레이크 구축을 위해 어떠한 기술을 채택하였고, 어떠한 사실을 근거로 구현하였는지 그 부분에 대해 심도있게 알아보자.
에지에서의 핵심 데이터 처리 기술 - 시계열 데이터베이스 : 마크베이스 네오
이제 가장 핵심 주제에 도달한 것 같다. 앞 시리즈에서 언급한 바와 같이 "에지 장치"는 하드웨어 리소스의 제약 상황에서도 대용량의 실시간 데이터 처리가 가능해야 한다고 이야기한 바 있으며, 이것이 거의 실현 가능성이 없기 때문에 대부분의 데이터를 클라우드(혹은 서버)에서 통합 관리하는 모델이 주류가 되었을 것이라고 추측한 바 있다.
우선 마크베이스에서는 자체 개발한 시계열 데이터베이스 엔진이 이러한 제약에도 불구하고, 데이터레이크의 성능을 지원할 만한 충분한 성능과 기능을 제공하고 있기에 이를 가장 핵심 데이터 처리 SW로 삼았다. 그렇다면, 마크베이스 시계열 데이터베이스는 에지 장치에서 얼마나 우수한 성능을 제공하는 걸까? 이를 이해하기 위해서 아래와 같은 다양한 에지 장치에서 테스트화고, 성능을 수치화하였다. 물론, 최근 에지 장치 혹은 에지 서버의 스펙이 많이 높은 관계로 인해 이 성능보다는 몇배이상 더 높은 수치를 제공할 수 있을 것이라는 예측을 할 수 있을 것이다.
에지 하드웨어에 따른 성능 비교
아래는 몇가지 낮은 사양의 에지 장치로부터 어느정도 성능이 보장된 에지 장치까지의 간략한 스펙과 데이터 처리 성능 자료이다.
여기에서 INSERT는 해당 에지 장치의 최대 성능을 측정하기 위해 100%의 CPU와 I/O를 활용하도록 뽑아낸 수치이고, SELECT는 모든 레코드가 입력된 상태에서 일반적인 센서 데이터 8만건을 특정 시간 범위에서 추출하는 성능을 측정한 것이다.
(참고로 실제 에지 서버의 경우 IPC 즉, 산업 환경을 위한 PC(Industrial PC)로 정의되어 다양한 제약 조건을 만족하는 형태로 현장에서 오랫동안 높은 내구성으로 동작하도록 구축된다. 아래의 에지 장치는 그러한 IPC 형태는 아니라는 것을 미리 알리며, 그럼에도 불구하고 에지 장치 성능에 대한 개략적인 감을 가지는데 도움이 될 것이다)
장치종류 | CPU / OS | Memory | Insert Performance (TPS) | Total
Count
(저장공간)
| Select Performance (8만건 추출) (단위 초) |
TURCK IM18-CCM60 (eMMC) | ARM (32bit) 1 core (LINUX) | 1GB | 41,582 | 0.1억건 (44MB) | 0.06 |
Raspberry Pi4 (*USB SSD) | ARM (64bit) 4 core (LINUX) | 8GB | 199,547 | 1억건 (500MB) | 0.04 |
vRaptor PEC (SSD) | ARM (64bit) 24 core (LINIUX) | 16GB | 492,219 | 10억건 (4.5GB) | 0.048 |
ODROID-M1 (SSD) | ARM(64bit) 4 core (LINUX) | 8GB | 809,644 | 3,133억건 (1.8TB) | 0.021 |
ODROID-H3 (SSD) | INTEL(64bit) 4 core (LINUX) | 8GB | 2,317,972 | 1조건 (3.5TB) | 0.015 |
위에서 저장소의 경우 eMMC 혹은 SSD를 활용하였으며,, 라즈베리파이의 경우 직접 장착이 어려워 USB 3.0 케이블을 통해 외부 SSD 저장소에 데이터를 저장한 것이다. (그래서 입력 성능이 오히려 낮았다. 만일 직접 PCI를 통해 연결된 SSD라고 하면, 2~3배 이상의 성능 향상을 기대할 수 있다)
데이터 스키마
3개의 기본 센서 데이터 컬럼으로 구성하였다.
CREATE TAG TABLE tagtbl (name VARCHAR(20) PRIMARY KEY, time DATETIME BASETIME, value DOUBLE SUMMARIZED)추출 질의
전체 데이터 세트에서 (0.1억건, 1억건, 1조건) 특정 센서에 대해 30분간의 데이터 8만건을 추출한다.
select count(*) from (select * from tag where name = 'EQ0^TAG1' and time between to_date('2019-01-01 00:00:00') and to_date('2019-01-1 00:30:00'));에지 장치 설명
위에서 한눈에 볼 수 있도록 성능을 정리하였으며, 이해를 돕기 위해 활용된 하드웨어 장치를 간략히 설명하도록 하겠다.
이 장치는 독일 터커에서 개발된 작업 현장 캐비넷 내부에 설치되어 관련 데이터를 수집/모니터링하는 용도의 초소형 에지 장치다. 얼마나 초소형인가하면, DBMS가 설치되어 동작하는 것을 가정하지 않았기에 느린 ARM CPU 1개가 설치되고, 내부 메모리도 1GB에 불과하다. 또한, 운영체제도 수정된 리눅스의 32비트 모드이고, 저장공간도 모두 합쳐 8GB 정도인데, 마크베이스를 이곳에 쑤셔(?) 넣어 에지 장치로 활용한 바 있다. 그럼에도 불구하고, 초당 4만건 이상의 센서 데이터를 수집하고, 실시간으로 추출도 가능했다. 이곳이 마이크로 데이터레이크라고 부르기에는 너무 작기는 하지만, 가장 열악한 하드웨어 대비 성능을 측정하기 위한 좋은 케이스이다.
너무나도 잘 알려진 소형 에지 장치의 전형이라고 할 수 있는 물건이다. 실제로 많은 곳에서 테스트 용도 뿐만 아니라 실제 필드에서도 활용하는 만큼 여러가지 면에서 자료도 많고, 활용할 수 있는 여지도 많다. 그런 이유로 마크베이스도 이 장치 기반으로 데이터베이스를 설치하고, 각종 테스트를 수행하였다. 특히 최근에는 우분투와 같은 리눅스 패키지도 잘 설치되고, 관련 리소스도 풍부하여 향후 저장 공간 이슈와 외부 케이스 문제만 잘 해결하면, 정말 낮은 비용으로 고도의 마이크로 데이터레이크를 구축할 수 있다.
한가지 아쉬운 점은 디폴트 저장공간인 microSD의 경우 너무 신뢰성이 낮아 데이터베이스와 같은 I/O intensive 프로그램을 사용할 경우 1년내에 디스크가 망가지기 때문에 SSD를 제대로 장착하기 위해 별도의 HW 구성을 해야 한다는 점이다. (관련 HW 모듈이 존재한다)
V-Rator는 국내 기업인 액세스랩에서 개발된 ARM 기반의 소형서버이며, 다양한 제품라인을 보유하고 있다. 테스트를 수행한 본 서버는 core가 무려 24개임에도 불구하고, 가격과 성능에서는 꽤 괜찮은 수준으로 제품이다. 최근에는 V-Rator SQ Nano 라는 깜찍한 서버군의 제품으로 함께 제공하고 있다. 코어 수가 많은 반면 코어 자체의 성능이 1GHz 정도라 단일 세션의 고속 프로세싱이 필요한 작업의 경우 약간의 인내심이 필요하다. ARM 서버의 특성상 냉각팬이 없고, 저전력으로 장기간 높은 내구성을 자랑하기 때문에 인텔 서버의 대안으로 많은 관심을 끌고 있다.
한국기업인 하드커널에서 제조하고 있는 라즈베리 파이와 같은 종류의 소형 에지 장치이다. 하드웨어 스펙은 거의 라즈베리파이 4와 유사하지만, 오히려 저렴한 가격으로 관련 서비스를 구축할 수 있고, 관련 정보도 풍부하다는 것을 알게 되었다. 또한, 내장 SSD 설치도 매우 편리하기 때문에 마크베이스의 성능 테스트를 수행할 때 삼성의 SSD를 설치하여, 직접 구동할 수 있었다. 한가지 아쉬운 점은 ARM CPU의 성능이 조금 낮다는 것인데 이는 장기간의 제품 공급이 가능한 Rockchip을 선택했기 때문에 상대적으로 클락이 낮다고 알려졌다. 낮은 성능의 CPU로 인해 진동 데이터와 같은 대규모의 실시간 데이터 추출에는 맞지 않지만, 그 외의 일반적인 센서 데이터 수집과 활용에서는 대단히 탁월한 성능과 안정성을 보여준다.
위의 M1과 같은 동일한 회상에서 인텔의 셀러론 기반으로 출시된 에지 장치이다. 인텔 CPU와 관련 보드의 특성으로 인해 전력 사용량은 상대적으로 높지만, 전체적인 데이터 처리 성능 또한 ARM과 비교하기 힘들 정도의 높은(?) 벤치마크 성능을 보여준다. (그래서인지, 냉각 팬도 장착되어 있다)
삼성 SSD를 PCIe를 통해 장착하고, 데이터를 고속으로 입력할 경우 초당 2백만건 이상의 성능을 기록했고, 장기간의 데이터 1조건의 입력과 데이터 추출시에도 고속으로 0.1초 미만으로 데이터가 검색되는 가공할 성능을 자랑한다.
그렇지만, 실제 현업에 설치되는 장치의 경우 레노보의 ThinkEdge 시리즈 혹은 어드밴텍 IPC 시리즈와 같은 완제품이 많이 활용되며, 최소한 오드로이드-H3 이상의 성능은 보장된다고 판단하면 될 것이다.
시계열 데이터베이스가 마이크로 데이터레이크의 핵심 저장소로서 충분?
전 시리즈에서 언급한 바와 같이 "특수목적성"을 고려하여, 대규모의 센서 데이터 처리를 위한 공간으로서 비지니스 범위를 고려한다면, 시계열 데이터베이스는 그 자체로 이미 "마이크로 데이터레이크" 로서 충분한 자격을 갖췄다고 봐도 무방할 것이다.
대략 1000억건의 센서 데이터를 저장하는데 실시간 압축을 통해 512GB의 적은 저장 공간이면 충분하고, 8GB 메모리, 4~8 Core의 리소스로서 초당 수십만건의 데이터 입력을 처리할 수 있기 때문이다.
이 정도의 성능과 리소스 활용량을 클라우드 서비스 사업자의 특정 서비스를 활용하다고 가정하면, 그 저장소 관리 비용은 상상 이상으로 많이 발생하고, 이후의 데이터 활용을 위한 실시간 데이터 추출과 가공에 들어가는 향후 API 비용도 고려하면, 얼마나 이 구조가 경제적인지 다시 한번 깨달을 수 있다.
(1000억건이 얼마나 큰 숫자인지 생각해 보면, 초당 1000건의 데이터를 쉬지 않고 저장했을 때 3년동안 발생하는 데이터의 총합인데, 이 규모의 데이터가 꼴랑 512GB의 저장공간에 모두 들어간다!!)
핵심 저장소로서는 충분하지만 마이크로 데이터레이크의 다른 기능은?
지금까지의 내용을 기반으로 시계열 데이터베이스가 데이터 저장 공간으로서의 탁월한 위치는 인정하더라도 실제 데이터레이크가 가지고 있는 많은 기능들 그리고, 구축을 위한 제약 사항은 어떻게 지원해야할까?
가장 대표적인 예들 들면, 1) 에지에서 지정된 일부 데이터를 실시간으로 서버로 전송하는 기능일텐데, 이 기능을 위해 사용자가 매번 관련 코드를 구현하고, 검증하기에는 너무 복잡하고, 어려운 기능일 것이다. 또한, 2) 양쪽 Tier의 통신에 있어서 데이터가 암호화되어 보안성이 검증되는 문제라든가 3) 수십개의 에지를 원격으로 조작하고, 관리하고, SW를 업데이트 하는 등의 작업 역시 "마이크로 데이터레이크" 라는 서비스의 일부로서 존재해야 전체적인 그림이 완성된다.
그런 이유로 마크베이스에서는 CEMS(Cloud-Edge Mamagement Solution)라고 불리는 "에지 컴퓨팅 데이터 인프라 솔루션"을 개발하였으며, 마이크로 데이터레이크 구축에 활용하고 있다. 그러나, 이 글의 목적상 이 제품의 기능이나 스펙은 건너뛰고 , 대신 에지 장치에서의 "데이터레이크"가 어떻게 구현되고, 동작하는지에 포커스를 맞춰 집중적으로 설명하도록 하다.
요구 기능 분석표
이제 지금까지 이야기해 왔던 "마이크로 데이터레이크"에 대한 많은 요구사항들이 실제로 마크베이스에서 만족되고, 구축이 가능할지에 대해 기술적으로 파악해보도록 하자. 에지 장치에서 "대용량 센서 데이터 처리 데이터레이크"를 구축하는 특수한 목적이 있다고 가정한다.
분석 상세
아래는 요구되는 일반 사항들에 대해 어떻게 이를 지원할 것인지에 대한 기술적인 내용이다.
요구 사항 항목 | 구축 기술 상세 |
HW 요구사항 | 마크베이스 NEO의 지원 HW 스펙 만족 (ARM, Intel, 소형 리소스 기반 다양한 운영체제 에서의 데이터 처리 기술 지원) |
정형 센서 데이터 처리 | Tag Table 활용 |
센서 데이터 수집 성능 - 저장 성능 | 초당 4만건에서 최대 2백만건 까지 가능 |
센서 데이터 수집 성능 - 인덱싱 성능 | 초당 2백만건의 실시간 인덱스 구축 성능 가능 |
센서 데이터 수집 성능 - 압축 성능 | 최대 100배까지 실시간 데이터 압축 (평균 센서 데이터 포인트당 4.5 ~7 byte 차지) |
센서 데이터 조작 성능 - 추출/검색 성능 (1000억건 저장소 기준) | 특정 센서의 시간 범위 1만건 추출시 0.1초 미만 연산 가능 |
센서 데이터 조작 성능 - 통계 연산 성능 (1000억건 저장소 기준) | Rollup을 통해 특정 센서의 월/연간 차트 0.1초 미만 연산 가능 |
데이터 보안성 - 저장소 암호화 | 해당 운영체제의 기능 활용 (물리적인 분리를 통한 탈취 가능성 배제) |
데이터 보안성 - 통신 암호화 | X.509 종단간 데이터 암호화 지원 |
데이터 보안성 - 물리적 분산 | 마이크로 데이터레이크의 본질적 특성 |
확장성 | 불필요 (scale up 가능) |
고가용성 | 향후 지원 필요 (customization needed) |
클라우드와의 데이터 통합 | CEMS 구축을 통해 가능 |
위에서 본 바와 같이 마크베이스 네오의 본질적인 기능을 통해 에지장치 기반의 "마이크로 데이터레이크 구축"이 충분히 가능한 것을 알 수 있으며, 아래 리스트는 현재 마크베이스 네오를 통해 에지에서 더 활용 가능한 부가적인 기능이니 참고하면 좋을 것 같다.
부가 기능들
에지에서 활용가능한 마크베이스 네오 기능 | 기능 상세 |
MQTT 서버 내장 | 서버 구축 없이 MQTT 클라이언트가 MQTT를 통해 바로 DBMS로 데이터 입력 가능 |
웹 서버 내장 | 웹서버 구축 없이 직접 HTTP 프로토콜을 통한 Rest API 활용 및 자체 서비스 구축 가능 |
SSH 서버 내장 | 안전한 SSH 프로토콜을 통해 에지 데이터베이스 대한 직접 접근 및 조작 가능 (ssh app) |
X.509 기반 암호화 접속 기능 제공 | 데이터 보안성 강화 |
다양한 CPU 및 운영체제 지원 | 윈도우즈(INTEL), 리눅스(ARM, INTEL), 맥오에스(ARM, INTEL) |
자체 대시보드 지원 | 초고속 데이터 시각화 지원 |
쉬운 외부 도구 연동 | 그라파나, telegraf 연동 지원 |
외부 DBMS와의 연동 지원 | sqlite, mssql, mysql, postgresql 등에 대한 원격 접속 및 데이터 입력/추출 기능 제공 |
데이터 변환 언어(TQL) 제공 | 별도의 프로그래밍 없이 자체 backend API 구축 및 서비스 가능 |
내장된 데이터 분석 도구 지원 | Tag Analyzer 도구를 통해 데이터 장단기 시각화 및 분석, 2차원/3차원 FFT 차트 분석 제공 (참고 FFT 블로그 자료) |
100% 웹 기반 DBMS 관리 인터베이스 제공 | 모든 데이터베이스 조작을 웹 상에서 가능 |
아래는 마크베이스 네오의 전체적인 기능에 대한 설명을 담고 있는 영상이니 더 자세한 내용을 알고 싶다면 참조하도록 하자.
한가지 놀라운 사실은 "마크베이스 네오"의 이 모든 기능은 위에서 언급한 손바닥만한 작은 장치부터 대용량 서버급의 하드웨어에서도 동일하게 수행 가능하기에 어디에서나 "데이터레이크" 구축이 가능한 상상에서나 있을 법한 데이터 인프라 SW 라는 것이다.
마치면서
본 네번째 시리즈에서는 "마이크로 데이터레이크"의 구체적인 구현을 위한 기술 대안으로 어떻게 "마크베이스 네오"가 채택되었는지, 전체적인 요구 사항과의 관계는 어떻게 되는지 살펴보았다. 이야기가 흩어지지 않도록 하기 위해 실제 구축을 위해 더 필요한 SW 스택인 "CEMS"를 잠깐 언급하고 자세히 다루지는 않았다. 마지막 시리즈가 될 다음회에서는 실제로 구축되어 동작하는 해당 데이터레이크에 대해 살펴보고, 향후 발전 방향에 대해 논의해 볼 수 있도록 하겠다.
이 시리즈에서 다뤘던 이야기는 오늘 현재 대부분의 시장에서는 모르고 있거나, 혹은 기술적으로 가능하지 않다고 생각한 이유로 오늘보다 3년 정도의 미래를 다루는 기술이라고 생각하고 있다. 그러나, 이러한 기술적 혁신이 더 빨리 이 땅에 정착하여, 저 멀리 앞서가는 미래 국가의 모습으로 대표되는 대한민국이 될 수 있기를 상상해본다.
Comments