빅데이터를 지탱하는 기술 Ch4 - 빅데이터의 축적

벌크 형과 스트리밍 형의 데이터 수집

객체 스토리지와 데이터 수집

빅데이터는 대부분 확정성이 높은 분산 스토리지에 저장된다. 데이터베이스가 이용되는 경우도 있지만, 기본적으로 객체 스토리지에 저장한다. HDFS, Amazon S3 등이 유명하다.

 

※ 스토리지와 데이터베이스의 차이

스토리지는 파일 형태가 되면 무엇이든 담을 수 있다. DB는 서버를 통해 가공된 데이터가 담긴다. 게시판에서 글은 DB에 담기고, 업로드한 파일은 스토리지에 담긴다. 스토리지에 저장된 데이터를 더욱 사용하기 쉽게 만들어주는 것이 데이터베이스라고 할 수 있다. 이러한 객체 스토리지는 작은 데이터에는 오히려 비효율적이다. 네트워크를 거쳐 실행하기 때문에 데이터양에 비해 통신 오버헤드가 너무 크기 때문이다.

데이터 수집

객체 스토리지는 대량의 작은 파일을 저장하면 성능을 저하시키는 요인이 된다. 따라서 작은 데이터는 적당히 모아서 하나의 큰 파일로 만듦으로서 효율을 높이는 데 도움이 된다. 그것과 반대로 파일이 지나치게 커도 안된다. 파일 크기가 증가하면 네트워크 전송에 시간이 걸려 예상치 못한 오류 발생률을 높인다. 이러한 데이터는 적당히 나눔으로써 문제 발생을 줄일 수 있다. 객체 스토리지에서 효율적으로 처리할 수 있는 파일 크기는 대략 1MB에서 1GB이다.

 

수집한 데이터를 가공해서 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스를 데이터 수집(Data ingestion)이라고 한다. 여기에는 데이터 수집부터 구조화 데이터의 작성, 분산 스토리지에 대한 장기적인 저장 등이 포함된다.

벌크 형의 데이터 전송

전통적인 데이터 웨어하우스에서 사용된 것이 주로 벌크 형 방식으로 DB나 파일 서버 또는 웹 서비스 등에서 SQL, API로 정리해 데이터를 추출한다.

데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 ETL 서버를 설치해야 한다.

파일 사이즈 적정화

벌크 형 도구로 파일 사이즈를 적정화하는 것은 비교적 간단하다. 데이터를 너무 자주 전송하고 있다면 한 번의 전송에 모든 파일을 포함하도록 변경하고, 또 너무 많은 양의 데이터를 한꺼번에 전송한다면 작은 태스크로 분해해 한 번의 태스크 실행이 커지지 않도록 조정한다. 이러한 작업은 워크플로 관리 도구를 사용해 쉽게 관리할 수 있다.

데이터 전송의 워크플로

데이터 전송의 신뢰성이 중요한 경우에는 가능한 벌크 형 도구를 사용해야 한다. 벌크 형은 워크플로 관리 도구와의 궁합이 뛰어나다.

스트리밍 형의 데이터 전송

스트리밍 형 데이터 전송의 특징은 다수의 클라이언트에서 계속해서 작은 데이터가 전송되는 것이다.

이러한 전송 방식을 일반적으로 메시지 전송이라고 한다. 이는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다.

 

메시지를 저장하는 데에는 여러 방법이 있다. 그 중 하나는 작은 데이터 쓰기에 적합한 NoSQL을 이용하는 것이다.

이 경우 Hive와 같은 쿼리 엔진으로 연결해 데이터를 읽을 수 있다.

 

또는 분산 스토리지에 직접 쓰는 것이 아니라 메시지 큐와 메시지 브로커 등의 중계 시스템에 전송할 수 있다.

이 경우 기록된 데이터는 일정한 간격으로 꺼내고 모아서 함께 분산 스토리지에 저장한다.

웹 브라우저에서의 메시지 배송

