[Database] 벌크형 vs 스트리밍형 : 데이터를 움직이는 두 가지 방식

대규모 데이터를 수집하고 처리하는 데이터 파이프라인에서는 전송 방식에 따라 효율성과 실시간성이 크게 달라진다. 데이터를 저장소로 옮기는 방식은 크게 벌크형과 스트리밍형 두 가지로 나뉜다. 

 

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

 

분산 스토리지

 

빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지(ditributed storage)에 저장된다. 여기서 기본이 되는 것은 파일을 저장하기 위한 객체 스토리지이다.

- Hadoop의 HDFS

- Amazon의 S3 

 

 

객체 스토리지의 동작 구조

객체 스토리지는 데이터를 여러 대의 디스크에 복사 및 분산하여 저장한다.

- [마스터-슬레이브] 구조

- 데이터를 슬레이브의 디스크에 저장

- 네트워크를 통해 파일 읽기/쓰기가 이루어짐 

 

객체 스토리지는 데이터가 여러 디스크에 복사되어 저장되므로, 일부 하드웨어가 고장나도 데이터의 손실이 없다. 또한 데이터 양이 증가해도 성능 저하 없이 확장이 가능하다. 

하지만 소량의 데이터를 자주 읽고 쓰는 경우에는 통신 오버헤드가 커 비효율적이다. 따라서 객체 스토리지는 대용량 파일 중심 처리에 사용하는 것이 좋다. 

 

 

시계열 데이터

빅데이터에서 자주 다루는 시계열 데이터는 시간이 흐르면서 계속 생성된다. 이 데이터를 객체 스토리지에 수시로 기록하면, 작은 파일이 너무 많아져서 성능이 저하된다. 이런 경우 작은 데이터를 모아 큰 파일로 저장하는 것이 효율적이다 .

 

반대로, 파일이 지나치게 커지는 것도 문제가 된다. 파일 크기가 너무 크면 네트워크에 부담이 생겨 오류가 발생할 가능성이 높아진다. 이런 경우 큰 파일을 나눠서 처리해야 안정성과 속도를 확보할 수 있다. 

 

너무 큰 파일은 작게 쪼개서, 너무 작은 데이터는 큰 파일로 저장해야 한다면, 파일 크기의 적정 범위는 어떻게 될까? 객체 스토리지에서 효율적인 파일 크기는 보통 수 MB ~ 수십 MB 사이이다. 

 

이렇게 수집한 데이터를 잘 저장하기 위해서 전처리, 구조화, 저장 최적화를 하는 과정 전반을 데이터 수집이라고 한다. 우리는 단순히 데이터를 모으는 것을 넘어, 저장성과 처리 효율까지 고려해서 작업해야 한다. 

 

 

| 벌크형 데이터의 전송 

벌크형이란?

벌크형이란, 전통적인 웨어하우스에서 주로 사용된 일괄 데이터 전송 방식이다. 

- 데이터를 한꺼번에 모아서 대량으로 전송

- 주로 DB, 파일 서버, 웹 서비스 등에서 SQL, API, 파일 형태로 데이터를 추출함

- 기존에 저장된 대량의 과거 데이터를 분산 스토리지로 전송할 때 사용

[예시] RDB에서 데이터를 추출해 HAdoop/HDFS로 옮기는 경우 

 

 

벌크형의 데이터 전송 과정

 

 

① 데이터 추출	DB나 웹 서비스에서 SQL/REST API 등으로 데이터 추출
② 전처리 및 변환	ETL 서버가 CSV 등 표준 포맷으로 변환
③ 저장	변환된 데이터를 분산 스토리지에 저장

 

* REST API : 웹에서 데이터를 주고 받을 때 사용하는 API 형식 

 

ETL 서버 

데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면, 중간에 ETL 서버를 설치해 사용한다.

- Extract : 데이터 추출

- Transform : 추출한 데이터를 표준 포맷으로 변환/,정제/구조화

- Load : 분산 저장소에 저장 

 

 

파일 사이즈의 적정화

벌크형 데이터의 전송은 보통 주기적으로(하루 1번처럼) 실행된다. 이때, 그동안 쌓인 데이터를 한 번에 묶어서 전송한다. 따라서 파일 사이즈를 조정하는 것이 비교적 간단한 편이다. 

 

[case1] 작은 파일이 많은 경우

작은 파일이 많은 경우, 하나로 묶어 1번만 전송한다. 전송 횟수가 감소해 성능이 향상된다. 

 

[case2] 파일이 너무 큰 경우

수 테라바이트급 데이터를 한꺼번에 전송해야 하는 경우 다음과 같은 문제가 발생할 수 있다.

- 디스크 넘침

- 오류 발생 

