[빅데이터를 지탱하는 기술] 4. 빅데이터의 축적 - 벌크 형과 스트리밍 형의 데이터 수집

목차

4. 빅데이터의 축적

 

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

4.1.1. 객체 스토리지와 데이터 수집 - 분산 스토리지에 데이터 읽어들이기

① 데이터 수집

4.1.2. 벌크 형의 데이터 전송 - ETL 서버의 설치 필요성

① 파일 사이즈의 적정화는 비교적 간단하다

② 데이터 전송의 워크플로우

4.1.3. 스트리밍 형의 데이터 전송 - 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송

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

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

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

④ 메시지 배송의 공통화

 

---

4. 빅데이터의 축적

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

데이터 전송에는 벌크 형과 스트리밍 형의 두 종류의 도구가 사용된다. 이 절에서는 각각의 방법으로 분산 스토리지에 데이터가 저장될 때까지의 흐름에 대해 살펴보겠다. 

4.1.1. 객체 스토리지와 데이터 수집 - 분산 스토리지에 데이터 읽어들이기

빅데이터는 대부분의 경우 확장성이 높은 '분산 스토리지(distributed storage)'에 저장된다. 분산 형의 데이터베이스가 이용되는 경우도 있지만, 우선 기본이 되는 것은 대량으로 파일을 저장하기 위한 '객체 스토리지(object storage)'다(그림4.1). Hadoop이라면 'HDFS', 클라우드 서비스라면 'Amazon S3'등이 유명하다.

객체 스토리지에서의 파일 읽고 쓰기는 네트워크를 거쳐서 실행한다. 이때, 그 내부 처리에는 다수의 물리적인 서버와 하드 디스크가 있다. 데이터는 항상 여러 디스크에 복사되기 때문에 일부 하드웨어가 고장 나더라도 데이터가 손실되진 않는다. 데이터의 읽고 쓰기를 다수의 하드웨어에 분산함으로써 데이터의 양이 늘어나도 성능이 떨어지는 일이 없도록 고안되어 있다.

객체 스토리지의 구조는 데이터양이 많을 때는 우수하지만, 소량의 데이터에 대해서는 반대로 비효율적임에 주의가 필요하다. 예를 들어, 100바이트의 작은 파일을 자주 읽고 쓰는 것은 객체 스토리지에는 적합하지 않다. 이것을 데이터양에 비해 통신 오버헤드가 너무 크기 때문이다.

 

① 데이터 수집

빅데이터로 자주 다루는 것은 시계열 데이터, 즉 시간과 함께 생성되는 데이터인데, 그것을 수시로 객체 스토리지에 기록하면 대량의 작은 파일이 생성돼서 시간이 지남에 따라 성능을 저하시키는 요인이 된다. 작은 데이터는 적당히 모아서 하나의 큰 파일로 만듦으로써 효율을 높이는 데 도움이 된다.

그것과는 반대로, 파일이 지나치게 커지는 것도 문제가 있다. 파일 크기가 증가하면 네트워크 전송에 시간이 걸려 예상치 못한 오류 발생률도 높아진다. 만일 1테라바이트의 파일을 100Mbp의 회선으로 전송하면 약 24시간이 소요된다. 그런 거대한 데이터는 한번에 처리하는 것이 아니라 적당히 나눔으로써 문제 발생을 줄일 수 있다. 

빅데이터는 단지 수집만 해서는 안 되고 나중에 처리하기 쉽도록 준비해 둘 필요가 있다. 객체 스토리지에서 효율적으로 처리할 수 있는 파일 크기는 대략 1메가바이트에서 1기가바이트 사이의 범위다. 그것보다 작은 데이터는 모아서 하나로 만들고 큰 데이터는 복수로 나누는 것을 고려해본다(그림 4.2).

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

 

4.1.2. 벌크 형의 데이터 전송 - ETL 서버의 설치 필요성

데이터 전송의 구조에는 벌크 형과 스트리밍 형의 두 가지 종류가 있다. 이 둘은 기술적인 특성도, 사용되는 도구도 전혀 다르므로 그 성질을 이해한 다음에 구분해서 사용해야 한다.

전통적인 데이터 웨어하우스에서 사용된 것은 주로 '벌크 형' 방식으로 데이터베이스나 파일 서버 또는 웹 서비스 등에서 각각의 방식(SQL, API 등)으로 정리해 데이터를 추출한다(그림 4.3). 빅데이터를 다루는 경우에도 과거에 축적된 대량의 데이터가 이미 있는 경우나 기존의 데이터베이스에서 데이터를 추출하고 싶을 경우에 벌크 형의 데이터 전송을 한다.

원래 데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 'ETL 서버(ETL server)'를 설치한다. ETL 서버에는 구조화된 데이터 처리에 적합한 데이터 웨어하우스를 위한 ETL 도구와 오픈 소스의 벌크 전송 도구 또는 손수 작성한 스크립트 등을 이용하여 데이터를 전송한다.

① 파일 사이즈의 적정화는 비교적 간단하다

