🏭 Data

실시간 데이터 처리 [1/3] - 배치 그리고 스트림

kukim 2025. 1. 19. 23:22

"매일 수많은 데이터가 실시간으로 발생합니다. 사용자의 클릭, 주문, 검색, 장바구니 담기까지... 이런 데이터들을 어떻게 활용할 수 있을까요?"

 

커머스 서비스에서는 끊임없이 데이터가 생성됩니다. 특히 추천 시스템을 개발하다 보면 이런 고민이 자주 듭니다.

"방금 인기가 급상승한 상품을 바로 추천에 반영할 순 없을까?"
"새로운 상품의 성과를 실시간으로 확인하고 싶은데..."
"프로모션 효과를 보면서 바로 전략을 수정하고 싶어요"

 

전통적인 배치 처리 방식은 여전히 중요하고 유용합니다. 특히 복잡한 머신러닝 모델 학습이나 대규모 데이터 분석같이 무거운 계산이 필요한 경우에는 배치 처리가 효율적인 선택이죠.

 

하지만 실시간성이 중요한 요구사항들이 늘어나면서 한계도 분명해졌습니다. 배치 주기를 줄여서 (예: 하루 한 번 → 한 시간에 한 번) 해결하려 할 수도 있지만, 그만큼 컴퓨팅 파워가 더 필요하고 비용도 증가하게 됩니다. 게다가 여전히 "실시간"이라고 보기는 어렵죠.

 


목차

1. 들어가며

1.1. 데이터는 끊임없이 흐른다

1.2. 데이터를 바라보는 관점의 변화

2. 데이터 처리의 진화

2.1. 전통적인 데이터 처리 방식

2.2. 실시간 스트림 처리로의 변화

3. 실시간 스트림 처리 살펴보기

3.1 데이터 플로우 프로그래밍의 이해

3.2 데이터 플로우 그래프

3.3 병렬 스트림 처리

3.4 병렬 스트림 처리 사례

  실시간 스트림 처리의 기본 아키텍처

  패션 커머스 실시간 랭킹 시스템 예

  개인화 추천 시스템 예

마치며 / Reference


1. 들어가며

1.1. 데이터는 끊임없이 흐른다.

우리 주변의 모든 데이터는 시간에 따라 계속해서 발생합니다. 마치 강물처럼 끊임없이 흐르죠.

 

예로

  • 사용자가 상품을 클릭할 때마다 로그가 쌓입니다
  • 검색어를 입력할 때마다 새로운 기록이 생성됩니다
  • A/B 테스트는 매 순간 새로운 실험 데이터를 만들어냅니다
  • 주문이 들어올 때마다 거래 데이터가 추가됩니다

이런 데이터들은 각각 독립적인 사건이 아닙니다. 서로 연결되어 있고, 시간의 흐름 속에서 의미를 가집니다.

 

1.2. 데이터를 바라보는 관점의 변화

위 데이터를 어떻게 다뤄야 할까요?

 

가장 간단하게 생각한다면

 

1. 일단 저장하기
   - 로그 시스템에 쌓아두기
   - DB에 차곡차곡 적재하기

2. 나중에 한꺼번에 처리하기
   - 새벽 시간에 집계 작업 실행
   - 다음 날 아침에 결과 확인

일단 저장하고 나중에 한번에 처리할 수 있습니다.

이런 방식은 마치 강물을 댐에 가두었다가, 한꺼번에 처리하는 것과 비슷합니다. 안정적이고 효율적이죠. 위 방법은 전통적인 배치 처리 방식 이라고 볼 수 있습니다.

 

다른 관점은 없을까요?

데이터를 '흐름' 그 자체로 바라보는 거죠. 댐에 가두지 않고, 흐르는 강물을 따라 실시간으로 처리하는 방식입니다. 이것이 바로 스트림 처리의 첫 시작이라고 할 수 있습니다.


2. 데이터 처리의 진화

2.1. 전통적인 데이터 처리 방식

전통적인 데이터 처리 아키텍처는 크게 두 가지로 볼 수 있습니다.

2.1.1. 트랜잭션 처리 (운영계)

비즈니스와 관련된 실시간 활동을 처리하기 위한 방식입니다.

웹 서비스의 상품 조회/클릭 로그 저장
주문/결제 데이터 DB 적재
검색어 입력과 검색 결과 저장

 

보통 애플리케이션 서버와 트랜잭션 DB로 구성된 2계층 구조로 처리합니다. 실시간으로 데이터를 '저장'하는 것이 주목적이죠.

하지만 이 구조의 한계도 분명합니다. 여러 애플리케이션이 같은 DB를 공유하다 보니, 스키마 변경이 어렵고 서로 강하게 결합됩니다. 이를 해결하기 위해 MSA 같은 패턴이 등장하기도 했습니다.

 

