김성진 대표, 마크베이스 |

 

바야흐로 IoT 시장에서의 데이터 전쟁이 시작되었다. 누가 가장 빨리 그리고 효율적으로 폭증하는 데이터를 처리하느냐가 앞으로 벌어질 전쟁에서의 승패를 가늠하는 중요한 잣대가 될 것이 분명하다. 그리하여, 이 IoT 데이터 전쟁에서 승리를 위해 뛰어든 많은 도전자가 있었다. 그 도전자는 나름의 장점과 승리의 추억도 있지만, 좌절 또한 겪을 수밖에 없는 한계를 가지고 있다. 그들의 이야기를 한번 펼쳐보자.

 

 

도전과 좌절의 역사

 

1. 트랜잭션 기반의 전통 데이터베이스

아이가 세상에 처음 태어나면 하는 일이 울음을 터뜨리고, 이 지구의 공기를 들이켜는 것이다. 너무나 당연한 일이고, 아이는 공기의 존재조차도 알지 못하는 상태에서 이를 행하게 된다. 마찬가지로 현재 RDBMS(전통적인 트랜잭션 기반의 데이터베이스)는 공기와 같이 우리의 삶에 직결되어 있다. 대부분의 IT 관련자가 학교에서 혹은 기업에서 사용하고 배우는 거의 모든 데이터베이스가 바로 이 종류이기 때문이다. 대표적으로 오라클, MySQL, MariaDB, PostgreSQL, MS-SQL, Sybase, DB2 등이 있으며, 기술하지 않은 수십여 종의 유사한 제품들이 존재한다.

 

이 세상에 센서 데이터가 발생한 후에는 첫 번째로 그러한 데이터가 RDBMS에 저장되고 처리될 것이라는 사실이 자명하다. 그러한 RDBMS의 편의성과 익숙함에도 불구하고, 오늘 21세기에 IoT 데이터를 처리하기에는 너무나 많은 제약사항이 있는 것이 사실이다.

 

실제로 지금까지 개발되어온 수많은 센서 데이터 관련 제품들(예를 들어, 로보틱스, 스마트 팩토리 등)과 관련된 데이터 처리의 한계와 어려움은 유명한데, 전통적인 데이터베이스가 이 전쟁에서 고전을 면치 못하는 근본적인 이유는 트랜잭션이라는 기능을 통해 데이터를 처리한다는 사상에 있다.

 

다시 말해, 트랜잭션은 은행의 송금 혹은 비행기 예약과 같은 복잡하고, 어려우면서 연속된 비즈니스 업무를 하나의 온전한 업무 단위로서 처리하기 위해 고안된 기술적인 요구사항이다.

 

위에서 언급한 비즈니스에서는 처리의 신뢰도가 매우 중요하기 때문에 해당 업무가 완벽하게 보장되는 것을 목표로 다양한 기술적인 연구와 해결책이 지난 30여 년간 지속적으로 발전되어 왔다. 즉, 데이터의 처리 비용과 관계없이 이론적으로 완벽하게 보장되는 방향으로 기술개발이 이루어졌기 때문에 현재의 하드웨어 성능으로는 초당 수백 혹은 수천 건을 처리하는 것이 그 한계이다. 이러한 트랜잭션을 지원하기 위해서, RDBMS는 아래와 같이, 성능을 희생하는 큰 비용을 지불하고 있다.

 

 

첫째, 연산 복구비용이다. 트랜잭션의 중요한 속성 중 하나로 원자성(Atomicity)을 들 수 있는데, 이는 수행 중인 트랜잭션은 완벽하게 끝나거나, 혹은 수행되기 이전의 상태로 완벽하게 복원이 되어야 한다는 것이다. 트랜잭션의 중간 상태는 존재할 수 없는데, 이를 위해서 RDBMS는 모든 트랜잭션의 변경 연산(입력, 수정, 삭제)에 대해서 로그(Log)라는 2차 저장 매체에 기록을 수행한다. 내가 특정 데이터를 입력하면, 단순히 데이터를 입력하는데 그치는 것이 아니라, 그 데이터가 저장되는 데이터 파일의 변경된 영역을 기록하고 그 데이터를 가리키는 인덱스의 변경 부분도 기록한다. 만일 생성된 인덱스가 10개라면, 10개 모두에 대한 변경 내역을 기록한다. 즉, 배보다 배꼽에 더 큰 경우가 발생하는데, 검색 성능을 높이기 위해 다양한 인덱스를 생성하면 할수록 입력 성능이 떨어지는 트레이드오프(Trade-off)가 발생한다. 이러한 로깅 비용이 전체 데이터베이스 성능을 저하시키는 가장 중요한 이유이다.

 

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

 