따라서 작은 단위로 나눠서 전송하는 것이 안정적이다. 

 

데이터 양이 많더라도, 작은 task 단위로 나누어 하루 단위로 전송하면 문제를 예방할 수 있다. 이때 워크플로우 도구를 사용할 수 있는데, 개별 작업 실행을 자동화/관리할 수 있으며 잠재적 오류도 빠르게 복구할 수 있다. 

 

 

데이터 전송의 워크플로우

벌크형 전송은 워크플로우 관리 도구와의 궁합이 좋다. 이유는 다음과 같다.

- 일괄 처리 방식으로 정해진 시간에 실행 가능 

- 실패 시 특정 작업만 다시 실행 가능 

- 과거 데이터 이관, 복구 작업 등에 적합 

 

벌크형 전송은 재실행이 쉬워 문제가 생겻을 때 여러 번 재시도가 가능하다. 이것은 신뢰성과 연결된다. 반면, 스트리밍은 실시간 처리이기 때문에 재실행이 어렵고 복잡하다. 

	벌크형	스트리밍형
실행 방식	주기적으로 실행	실시간 연속 실행
오류 발생 시	재실행 쉬움	재실행 어려움
워크플로 관리	잘 호환됨	일부만 적용 가능

 

 

| 스트리밍 형 데이터 전송 

스트리밍형 데이터 전송은, 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데잍어 전송 방법을 말한다. 지금 바로 생성되어 아직 어디에도 저장되지 않은 데이터는 그 자리에서 바로 전송하는 수밖에 없다. 

 

메시지 배송

이러한 데이터들은 다수의 클라이언트에서 계속해서 작은 데이터가 전송된다는 점인데, 이러한 방식을 일반적으로 메시지 배송(message delivery)이라고 한다. 

- 여러 클라이언트에서 작은 데이터가 지속적으로 전송되는 박ㅇ식

- 데이터 양은 적지만 전송 횟수가 많아 통신 오버헤드가 크

- 이를 처리할 수 있는 서버 성능이 중요 

 

이러한 환경에서는 메시지 큐 또는 NoSQL DB를 활용해 데이터를 수집,처리하고 이를 모아 저장하는 구조가 효율적이다. 

NoSQL 데이터베이스	- 작은 데이터를 자주 쓰고 읽는데 적합 - Hive같은 쿼리 엔진과 연결해서 분석 가능
메시지 큐(message queue), 메시지 브로커(message broker)	- 데이터를 바로 저장하지 않고, 중간 시스템을 통해 수집  - 데이터를 일정 간격으로 모아서 분산 스토리지에 전달

 

 

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

웹 브라우저에서 메시지를 배송하는 방법에는 크게 두 가지가 있다. 

 

[1] 서버에서 메시지를 모아 전송하는 방식 (그림 1)

- 웹 애플리케이션은 서버 안에서 메시지를 생성해 전송한다

- 전송 효율을 높이기 위해, 메시지를 서버에 잠시 쌓아 두었다가 한꺼번에 전송한다.

- 대표적인 도구 : Fluented/Logstash 

 

[2] 웹 브라우저에서 직접 메시지를 보내는 방식 (그림 2) 

- 자바스크립트를 사용하여 웹 브라우저가 직접 메시지를 전송하는 방법

- 이를 웹 이벤트 추적(Web Event Tracking)이라고 한다.

- 클릭, 스크롤, 페이지 이동 등이 있다.

- HTML에 태그 삽입만 하면 동작하며, JS가 이벤트 발생 시 서버에 바로 메시지를 전송한다.

 

 

 

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

모바일 앱도 HTTP 기반의 메시지 전송 방식을 사용하기 때문에, 웹 브라우저와 원리가 비슷하다. 히지만 모바일은 서버를 직접 관리하기 보다는 MBaaS를 자주 사용한다. 

 

 

[1] 백엔드에 저장된 데이터 수집 (그림 1) 

- 백엔드 저장소에 누적된 데이터를 나중에 벌크형 도구로 수집한다. 

 

[2] 살시간 액세스 이벤트 전송 - SDK 활용 (그림 2) 

- SDK(Software Development Kit)를 통해, 앱 내 액션(클릭, 로그인 등) 이벤트 형태로 수집한다. 

- 앱 안에서 임시 저장 후, 온라인 상태일 때 모아서 전송한다. 

 

 

[여기서 잠깐] SDK(Software Development Kit)란? 

SDK란, 소프트웨어를 개발할 때 쓰는 도구의 모음이다. 

라이브러리	우리가 쓸 수 있는 함수나 클래스 (예: 메시지 전송, 로그인 등)
문서	어떻게 쓰는지 설명한 가이드
테스트 예제	미리 짜여 있는 샘플 코드
도구/스크립트	설정 도와주는 유틸리티

 