책 <아파치 플링크로 하는 스트림 데이터 처리> 그림 1-2

2.1.2. 분석 처리 (분석계)

트랜잭션 처리에서 저장한 데이터(운영 데이터) 쌓인 데이터를 분석해서 인사이트를 얻을 수 있습니다.

상품별 조회수와 클릭률 집계

사용자 행동 패턴 분석

추천 모델 학습용 데이터 준비

 

이를 위해 ETL(Extract, Transform, Load) 과정을 거쳐 데이터 웨어하우스에 적재합니다. 여기서는 데이터의 '활용'이 주목적이죠.

책 <아파치 플링크로 하는 스트림 데이터 처리> 그림 1-3

 

참고) 정형화된 데이터를 저장하기 위한 데이터 웨어하우스를 넘어 비정형 데이터 등 더 넓은 범위의 데이터 레이크도 있습니다.

 

이러한 전통적인 방식은 안정성과 신뢰성이 높지만, 점점 더 빠른 의사결정이 필요한 환경에서는 좀 더 좋은 환경이 필요할 수 있습니다.

2.2. 실시간 스트림 처리로의 변화

2.2.1. "이벤트가 발생하는 순간" 처리하기

데이터를 더 이상 정적인 덩어리가 아닌, 시간에 따라 흐르는 연속된 이벤트로 바라봅니다.

 

기존 방식

1. 클릭 로그 저장

2. 하루 뒤 집계

3. 인사이트 도출

4. 다음 날 적용

 

실시간 처리

1. 클릭 발생

2. 즉시 처리/집계

3. 실시간 인사이트

4. 바로 적용

 

실시간 처리는 다음과 같은 상황에서 활용할 수 있습니다.

이상 거래 탐지: 부정 주문 즉시 차단
실시간 트렌드: 급상승 검색어 감지
동적 가격 정책: 수요에 따른 실시간 가격 조정

 

책 <아파치 플링크로 하는 스트림 데이터 처리> 그림 1-4

2.2.2. 상태 관리의 중요성

러한 무한한 이벤트 스트림을 처리하기 위해서는 "상태(state)"가 필요합니다. 왜 그럴까요?

 

간단한 예시를 들어보겠습니다.

"최근 1시간 동안 가장 많이 본 상품 TOP 10"을 계산하려면 어떻게 해야할까요?

 

1. 시간 정보 관리

   - 언제부터 언제까지의 데이터인지

   - 윈도우 밖의 데이터는 언제 버릴지

 

2. 집계 정보 유지

   - 각 상품별 조회수

   - 순위 정보

 

3. 장애 대비

   - 서버가 다운되면 여태 계산한 정보는?

   - 다시 시작할 때 어떻게 복구할지

 

네, 위 1,2,3을 적용하기 위해서는

- 메모리나 로컬 저장소에서 관리되어 빠른 접근 가능

- 장애 시에도 복구 가능해야 함

- 이벤트 순서가 보장되어야 함

 

즉, "상태"가 필요합니다.

2.3. 실시간 처리 사례

2.3.1. 이벤트 기반 애플리케이션

전통적인 요청-응답 방식 대신, 이벤트 스트림을 기반으로 동작하는 애플리케이션입니다.

 

장점

- 실시간 반응: 이벤트 발생 즉시 처리 가능

- 느슨한 결합: 시스템 간 직접적인 의존성 감소

- 확장성: 개별 컴포넌트 독립적 확장 가능

단점

- 복잡성 증가: 이벤트 흐름 추적이 어려울 수 있음

- 디버깅 어려움: 비동기 처리로 인한 문제 해결 복잡

 

적용 사례

- 실시간 추천: 사용자 행동 기반 즉시 추천

- 부정 거래 탐지: 이상 패턴 실시간 감지

-  이상 징후 감지: 시스템 모니터링

 

책 <아파치 플링크로 하는 스트림 데이터 처리> 그림 1-5

 

Apache Flink Evenet-driven Applications - https://flink.apache.org/what-is-flink/use-cases/

2.3.2. 실시간 데이터 파이프라인

서로 다른 시스템 간의 데이터 동기화를 실시간으로 처리합니다

 

장점

- 낮은 지연 시간: 배치 처리 대비 빠른 데이터 전달

- 유연한 변환: 데이터 형식을 실시간으로 변환 가능

- 다양한 시스템 연동: 서로 다른 시스템 간 실시간 통합

 

단점

- 리소스 사용량: 지속적인 처리로 인한 리소스 부담

- 순서 보장 어려움: 분산 환경에서 이벤트 순서 관리 필요

 

적용 사례

- 검색 데이터 동기화: 상품 정보 변경 → 검색 인덱스 실시간 갱신

- 캐시 갱신: DB 변경 → 캐시 즉시 업데이트