셋째는 일반화된 데이터 저장 구조 및 인덱스 구조의 복잡성으로 인한 비효율성이다. 앞에서도 잠깐 언급한 바와 같이 트랜잭션 기반의 RDBMS는 느릴 수밖에 없는 한계를 스스로 인식하고 이를 극복하기 위하여 노력하여 왔다. 그리고 그 결과로 데이터베이스는 매우 복잡한 구조로 진화했다. 특히 당시에는 하드디스크가 가장 대중적인 저장매체였기 때문에 읽기 성능을 향상시키기 위해 디스크 관리자, 버퍼 관리자 등을 통해서 최악의 상황에서도 나름 평균적인 성능을 보장하도록 설계하였고, 이로 인해 전체적인 코드의 복잡성이 더 커진 것이다. 이 복잡성은 단순한 연산(입력)에 대해서도 복잡한 내부 로직을 수행할 수밖에 없는 구조적인 한계를 가지게 되었다.

 

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

 

2. 일반 텍스트 파일

위와 같이 기존의 데이터베이스로 해결이 어려운 경우에 가장 빈번하게 찾게 되는 방법이 일반 텍스트 파일(Plain Text File)이다. 가장 쉽고 강력하지만 뒤처리가 복잡한 방법이다. 쉽게 말하면, 쏟아져 나오는 센서 데이터를 그대로 일반 텍스트 파일에 저장하는 방법이다. 의외로 이렇게 센서 데이터 혹은 시계열 로그 데이터를 일반 텍스트 파일에 저장하는 방법을 선호하는 기업이 상당히 많다.

 

보통 특정 크기(예를 들면 2GB)로 생성되면, 압축 후 보관하고, 파일명과 폴더를 시간순으로 저장해서 나중에 찾아보기 쉽도록 관리한다. 주로 방화벽이나 공장의 장비에서 미래에 사용 가능성이 있지만 중요도가 떨어지는 데이터를 저장해야 하는 경우 사용하는 방법이기도 하다. 그러나 이렇게 저장하는 경우에 다음과 같은 문제점이 발생한다.

 

첫째로, 데이터 접근이 어렵다. 일단 압축된 상태이기 때문에 압축을 해제해야 하고, 이를 위해서는 콘솔이나 임의의 솔루션을 통해서 접근하고, 복사해야 한다. 사용자의 특정한 요구를 위해 정규화되지 않은 관리비용이 크게 발생한다는 것이다.

 

둘째는, 이것이 더 큰 문제인데, 데이터 검색 시의 느린 성능이다. 접근하기 위한 대상 파일을 이미 알고 있는 경우에는 그나마 쉽지만, 특정 패턴을 찾는다고 가정한다면, 이는 업무의 양과 비용의 측면에서 재앙이라고 할 수밖에 없다. 모든 압축된 텍스트 파일을 순차적으로 일일이 확인하면서 특정 데이터 혹은 패턴을 찾아야 하는데, 그 데이터의 크기가 수 테라에 달한다면 어떻게 할 것인가? 하나의 업무를 수행하기 위해 수일의 분석 시간과 비용이 들어가는 것을 당연하게 생각하는 조직은 아마 없으리라 생각한다.

 

3. 검색엔진 기반 솔루션

최근 몇 년간 각광을 받고 있고 또한 특정 비즈니스 영역에서는 대세로 자리 잡은 기법이다. 이러한 검색엔진 솔루션으로는 대표적으로 스플렁크(Splunk)나 일라스틱(Elastic) 등이 있는데, 이러한 솔루션이 각광을 받게 된 몇 가지 이유를 살펴보자.

 

첫째로 특정 산업계의 시계열 데이터가 일반 텍스트 파일(Plain Text File)로 존재한다는 것이다. 예를 들어 운영체제의 시스템 로그 혹은 보안 분야에서 발생하는 막대한 로그는 대부분 텍스트 형태로 발생하고, 이를 텍스트 파일로 저장하는 것이 일반적이었다. 검색엔진은 이러한 텍스트 파일을 읽고, 인덱싱하기 위한 최적의 솔루션이 아니던가?

 

둘째로 대규모의 데이터 크기에도 적절한 성능을 보장하기 때문이었다. 수 테라 크기로 검색할 수 없었던 텍스트 파일을 수초 만에 검색하고, 일부 분석까지 할 수 있다. 이러한 장점으로 말미암아 대규모의 로그성 빅데이터를 보유하고 있던 많은 기업이 이를 채택하게 되었고, 그중에서도, 검색과 부분 분석이 필요한 보안 영역에서 특히 많은 고객을 확보하게 되었다.

셋째로는 직관적이고 쉬운 사용자 인터페이스(Graphic User Interface)를 제공했다는 점이다.

 