자체 개발한 웹 어플리케이션에서는 서버 웹 서버 안에서 메시지를 만들어 배송한다.

이때는 Fluentd나 Logstash와 같은 서버 상주형 로그 수집 소프트웨어가 자주 사용된다.

 

아니면 자바스크립트를 이용하여 웹 브라우저에서 직접 메시지를 보내는 경우도 있다.

이것은 웹 이벤트 추적이라고 한다. 수집된 데이터는 그대로 다른 서버로 전송되거나 API 경유로 함께 취득해 그것을 분산 스토리지에 저장함으로써 다른 데이터와 조합한 분석이 가능해진다.

모바일 앱으로부터의 메시지 배송

모바일 앱은 HTTP 프로토콜을 사용하는 클라이언트이기 때문에 웹 브라우저와 동일하다. 또한 서버를 직접 마련하는 것이 아니라 MBaas라는 백엔드의 각종 서비스를 이용할 수도 있다.

아니면 모바일 앱에 톡화된 엑세스 해석 서비스를 통해 이벤트 데이터를 수집한다. 이 경우 서비스에서 제공되는 모바일 용의 SDK를 사용하여 메시지를 보낸다.

디바이스로부터의 메시지 배송

아직까지 디바이스로부터 메시지 전달은 표준이라고 할 만한 것 없이 많은 규격이 난립하고 있다.

그 중 MQTT는 TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나이며, 일반적으로 Pub(전달)/Sub(구독) 형 메시지 배송의 구조를 가진다. 주로 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술이다.

 

MQTT에서는 관리자에 의해 토픽이 만들어진다. 이는 대화방 같은 것으로, 그 토픽을 구독하면 메시지가 도착하고, 그 토픽을 전달하면 구독 중인 모든 클라이언트에 보내진다.

메시지 배송의 공통화

메시지 배송 방식은 어디에서 데이터를 수집하느냐에 따라 전혀 다르다. 여기서는 메시지가 처음 생성되는 기기를 클라이언트, 해당 메시지를 받는 서버를 프론트 엔드라고 한다. 프런트 엔드의 역할은 클라이언트와의 통시 프로토콜을 제대로 구현하는 것이다.

메시지 배송의 트레이드 오프: 성능X신뢰성

클라이언트의 수가 많아지면 스트리밍 형의 메시지 배송의 성능과 신뢰성을 둘 다 만족하기는 어렵게 된다.

메시지 브로커

대량의 메시지를 안정정으로 받기 위해서 빅데이터 메시지 시스템에서는 데이터를 일시적으로 축적하는 중산층이 설치되는데, 이를 메시지 브로커라고 한다.

빅데이터를 위한 분산형 메시지 브로커는 오픈 소스의 경우는 Apache Kafka, 클라우드 서비스라면 Amazon Kinesis 등이 유명하다.

푸시 형과 풀 형

송신 측의 제어로 데이터를 보내는 방식을 푸시형이라고 하고, 수신 측의 주도로 데이터를 가져오는 것을 풀형이라고 한다.

메시지 브로커에 데이터를 푸시하는 것을 생산자(producer), 메시지 브로커의 데이터를 풀하는 것을 소비자(consumer)라고 한다. 메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화되어 있고, 뛰어난 확장성을 구현하고 있어서 푸시형의 메시지 배송은 모두 메시지 브로커에 집중시키고 거기에서 일정한 빈도로 꺼낸 데이터를 분산 스토리지에 기록하여 성능 문제를 피할 수 있다.

메시지 라우팅

메시지 브로커에 써넣은 데이터는 복수의 다른 소비자에서 읽어 들일 수 있다. 이를 통해 메시지가 복사되어 데이터를 여러 경로로 분기시킬 수 있다. 이것을 메시지 라우팅이라고 한다. 예를 들어, 메시지 일부를 실시간 장애 감지를 사용하면서 같은 메시지를 장기적인 데이터 분석을 위한 분산 스토리지에 저장하는 것도 가능하다.

