4. 빅데이터의 축적

들어가며

1. 벌크와 스트리밍 데이터 전송

bulk and streaming

데이터 수집 이란 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 과정을 말합니다.

빅데이터를 저장하기 위한 저장소로 객체 스토리지(object storage)를 많이 사용합니다. 파일 스토리지와 다르게 객체 스토리지(object storage) 는 여러 HW에 분산되어 평면(flat) 구조로 저장되고, 고유 식별자를 비롯한 여러 메타 데이터를 가진 상태로 저장됩니다. 객체 스토리지를 도입하는 경우에는 네트워크 성능도 함께 고려해야 합니다. 대표적인 스토리지로 HDFS, AWS S3 등이 있습니다.

• 다수의 하드웨어에서 분산처리 하므로 데이터의 양이 많을수록 유리합니다.
• 반면 소량의 파일을 자주 읽고 쓰는 경우, 통신 오버헤드가 크므로 오히려 불리합니다.

(벌크형의 데이터 처리)
벌크형의 데이터는 적정한 크기의 테스크로 쪼개어 워크플로 관리도구를 통해 실행합니다. 테스크의 크기를 꾸준히 모니터링하면 디스크 풀 등 잠재적인 문제와 함께, 재수행을 수월하게 할 수 있는 장점이 있습니다. 여러 번 데이터를 재전송 할 수 있다는 점은 데이터의 신뢰성을 확보하는데 큰 도움이 됩니다.

(스트리밍 데이터의 처리)
각종 디바이스나 실시간성으로 생성되는 데이터의 경우에는 벌크형 도구로 모으는 것이 쉽지 않기 때문에 벌크의 경우와는 다른 별도의 처리과정을 통합니다. 이런 경우에는 분산 스토리지에 바로 쓰지 않고 메세지 큐(message queue)와 메세지 브로커(message broker) 등의 중계시스템을 통합니다.

1. 웹브라우저 : 웹브라우저가 있는 경우는 전송효율을 위해 서버상에 데이터를 축적해 두었다가 전송합니다. Fluentd, logstash 등 상주형 로그 수집 소프트웨어를 많이 사용합니다. 축적된 파일을 수집하여 kafka에 저장해 두었다가 컨슘하는 구조가 대표적입니다. 물론 javascript에서 수집서버 혹은 브로커로 바로 전송할 수 도 있습니다.

2. 모바일 앱 : 모바일앱 역시 HTTP 프로토콜을 사용하는 클라이언트로서, 메세지 배송 방식은 웹브라우저와 동일합니다. 다만 모바일 앱은 서버를 직접 마련하는 것이 아니라 MBaas(Mobile Backend as a Service)와 같은 벡엔드 서비스를 이용할 수 있습니다. 웹브라우저의 js와 마찬가지로, 모바일 SDK를 통해 데이터를 전송하기도 합니다. 모바일 회선은 통신이 불안정하고 데이터 중복의 가능성이 높아 중복에 대한 대책이 마련되어야 합니다.

3. IOT 디바이스 : IOT 등의 디바이스는 여러 규격이 있지만 대표적으로 MQTT(Message Queuing Telemetry Transport) 프로토콜에 의한 배송이 있습니다. Pub/Sub 구조를 통해 특정 Topic 을 구독하고 있는 Subscriber들에게 메세지가 뿌려지게 됩니다.

