All
6.1 실시간 수집 계층과 실시간 처리 계층 비교
실시간 수집
•
소스 시스템에서 데스티네이션 시스템으로 한 번에 한 메시지를 스트리밍하는 파이프라인
•
실시간으로 데이터가 전달되지만, 실시간으로 활용된다는 의미는 아님
•
예: ADHOC 쿼리나 대시보드 새로고침 시 최신 데이터를 조회하는 것
실시간 처리
•
스트리밍 데이터를 바로 변환하는 작업을 표현할때 사용
•
데이터 웨어하우스는 이미 수신된 데이터만 조회가능하고 대체적으로 많은 양의 데이터를 읽어야해서 조회가 초~분단위까지 가므로 실시간 처리에 적합하지 않음
•
대용량 데이터를 읽지 않고 상시 실행되는 상태에서 값을 재계산
•
엔드포인트 대신 키/밸류 DB, 인메모리 캐시 등으로 데이터 액세스 지연 최소화
•
예: 게임 내 활동 반응, 추천 시스템, 이상행위 탐지 등
6.2 실시간 데이터 처리 유스케이스
실시간이 요구되는 두 가지 유스케이스
유스케이스 | 실시간의 의미 | 데이터 플랫폼 필요조건 |
대시보드 실시간 조회 | 조회 시점에 최신 정보 제공 | 데이터 웨어하우스로 실시간 데이터 수집 |
사용자 행동 패턴이 바뀔때마다 반응하는 게임 애플리케이션 | 행동 변화에 즉각 반응 및 처리 | 실시간 데이터 수집 + 실시간 처리 |
대시보드 실시간 조회
•
최종 사용자: 영업부서 등
•
초단위로 대시보드를 바라보는 것이 목적이 아니고, 현재 상태의 실적 통계와 추이가 필요한 것으로 최신의 데이터를 제공받는 것이 중요
•
데이터 웨어하우스에 실시간으로 저장하고 필요할 때 갱신
•
실시간 수집 파이프라인이 필요
행동 기반 실시간 반응
•
사람 개입 없이 자동 처리 필요
•
온라인 게임에서 게임 플레이어들의 진행 내용을 수집하고 실시간으로 게임의 흐름 변경
•
실시간 수집과 처리 파이프라인 필요
→ 즉, 수집되는 데이터 기반으로 바로 액션을 취해야 하는 애플리케이션이 최종 데이터 소비자일 경우 실시간 수집 + 처리 구조 필요
6.3 실시간 파이프라인 구조화
flowchart TB
RAW[랜딩 영역]
ARC[아카이브 영역]
STG[스테이징 영역]
PROD[프로덕션 영역]
D1[데이터 산출물 1]
D2[데이터 산출물 2]
ST[데이터 저장소]
RAW --> STG
RAW --> ARC
STG --> PROD
PROD --> D1
PROD --> D2
D1 --> ST
D2 --> STMermaid
복사
1.
수집 계층에서 들어온 원시 데이터는 랜딩 영역에 저장
2.
공통 변환 후 스테이징 영역으로 이동
3.
비즈니스 로직 적용하여 프로덕션 영역에 저장
4.
각 단계별 실패 처리 방안 필요
6.3.1 실시간 시스템에서 공통 데이터 변환
공통 변환 처리
•
메시지 속성이 잘 정의된 단일 토픽으로 수집 후 공통 처리
◦
(책이 옛날거여서 그런지 하나의 컨슈머에서 하나의 토픽만 읽을수 있다고 함.. 하나의 컨슈머에서 여러 토픽 소비 가능해서 단일토픽 아니더라도 공통로직 다 적용시킬수 있음)
•
도메인/소스 시스템별 메시지 구조가 다르면 토픽 분리하여 처리
중복 데이터의 원인
실시간 시스템에서는 개별 서버에 장애가 발생할 경우 데이터 유실을 허용해서 안되므로 재시도 처리 과정에서 데이터 중복이 발생할 수 있음
•
프로듀서
◦
프로듀서가 메시지 보내고 1번 파티션에 저장이 완료되고 ACK를 프로듀서에 보냄
◦
네트워크에 문제가 생겨 프로듀서는 ACK 못받았지만 저장은 완료된 상태
◦
프로듀서는 ACK 못받았으므로 메시지 또 발송해 두번 저장
•
컨슈머
◦
컨슈머가 1번 오프셋 읽고 처리 완료함
◦
컨슈머 문제가 생겨 1번 오프셋을 처리했다는 ACK 보내기 실패
◦
1번 오프셋은 처리 완료됐었지만 컨슈머가 재기동되면서 커밋안된 오프셋부터 읽어 메시지 중복 소비
◦
자동 커밋 주기를 길게 잡으면 중복 가능성 증가
◦
오프셋마다 커밋 가능하지만 실시간 시스템의 성능 저하
•
처리 보장 요구사항에 따라 "Exactly-once" 또는 "At-least-once" 전략 선택 필요
데이터 중복 제거
•
타임 윈도우 활용
◦
메시지들의 타임스탬프와 타임윈도우 활용해 특정 시간 간격을 그룹화하고 그룹내 중복 메시지 제거
◦
윈도우가 충분히 크지 않으면 중복 데이터를 결국 막을 순 없고, 윈도우 사이즈 한계도 있기 때문에 이 방식으로 충분하진 않음
•
고유 ID 활용
◦
고유 ID를 고속 스토리지(키/밸류 저장소)에 캐싱하여 활용하는 방식
◦
예: order_id를 캐시에서 조회 → 없으면 메시지 처리하고 id 저장, 있으면 처리하지 않음
◦
단점은 성능와 가용성이 보장된 별도의 스토리지가 필요해 관리 포인트와 복잡성이 증가
•
데스티네이션 시스템에서 제거하기
◦
데이터 웨어하우스에서 배치 처리로 중복 제거
◦
실시간 수집은 하지만 실시간 처리는 필요 없을 경우 유효
즉시 분석이 필요 없고 빠른 수집이 중요하다면, 중복 허용 후 레이크나 웨어하우스에서 제거하는 전략이 구축 복잡성 측면에서 유리
메시지 포맷 변환
•
메시지는 바이트 스트림이며, 포맷은 컨슈머/프로듀서 간 합의 필요
•
단일 메시지 처리 상황에서 스키마를 매번 추론하는 방식은 비효율적
•
JSON: 스키마 관리 불가, 압축률 낮음 → 비효율적
•
Avro: 바이너리 포맷으로 메시지 크기 감소, 스키마 관리할 메타데이터 계층이 따로 필요
•
Parquet: 컬럼 기반 포맷으로 하나의 메시지 단위 처리에는 부적합
실시간 데이터 품질 체크
•
메시지의 정상/비정상 여부 규칙 정의
•
검사 결과에 따라 실패용 토픽으로 보냄
•
타임 윈도우로 그룹화하여 체크도 가능
◦
예시: 최근 1시간 주문 중 취소 비율이 10% 이상이면 경고 발생 규칙
◦
한시간 윈도우로 모아서 전체 ORDERS 개수와 취소된 ORDERS 개수로 백분율 구하는 방식으로 활용