벌크 형의 도구로 파일 사이즈를 적정화하는 것은 비교적 간단하다. ETL 프로세스는 하루마다 또는 1시간 마다의 간격으로 정기적인 실행을 하므로 그동안 축적된 데이터는 하나로 모인다.

만약 그렇게 하고 있지 않다면 전송 방법을 검토하는 것이 좋다. 예를 들어, 100개의 파일을 전송하는데 100번 전송을 반복하고 있다면 모아서 전송하는 것이 좋다. 한 번의 전송에 모든 파일을 포함하도록 변경하자.

물론 너무 많은 양의 데이터를 한꺼번에 전송하려고 하는 것은 위험하다. 너무 큰 데이터라면 전송 도구 쪽에서 나눌 수 있다. 예를 들어, 지난 몇 년 동안의 몇 테라바이트에 이르는 데이터를 한 번에 전송하려고 해서는 안 된다. 만일 그렇게 전송해 버리면 몇 시간 후에 디스크가 넘쳐나서 오류가 발생하는 일을 여러 번 경험하게 될 것이다.

데이터양이 많을 때는 한 달씩이나 하루 단위로 전송하도록 작은 태스크로 분해해 한 번의 태스크 실행이 커지지 않도록 조정한다. 워크플로우 관리 도구를 사용하면 이러한 태스크 실행을 쉽게 관리할 수 있다. 태스크를 비교적 작게 함으로써 디스크가 넘쳐나는 잠재적인 문제를 해결할 수 있음은 물론이고 만약 도중에 문제가 발생해도 재시도하기가 쉬워진다.

 

② 데이터 전송의 워크플로우 - 워크플로우 관리 도구와의 친화성

데이터 전송의 신뢰성이 중요한 경우에는 가능한 한 벌크 형 도구를 사용해야 한다. 스트리밍 형의 데이터 전송은 나중에 재실행하기가 쉽지 않다. 뭔가 문제가 발생했을 때 여러 번 데이터 전송을 재실행할 수 있다는 점이 벌크 형의 장점이다.

벌크 형의 데이터 전송은 워크플로우 관리 도구와의 궁합이 뛰어나다. 스트리밍 형 전송은 그 특성상 실시간으로 계속 동작하는 것을 전제로 하므로 워크플로우의 일부로 실행하지 않는다. 과거의 데이터를 빠짐없이 가져오거나 실패한 작업을 재실행할 것을 고려한다면, 벌크 형 전송을 해야 한다.

 

---

위와 같은 특성으로 벌크 형 데이터 전송은 워크플로우 관리 도구와 조합시켜 도입한다. 정기적인 스케줄 실행 및 오류 통지 등은 워크플로우 관리 도구에 맡기고 있다. 매일 매일의 마스터 데이터의 스냅샷과 신뢰성이 중시되는 과금 데이터 전송 등은 다른 배치 처리와 함께 워크플로우의 일부에 포함하는 것이 좋다.

 

 

 

4.1.3. 스트리밍 형의 데이터 전송 - 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송

지금 바로 생성되어 아직 어디에도 저장되지 않은 데이터는 그 자리에서 바로 전송하는 수밖에 없다. 대다수 데이터는 통신 장비 및 소프트웨어에 의해 생성되고, 네트워크를 거쳐서 전송된다. 이러한 데이터를 벌크 형 도구로 모으는 것은 불가능하므로, 스트리밍 형의 데이터 전송이 필요하다. 여기에서는 예로 '웹 브라우저', 스마트 폰의 '모바일 앱', 그리고 센서 기기 등의 각종 '디바이스'에서 데이터를 수집하는 경우를 고려해본다(그림 4.4).

이러한 데이터 전송의 공통점은 다수의 클라이언트에서 계속해서 작은 데이터가 전송되는 것이다. 이러한 데이터 전송 방식을 일반적으로 '메시지 배송(message delivery)'이라고 한다. 메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다. 

보내온 메시지를 저장하는 데에는 몇 가지 방법이 있다. 그중 하나는 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스를 이용하는 것이다. 이 경우 Hive와 같은 쿼리 엔진으로 NoSQL 데이터베이스에 연결해 데이터를 읽을 수 있다.

또는, 분산 스토리지에 직접 쓰는 것이 아니라, 그림 4.4와 같이 '메시지 큐(message queue)'와 '메시지 브로커(message brocker)' 등의 중계 시스템에 전송할 수 있다. 이 경우 기록된 데이터는 일정한 간격으로 꺼내고 모아서 함께 분산 스토리지에 저장한다.

 

① 웹 브라우저에서의 메시지 배송 - Fluentd, Logstash, 웹 이벤트 트래킹

자체 개발한 웹 애플리케이션 등에서는 그림 4.5의 ❶처럼, 웹 서버 안에서 메시지를 만들어 배송한다. 이때 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보내는 경우가 많다. 이때는 'Fluentd'나 'Logstash'와 같은 서버 상주형 로그 수집 소프트웨어가 자주 사용된다.