사용자는 몇 가지 조작만으로 이전에 볼 수 없었던 자신의 빅데이터 분석 결과를 화려한 그래픽으로 볼 수 있다는 것은 그야말로 희소식이었음을 부정할 수 없다.

 

그러나 이 검색엔진 기술 기반의 솔루션은 IoT를 위한 센서 데이터 처리에 적합하지 않다는 치명적인 약점을 가지고 있다. 이 사실을 정확하게 인식하지 못한 채로 대량의 IoT 센서 데이터 처리에 검색엔진 기반의 솔루션을 도입했다가 낭패를 당한 경우들이 상당수 알려져 있다. 그 이유는 다음과 같다.

 

첫째, 모든 처리 가능한 데이터가 일반 텍스트 형태로 구성되어야 한다는 점이다. 이것은 사실 매우 치명적인 약점일 수 있는데, 검색엔진의 특성으로 인해 정수나 실수와 같은 수치 데이터의 경우에도 아스키 코드의 텍스트로 변환이 되고, 이 데이터가 임의의 일반 텍스트로 존재해야 한다. 이 경우 데이터의 관리도 어려울 뿐 아니라, 모든 데이터를 무조건 일반 텍스트로 변환하면서 발생하는 저장공간의 낭비와 변환 비용이 매우 크다.

 

둘째, 실시간 처리에 대한 어려움이다. 검색엔진 기술의 핵심 중의 하나인 역인덱스(Inverted index) 생성이다. 이는 특정 문서에 포함된 임의의 키워드를 기반으로 검색할 수 있게 해 주는 주된 알고리즘인데, 이 인덱스를 생성하는 데는 상당히 많은 시스템 비용을 지불해야 한다. 왜냐하면, 이 인덱스는 트리(Tree) 기반의 전역 인덱스로 구성이 되는데, 입력되는 모든 데이터를 하나씩 분석하여 인덱스의 키로 구성하는, 비용이 많이 드는 아키텍처이기 때문이다. 그래서 이런 기술은 실시간 처리보다는 포털사이트와 같이 하루에 한 번 전체적인 인덱스를 구축하는 곳에서 주로 사용된다. 시간이 충분한 경우라면 상관없지만, 발생하는 사건을 빠른 시간 내에 확인하고, 대처해야 하는 경우에는 생각보다 더 많은 하드웨어 및 비용이 투입되어야 한다.

 

셋째, 대규모 시계열 센서 데이터의 특성을 지원할 수 없는 구조적인 한계 및 느린 성능이다. 시계열 센서 데이터는 독특한 특징을 가지고 있다. 센서 데이터는 시간 값에 대해 높은 카디널리티(Cardinality)를 가지면서도, 각각의 센서가 대량의 데이터를 생산한다. 카디널리티가 높다는 것은 센서의 종류와 시간 값이 매우 다양하여 중복되는 데이터가 적다는 의미이다. 이런 특성의 데이터 분석 기능을 지원하는 것은 검색엔진의 원래 목적에 비추어 보면 거의 불가능에 가깝다. 물론, 센서의 종류가 수십 종류에 불과하고, 데이터의 총량이 수백만 건에 불과하다면 충분히 처리가 가능할 것이나, 이 정도면 그냥 일반 데이터베이스를 쓰는 게 나을 수 있다. 굳이 비효율적인 검색엔진에 데이터를 넣을 이유가 없기 때문이다.

 

4. 하둡 기반 솔루션

중국 삼국지에 나오는 고사 중에서 가장 유명한 것 중의 하나가 조조와 얽힌 에피소드인 “계륵”일 것이다. 이 계륵은 먹기에는 귀찮고, 버리기에는 아까운 상당히 애매한 수준의 뭔가를 뜻한다고 볼 수 있다. 모르긴 몰라도 IT 시장에서 이 “계륵”이라는 단어가 가장 잘 어울리는 제품이 바로 하둡(Hadoop)이 아닌가 생각된다. 자세히 기술하기에는 너무 많은 분량이기 때문에 출현 배경과 그 철학적인 배경만을 이야기하는 것이 적절할 듯하다.

 

이 하둡은 구글의 내부 데이터 처리 엔진인 빅테이블과 동일한 자바 기반의 오픈소스 버전이라고 정의할 수 있다. 다시 말하자면, 구글과 같은 인터넷 검색엔진 서비스를 해서는 이와 관련되어 수집된 웹 문서를 위한 역인덱스가 필요하다. 문제는 이 수집된 웹 문서의 크기가 수백 테라가 넘어간다는 것과, 이 문서를 모두 읽어서 역인덱스를 구성해야 한다는 것이다. 더 큰 문제는 이 수백 테라를 한곳에 저장할 수 있는 물리적인 하드디스크가 존재하지도 않거니와 존재한다고 해도 수백 테라를 읽어서 역인덱스를 만들기 위해서는 일반 PC에서는 1년 이상의 시간이 걸릴 수 있다.

 