쉽게 말해, 누군가가 우리가 필요한 기능을 미리 만들어두었다고 생각하면 된다. 예를 들어 앱에서 사용자가 버튼을 누르면 서버에 데이터를 보내고 싶다고 할때, SDK를 활용하면 코드 한 줄로 모든 기능을 해결할 수 있다. 

 

 

 

모바일 환경의 경우, 몇 가지 특수성을 가진다.

- 오프라인 상태 발생 : 메시지를 바로 전송할 수 없어 앱 내부에 저장된다.

- 통신 불안정 : 메시지가 여러 번 전송되어 중복 발생의 가능성이 있다.

- 중복 제거 필요 : SDK는 중복 메시지를 자동으로 식별하거나 제거하는 기능이 필요하다. 

 

모바일 앱은 네트워크 환경이 불안정하므로, 이벤트 메시지를 앱 내부에 저장해두었다가 온라인 상태가 되면 전송한다. 이때 SDK를 사용해 수집하고, 중복 방지 대책이 함께 포함되어야 한다. 

 

 

[여기서 잠깐] 모바일 앱은 왜 네트워크가 불안정할까?

- 모바일 기기는 언제 어디서든 이동하면서 사용하기 떄문에, 신호가 끊기는 경우가 있다. 

- 웹의 경우, 대부분 고정된 위치에서 안정적인 유선/와이파이를 사용하기 때문에 안정적이다. 

- 이외에도 앱이 꺼져잇거나, 토시 제한 요금제로 속도가 느려지거나, 타임아웃, 배터리 절약으로 인한 네트워크 요청 차단 등으로 네트워크가 불안정하다. 

 

 

 

디바이스로부터 데이터 전송

IoT 등의 디바이스로부터 메시지 전달에는 다양한 방법이 있다. 그 중 MQTT에 대해 알아보자. 

 

MQTT(MQ Telemetry Transport)

TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나

- 센서, IoT 기기 등에서 작은 데이터를 주고받기 위해 만든 통신 방식

- 일반 인터넷 통신 방식인 HTTP보다 가볍고 빠름

- 주로 센서 데이터, 알림, 상태 변화 같은 걸 실시간으로 전송할 때 사용함 

- Pub/Sub 구조로 메시지를 주고받음 

 

구조 

발행자 (Publisher)	메시지를 보내는 쪽 (예: 센서, 디바이스)
브로커 (Broker)	중간에서 메시지를 전달해주는 서버
구독자 (Subscriber)	메시지를 받는 쪽 (예: 알림 시스템, 서버 등)

 

작동 흐름

1. 디바이스가 토픽(topic)을 만들어 메시지를 보낸다

2. MQTT 브로커가 그 메시지를 받는다

3. 해당 토픽을 구독한 구독자에게 자동 전달한다. 

* 토픽 : '이런 주제의 메시지를 보내겠다'와 같은 주소의 개념 

 

MQTT는 발행/구독의 모델로 구성되어 있어 실시간 메시지 전달에 최적화되어 있다. 

 

 

  | 메시지 배송의 공통화

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

 

메시지 배송에 있어서 공통적인 부분 

클라이언트(Client)	메시지를 처음 만드는 쪽 (예: IoT 센서, 웹 브라우저, 모바일 앱)
프론트엔드(Frontend)	메시지를 제일 먼저 받는 서버 (게이트웨이 같은 역할)
백엔드(Backend)	메시지를 처리하고 저장하는 공통 시스템 (브로커, 스토리지 등)

 

메시지 배송의 구조와 역할 

[Client] → [Frontend] → [Message Broker] → [Storage or Analytics]

 

Client	메시지를 생성함 (센서가 온도 측정 등)
Frontend	메시지를 받아서 인증, 보안, 포맷 정리 등 처리
Broker/Storage	데이터를 저장하거나 분석하는 백엔드 역할 담당

 

여기서 프론트엔드는 중요한 역할을 한다. 클라이언트와 통신해 메시지를 받아오고, 암호화/인증 등의 보안 처리를 한다. 많은 디바이스가 붙을 수 있도록 확장성을 고려해 설계한다. 실질적인 저장이나 분석은 백엔드가 할 수 있도록 전송한다. 

 

정리하자면, 메시지를 주고받는 시스템을 클라이언트/프론트엔드/백엔드로 나누어서 생각하는 것이다. 클라이언트는 데이터를 생성해 그냥 보내기만 하고, 프론트엔드는 받고나서 처리만 한다. 저장, 분석, 오류 처리 등은 백엔드가 처리한다. 

이렇게 나누면 역할이 단순해져서 관리가 쉬워지고, 문제도 한 군데에서만 해결하면 돼서 더 튼튼한 시스템이 된다.