- 실시간 집계: 주문 발생 → 매출 대시보드 실시간 반영

 

Data Pipeline Applications - https://flink.apache.org/what-is-flink/use-cases/

2.3.3. 스트리밍 분석

실시간으로 들어오는 데이터를 즉시 분석하여 인사이트를 도출합니다.

 

장점

- 즉각적인 인사이트: 데이터 발생 즉시 분석 가능

- 빠른 대응: 이상 징후 즉시 감지 및 대응

- 리소스 효율성: 필요한 데이터만 선택적 처리

단점

- 정확도 vs 속도: 실시간성과 정확성 사이 트레이드오프

- 분석 복잡도 제한: 복잡한 분석은 여전히 배치 처리 필요

 

적용 사례

- A/B 테스트 모니터링: 실험 결과 실시간 확인

- 트래픽 분석: 서비스 이상 징후 즉시 감지

- 실시간 리포트: 프로모션 효과 실시간 측정

 

Data Analytics Applications - https://flink.apache.org/what-is-flink/use-cases/
책 <아파치 플링크로 하는 스트림 데이터 처리> 그림 1-6

 

이처럼 실시간 스트림 처리는 다양한 형태로 활용될 수 있습니다.

 

그렇다면 실시간 스트림 처리에 대해 좀 더 살펴볼까요?


3. 실시간 스트림 처리 살펴보기

3.1. 데이터 플로우 프로그래밍의 이해

데이터 플로우 프로그래밍이란 데이터가 어떻게 흐르고 처리되는지를 기술하는 방식입니다. 마치 공장의 조립 라인처럼, 데이터가 각 처리 단계를 거쳐 흘러가는 모습을 그려볼 수 있죠.

3.2. 데이터 플로우 그래프

데이터 플로우는 보통 방향성 그래프(directed graph)로 표현됩니다.

노드(연산자): 실제 데이터를 처리하는 부분

엣지(화살표): 데이터가 흐르는 경로

소스: 데이터가 시작되는 지점

싱크: 데이터가 최종적으로 도달하는 지점

 

데이터 플로 그래프 사례를 좀 더 살펴보면 

- 실시간 추천 시스템

실시간 추천 시스템 데이터 플로우

 

- 실시간 이상 거래 탐지

실시간 이상 거래 탐지 데이터 플로우

- A/B 테스트 모니터링

A/B 테스트 모니터링 데이터 플로우 그래흐

 

3.3. 병렬 스트림 처리

실제 서비스에서는 수많은 데이터를 동시에 처리해야 합니다. 이를 위해 병렬 처리가 필수적이죠.

3.3.1. 지연과 처리율

스트림 처리에서 가장 중요한 두 가지 지표는 "지연"과 "처리율" 입니다.

 

3.3.1.1. 지연(Latency)

하나의 이벤트가 처리되는 데 걸리는 시간입니다.

 

추천 시스템 예

- 상품 클릭 → 추천 결과 갱신: 100ms

- 장바구니 담기 → 연관 상품 추천: 150ms

- 검색어 입력 → 실시간 검색어 순위 반영: 200ms

모니터링 예

- 이상 거래 감지: 50ms 이내

- 시스템 장애 알림: 100ms 이내

 

3.3.1.2. 처리율(Throughput)

단위 시간당 처리할 수 있는 이벤트의 수입니다.

 

일반적인 요구사항

- 클릭 이벤트: 초당 10,000건

- 로그 데이터: 분당 1,000,000건

- 결제 트랜잭션: 초당 1,000건

 

피크 시간대

- 대규모 프로모션: 평소 대비 10배 처리율 필요

- 명절 시즌: 평소 대비 5배 처리율 필요

 

이러한 요구사항을 만족시키기 위해 병렬 처리가 필요합니다.

3.4. 병렬 스트림 처리 사례

3.4.1. 실시간 스트림 처리의 기본 아키텍처

좀 더 구현 레벨에서 예시를 살펴봅시다.

실시간 스트림 처리의 기본 아키텍처

기본 구성 요소

- 이벤트 소스: 사용자 행동 로그, 시스템 이벤트 등

- 메시지 큐: Kafka 등을 통한 이벤트 스트림 관리

- 스트림 처리: 실제 데이터 처리 로직

- 저장소: 처리 결과 저장

3.4.2. 패션 커머스 실시간 랭킹 시스템 예시

먼저 가장 단순한 형태의 실시간 랭킹을 아래와 같이 볼 수 있습니다.

간단한 실시간 랭킹 시스템

기본 요구사항

- 조회수 기반의 단순 인기도 계산

- 1시간 단위 순위 업데이트

- 전체 상품 대상 단일 순위

 

실시간 랭킹 - 현실의 요구사항

하지만 실제 서비스에서는 더 복잡한 요구사항들이 있습니다.

 