이런 빅데이터 문제를 해결하기 위해, 저렴한 다수의 PC를 조합해서 가상의 디스크를 구성하고, 각각의 PC가 병렬로 일하게 만들면 1년 걸릴 작업을 하루 만에 할 수 있게 된다. 이를 위해 하둡이 개발되었고, “빅데이터 솔루션”이란 별명을 가지게 되었다. 이 하둡이 바라보는 데이터에 대한 철학적 배경은 이렇다.

 

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

 

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

 

물론 그 이후에 많은 개선 방안과 솔루션이 나왔지만, 이 근본적인 철학은 동일하다. 더구나 오픈소스라서 무료이고, 누구나 설치하여 사용할 수 있으며, 빠른 빅데이터 처리 속도를 제공한다. 더구나 RDBMS처럼 SQL도 사용할 수 있다고 하니 사용자들에게 최고의 선택이었던 것이다. 그래서 지난 수년간 사용자들은 엘도라도를 상상하며, 너나없이 하둡을 도입하기 시작했다. 덕분에 클라우데라나 호튼웍스 같은 미국 기업들이 비즈니스를 시작했고, 한국에서도 수십 개 이상의 토착 기업이 하둡 소스를 기반으로 한 자체 빅데이터 솔루션을 출시하였으며, 이를 기반으로 한 다양한 비즈니스가 가능해지기 시작했다. 빅데이터의 봄이 시작된 것이다. 여기까지는 행복한 스토리다.

 

이제 반대로 돌아가서 불행한 이야기를 살펴보자. 하둡의 기본 특성을 이해하지 못하면, 바느질할 곳에 망치와 못을 사용하는 격이 될 수 있다.

 

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

 

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

 

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

 

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

 

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

 

이런 사실을 모르고, 그냥 빅데이터라고 활용했다가 곤란을 당한 고객의 이야기는 인터넷상에서 많이 발견할 수 있으며, 실패한 도입 사례로 스스로 말할 수 없는 경우도 많아서 알려진 것보다 더 많은 스토리가 있다. 실시간으로 처리해야 하는 센서 데이터 영역에서 하둡을 도입하는 것이 매우 어렵다는 것을 이해할 수 있을 것이다.

 

계륵이라고 한 이유는 여전히 하둡이 무료로 빅데이터를 쉽게 처리할 수 있다고 믿지만, 실제 성공적인 사용사례를 찾기 힘들어 도입 여부와 관련하여 딜레마에 빠진 고객들의 상황을 빗대어 표현한 것이다.

 

5. NoSQL

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

 

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

 

예를 들어, 대한민국 사람은 누구나 주민등록번호를 가지고 있는데, 이런 주민등록번호를 기반으로 데이터를 등록하고, 수정하고, 탐색하고, 삭제하는 작업은 NoSQL의 성능을 따라갈 제품이 없다. 마치 골목길을 돌아다니는데 자전거의 민첩함은 자동차나 비행기가 따라갈 수 없는 것과 마찬가지로 말이다. 그리고 포털 서비스 사이트에서 수많은 페이지의 웹 서비스를 제공할 때, 특정 웹페이지마다 고유의 키를 부여하여 요청된 페이지를 실시간으로 서비스하는 페이지 캐시 서비스를 사용하는데 여기에도 NoSQL을 사용하고 있다.

 

세상을 이렇게 유일 키를 가진 대상으로 보게 되면, 이에 따라오는 소프트웨어적인 장점이 있는데, 바로 확장성과 고가용성이다. 확장성 관점에서는 모든 데이터(혹은 엔트리)에는 반드시 유일 키가 존재하기 때문에 자신이 속할 서버를 쉽게 지정할 수 있고, 이 서버의 개수를 무제한으로 늘림으로써 사용자 요청의 증가에 대한 유연한 대처가 가능하다. 고가용성 관점에서는 자신의 데이터를 두 개 이상의 서버에 복제해 둠으로써 만일 하나의 서버에 장애가 발생하더라도 나머지 서버가 대신할 수 있도록 하여, 장애에도 큰 어려움 없이 서비스를 수행할 수 있다.

 

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

 

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

 

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

 

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

 

6. 몽고디비

인터넷 시대에 가장 독특하면서도 대중적으로 인기가 있는 DBMS가 바로 몽고디비(MongoDB)라고 할 수 있다. 우선 오픈소스이기 때문에 많은 사용자가 무료로 사용할 수 있을 뿐 아니라, 빠른 성능으로 인해 전 세계적으로 대단한 인기를 자랑한다.

 