메시지 배송을 확실하게 실시하는 것은 어렵다.

성능 문제 외에도 피할 수 없는 것이 신뢰성 문제이다. 이는 다음 중 하나를 보장하도록 설계하여 처리한다.

 

at most once

무슨 일이 일어나도 절대로 메시지를 다시 보내지 않는다. 그러나 도중에 전송에 실패해서 사라질 가능성이 있다.

 

exactly once

메시지는 손실되거나 중복 없이 한 번만 전달된다. 메시지의 송/수신 측 모두 서로의 정보를 코디네이터에게 전달함으로써 문제가 발생한 경우에는 코디네이터의 지시에 따라 그것을 해결한다. 하지만 이 또한 코디네이터가 문제가 생길 수도 있고, 시간이 너무 소요된다는 단점이 존재한다.

 

at least once

메시지는 확실하게 전달된다. 단, 같은 것이 여러 번 전달될 가능성이 있다. 중복이 발생하지만, 모든 TCP 패킷에서는 그것을 식별하는 시퀀스 번호가 포함되어 있으며, 그것을 이용하여 중복 제거가 이루어진다.

대부분의 메시지 배송 시스템은 이를 보장하는 한편, 중복 제거는 이용자에게 맡기고 있어 TCP/IP처럼 자동으로 중복을 제거해주지 않는다.

데이터 수집의 파이프라인

위와 같은 일련의 프로세스를 거친 다음, 마지막으로 데이터를 구조화해서 열 지향 스토리지로 변환함으로써 데이터 분석에 적합한 스토리지가 완성된다.

시계열 데이터의 최적화

프로세스 시간과 이벤트 시간

• 이벤트 시간: 클라이언트 상에서 메시지가 생성된 시간. 실제 분석의 대상이 되는 시간이다.
• 프로세스 시간: 서버가 처리하는 시간.

프로세스 시간의 문제점

여러 변수로 인해 둘 간의 시간 차이가 분석에 방해가 되기도 한다. 분산 스토리지에 데이터를 넣는 단계에서는 프로세스 시간을 사용하는데, 만약 과거 특정 일에 발생한 이벤트를 집계하고 싶다면 모든 데이터를 로드해야만 원하는 이벤트 시간을 찾을 수 있다.

 

다시 말해, 원하는 파일 하나를 찾기 위해서 모든 파일을 검색하는 풀 스캔을 해야하는 것이다. 이는 시스템의 부하를 높는 요인이 된다. 

시계열 인덱스

RDB에서 인덱스를 만드는 것처럼 이벤트 시간에 대해 인덱스를 만들어 데이터 집계를 빠르게 실행할 수 있다. 여기에는 카산드라와 같은 분산 데이터베이스를 활용할 수 있다. 이는 정해진 시간에 발생한 이벤트를 조사하거나, 실시간 대시보드를 만드는 경우에 유용하다. 하지만 장기간에 걸쳐 대량의 데이터를 집계하는 경우에는 이보다 열지향 스토리지를 만드는 것이 유리하다.

조건절 푸쉬다운

열 지향 스토리지는 칼럼 단위의 통계 정보를 이용하여 최적화가 이루어지기 때문에 이를 활용하여 미리 데이터를 정렬해둠으로써 최소한의 데이터만을 읽도록 하는 조건절 푸쉬다운에 의한 최적화로 풀 스캔을 피할 수 있다.

비구조화 데이터의 분산 스토리지

키-값 스토어

모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소.

키가 정해지면 그 값을 클러스터 내의 어느 노드에 배치할 것인지 결정한다. 이 구조에 의해 노드 간의 부하를 균등하게 분산한다.

 

Amazon DynamoDB

키-값 스토어의 가장 대표적인 예로는 아마존의 다이나모 디비가 있다. 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용하고, 특히 다양한 AWS 서비스와 결합하여 사용할 수도 있다.