MQTT(Message Queuing Telemetry Transport)
MQTT(Message Queuing Telemetry Transport) 브로커는 경량 메시징 프로토콜을 사용하는 메세지 브로커의 한 종류입니다. IoT(Internet of Things) 환경에서 많이 사용되며, 네트워크 대역폭이 제한적이거나, 네트워크 연결이 불안정한 환경에서도 효율적으로 메시지를 교환할 수 있도록 설계되었습니다. MQTT 브로커는 발행/구독(pub/sub 모델을 기반으로 작동하며, 클라이언트가 특정 토픽에 메시지를 발행하면 해당 토픽을 구독하는 다른 클라이언트에게 메시지를 전달합니다.

대표적인 MQTT 제품은 다음과 같습니다.

1. Mosquitto
   • Eclipse Foundation에서 관리하는 오픈 소스 MQTT 브로커로, 경량이며 쉽게 설치하고 사용할 수 있습니다.
2. RabbitMQ
   • AMQP(Advanced Message Queuing Protocol) 지원과 함께 MQTT 플러그인을 제공하는 오픈 소스 메시지 브로커입니다.
3. HiveMQ
   • 상업적으로 사용되는 MQTT 브로커로, 대규모 IoT 애플리케이션을 위해 설계되었습니다. 고가용성과 확장성을 제공합니다.
4. EMQ X (Erlang/Enterprise MQTT Broker)
   • 대규모 분산 환경을 위해 설계된 오픈 소스 MQTT 메시지 브로커로, 높은 처리량과 낮은 지연 시간을 자랑합니다.

2. 스트리밍 - 메세지 배송의 구조와 주의점

대량으로 쏟아지는 메세지를 안정적으로 받아 쓰기 위해서, 분산스토리지 앞단에는 메세지 브로커(Apache kafka, Amazone Kinesis) 가 설치됩니다. 다시 브로커와 스토리지 사이에는 컨슈머(consumer) 가 소비하는 메세지의 양을 조절합니다. 이렇게 메세지를 짧은 간격이라도 축적하여 차례로 데이터를 처리하는 것을 스트림 처리(stream processing) 라고 합니다. 또한 복수의 컨슈머(consumer) 를 세팅하여 동일한 메세지를 여러 경로로 분기처리도 가능합니다.

이런 Pull 구조의 메세징 시스템은 메세지 배송에서 매우 중요한 위치를 가지고 있지만 그렇다고 만능은 아닙니다. Client 의 수가 많아질수록 스트리밍형 메세지 배송의 성능과 신뢰성 모두 만족하기는 쉽지 않기 때문입니다. 이 중에서 신뢰성을 보장하는 시스템은 다양한 방식으로 설계하게 됩니다.

1. at most once
   • 메세지는 최대 한번만 전송됩니다. 하지만 도중에 유실될 가능성이 있습니다. 대부분 데이터의 결손을 막기위해 재전송이 이루어지지만, 재전송이 이루어지는 시스템에서는 at most once를 보장하기 어렵습니다.
2. exactly once
   • 메세지는 손실/중복 없이 정확히 한번만 전송됩니다. 네트워크상에서 두 개의 노드가 있는 경우, 양쪽의 exactly once 통신을 보장하기 위해서는 둘 사이를 중계하는 코디네이터(coordinator)의 존재가 필수적입니다. 하지만 코디네이터와의 통신에 장애가 발생할 수 있고, 마찬가지 코디네이터의 응답이 너무 느리면 시간이 소요된다는 단점이 있습니다.
3. at least once
   • 메세지는 적어도 한번 확실히 전달되지만 여러번 중복 전달 되었을 가능성이 있습니다. 대부분의 메세지 배송 시스템은 at least once 를 보장하지만, TCP/IP 처럼 자동으로 중복제거를 이루지는 못하고 사용자가 중복을 제거하여야 합니다.

빅데이터 시스템에서는 신뢰성 보다는 효율이 중시되며, 따라서 종단간 중간 경로에 at least once 는 보장하면서 중복을 허용하고, 결론적으로 중복제거는 나중에 값을 읽어들일때 진행합니다. 중복 제거는 아래와 같은 방법으로 이루어집니다.

1. offset을 이용한 중복제거(offset 지점부터 다시 씀)
2. UUID(Universally Unique IDentifier) 에 의한 중복제거
   • cassandra, elasticsearch 는 특성상 고유ID를 지정하게 되어 있어, 동일한 ID는 덮어쓰므로 중복제거가 실현됩니다.

결론적으론, 빅데이터 시스템을 통해 신뢰성을 어느정도는 확보할 수 있지만 신뢰성이 중시되는 경우에는 스트리밍형의 메세지 배송을 피하고 트랜젝션 처리를 지원하는 데이터베이스에 어플리케이션이 직접 기록하는 것이 제일 좋습니다.

3. 프로세스 시간과 이벤트 시간의 구별

스트리밍형의 메세지 배송에는 메세지 도착까지의 시간 지연 역시 고려해야 합니다. 메세지 도착까지의 시간이란 이벤트 시간 과 프로세스 시간 이 있습니다. 실제 이벤트가 발생한 시간과, 분산 스토리지에 넣은 서버상의 시간 사이에는 시간차가 있으며 이를 감안한 Full scan을 진행하면 효율이 떨어지게 됩니다.

• 이벤트 시간(event time) : 클라이언트에서 메세지가 생성된 시간
• 프로세스 시간(process time) : 메세지를 서버가 처리하는 시간

이를 효율화 하기 위해서는 다음과 같은 방법을 사용합니다.

1. Cassandra 와 같은 시계열 인덱스(time-series index) 에 대응하는 분산 데이터베이스를 이용합니다. (장기간에 적절하지는 않음)

2. 매일 한 번씩 새로 도착한 데이터 이벤트 시간으로 정렬한 후 배치처리를 통해 열 지향 스토리지로 변환합니다. 열 지향 스토리지는 칼럼 단위 통계정보를 이용해 최적화가 이루어 지며 최소한의 데이터만을 읽어들여 풀 스캔을 피합니다. 이를 조건절 푸쉬 다운(predicate pushdown)이라고 합니다.

3. 시간을 이용하여 분할된 테이블인 시계열 테이블(time-series table)에 시간 단위 파티션에 저장합니다. 더 나은 방법으로는, 데이터 수집때는 프로세스 시간 기준으로 수집하고 추후 데이터 마트를 만들때 이벤트 시간으로 정렬하여 유지합니다.

4. NoSQL 데이터베이스의 특성

객체 스토리지는 아래와 같은 단점을 가지고 있습니다.

• 객체 스토리지 상의 파일은 교체하기 어렵습니다. 데이터베이스처럼 수시로 변경하는 용도에는 적합하지 않으며, 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 스냅샷을 뜨거나 다른 분산 데이터베이스에 저장합니다.

• 객체 스토리지에 저장된 데이터는 집계를 위해 열 지향 스토리지를 만들지만, 데이터를 기록하고 곧바로 활용하기가 어렵습니다.

NoSQL은 위 상황에 최적화된 데이터 저장소 입니다. 간단하게 정리해보면 다음과 같습니다.

1. 분산 KVS(distributed Key-Value store)
   • 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소입니다.
   • 모든 데이터에 고유키를 지정하고, 부하분산에 이용합니다.
   • 마스터/슬레이브형이 있고 P2P형(Amazone DynanoDB)이 있습니다.
2. 와이드 칼럼 스토어
   • 와이드 칼럼 스토어는 성능 향상이 목표입니다.
   • 분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것입니다.
   • 대표적으로 GCP Bigtable, Apache HBase, Apache Cassandra 가 있습니다.
   • 행 추가와 마찬가지로 열 추가도 자유롭게 할 수 있습니다.
   • 어플리케이션에서의 영양도를 없애기 위해, Cassandra를 복제하여 Spark, Presto 등을 통해 로드합니다.
3. 도큐먼트 스토어
   • 도큐먼트 스토어는 데이터 처리의 유연성이 목표입니다.
   • 스키마를 정하지 않고 데이터 처리가 가능합니다.
   • 수평적 확장성을 지원하며 대량의 데이터를 다루는 대규모 애플리케이션에 특히 유용합니다.
   • MongoDB, Couchbase, Amazon DynamoDB 등이 대표적인 도큐먼트 스토어 데이터베이스 입니다.

정리하며

이번 장의 내용은 정리하면 다음과 같습니다.

• 스트리밍 데이터의 운반은 메세지 큐(message queue)와 메세지 브로커(message broker) 등의 중계시스템을 통하며, 시스템의 특성에 맞게 구성합니다.

• 빅데이터 시스템은 신뢰성보단 효율성을 중시하여, 종단간(End to End) 중간 경로에 at least once 는 보장하면서 중복을 허용하여 저장합니다. 추후 마트 구성시에 중복을 제거합니다.

• 데이터 수집때는 프로세스 시간 기준으로 수집하고 추후 데이터 마트를 만들때 이벤트 시간으로 정렬하여 유지합니다.

참고문헌

• [출처] 니시다 케이스케(Keisuke Nishida), ⌜빅데이터를 지탱하는 기술(BIG DATA WO SASAERU GIJUTSU)⌟, 장성두 옮김, 주식회사 제이펍
• https://bin-kkwon.tistory.com/entry/CS-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80-%EC%A2%85%EB%A5%98-object-block-file
• https://k21academy.com/microsoft-azure/data-engineer/batch-processing-vs-stream-processing/