또한, 그 정체성이 매우 독특한데 스스로 문서 DBMS(Document DBMS)라고 밝히고 있을 정도로 문서와 같은 비정형 데이터 처리에 특화되어 있으며, 질의 언어도 SQL이 아닌 JSON(JavaScript Object Notaion) 형태로 동작하기 때문에 어느 특정한 종류의 데이터베이스라고 이야기하기 힘들다(혹자는 NoSQL로 구분하기도 한다).

 

굳이 구분하자면 전통 데이터베이스와 NoSQL 중간 정도에 있다고 볼 수 있다. 즉, 데이터베이스 스키마가 필요 없고, 트랜잭션 지원을 지원하지 않으며 키-밸류(Key-Value) 특성을 가진 점은 NoSQL로 볼 수 있으나, 통계 등 다양한 질의문을 지원하고 트리(Tree) 기반의 다수 인덱스 생성을 허용한다는 측면에서는 오히려 전통적인 데이터베이스에 가깝다고 볼 수 있다.

 

위와 같은 이유로 빅데이터 일반 문서 처리 혹은 일반 데이터 저장소 등 산업군을 가리지 않고 사용되고 있어서 만능으로 보이기도 한다. 그러나 센서 데이터 처리 관점에서 보면 이 제품의 한계는 오히려 명확하다. 너무 많은 기능과 형태를 지원한다는 것은 특정한 제품 영역에서 경쟁력이 떨어진다는 것을 의미하기도 하는데, 실제로 대량의 시계열 데이터의 입력 성능과 추출 성능이 매우 느리기 때문에 IoT 센서 데이터 처리 영역에 적합하다고 할 수 없다.

 

7. RTDB

이 RTDB 용어는 대한민국의 제조업 분야에 국한된 용어로서 실시간 데이터베이스(RealTime Database)라고도 불린다. 주로 산업용(Industrial) IoT 영역으로 불리는, 발전, 제조 분야의 데이터를 처리하는 OT(Operational Technology) 영역에서 사용되는 데이터 저장소를 RTDB라 부르는데, 제품의 종류와 무관하게 센서 데이터를 저장하는 제품을 RTDB로 지칭한다.

 

그러나 엄격하게 이 제품의 기원부터 살펴보면, 원래 RTDB라고 부르는 제품은 DBMS라기보다는 솔루션 측면에서의 데이터 저장소로 볼 수 있다. 예를 들면, 오에스아이소프트(OSISoft)의 파이 시스템(PI System)이나 유사 제품인 데이터파크(dataPARC)를 지칭하기도 하고, 이러한 제품과 센서 데이터를 저장하는 유사 제품군을 일컫는 용어인 히스토리안(Historian 혹은 Operational Historian)으로 사용되기도 한다.

 

이 제품들은 수만 개 이상의 서로 다른 종류의 센서 데이터를 고속으로 저장하고, 이를 실시간으로 시각화해 주는 제품으로 오랫동안 사용되어 왔다. 또한, 해당 영역의 고객이 필요로 하는 기능과 성능을 제공하고 있었기 때문에 DBMS라는 용어는 이 OT 영역에서는 거의 활용될 여지가 없었다. 그러나 세상이 변하면서 기존의 솔루션으로는 폭발적으로 증가하는 데이터를 처리하기 힘든 지점에 이르렀다. 그 이유는 다음과 같은 몇 가지를 들 수 있다.

 

첫째는 확장성이 제공되지 않는다. RTDB는 단일 서버로 최고의 성능을 낼 수 있는 구조로 진화해 왔고 이중화까지 지원하는 것이 가능하다. 그럼에도 불구하고 확장성이 문제가 되는 것은 데이터양이 급격하게 증가하는 상황에서 이중화를 넘어선 다중화가 필요하고, 무엇보다 서버를 추가하여 처리 성능을 높이는 것이 중요한데 이에 대한 대처 방안이 없기 때문이다.

 

둘째는 IT와 OT의 융합이 시작되었다는 점이다. 앞에서 언급한 바와 같이 OT 영역에서는 SQL을 사용하는 RDBMS를 고려하지 않았다. 그러나 폭발적인 센서 데이터의 증가와 함께 이와 관련된 요구사항이 늘어남에 따라, 해결점을 IT 영역에서 찾기 시작하였으며, 관련된 IT의 기술은 대부분 RDBMS을 기반으로 하고 있기 때문에 RTDB와 같은 특화된 제품이 배제되는 상황이 된 것이다. 특히, 스마트 팩토리 솔루션이라는 이름의 IT 기반 제품들이 OT 영역으로 확장함에 따라 RTDB가 가지고 있는 한계가 발목을 잡고 있다. 스마트 시대에는 RTDB보다 RDBMS와 같이 개발과 사용이 편하고 빠른 성능을 제공하는 솔루션이 더 각광을 받게 되었다. 사용자는 패키지 구조를 가진 단일 데이터베이스 형태를 선호하는 데 반해, RTDB는 단일 패키지가 아니라 큰 솔루션의 한 부분으로 제공되고 있기 때문에 미래 시장에서 수요가 감소할 수밖에 없다.

 

