IT기술의 급속한 발전으로 인류가 생산하는 디지털 데이터가 폭발적으로 증가하고 있다. 2000년 뉴멕시코에 천체 만원경이 설치되고, 고작 몇 주간 생성한 데이터가 인류 역사 전체에 걸쳐 생성된 천문 데이터의 양을 뛰어 넘었다고 한다. 또한 미국의 월마트(Wall Mart)는 시간 당 100만 건의 판매 업무를 처리하는데, 이 데이터는 1.5 페타바이트(Petabyte = 1024 Terabytes)이며 이는 미국 국회 도서관이 보유한 책의 167배에 해당하는 양이다. 이 글에서는 데이터의 양의 증가함에 따라 이를 실시간으로 분석하여 처리하는 기술에 대해 다루고자 한다.

김재명 알티베이스 선임연구원 jmkim@altibase.com

데이터 양이 증가함에 따라, 이에 대한 처리 및 분석 역시 중요해지고 있다. 이러한 추세에 따라 최근에는 미국의 오라클, IBM, 마이크로소프트, SAP 등과 같은 소프트웨어 기업들은 데이터 관리 및 처리 기술을 가진 회사를 인수하는데 약 150억 달러(한화 약 18조원)를 지출했다. 전 세계 데이터 처리 및 관리 등과 관련된 시장 규모는 연간 약 1000억 달러 정도로 추산되고 있으며 매년 10% 가량 성장하고 있다. 기업 비즈니스 환경도 과거와 비교할 수 없이 실시간으로 생성되는 데이터의 양이 증가함에 따라 기존의 데이터베이스 관리 시스템(Database Management System, DBMS)으로 처리하는 것은 한계에 부딪히게 됐다. 이를 위해 실시간 데이터를 처리하기 위한 데이터 스트림 처리 시스템(Stream Processing Engine 혹은 Complex Event Processing Engine, CEP)이 개발됐다. 움직이는 데이터 데이터 스트림 처리란 이전에는 없던 새로운 개념이 아니다. 이는 데이터가 발생되는 상황을 바라보는 관점에 따른 기술이다. 기존의 DBMS에서 데이터를 정적인 관점으로 보았다면, 데이터를 움직이는(혹은 흘러가는) 관점으로 바라보는 것이다. 설령 자각하지 못하였더라도, 우리는 이미 이런 개념을 기반으로 한 서비스와 함께 생활하고 있다. 어항에 물고기가 있다고 생각해 보자. DBMS에서는 데이터를 정적으로 바라본다. 이 때문에 마치 어항에 물이 저장되어 있고, 물고기는 어항에 포함되어 ‘존재하는’ 것으로 인식한다. 만일 어항에 물고기가 세 마리가 있다면, 누군가 물고기를 빼거나(Delete) 더하지(Insert) 않는 이상 어항 속의 물고기 수는 변하지 않는다. 반면, 낚시꾼이 강에서 낚시를 드리우고 있다고 생각해보자. 강물이 흐르고, 물고기가 헤엄을 쳐서 이동하기 때문에 특정한 낚싯대를 드리운 지점에서 바라보는 물고기는 계속 변화한다. 물고기는 계속 이동하기 때문에 낚싯대는 언제 드리우냐에 따라 걸려드는 물고기도 달라질 것이다. 이렇듯 새로 발생한 데이터를 흘러가는 관점에서 바라보는 것이 CEP(Complex Event Processing)에서 바라보는 데이터 스트림이다. 의 테이블은 증권 거래에서 발생할 수 있는 데이터를 가상으로 표현한 것이다. 오전 9시5분5초부터 25초까지 5건의 거래가 발생했고, 이를 DBMS에서 처리하기 위해서는 과 같은 테이블로 저장돼야 한다. 하지만 CEP 엔진의 경우, 실시간 데이터를 데이터의 흐름(스트림)으로 바라보기 때문에 와 같이 시간이 흐름에 따라 5개의 이벤트(데이터)가 발생한 것으로 바라볼 수 있다. 데이터를 처리하기 위해 꼭 의 관계형 테이블에 먼저 저장 후 처리할 필요는 없다. 다시 요약하면, DBMS와 CEP 엔진의 가장 큰 차이점은, 데이터베이스(DBMS)는 모든 데이터를 먼저 저장 후 처리하는 반면, CEP엔진은 데이터가 발생한 즉시 반응해 처리하도록 설계되었다는 것이다. 동적 데이터 처리 사례 DBMS는 데이터를 정적인 관점으로 바라본다. 데이터베이스에 사용자의 추가/ 삭제/ 수정 (INSERT/ DELETE/ UPDATE) 연산을 허용하지만, 사용자가 데이터에 접근하는 순간에는 (실제로 데이터가 변경되고 있음에도) 데이터는 고정되어 있다는 착각을 제공해 줘야 한다. 또 다른 특징은 아무리 데이터베이스에 많은 변경이 발생하고 있더라도, 사용자가 명시적으로 데이터를 읽어오기(SELECT) 전에는 사용자에게 어떠한 정보도 알릴 필요가 없다. 데이터베이스는 단지 사용자가 데이터를 요청하는 순간에만 데이터를 제공해 줄 의무를 가진다. 이러한 특징을 가지는 모델을 사용자가 원할 때, 준다는 의미로 요청기반 모델(Pull-based Model)이라 부른다. 이때, 데이터를 요구하는 사용자는 동적(active party)이고, 데이터를 제공하는 시스템은 정적(passive party)이다. 반면 CEP는 데이터를 동적인 관점으로 바라본다. 사용자가 명시적으로 요구하지 않더라도 데이터가 동적으로 사용자에게 전달(push)돼야 한다. 이메일 서비스는 원래 요청기반 모델을 기반으로 설계됐다. 사용자가 이메일을 확인하지 않는 한 이메일이 사용자에게 전달되지 않는다. 혹은 이를 위해 응용프로그램에서 매 10분마다 이메일을 자동으로 확인하게 하도록 스케줄을 설정해야만 했다. 모두 명시적으로 데이터를 확인하는 경우에만 데이터가 전달되므로 요청기반 모델이라 할 수 있다. 최근 아이폰을 비롯한 스마트폰에서는 이메일 푸쉬(push)라는 서비스를 제공해주고 있다. 사용자가 명시적으로 이메일을 확인하지 않더라도, 새로운 이메일이 도착 시 사용자에게 알려주는 서비스이다. 이런 서비스는 CEP에서 바라보는 스트림 관점으로 이메일이라는 데이터(혹은 이벤트)를 바라보고 서비스를 제공하는 것이다. 이는 푸쉬기반 모델(Push-based Model)로 설계된 것이라 볼 수 있다. 아이폰을 보면, 이러한 푸쉬기반 모델을 이메일 뿐 아니라 다른 애플리케이션에도 활용할 수 있도록 설계했음을 알 수 있다. 덕분에 우리는 트위터(twitter)나 카카오톡과 같은 서비스에서 발생한 이벤트에 대해서도 푸쉬 서비스를 받을 수 있다. 과거의 시스템은 대부분 요청기반 모델을 기반으로 설계됐다. 예를 들어 웹 브라우저를 통해 인터넷 상의 특정 주소(Uniform Resource Locator, URL)에 접속하면, 해당하는 웹서버는 미리 준비된 정보를 서로 약속된 언어로(Hyper Text Markup Language, HTML) 전달해주게 된다. 기술의 발전에 따라, 사용자가 특정한 주소로 접속하지 않더라도 필요에 따라 사용자에게 적절한 정보를 전달해야 할 필요가 발생했다. 이러한 요구에 부응하기 위해 Adobe Flash Platform이나 Microsoft Silverlight Platform과 같이 개별 회사들의 기술이 활용됐다. 최근 HTML5 표준에 Server-Sent Events2 에 대한 항목을 포함하는 것은 이러한 이유라 한다. 앞에서는 데이터의 양과 발생 속도의 증가에 따라 이를 빠르게 처리하기 위해 데이터 스트림 기술이 적용되는 사례만을 지적했다. 이와 더불어 최근에는 사용자의 이용 패턴 자체가 푸쉬 기반 모델과 적합하기에 이러한 방식으로 처리되는 경우도 증가하고 있음을 주목할 필요가 있다. DBMS와 CEP의 기술적 비교 DBMS를 실시간 데이터 처리에 활용할 경우, 다음과 같은 문제가 있다. 데이터의 변경에 관계없이, 사용자가 요청할 때에만 데이터를 전달 (pull-based model)한다. 데이터가 발생하는 빈도와 사용자의 요청 빈도를 맞추기가 쉽지 않다. 특히, 데이터가 발생하는 경우에만 처리하고자 하는 상황에는 적합하지 않다. 두 번째로 DBMS는 모든 데이터를 저장하고, 모든 데이터를 같은 비중으로 중요하게 다루도록 설계되어 있기 때문에, 비록 최근의 데이터만 접근하는 경우에도 모든 데이터를 검사하거나 이를 유지하기 위한 색인(index)을 유지하고 탐색해야 한다. 이에 반해, 실시간 데이터를 처리/분석하는 경우, 최근의 데이터에 대해서만 관심이 있는 경우도 많아 DBMS의 구조는 적합하지 않다. 세 번째로 데이터 변경 후 집합함수3을 계산할 때, 변경된 양이 아무리 적더라도 테이블에 포함된 모든 레코드에 대해 매번 계산을 반복해야 한다. 실제로 매 초간 데이터를 반복적으로 조회하는 경우 △ 데이터가 변하지 않거나 △ 데이터의 일부만 변경된 경우, 이에 대한 계산만을 효율적으로 할 수 있음에도 이러한 최적화를 구조적으로 적용하기 어렵다. 또한 DBMS는 은행업무와 같이 트랜잭션의 처리를 위해 설계되었다. 이를 위해 이론적으로 ACID 속성4을 만족해야 한다. 이는 추가로 동시성 제어나 복구 기능을 필요로 한다. 이러한 기능은 실시간 데이터 처리를 위한 성능 저하 요인이 된다. 위에서 언급한 문제점을 드러내기 위해 예제를 준비했다. 실시간 데이터에 대한 처리가 필요한 상황을 가정하기 위해 앞에서 사용한 증권 거래를 예제로 활용했다. 사용자는 실시간으로 거래가 발생하는 가운데, 최근 11초안에 발생한 증권 거래의 평균 가격을 알고자 한다. 이 문제에 대해 각각 DBMS와 CEP는 어떻게 처리하는지 살펴보고, 데이터 스트림 시스템(CEP)의 장점에 대해 살펴본다. 는 DBMS가 사용하는 언어인 Structured Query Language(SQL)5를 이용해 최근 11초 동안 발생한 데이터에 대해서 평균을 구하는 예제이다. ‘sysdate’는 SQL 질의를 보내는 현재 시각을 나타낸다. 예제에서는 현재 시각이 09:05:25의 값을 가진다고 가정했다. 에서 사용한 SQL질의를 자연어로 표현하면 다음과 같다. “‘StockTrades’라는 이름을 갖는 테이블에 들어있는 데이터에 대해, 사용자가 질의를 DBMS에 전달하는 현재 시각 (sysdate)에서 11초 이전의 과거시간부터 현재까지의 모든 값에 대해 평균을 계산해서 알려달라.” 데이터베이스에 총 5개의 레코드가 저장되어 있다. 일단 사용자가 질의를 수행하면 이중 최근 11초에 해당하는 값을 구하기 위해 ‘time’ 값과 현재시각(‘sysdate’)에서 11초 이전인 09:05:14를 비교해, 이보다 큰 레코드를 3건 추출한다. 조건을 만족하는 레코드에 대해 평균을 구하는 연산을 수행하여 결과가 나오면, 사용자는 결과를 한 건씩 가져간다. 이후에 새로운 데이터가 추가되면 어떻게 될까. DBMS에서는 이전에 어떠한 연산 결과가 있었는지에 관계없이 위에서 반복했던 모든 연산, 탐색과 필터링, 집합연산을 새로 반복해야만 한다. 이러한 불합리한 구조를 개선하기 위해 실시간 데이터를 처리하기 위한 CEP (Complex Event Processing) 엔진이 개발됐다. 그럼 CEP에서는 이를 어떻게 처리하는지 살펴보도록 하자. 에서 사용된 CQL (Continuous Query Language) 언어는 Altibase Data Stream(ADS) 제품에서 실제로 사용되는 문법이다. DBMS를 위한 SQL (Structured Query Language) 표준과 거의 유사하도록 설계했다. 이러한 문법은 기존의 DBMS개발자로 하여금 새로운 기술에 대한 학습 비용을 줄이고, 기존 지식을 이용해 더 직관적으로 새로운 시스템을 이해하도록 돕기 위함이다. 아래 예제에서는 시간의 흐름에 따라 지속적으로 최근(예: 11초, 1일, 혹은1년)의 데이터를 분석하기 위해 시간 단위의 슬라이딩 윈도우 (Time-based Sliding Window) 기능이 사용됐다. 이는 DBMS에서는 지원하지 않는 기능이다. 에서 사용한 질의를 자연어로 표현하면 다음과 같다. “’StockTrades’라는 스트림 (흘러가는 데이터)에서 최근 11초간 발생한 평균 가격을 계산하라”. CEP 엔진 (구현 방식은 시스템에 따라 다를 수 있으며, 이하 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)을 갱신하여 사용자에게 알려준다. 평균을 구하는 집합함수(AVG) 를 DBMS는 사용자가 SQL 질의를 요청한 시점에 매번 반복적으로 수행할 수 밖에 없다. 이는 데이터의 크기와 요청 빈도에 비례하여 수행시간이 증가하는 구조이다. 반면 CEP는 실시간으로 변경된 데이터에 대해서만 지속적으로 값을 갱신해 사용자에게 알려주는 실시간 집합 함수 기능을 가지고 있다. 변경된 값만 더하고, 빼는 식으로 동작하므로 실시간으로 최신 결과를 얻을 수 있다. 위에서 언급된 이유들로 실시간으로 데이터를 분석해 처리해야 하는 경우 DBMS보다는 CEP를 이용하는 것이 유리하다. 데이터의 양이 적거나 성능이 중요한 이슈가 아니라면 기존의 DBMS를 활용하여도 별 문제가 없지만, 그렇지 않은 경우에는 CEP를 활용해야만 한다. 이러한 이유로 최근 미국의 대형 소프트웨어 업체들은 앞다퉈 스트림 이벤트 처리 기술을 가진 업체를 인수하여 기술을 개발하고 있다. CEP 활용 분야 데이터 스트림이 활용되는 대표적인 분야 중 하나는 금융 서비스 분야이다. 미국에서 규제에 대해 논의가 있는 고빈도 거래(High Frequency Trading, HFT)가 대표적이다. 한 기사에 따르면 미국의 투자은행 골드만 삭스 (Goldman Sachs)는 2010년 1분기 하루도 돈을 잃은 적이 없다고 한다. 이에 대한 이유로 컴퓨터를 이용한 고빈도 거래를 꼽는 이도 있으며 이는 향후 규제의 이유가 될 것으로 보인다. 이러한 분야에서는 보안 등의 이유로 일반화된 스트림 관리 시스템을 사용하기 보다는 고급 프로그래머를 고용해 직접 시스템을 개발하는 경우가 많다. 그 외에도 거래 내용을 모니터링 하거나 컴퓨터를 이용한 (고빈도가 아니더라도) 알고리즘 거래 등에도 데이터 스트림 기술은 활용된다. 다른 주요한 분야는 경영 정보(Business Intelligence, BI) 분야6이다. 여기서는 기업의 데이터를 수집, 정리, 분석하고 이를 이용해 의사결정에 활용하는 방법에 대해 다룬다. 경영 정보 시스템은 과거, 현재, 그리고 예측에 대한 관점을 제공하는데 이를 위해 실시간 데이터 처리 및 분석은 핵심적인 기술이다. 세 번째는 제조 공정 관리 분야이다. 원유 정제나 화학 공장 혹은 식품이나 자동차와 같은 생산 라인에서는 각각의 생산 단계 별로 연속적인 실시간 데이터가 발생한다. 자동화된 공장에서는 실시간 데이터를 적절히 처리해 다음 단계로 전달하고, 문제가 있으면 사전에 혹은 ‘실시간으로’ 감지하는 소프트웨어가 필요하다. 네 번째 분야는 네트워크를 비롯한 시스템 모니터링 분야이다. 네트워크 모니터링을 통해 DOS(Denial of Service)공격을 사전에 탐지한다거나 침임 혹은 웜이나 바이러스의 침투 등에 대해 사전에 감지해 대처할 수 있다. 이밖에도 이와 비슷한 시스템이 거대한 컴퓨터 시스템의 상태 모니터링으로 활용되기도 한다. 프로세서(CPU), 메모리를 비롯한 각각의 하드웨어 구성요소를 비롯해 개별 서버 소프트웨어 (Web Server, Mail Server, DBMS, Storage Area Network등) 역시 고유의 메시지를 생성한다. 이러한 메시지를 종합하여 전체적인 상태를 모니터링 하기 위한 목적으로 데이터 스트림 시스템이 활용된다. 최근에는 다양한 목적으로 RFID 태그와 같은 센서를 많이 활용한다. 현재는 상품유통을 위해 아직 바코드를 이용해 제품을 관리하는 경우가 많지만, 향후 RFID가 이를 대체할 것으로 예상된다. RFID는 바코드와 달리 각각이 자신의 위치정보를 비롯한 많은 정보를 메시지 형태로 방출할 수 있다. 따라서 이러한 메시지를 모아 유통 효율을 위해 실시간으로 최적화 할 수 있다. 이 경우, 데이터 스트림 시스템의 활용은 불가피하다[3]. 이 외에도 CEP 기술은 무선 센서 네트워크 분야에서도 활용된다. 무선 센서 네트워크는 RFID보다 한 단계 발전된 기술로 각각의 센서가 독립적인 전원을 가지고 온도, 압력, 습도 등의 정보를 측정하여 전송한다. 이러한 센서 네트워크는 기상관측이나 다리와 같은 건축물의 노후와 측정을 비롯한 우리가 상상할 수 있는 많은 분야에서 사용될 수 있다. 센서 네트워크 분야가 발전한다면 이에 맞추어 스트림 처리에 대한 요구 역시 늘어날 것으로 보인다. 데이터 스트림은 아주 새롭게 등장한 개념은 아니지만, 정보의 흐름이 빨라지고, 데이터의 양이 늘어남에 따라 기존의 DBMS에서 처리하기 어려운 실시간 데이터 처리 및 분석 분야에서 필수 기술로 활용되고 있으며, 앞으로도 이에 대한 수요는 꾸준히 증가할 것으로 예상된다.