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

데이터 전송에는 벌크 형과 스트리밍 형 두 종류가 있다.

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

빅데이터는 대부분 확장성이 높은 분산 스토리지(distributed storage)에 저장됨

• 기본적으로 대랑으로 파일을 저장하기위한 객체 스토리지(object storage)가 많이 사용됨
  • Hadoop이라면 HDFS, 클라우드 서비스라면 Amazon S3 등
• 객체 스토리지의 내부 처리에는 다수의 물리적 서버와 하드디스크가 존재하므로 일부의 HW가 고장나더라도 데이터 손실X
  • 데이터의 읽기, 쓰기를 다수의 하드웨어에 분산 -> 데이터의 양이 늘어나도 성능 유지
• 객체 스토리지 구조는 데이터 양이 많을 때는 우수하지만, 소량의 데이터를 처리할 때는 오버헤드가 너무 크므로 비효율적

데이터 수집: 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스

빅데이터로 자주 다루는 것은 시계열 데이터(시간과 함께 생성되는 데이터)

• 시간이 지날수록 대량의 파일이 생성 및 객체 스토리지에 저장되므로 성능 저하의 요인이 됨
• 작은 데이터는 모아서 하나의 큰 파일 생성 -> 효율 높이는데 도움이 됨
• 거대한 데이터는 한번에 처리하기 X -> 적당히 나누어 전송
  • 시간 오류 등과 같은 성능 저하 방지
• 객체 스토리지에서 효율적으로 처리할 수 있는 파일크기: 대략 1MB ~ 1GB

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

• 데이터 웨어하우스의 전통적 데이터 전송 방식: 벌크 형
• 빅데이터를 다루는 경우에도 다음과 같은 경우 벌크 형의 데이터 전송 방식 사용
  • 과거에 축적된 대량의 데이터가 이미 존재하는 경우
  • 기존의 데이터베이스에서 데이터를 추출하고 싶은 경우
• 데이터가 처음부터 분산 스토리지에 저장되어 있지 않다면, 데이터 전송을 위한 ETL 서버(ETL server)를 설치함

파일 사이즈의 적정화: 번크형의 도구로 파일 사이즈 적정화

ETL 프로세스는 하루에 1회 또는 1시간 마다 정기적인 실행을 하므로, 그동안 축적된 데이터는 하나로 모임

• 이때, 한번에 너무 많은 양의 데이터나 너무 작게 하는 것은 위에서 설명했든 효율 측면에서 좋지 않음
• 데이터 양이 많을 때는 한 달/하루 단위로 전송할 수 잇도록 작은 태스크로 분해해 한 번의 태스크 실행이 커지지 않도록 조정함
  • 워크플로 관리 도구의 사용은 태스크 관리를 용이하게 해줌
  • 태스크를 작게 만들면, 디스크 넘침 방지와 같은 잠재적 문제 해결 또 만약 태스크 실행 도중 문제가 발생해도 재시도 하기가 쉬워짐

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

데이터 전송의 신뢰성이 중요한 경우에는 가능한 벌크 형 도구를 사용해야 함

• 스트리밍 형의 데이터 전송은 나중에 재실행하기가 어려움 -> 벌크 형은 문제 발생했을 때 데이터 전송을 여러 번 재실행 할 수 있음(벌크형의 장점)
• 벌크 형의 데이터 전송은 워크플로 관리 도구와 궁합이 좋음
  • 스트리밍 형은 실시간으로 계속 동작함을 전제로 하므로 워크플로의 일부로 실행하지 않음
  • 과거 데이터를 빠짐없이 가져오거나 실패한 작업을 재실행할 것을 고려한다면, 벌크 형 전송을 해야 함
• 워크플로 도구의 역할: 정기적인 스케줄 실행 및 오류 통지
  • 일일 마스터 데이터 스냅샷과 신뢰성이 중시되는 과금 데이터 전송 등은 다른 배치 처리와 함께 워크플로의 일부에 포함하는 것이 좋음

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

지금 바로 생성되어 아직 어디에도 저장되지 않는 데이터는 그 순간 바로 전송해야만 함. 통신 장비 및 소프으웨어에 의해 생성된고, 네트워크를 거쳐 전송되는데 이렇게 실시간으로 생성되는 데이터는 벌크형 도구로 모으는 것은 불가능함. 따라서 스트리밍 형 데이터 전송이 필요함

• 스트리밍 형의 데이터 전송의 공통점: 다수의 클라이언트에서 지속적으로 작은 데이터가 전송 됨: 메시지 배송(message delivery)의 전송 방식
• 이러한 메시지 배송 시스템은 전송되는 데이터 양에 비해 통신을 위한 오버헤드가 커지므로 이를 처리하는 서버는 높은 성능이 필요함
• 메시지 저장 방식
  • NoSQL 데이터베이스 사용: 작은 데이터 쓰기에 적합. Hive와 같은 쿼리 엔진으로 NoSQL DB에 연결해 데이터 읽기 가능
  • 메시지 큐(message queue)와 메시지 브로커(message broker)등과 같은 중계 시스템에 전송(중간 저장): 기록된 데이터는 일정한 간격으로 꺼내고 모아 한번에 분산 스토리지에 저장됨