IoT 데이터 전쟁 승리의 조건들

 

그렇다면, 과연 이 전쟁에서 승리하기 위해서는 어떤 특징을 보유하고 있어야 할까?

 

1. 데이터 입력과 저장 속도

센서 데이터 처리에 있어 가장 중요한 덕목이다. 앞 장에서 이야기했던 이야기의 핵심은 데이터가 많아진다는 것이다. 이는 처리하고자 하는 데이터양이 기존에는 초당 10건 혹은 100건이었다면, 스마트 시대에는 초당 만 건 혹은 초당 십만 건의 데이터를 처리해야 한다는 뜻이다.

 

IoT 시대에 접어들어 특히 반도체 혹은 유사 업계에서 발생되는 최근의 데이터 빈도를 살펴보면 초당 10만 건을 넘어, 초당 1,200만 건의 데이터를 처리해야 하는 곳도 존재한다. 특정 센서에 측면에서 살펴보면, 회전체(모터)를 관리 감시하기 위해 설치되는 정밀 진동 센서의 경우 그 대역폭이 12,000㎐에서 18,000㎐ 정도이다. 이를 데이터로 환산하면 하나의 센서에서 초당 약 2만 건 이상(일반적으로 대역폭의 두 배의 데이터가 생산된다고 본다)의 데이터가 발생하고, 10개의 센서를 측정하기 위해서는 초당 20만 건 이상의 데이터를 저장해야 한다.

 

2. 고속 데이터 추출

당연하다고 생각할 수 있지만, 실제 소프트웨어 측면에서 생각해보면 이게 만만한 문제가 아님을 직감할 수 있다. 가장 단순하게는 데이터를 저장하는 방식이 일반 텍스트 파일에 저장하는 것이다. 시스템 측면에서 보면, 쏟아져 나오는 데이터를 추가(append)하는 방식으로 텍스트에 기록하는 것이 저장장치에 저장하는 가장 빠른 방법이다. 그러나 내가 원하는 특정 시간과 특정 센서에 대한 데이터를 얻기 위해서는 모든 파일을 검색해야 하는 순차적 탐색으로 인해 성능이 느릴 수밖에 없다. 시장에서는 특정 데이터를 추출할 때 초당 백만 건 이상의 성능을 원한다.

 

3. 고속 시계열 질의 지원

앞에서 언급했던 ‘고속 데이터 추출’과 유사한 맥락이지만, 시간이라는 축을 하나 더 놓고 이야기를 풀어보자. 센서 데이터의 경우, 대부분, 시간 축을 기준으로 발생하는 데이터이므로 시계열 데이터라고 한다고 언급하였었다. 이를 활용하는 사용자 측면에서 보면, 대부분의 데이터 질의문은 이러한 시간 축을 필수조건으로 놓고, 나머지 조건들을 처리한다. 즉 다음과 같은 사용자 질의문을 고속으로 처리하는 것이다.

 

2019년 3월 21일 11시부터 2019년 3월 21일 18시까지의 데이터 중에서 센서 S123의 데이터를 가져온다.

 

위의 사용자 질의를 자세히 살펴보면 모든 구문에 시간 범위가 조건으로 들어가 있는 것을 볼 수 있다. 시계열 센서 데이터 처리를 위한 가장 기본적인 특징이기도 하고, 쉽게 풀기 힘든 문제이기도 하다. 이 정도의 질의문은 이미 기존의 DBMS에서도 충분히 해결해 온 것 아니냐고 반문하는 독자도 있을 것이다. 물론 그렇다. 그렇지만 기존의 DBMS는 위의 질의를 처리하는 것이 실제로 매우 느리다. 또한, 다양한 시간에 관련된 함수 및 연산자도 부가적으로 지원해야 한다.

 

4. 실시간 통계 기능 지원

여기서 말하는 실시간 통계 기능은 “2013년 한 해 동안 특정 센서 집단에 대해 일평균 값을 구하라.” 혹은 “동일한 집단에 대해 지금부터 2시간 전까지 분당 평균값을 구하라.”와 같은 것이다.

 