다른 방법으로는 그림 4.5의 ❷와 같이 자바스크립트를 사용하여 웹 브라우저에서 직접 메시지를 보내는 경우도 있다. 이것은 '웹 이벤트 추적(web event tracking)'이라고 한다. 사용자 측면에서 보면 HTML 페이지에 태그를 삽입만 하면 되므로 각종 액세스 분석 서비스 및 데이터 분석 서비스 등에서 사용되고 있다. 수집된 데이터는 그대로 다른 서버로 전송되거나 API 경유로 함께 취득해 그것을 분산 스토리지에 저장함으로써 다른 데이터와 조합한 분석이 가능해진다.

 

② 모바일 앱으로부터의 메시지 배송 - MBaaS, SDK

모바일 앱은 통신 방법만을 보면 HTTP 프로토콜을 사용하는 클라이언트 중 하나이므로 메시지 배송 방식이 웹 브라우저와 동일하다. 모바일 앱에서는 서버를 직접 마련하는 것이 아니라 MBaaS(Mobile Backend as a Service)라는 백엔드의 각종 서비스를 이용할 수도 있다. 그 경우에는 그림 4.6 ❶처럼 백엔드 데이터 저장소에 저장한 데이터를 벌크 형 도구를 사용하여 꺼낸다.

또는, 그림 4.6 ❷와 같이 모바일 앱에 특화된 액세스 해석 서비스를 통해 이벤트 데이터를 수집한다. 이 경우 서비스에서 제공되는 모바일 용의 편리한 개발 키트(SDK)를 사용하여 메시지를 보낸다. 모바일 앱은 오프라인이 되는 경우도 많으므로 발생한 이벤트는 일단 SDK의 내부에 축적되고 온라인 상태가 되었을 때 모아서 보내도록 만들어져 있다.

모바일 회선은 통신이 불안정하고 통신 오류에 따른 메시지 재전송이 여러 번 발생한다. 그 결과 데이터가 중복될 가능성도 높아 특정한 중복 제거의 구조가 필요하다. SDK를 도입할 경우에는 데이터의 중복에 대해 어떤 대책이 이루어지고 있는지 확인하는 것이 좋다.

 

③ 디바이스로부터의 메시지 배송 - MQTT의 예

IoT 등의 디바이스로부터 메시지 전달은 아직 업계 표준이라고 부를 만한 것 없이 많은 규격이 난립하고 있는 것 같다.(문서 작성 시점)

여기에서는 하나의 예로서 MQTT에 대해 살펴보자. 'MQTT(MQ Telemetry Transport)'는 TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나이며, 일반적으로 'Pub/Sub형 메시지 배송(Pub/Sub message delivery)'이라는 구조를 가진다.  'Pub/Sub'라는 것은 '전달(publish)'과 '구독(subscription)'의 약자이며, 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술이다. 

MQTT에서는 먼저 관리자에 의해 '토픽(topic)'이 만들어진다. 이것은 메시지를 송수신 하기 위한 대화방과 같은 것으로, 그 토픽을 구독하면 메시지가 도착하게 되고, 그 토픽을 전달하면 구독 중인 모든 클라이언트에 보내진다. 이러한 메시지의 교환을 중계하는 서버를 'MQTT 브로커(MQTT broker)'라고 하고, 메시지를 수신하는 시스템을 'MQTT 구독자(MQTT subscriber)'라고 한다(그림 4.7).

MQTT에서 데이터를 수집하려면 먼저 토픽을 작성하고 그것을 구독한다. 그리고 각 디바이스가 토픽에 메시지를 전달하는 프로그램을 작성하고 나면 MQTT가 정하는 규칙에 따라 메시지 배송이 이루어진다. MQTT의 특징 중의 하나로서 네트워크에서 분리된 경우에도 나중에 재전송하는 구조가 프로토콜 수준에서 고려되고 있다. HTTP는 이런 구조를 스스로 생각해야 하지만, MQTT는 이미 준비된 구조를 사용할 수 있다.

④ 메시지 배송의 공통화 - 다른 부분과 공통되는 부분을 분리해서 생각하기

위와 같이 메시지 배송 방식은 어디에서 데이터를 수집하느냐에 따라 전혀 다르다. 따라서, 환경에 따라 다른 부분과 공통되는 부분을 분리하여 생각한다.

이 책에서는 메시지가 처음 생성되는 기기를 '클라이언트(client)', 해당 메시지를 먼저 받는 서버를 '프론트엔드(frontend)'라고 한다. 프론트엔드의 역할은 클라이언트와의 통신 프로토콜을 제대로 구현하는 것이다. 악의적인 공격으로부터 데이터를 보호하기 위해 암호화와 사용자 인증을 구현하고 성능 문제를 해결하기 위해 높은 확장성도 필요하다.

프론트엔트가 받은 메시지는 그대로 메시지 브로커로 전송한다. 분산 스토리지에 데이터를 저장하는 것은 메시지 브로커로부터 그 이후의 역할이다. 이렇게 역할을 분리함으로써 프론트엔드는 단지 데이터를 받는 것에만 전념하고 거기에서 그 이후의 어려운 문제에 대해서는 백엔드에 존재하는 공통 시스템에 맡길 수 있다.