웹 브라우저에서의 메시지 배송(Fluented, Logstash, 웹 이벤트 트래킹)

방법 1. 웹 서버 안에서 메시지를 만들어 배송함

• 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보냄
• 이때, Fluented나 Logstash와 같은 상주형 로그 수집 소프트웨어가 자주 사용됨

Fluented

• 분산 스토리지에 데이터를 중계하는 메시지 브로커의 역할로 로그 수집 소프트웨어로 Fluented가 선택지가 될 수 있음
• 내부에 효율적 버퍼링 메커니즘을 갖고 있어 일정한 시간 간격 또는 특정 상지ㅡ에 외부로 데이터를 모아 내보낼 수 있음
• 그러나, 원래 메시지 브로커로 설계된 것이 아니므로 한계도 존재함
  • 여러 대로 데이터 복제 불가: 고장 시 데이터 손실 가능성 존재 -> 디스크 상의 버퍼가 사라지지 않는 한 재전송으로 극복 가능한 문제
  • 메시지를 일방적으로 발송하는 것밖에 못하므로 외부 요청으로 메시지를 꺼낼 수 없음
  • 배송에 성공한 메시지는 사라지므로 재송신 불가

방법 2. 자바 스크립트를 사용하여 웹 브라우저에서 직접 메시지를 보내는 경우: 웹 이벤트 추적(web event tracking)

• 사용자 측면에서 보면, HTML 페이지에 태그 삽입만 하면 됨
  • 각종 액세스 분석 서비스 및 데이터 분석 서비스 등에서 사용됨
• 수집된 데이터는 그대로 다른 서버에 전송되거나 API 경유로 함께 취득해 분산 스토리지에 저장함으로써 다른 데이터와 조합한 분석이 가능해짐

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

모바일 앱은 통신 방법만 보면 HTTP 프로토콜을 사용하는 클라이언트 중 하나이므로 메시지 배송 방식이 웹 브라우저와 동일함.

• 모바일 앱에서는 서버를 직접 마련하는 것이 아니라 MBaaS(Mobile Backend as a Service)라는 백엔드의 각종 서비스를 이용할 수도 있음.
  • 백엔드 데이터 저장소에 저장한 데이터를 벌크 형 도구를 사용해 꺼냄
• 모바일 앱에 특화된 액세스 해석 서비스를 통해 이벤트 데이터 수집 -> 이 경우, 서비스에서 제공되는 모바일 용의 편리한 개발 키트(SDK)를 사용해 메시지 전송
  • 모바일 앱은 오프라인 되는 경우도 많으므로 발생한 이벤트를 일단 SDK 내부에 축적하고, 온라인 상태가 되었을 때 모아서 전송
• 모바일 회선은 통신 불안정, 통신 오류에 따른 메시지 재전송이 여러번 발생함 -> 데이터 중복 가능성 높으므로 중복 제거의 구조가 필요함
  • SDK 도입할 경우에는 데이터 중복에 대해 대책 마련 필수

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

IOT 등의 디바이스로부터 메시지 전달은 아직 업계 표준 규격이 존재하지 않음(책을 쓴 시점). 하나의 예시로 MQTT가 존재

• MQTT(MQ Telemetry Transport): TCP/IP를 사용해 데이터를 전송하는 프로토콜의 하나이며, 일반적으로 'Pub/Sub 형 메시지 배송' 구조를 가짐
  • Pub/Sub는 전달(Publish)와 구독(Subscription)의 약자
  • 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술
• MQTT에서는 먼저 관리자에 의해 '토픽(Topic)'이 생성됨: 메시지 송수신을 위한 대화방 같은 것
  • 토픽을 구독하면 메시지 도착, 토픽을 전달하면 구독 중인 모든 클라이언트에 메시지 보내짐
  • 메시지 교환을 중계하는 서버를 'MQTT 브로커'라고 하고, 메시지를 수신하는 시스템을 'MQTT 구독자'라고 함
• 즉, MQTT에서 데이터 수집하려면 토픽을 작성하고 이를 구독함. 그리고 메시지 전달 프로그램을 작성하고 나면 MQTT가 정하는 규칙에 따라 메시지 배송이 이루어짐

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

위와 같은 메시지 배송 방식은 어디에서 데이터가 수집되느냐에 따라 달라짐. 따라서 환경에 따라 다른 부분과 공통되는 부분을 분리해 생각함

• 메시지가 처음 생성되는 기기를 '클라이언트(client)', 해당 메시지를 먼저 받는 서버를 '프런트 엔드(frontend)'라고 함
  • 프런트엔드의 역할: 클라이언트와의 통신 프로토콜을 제대로 구현하는 것
  • 악의적인 공격으로부터 데이터를 보호하기위해 암호화나 사용자 인증을 구현하고 성능 문제 해결을 위해 높은 확장성 필요
• 프런트엔드가 받은 메시지는 그대로 메시지 브로커에 전송 -> 분산 스토리지에 데이터를 저장하는 것은 메시지 브로커로부터 그 이후의 역할