문제는 저장된 데이터양의 크기와 무관하게 수 밀리초 내에 결과를 제공해야 하고, 수행되는 과정에서 데이터의 입력에 크게 영향을 주지 않아야 한다는 것이다. 전통적인 데이터베이스처럼 대상 데이터에 대해 직접 연산을 하는 방식으로는 이 요구사항을 만족시킬 수 없으며, 미리 통계 자료를 생성해 놓는 새로운 접근 방식을 필요로 한다.

 

 

5. SQL 지원

OT(Operational Technology)로 불리는 산업 데이터 처리 분야에서는 SQL이 지원되지 않는 특화된 솔루션이 자리 잡고 있다. 그러나 이 세상이 발전하면서 IT 영역의 기술들이 전 산업계에 영향을 미치기 시작했고, 기존의 특화된 솔루션보다는 일반적인 데이터베이스 형태의 기술이 각광을 받고 있다. 무엇보다 ‘스마트 팩토리’가 대두되면서, 기존의 특화된 솔루션 대신, SQL과 같은 IT 기술이 더 나은 방법으로 제시되고 있다.

 

6. 임베디스 아키텍처 지원

다소 엉뚱하다고 생각할 수도 있지만, IoT 시장과 세상이 변하는 방향을 고려해 보았을 때, 이 요구사항은 그냥 간과할 수 없는 것이다. 이는 ‘클라우드 서비스’와 매우 밀접한 관계를 맺고 있기도 하고, IoT 혹은 스마트 팩토리를 구성하는 최종 고객의 현실과도 맞아떨어진다.

 

대규모 데이터 발생이라는 이슈가 가진 대전제는 “데이터가 대량으로 쏟아지고 있고, 이를 처리하기 위한 새로운 방법이 필요하다.”라는 것이다. 이런 상황에서 이러한 데이터를 어떻게 처리하는 게 가장 좋은 방법일까? 물론 데이터를 저장할 수 있는 충분한 성능의 DBMS가 존재한다는 가정하에서 말이다. 이 경우, 크게 두 종류의 방법을 고려하는 것이 일반적이다.

 

 

첫째는 모든 데이터를 클라우드에 두고 처리하는 방식이다. 이는 현재 주요한 트렌드 중의 하나로 데이터를 처리하는 복잡한 구성을 하지 않고, 일단 데이터를 클라우드(혹은 중앙 서버)로 올리기만 하면, 편하게 모든 것을 대신해 주는 편리한 방법이다. 그런데 그 편리함의 뒤편에는 클라우드에 데이터를 전송하고, 보관하기 위한 비용이 숨어 있다. 데이터가 더 많아질수록 그 비용은 선형적으로 증가하는 점을 제외하고는 참으로 좋은 해결책이다.

 

둘째는 데이터를 로컬 영역에 보관하고, 일부 중요한 데이터를 클라우드에 올리는 방식이다. 이 방식에는 몇 가지 장점도 있는데 첫 번째는 데이터 보안 관점에서 데이터를 외부로 오픈하지 않아도 된다는 점이고, 혹시나 클라우드 서비스 혹은 공용망(WAN)에 장애가 나더라도 서비스에 크게 문제가 되지 않는다는 점이다. 또한, 데이터를 전송하기 위한 인터넷망의 대역폭에 크게 구애받지 않으며, 클라우드까지 데이터를 전송하는 시간과 비용을 쓰지 않고 실시간 의사 결정을 할 수 있다는 점이다. 이러한 이유로 최근 들어 엣지 컴퓨팅(Edge Computing)이라는 개념이 대두되기 시작했고, 이 영역에서 가장 중요한 요소 중의 하나가 바로 엣지 부분, 즉 임베디드(Embedded) 장비에서도 잘 동작하는 데이터 처리 소프트웨어(DBMS)가 필요해진 것이다. 흔히 우리가 들어 봤음직한 작은 장비인 ‘라즈베리파이’ 혹은 ‘라떼판다’와 같은 곳에 대규모 데이터 처리를 위한 DBMS가 동작해야 한다는 뜻이다.

 

문제 다시 보기 : 왜 해결하기 어려울까?

 

1. 그림으로 보는 센서 데이터 배치 구조

위의 그림은 실제 센서 데이터가 입력되는 모습을 데이터 관점에서 그린 것이다. 세로축은 아래쪽으로 시간의 증가를 나타내고, 가로축은 데이터를 생산하는 센서를 나타낸다. 그리고 붉은 상자 사용자가 특정 시간 범위 내의, 특정 센서의 데이터에 접근하는 경우를 확대한 것으로, 확대한 그림의 흰 박스는 데이터가 없는 경우이며, 푸른색의 경우에는 데이터가 입력된 것이다. 위의 그림을 기반으로 다음과 같이 센서 데이터 저장 및 접근의 특성을 기술할 수 있을 것이다.

 

 