다이나모디비와 AWS 서비스의 결합

다이나모 디비에만 국한된 것이 아니라 일반적으로 NoSQL은 데이터를 집계하기에는 적합하지 않다. 따라서 데이터 분석으로 위해서는 외부로 데이터를 추출해야 한다. 읽기 성능이 높기 때문에 쿼리 엔진으로 직접 연결하여 사용할 수 있다.

와이드 칼럼 스토어

하나의 테이블에 가로와 세로의 2차원 데이터를 쓸 수 있도록 한 데이터베이스. Google Cloud Bigtable, Hbase, Cassandra 등이 있다.

Apache Cassandra

카산드라는 와이드 칼럼 스토어를 이용하며서 CQL이라는 쿼리 언어가 구현되어 있다. 테이블의 스키마를 결정할 필요가 있기 때문에 구조화 데이터만을 취급할 수 있다. 

 

분산 아키텍처를 갖고 있으며, 지정한 키에 의해 결정한 노드에 해당 키와 관련된 모든 값을 저장한다. 만약 사용자 ID를 키로 사용하는 경우 그 사용자에 대한 기록은 하나의 노드에 모이고 그 노드 안에서 쿼리가 실행된다. 

 

이것이 활용되는 예를 메시지 서비스를 통해 살펴보자. 각 사용자가 매일 수십 메시지를 기록한다면 이 경우, 사용자 ID를 키로 데이터를 분산하고, 타임스태프로 레코드를 분리함으로써 사용자별 타임라인을 구축할 수 있다. CQL에서는 이러한 거대한 테이블을 복합키를 이용하여 실현한다. 

 

와이드 칼럼 스토어도 데이터 집계에는 적합하지 않으므로, Hive, Presto, Spark 등을 이용하여 데이터를 추출하여야 한다. 

도큐먼트 스토어

도큐먼트 스토어는 주로 데이터 처리의 유연성을 목적으로 한다. JSON처럼 복잡하게 뒤얽힌 스키마리스 데이터를 그대로 저장하고 쿼리를 실행할 수 있게 해준다. 그래서 자체 개발 애플리케이션보다는 외부에서 들여온 데이터를 저장하는 데 특히 적합하다. 

 

MongoDB

몽고디비는 오픈 소스의 분산형 도큐먼트 스토어로 트랜잭션 즉, 신뢰성을 희생한 대신 성능을 높였다. 몽고디비도 여러 노드에 데이터를 분산할 수 있지만 데이터 집계에는 적합하지 않기 때문에 쿼리 엔진으로 접속하여 데이터를 추출할 필요가 있다. 

검색 엔진

검색 엔진은 NoSQL과 조금 성격이 다르지만 쿼리를 사용한다는 점에서는 유사한 부분이 많고, 특히 텍스트 데이터나 스키마리스 데이터를 집계하는데 자주 사용된다. 역색인을 통해 키워드 검색이 훨씬 고속화된다.

 

역색인: 텍스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가 하는 인덱스를 먼저 만들어 둠으로써 검색을 고속화한다. 

 

결과적으로 데이터 집계에 적합하며 실시간 집계 시스템의 일부로 이용된다. 

 

Elasticsearch

엘라스틱 서치는 오픈 소스의 검색엔진으로 로그 수집 소프트웨어 Logstash, 시각화 소프트웨어인 Kibana와 함께 ELK 스택으로 함께 자주 이용된다.

 

기본적으로는 도큐먼트 스토어와 비슷하지만, 쓰기 부하가 더 크고, 필요에 따라 명시적으로 스키마를 결정함으로써 색인을 무효화하는 식의 튜닝이 필요하다.

 

Splunk

스플렁크는 오픈소스는 아니지만 주로 웹서버나 네트워크 기기 등의 로그 파일이나 JSON 파일을 다루어 텍스트 처리해야만 분석할 수 있는 데이터를 처리하는데 적합하다.