General Article 데이터 폭발 시대의 실시간 데이터 분석 김 재 명 연구원(알티베이스) 데이터 폭발 시대 New 데이터 처리 기술 컴퓨터 기술이 발전하고, 많은 산업분야에서 컴퓨터를 활용하여 데이터를 생산, 가공 및 처리하는 사례가 늘어나고 있다. 이에 따라 인류가 생산하는 디지털 데이터는 과거에는 상상할 수 없을 만큼 폭발적으로 증가하고 있다. 2000년에 뉴멕시코에 있는 천체 만원경이 설치되고, 고작 몇 주간 생성한 데이터가 인류 역사를 전체에 걸쳐 생성된 천문학 분야에서 생성한 전체 데이터의 양을 뛰어 넘었다고 한다. 또한 미국의 월마트(Wall Mart)는 시간 당 100만 건의 판매 업무를 처리하는데, 이 데이터는 1.5 페타바이트 (Petabyte = 1024 Terabytes)이며 이 양은 미국 국회 도서관에서 보유한 책의 167배에 해당하는 양이다. 정보의 양이 증가함에 따라 이에 대한 처리 및 분석 역시 중요해지고 있다. 이러한 추세에 따라 최근에는 미국의 Oracle, IBM, Microsoft, 그리고 SAP와 같은 소프트웨어 기업들은 정보 관리 및 처리 기술을 가진 회사를 구입하는데, 우리 돈으로 약 18조원(150억$) 가량을 사용했다. 이러한 산업은 1000억 달러 정도로 추산되고 있으며, 매년 10%가량 성장하고 있다[2]. 이 글에서는 데이터의 양의 증가함에 따라 이를 실시간으로 분석하여 처리하는 기술에 대해 다루고자 한다. 과거와는 비교할 수 없이 실시간으로 데이터의 양이 증가함에 따라 기존의 데이터베이스 관리 시스템(Database Management System, DBMS)으로 처리하는 것은 한계로 부딪치게 되었다. 이를 위하여 실시간 데이터를 처리하기 위한 데이터 스트림 처리 시스템(Stream Processing Engine, SPE)이 개발되었다. 데이터베이스 (DBMS)와 스트림을 처리하기 위한 시스템인 SPE의 차이점을 통해 SPE의 필요성에 대해 알아본다.
데이터 스트림이란 데이터가 발생되는 상황을 바라본다 데이터 스트림이란 이전에는 없던 완전히 새로운 개념이 아니다. 데이터 스트림이란 데이터가 발생되는 상황을 바라보는 관점이다. 기존의 DBMS에서는 데이터를 정적인 관점으로 보았다면, 이를 데이터의 흐름으로 바라보는 것이다. 우리가 자각하지 못할 뿐, 우리는 이미 이러한 개념을 기반으로 한 서비스와 함께 생활하고 있다. 이해를 돕기 위해 이를 그림으로 표현하면 아래와 같다. [그림1. 데이터를 정적으로 바라보는 관점] 어항에 물고기가 있는 그림1을 보자. DBMS에서는 데이터를 정적으로 바라보기 때문에 마치 어항에 물이 고정되어 있고, 물고기도 고정되어 있는 것으로 인식한다. 위의 그림에서 보는 바와 같이 노란색 물고기는 세 마리가 있는데, 누군가 억지로 물로기를 빼거나 더하지 않는 이상, 어항에 있는 물고기는 변하지 않는다. [그림2. 데이터를 동적으로 바라보는 관점] 1 1 그림출처 : http://www.museyearbookcommittee.com/
반면, 강에 낚싯대를 드리우고 있는 오류! 참조 원본을 찾을 수 없습니다.그림2를 보자. 강물이 흐르고, 물고기가 헤엄을 쳐서 이동하기 때문에 특정한 낚싯대를 드리운 지점에서 바라보는 물고기는 계속 변화한다. 물고기는 계속 이동하기 때문에 낚싯대는 언제 드리우냐에 따라 걸려드는 물고기도 달라질 것이다. 이렇든 새로 발생한 데이터를 흘러가는 관점에서 바라보는 것이 SPE (Stream Processing Engine)에서 바라보는 데이터 스트림이다. [그림3. DBMS 관점에서 실시간 데이터 표현] 위 그림3의 테이블은 증권 거래에서 발생할 수 있는 데이터를 가상으로 표현한 것이다. 오전9시5분5초부터 25초까지 5건의 거래가 발생하였고, 이를 DBMS에서 처리하기 위해서는 위와 같은 테이블로 저장되어야 한다. [그림4. SPE 관점에서 실시간 데이터 표현] 하지만 SPE의 경우, 실시간 데이터를 데이터의 흐름(스트림)으로 바라보기 때문에 위의 오류! 참조 원본을 찾을 수 없습니다.그림4와 같이 시간이 흐름에 따라 5개의 이벤트(데이터)가 발생한 것으로 바라볼 수 있다. 데이터를 처리하기 위해 꼭 그림3의 관계형 테이블에 먼저 저장 후 처리할 필요는 없다. 다시 요약하면, DBMS와 SPE의 가장 큰 차이점은, 기존의 데이터베이스인 DBMS는 모든 데이터를 먼저 저장 후 처리하는 반면, SPE는 데이터를 받아 즉시 처리하도록 설계되었다.
스트림 데이터 모델 사례 : Push-based email Service 위 장에서는 SPE가 어떻게 실시간 데이터의 흐름을 바라보는지 살펴보았다. 이 장에서는 SPE가 데이터를 처리하기 위해 DBMS와 어떻게 다른 모델을 이용하여 처리하는지 살펴보도록 한다. DBMS는 데이터를 정적인 관점으로 바라본다. 데이터베이스에 사용자의 추가/ 삭제/ 수정 (INSERT/ DELETE/UPDATE) 연산을 허용하지만, 사용자가 데이터 접근하는 순간에는 (실제로 데이터가 변경되고 있음에도) 데이터는 변하지 않는다는 착각을 제공해주어야 한다. 또 다른 특징은 아무리 데이터베이스에 많은 변경이 발생하고 있더라도, 사용자가 명시적으로 데이터를 읽어오기 (SELECT) 전에는 사용자에게 어떠한 정보도 알릴 필요가 없다. 데이터베이스는 단지 사용자가 데이터를 달라고 하는 순간에만 데이터를 제공해 줄 의무를 가진다. 이러한 특징을 가지는 모델을 사용자가 원할 때, 준다는 의미로 pull-based 모델이라 부른다. 이때, 데이터를 요구하는 사용자는 동적 (active party)이고, 데이터를 제공하는 시스템은 정적 (passive party)이다. 반면 SPE는 데이터를 동적인 관점으로 바라본다. 사용자가 명시적으로 요구하지 않더라도 데이터가 동적으로 사용자에게 전달 (push)되어야 한다. [그림5. Pull-based email service] [그림6. Push-based email service] 이메일 서비스는 원래 pull-based 모델을 기반으로 설계되었다. 사용자가 이메일을 확인하지 않는 한 이메일이 사용자에게 전달되지 않는다. 혹은 이를 위해 응용프로그램에서 매 10분마다 이메일을 자동으로 확인하게 하도록 스케줄을 설정해야만 했다. 모두 명시적으로 데이터를 확인하는 경우에만 데이터가 전달되므로 pull-based 모델이라 할 수 있다. 하지만 아이폰을 비롯한 스마트폰에서는 이메일 푸쉬(push)라는 서비스를 제공해주고 있다. 이는 모두 SPE에서 바라보는 스트림 관점으로 이메일이라는
이벤트를 바라보고 서비스를 제공하도록 push-based 모델로 설계된 것이라 볼 수 있다. 아이폰을 보면, 이러한 push-based 모델이 이메일 뿐 아니라 다른 어플리케이션에도 활용할 수 있도록 설계했음을 알 수 있다. 덕분에 우리는 아이폰에서 이메일이 아니더라도 트위터나 카카오톡과 같은 서비스에서 발생한 메세지에 대해서도 푸쉬 서비스를 받을 수 있다. 과거의 시스템은 대부분 pull-based 모델을 기반으로 설계되었다. 예를 들면 우리가 사용하는 인터넷도 우리가 웹브라우저를 통해서 특정 주소(Uniform Resource Locator, URL)에 접속하면, 해당 웹서버는 미리 준비된 정보를 서로 약속된 언어로(Hyper Text Markup Language, HTML) 전달해주게 된다. 하지만 웹 기술이 발전함에 따라, 꼭 사용자가 특정한 주소로 접속하지 않더라도 필요에 따라 사용자에게 대화식으로 적절한 정보를 알아서 전달해야 할 필요가 발생하였다. 그 동안은 Adobe의 Flash나 Microsoft의 Silverlight와 같이 개별 회사들이 들의 기술이 이러한 목적으로 활용되었지만, 이러한 이유로 최근의 HTML5 표준에서는 Server-Push에 대한 항목을 포함하고 있다. 앞에서는 데이터의 폭발적 증가에 따라 이를 빠르게 처리하기 위해 데이터 스트림 기술이 적용되는 사례만을 지적하였다. 이와 더불어 최근에는 사용자의 이용 패턴 자체가 푸쉬 기반 모델과 적합하기에 이러한 방식으로 처리되는 경우도 증가하고 있음을 주목할 필요가 있다. 실시간 데이터 처리에서 데이터 스트림 장점 DBMS를 실시간 데이터 처리에 활용할 경우, 다음과 같은 문제가 있다. 데이터의 변경에 관계없이, 사용자가 요청할 때에만 데이터를 전달 (pull-based model)한다. 이는 데이터가 발생하는 빈도를 알지 못할 경우, 너무 빈번한 요청이나 반대의 경우 모두 낭비를 초래한다. 두 번째로 DBMS는 모든 데이터를 저장하고, 모든 데이터를 같은 비중으로 중요하게 다루도록 설계되어 있기 때문에, 비록 최근의 데이터만 접근하는 경우에도 모든 데이터를 검사하거나 이를 유지하기 위한 인덱스 구조를 역시 유지하고 탐색해야 한다. 하지만, 실제로 실시간 데이터를 처리/분석하는 경우에는 최근의 데이터에 대해서만 관심이 있는 경우도 많다. 세 번째로 최근의 데이터에 해당하는 모든 레코드 대해 이전에 매번 반복적으로 계산을 반복해야 한다. 실제로 매 초간 데이터를 반복적으로 조회하는
경우, 1) 데이터가 변하지 않거나 2) 데이터의 일부만 변경된 경우, 이에 대한 계산만을 효율적으로 할 수 있음에도 이러한 최적화를 구조적으로 적용하기 어렵다. 마지막으로, 원래 DBMS는 은행업무와 같이 트랜잭션을 처리를 위해 설계되었다. 이를 위해 이론적으로 ACID 속성 2 을 만족해야 한다. 이는 추가로 동시성 제어나 복구 기능을 필요로 한다. 이러한 기능은 실시간 데이터 처리를 위한 성능 저하 요인이 된다. 위에서 설명한 문제점을 확인하기 위해 예제를 준비하였다. 실시간 데이터를 처리가 필요한 상황을 가정하기 위해 위에서 사용한 증권 거래를 이용하겠다. 사용자는 실시간으로 거래가 발생하는 가운데, 최근 11초안에 발생한 증권 거래의 평균 가격을 알고자 한다. 이 문제에 대해 각각 DBMS와 SPE는 어떻게 처리하는지 살펴보고, 데이터 스트림 시스템(SPE)의 장점에 대해 살펴본다. 아래의 오류! 참조 원본을 찾을 수 없습니다.그림7은 DBMS가 사용하는 언어인 Structured Query Language (SQL) 3 을 이용하여 최근 11초 동안 발생한 데이터에 대해서 평균을 구하는 예제이다. sysdate 는 SQL 질의를 보내는 현재 시각을 나타낸다. 예제에서는 현재 시각이 09:05:25의 값을 가진다고 가정하였다. [그림7. RDBMS에서 실시간 데이터를 처리하는 방식] 2 ACID (원자성, 일관성, 독립성, 지속성)는 데이터베이스 트랜젝션이 안전하게 수행되는 것을 보장하는 특성 집합이다. 데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 한다. 여러 개별 단 계로 이루어진다 하더라도 은행 계좌이체를 트랜잭션의 예로 들 수 있다. (출처 : http://ko.wikipedia.org/wiki/acid) 3 SQL(Structured Query Language, 구조화 질의어)는 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안된 컴퓨터 언어이다.
위의 그림7에서 사용한 SQL질의를 언어로 표현하면 다음과 같다. StockTrades 라는 이름을 가지는 테이블에 들어있는 데이터에 대해, 사용자가 질의를 DBMS에 전달하는 현재 시각 (sysdate)에서 11초를 뺀 과거시간부터 현재까지의 모든 값에 대해 평균을 계산해서 알려달라. 데이터베이스에 총 5개의 레코드가 저장되어 있다. 1) 일단 사용자가 질의를 날리면, 2) 이중 최근 11초에 해당하는 값을 구하기 위해 time 값과 현재 시각( sysdate )에서 11초를 뺀 09:05:14를 비교하여, 이보다 큰 레코드를 3건 추출한다. 3) 조건을 만족하는 레코드에 대해 평균을 구하는 연산을 수행하여 결과가 나오면, 4) 사용자는 결과를 한 건씩 가져간다. 이후에 새로운 데이터가 추가되면 어떻게 될까? DBMS에서는 이전에 어떠한 연산 결과가 있었는지에 관계없이 위에서 반복했던 모든 연산 1) 탐색과 2) 필터링 3) 집합연산을 새로 반복해야만 한다. 이러한 불합리한 구조를 개선하기 위해 실시간 데이터를 처리하기 위한 SPE (Stream Processing Engine)이 개발되었다. 그럼 SPE에서는 이를 어떻게 처리하는지 살펴보도록 하자. 아래의 오류! 참조 원본을 찾을 수 없습니다.그림8에서 사용된 SQL (Stream Query Language) 언어는 Altibase Data Stream (ADS) 제품에서 실제로 사용되는 문법이다. DBMS를 위한 SQL (Structured Query Language) 표준과 거의 유사하도록 설계하였다. 이러한 문법은 기존의 DBMS개발자로 하여금 새로운 기술에 대한 학습 비용을 줄이고, 기존 지식을 이용하여 더 직관적으로 새로운 시스템을 이해하도록 돕기 위함이다. 아래의 예제에서는 추가로 시간의 흐름에 따라 지속적으로 최근(예: 11초, 1일, 혹은1년)의 데이터를 분석하기 위해, 시간 단위의 슬라이딩 윈도우 (Time-based Sliding Window)라는 기능이 사용되었다. [그림8. SPE에서 실시간 데이터를 처리하는 방식]
위의 오류! 참조 원본을 찾을 수 없습니다.그림8에서 사용한 질의를 언어로 표현하면 다음과 같다. StockTrades 라는 스트림 (흘러가는 데이터)에서 최근 11초간 발생한 평균 가격을 계산해라. SPE 시스템 (구현 방식은 시스템에 따라 다를 수 있어 이하 ADS라 지칭함)은 다음과 같이 동작한다. 먼저 {09:05:15, KT, 3500} 데이터가 입력되면, ADS는 이를 포함한 이전 세 이벤트에 대한 평균값 (3500)을 계산에서 사용자에게 전달한다. 시간이 흘러 9시 5분 16초가 지나면 가장 처음에 입력된 데이터 (09:05:05)는 최근 11초 범위를 벗어난 값이 된다. 따라서 이 값은 평균 계산에서 제외한다. 시간이 흘러, 다시 {09:05:20, ALTIBASE, 6000}이 입력되면, 이 값을 평균에 적용하여 사용자에게 새로운 평균값 (4500)을 알린다. 시간이 흘러 {09:05:25, IBM, 2500}이 입력되면 역시 최근의 11초 간의 평균값 (4000)을 갱신하여 사용자에게 알려준다. 복수의 값에 대해 최대, 최소, 합계, 평균 등과 같은 계산을 수행하는 함수를 집합 함수 (Aggregation Function)라 부른다. 이러한 집합함수를 기존의 DBMS는 사용자가 SQL 질의를 요청한 시점에 매번 반복적으로 수행할 수 밖에 없다. 이는 데이터의 크기에 비례하여 매우 수행하는데 많은 시간이 걸릴 수 있다. 반면 SPE는 실시간으로 변경된 데이터에 대해서만 지속적으로 값을 갱신하여 사용자에게 알려주는 실시간 집합 함수 기능을 가지고 있다. 이는 변경된 값만 더하고, 빼는 식으로 동작하므로 실시간으로 최신 결과를 얻을 수 있다 위와 같이 실시간으로 데이터를 분석하여 처리해야 하는 경우에는 DBMS보다는 SPE를 이용하는 것이 훨씬 유리하다. 데이터의 양이 적거나 성능이 중요한 이슈가 아니라면 기존의 DBMS를 활용하여도 별 문제가 없지만, 그렇지 않은 경우에는 SPE를 활용해야만 한다. 이러한 이유로 최근 미국의 대형 소프트웨어 업체들은 앞다투어 스트림 이벤트 처리 기술을 가진 업체를 인수하여 기술을 개발하고 있다. 데이터 스트림 활용 분야 (1) 금용 서비스 분야 미국에서 규제에 대해 논의가 있는 고빈도 거래(High Frequency Trading, HFT)이 대표적이다. 한 기사에 따르면 미국의 투자은행 골드만 삭스 (Goldman Sachs)는
2010년 1분기 하루도 돈을 잃은 적이 없다고 한다. 이에 대한 이유로 컴퓨터를 이용한 고빈도 거래를 꼽는 이도 있으며 이는 향후 규제의 이유가 될 것으로 보인다. 이러한 분야에서는 보안등의 이유로 일반화된 스트림 관리 시스템을 사용하기 보다는 고급 프로그래머를 고용하여 직접 시스템을 개발하는 경우가 많다. 그 외에도 거래 내용을 모니터링 하거나 컴퓨터를 이용한 (고빈도가 아니더라도 ) 알고리즘 거래 등에도 데이터 스트림 기술은 활용된다. (2) 경영 정보(Business Intelligence, BI) 분야 이는 기업의 데이터를 수집, 정리, 분석하고 이를 이용하여 의사결정에 활용하는 방법에 대해 다룬다. 경영 정보 시스템은 과거, 현재, 그리고 예측에 대한 관점을 제공하는데 이를 위해 실시간 데이터 처리 및 분석은 핵심적인 기술이다. (3) 제조 공정 관리 분야 원유 정제나 화학 공장 혹은 식품이나 자동차와 같은 생산 라인에서는 각각의 생산 단계 별로 연속적인 실시간 데이터가 발생한다. 자동화된 공장에서는 이러한 실시간 데이터를 적절히 처리하여 다른 단계로 전달하고, 혹시 데이터를 바탕으로 문제가 있는지 사전에 감지하는 소프트웨어가 필요하다. (4) 시스템 모니터링 분야 네트워크 모니터링을 통해 DOS(Denial of Service)공격을 사전에 탐지한다거나 침임 혹은 웜이나 바이러스의 침투 등에 대해 사전에 감지하여 대처할 수 있다. 그 밖에도 이와 비슷한 시스템이 거대한 컴퓨터 시스템의 상태 모니터링으로 활용되기도 한다. CPU, SAN을 비롯한 각각의 하드웨어 구성요소를 비롯하여 개별 서버 소프트웨어 (Web Server, Mail Server, DBMS, 등) 역시 고유의 메시지를 생성한다. 이러한 메시지를 종합하여 전체적인 상태를 모니터링 하기 위한 목적으로 데이터 스트림 시스템이 활용된다. (5) RFID 및 센서 네트워크 분야 최근에는 다양한 목적으로 RFID 태그와 같은 센서를 많이 활용한다. 현재는 상품유통을 위해 아직 바코드를 이용하여 제품을 관리하는 경우가 많지만, 향후 RFID가 이를 대체할 것으로 예상된다. RFID는 바코드와 달리 각각이 자신의
위치정보를 비롯한 많은 정보를 메시지 형태로 방출할 수 있다. 따라서 이러한 메시지를 모아 유통 효율을 위해 실시간을 최적화 할 수 있다. 이 경우, 데이터 스트림 시스템의 활용은 불가피하다[3]. 무선 센서 네트워크는 RFID보다 한 단계 발전된 기술로 각각의 센서가 독립적인 전원을 가지고 온도, 압력, 습도 등의 정보를 측정하여 전송한다. 이러한 센서 네트워크는 기상관측이나 다리와 같은 건축물의 노후와 측정을 비롯한 우리가 상상할 수 있는 많은 분야에서 사용될 수 있다. 센서 네트워크 분야가 발전한다면 이에 맞추어 스트림 처리에 대한 요구 역시 늘어날 것으로 보인다. 결론 그 동안 실시간 데이터 처리를 위한 기술에 대해 살펴보았다. 이를 위해 데이터 스트림이라는 개념 및 푸쉬 기반 모델에 대해 언급하였다. 추가로 실시간 데이터 처리 및 분석 분야에 기존의 DBMS를 사용하기 어려운 이유에 대해서도 살펴보았다. 마지막으로 이러한 데이터 스트림 분야가 활용되는 금융, 경영정보, 제조 공정 관리, 네트워크 및 시스템 모니터링, RFID 및 센서 네트워크 분야에 대해 살펴보았다. 데이터 스트림은 아주 새롭게 등장한 개념은 아니지만, 정보의 흐름이 빨라지고, 데이터의 양이 늘어 남에 따라 기존의 DBMS에서 처리하기 어려운 실시간 데이터 처리 및 분석 분야에서 필수 기술로 활용되고 있으며, 앞으로도 이에 대한 수요는 꾸준히 증가할 것으로 예상한다. [참고 자료] 1. Hyde. Data in Flight. Communications of the ACM (2010) vol. 53 (1) pp. 48-52 2. Data, data everywhere. Economist SPECIAL REPORT (2010) (February 25th) 3. Hellerstein and Stonebraker. Chapter 10. Stream-Based Data Management. Readings in Database Systems, Fourth Edition, MIT Press (2005) 4. Luckham. What s the Difference Between ESP and CEP?. http://complexevents.com (2006) 5. Babcock et al. Models and issues in data stream systems. Proceedings of the twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems (2002) pp. 1-16 6. Golab et al. Issues in data stream management. SIGMOD Record (2003) vol. 32 (2) pp. 5-14 7. Altibase Data Stream (ADS) http://www.altibase.com 문의 : KT 종합기술원 기술전략담당 기술분석Task(rnd@kt.com)