1) 저장된 데이터의 시간은 증가하는 방향으로 저장된다 : 이렇게 되어야 추출 시 시간순으로 정렬된 값을 얻을 수 있다.

 

2) 센서 데이터 입력의 시간 값이 항상 증가하는 것은 아니다 : 센서의 시간 차이 혹은 데이터 입력 환경에 따라 간혹 역전도 가능하다.

 

3) 센서 종류는 항상 증가한다 : 센서의 이상 유무에 따라 데이터가 입력되지 않거나, 해당 센서가 입력 대상에서 삭제될 수 있지만, 이미 입력된 센서 데이터가 사라지는 것은 아니다.

 

4) 각각의 센서는 각자의 주파수가 존재한다 : 주파수에 따라 단위 시간당 입력 건수가 다르다. A 센서는 1초에 100건이 입력되지만, B 센서는 1분에 1건씩 입력될 수 있다.

 

5) 사용자는 시간이 증가하는 방향으로, 연속적으로 데이터를 얻는다 : 얻어지는 센서 데이터를 불연속적으로 추출하는 경우는 없다.

 

6) 하나의 센서 데이터는 <센서아이디, 시간, 센서값>으로 구성된다 : 센서아이디는 문자열로 가정한다. 센서값은 실수로 가정하고, 문자열인 경우는 예외로 한다.

 

이 내용을 종합해 보면, 센서 데이터 구조는 매우 높은 카디널리티(Cardinality)를 가지는 시간과 센서아이디로 구성된 2차원 문제라는 것을 이해할 수 있다. 여기에서 카디널리티가 높다는 것은 센서의 종류와 시간 값이 매우 다양하여 중복되는 데이터가 적다는 의미이다.

 

2. 트리 기반 인덱스 데이터 구조의 한계

데이터베이스가 빠르게 데이터를 추출할 수 있게 해주는 기반 기술이 트리(Tree) 구조의 인덱스이다. 이 트리 구조는 조건이 하나인 1차원 문제는 잘 해결할 수 있지만, 두 가지 조건, 즉 시간과 센서아이디가 복합된 2차원의 문제를 해결하기에는 역부족이다.

 

그 이유를 그림을 통해 알아보자. 다음 그림은 3개의 컬럼을 가진 테이블(센서아이디, 시간, 센서값)에서 시간 컬럼에 트리 인덱스가 만들어진 것을 가정한다. 그리고 특정 센서에 대해 시간 범위 T1과 T2에 대한 데이터를 얻는 상황을 나타내었다. 오른쪽의 트리 인덱스는 아래와 같은 몇 가지 근원적인 문제를 담고 있다.

 

 

첫째, 우선 인덱스에 포함된 레코드의 개수가 지속적으로 늘어나면, 점점 입력 성능이 느려진다. 인덱스가 크면 클수록 인덱스의 갱신 작업에 더 많은 시간이 소요되므로 성능이 느려지기 때문에 매우 불리하다.

 

둘째, 특정 시간 범위의 센서 데이터 추출 성능이 데이터양 증가에 비례해 느려진다. 위의 다음 그림처럼 T1과 T2의 검색 범위가 넓고, 그 사이에 포함된 태그 아이디의 개수가 많으면 많을수록 지정된 태그 아이디 값을 얻기 위해 그 범위의 데이터를 순차적으로 모두 방문을 해야 하는 악몽과 같은 일이 매번 벌어지는 것이다.

 

즉, 트리 구조는 두 개 이상의 서로 다른 데이터 차원을 처리하는 목적으로 설계되지 않았기에 센서 데이터 구조를 저장하면, 필연적으로 성능이 떨어질 수밖에 없다. 만일, 전체 저장될 데이터양이 적고(천만 건 이하), 센서의 종류가 얼마 되지 않으며(백여 종류 이하), 수행되는 질의의 데이터 시간 범위가 좁을 경우에는(한 번에 1,000건 이하) 충분히 빠르게 처리된다. 그러나 빅데이터 환경에서는 도대체 어떻게 해야 빠른 성능을 보장할 수 있을까?

 

좌절의 끝에서

 

이 글에서는 대규모로 발생하는 IoT 데이터에 대한 시장의 요구 사항과 이를 처리하기 위해 많은 시도를 했던 솔루션들에 대해 설명을 해 보았다. 인류의 발전이 그렇듯이 좌절은 또 다른 고민과 창조를 낳는다. 다음 장에서는 기존의 도전과 좌절이 어떤 형태의 새로운 창조의 결과물을 낳았는지 살펴보게 될 것이다. 과연 우리는 이 전쟁에서 승리할 수 있을 것인가?