1. 다양한 사용자 행동 반영

   - 단순 조회가 아닌 구매/장바구니/찜하기 등

   - 각 행동별 가중치 적용 필요

 

2. 시간에 따른 중요도

   - 최신 데이터에 더 높은 가중치

   - 시간별로 다른 사용자 패턴

 

3. 카테고리별 특성

   - 상품 종류마다 다른 인기도 패턴

   - 카테고리별 독립적인 순위 필요

 

이러한 요구사항을 반영하기 위해 병렬 스트림 처리가 필요해집니다.

병렬 스트림 처리 랭킹 시스템

 

위 처리를 좀 더 복잡한 예시로 설명을 해보면 아래와 같이도 볼 수 있습니다.

현실(?)적인 랭킹 시스템

 

1. 이벤트 수집 계층

사용자의 모든 행동을 실시간으로 수집하여 Kafka로 전송합니다. 각 이벤트는 발생 시점, 상품 정보, 사용자 행동 타입 등을 포함합니다.

2. 카테고리별 처리 계층

각 카테고리별로 독립적인 랭킹 처리를 수행합니다. 행동 점수, 시간 가중치, 카테고리별 특성을 반영한 보정값을 적용합니다.

3. 저장 및 서빙 계층

시간 단위별로 집계된 랭킹을 Redis에 저장하고, API를 통해 서비스에 제공합니다.

이런 구조로 실시간 랭킹을 처리하면서, 이를 기반으로 추천 시스템도 구현할 수 있습니다.

3.4.3. 개인화 추천 시스템

추천 시스템은 사용자에게 적절한 상품을 추천하는 복잡한 시스템입니다. 여기서 실시간 스트림 처리는 어떤 역할을 할 수 있을까요?

 

가장 단순한 형태

가장 단순한 추천 시스템

처음에는 "방금 본 상품과 비슷한 상품 추천"처럼 단순한 형태를 생각할 수 있습니다. 하지만 실제 추천 시스템은 훨씬 더 복잡합니다.

 

실시간 추천 시스템

추천 시스템에 재료로 사용되는 실시간스트림 처리

추천에서 실시간 스트림 처리는 주로 "재료"를 만드는 역할을 합니다. 사용자가 지금 무엇에 관심이 있는지, 어떤 행동 패턴을 보이는지를 실시간으로 파악하는 거죠.

 

실시간 사용자 프로파일링

사용자의 모든 행동은 하나의 스트림으로 수집됩니다. 이 데이터를 실시간으로 처리하면서 사용자의 현재 상태와 의도를 파악할 수 있습니다.

 

사용자 행동 스트림의 활용

1. 실시간 프로파일링

   - 현재 관심 카테고리

   - 선호하는 가격대

   - 브라우징 패턴

 

2. 추천 시스템에서의 활용

   - 배치로 계산된 추천 결과 필터링

   - 실시간 모델의 입력값으로 사용

   - 트렌드 감지에 활용

 

이렇게 만들어진 "재료"는 추천 시스템의 여러 부분에서 사용됩니다.

 

 

1. 배치 추천 결과 활용

미리 계산된 추천 결과를 현재 상황에 맞게 조정합니다.

 

예시: "당신을 위한 추천"

- 협업 필터링으로 계산된 200개 상품 중

- 지금 보고 있는 카테고리 상품 우선

- 최근 본 상품과 비슷한 가격대 필터링

 

2. 실시간 모델 입력값

실시간 추천 모델의 정확도를 높이는 데 활용됩니다.

 

예시: "지금 이 상품은 어떠세요?"

- 현재 세션의 관심사 반영

- 최근 1시간 행동 패턴 기반

- 비슷한 상품 클릭률 예측

 

3. 트렌드 감지

전체적인 인기도와 개인의 관심사를 결합합니다.

 

예시: "실시간 인기 상품"

- 현재 카테고리 인기 상품 중

- 사용자 선호도와 매칭

- 가격대/스타일 필터링

 

이러한 활용은 추천의 정확도와 실시간성을 모두 높여줍니다. 복잡한 계산은 배치 처리 / 실시간 모델로하고, 실시간 상황은 스트림 처리로 보완하는 거죠.


마무리 & Reference

이번 글에서는 실시간 스트림 처리의 기본 개념과 활용 사례를 살펴보았습니다. 실시간 랭킹과 개인화 추천 시스템 예시도 소개 드렸습니다.

다음 글에서는 이러한 실시간 스트림 처리를 구현하기 위한 도구들과 실제 구현 방법에 대해 자세히 알아보도록 하겠습니다.

 

감사합니다. 😊

 

Reference

- 책 <아파치 플링크로 하는 스트림 데이터 처리>

- https://flink.apache.org/what-is-flink/use-cases/