2장. 스트리밍 처리 기초
2장에서는 데이터 플로우 프로그래밍 관련 용어 소개와 배경지식을 설명하고 있다.
데이터 플로우 프로그래밍 소개
데이터 플로우 그래프
데이터가 어떻게 흐르는지 표현하는 그래프.
- 노드(node) - 연산자(operator)라 부르고 계산을 표현
- 엣지(edge) - 의존 관계를 표현
- 데이터 소스 - 입력이 없는 연산자
- 싱크(sink) - 출력이 없는 연산자
데이터 병렬화와 태스크 병렬화
- 데이터 병렬화 - 동일한 연산을 수행하는 태스크에 데이터를 분할하여 병렬 처리
- 태스크 병렬화 - 어플리케이션의 개별 태스크를 워커 또는 쓰레드를 분할 할당 하여 병렬로 처리
데이터 교환 전략 (data exchange strategy)
물리적 데이터플로우 그래프에서 어떤 태스크로 레코드를 할당할지 정의한다.
- 전진(Forward) 전략 - 한 태스크로 들어온 데이터를 다른 태스크로 전달
- 브로드 캐스트(Broadcast) 전략 - 한 태스크로 들어온 데이터를 모든 다른 병렬 태스크로 전달
- 키 기반(Key-based) 전략 - 데이터를 키 기준으로 모아 같은 키 값을 가진 데이터를 같은 태스크로 모이도록 보장 (ex 같은 해시태크를 가진 데이터끼리 모아서 처리)
- 랜덤(Random) 전략 - 각 계산 태스크의 부하를 균등하게 분산시키고자 모든 연산자 태스크로 데이터를 균등하게 분배
병렬 스트림 처리
데이터 스트림이란? 데이터 스트림은 무한 이벤트 순서열(unbounded sequence of events)이다.
데이터플로우 프로그래밍을 사용해 어떻게 무한 이벤트 스트림을 병렬로 처리 하는지 알아보자.
지연과 처리율
- 스트리밍 애플리케이션에서 성능을 측정하는 요건
- 지연(Latency)
- 이벤트를 처리 하는데 얼마나 많은 시간이 걸리는지 나타내는 지표
- 이벤트 수신과 처리 결과가 출력될때까지의 경과 시간
- 애플리케이션에 따라 평균 지연, 최대 지연, 또는 퍼센타일 지연(이벤트의 95%를 처리 하는데 걸린 시간)에 관심을 가지게 된
- 짧은 지연은 스트림 처리의 핵심 특징이며, 짧은 지연 덕분에 실시간(real-time) 애플리케이션 구현이 가능해진다.
- 대조적으로 전통적인 배치 처리의 지연은 몇 분에서 몇시간 걸리는게 보통이다. 배치 처리에서는 이벤트를 배치로 모아야 처리가 가능하다.
- 처리율(Throughput)
- 단위 시간당 얼마나 많은 이벤트를 처리할 수 있는지를 알려준다.
- 도착한 이벤트 비율에 의존하기 때문에 낮은 처리율이 꼭 나쁜 성능을 나타내지는 않는다.
- 시스템이 처리 할 수 있는 비율보다 높게 데이터를 계속 받으면 버퍼링도 불가능하게 돼 데이터를 잃을 수도 있다. 이런 상황을 배압(backpressure)라고 하고, 이를 처리하기 위한 여러 전략이 있다.
짧은 지연과 처리율과 높은 성능 모드를 만족하기 위해서는 태스크(책에서는 까페의 바리스타 수로 설명)수를 늘려 병렬 처리 하여 해결 할 수 있다.
데이터 스트림 연산
스트리밍 애플리케이션은 앞서 소개한 데이터 플로우 그래프의 인입, 변환, 출력과 같은 연산의 조합이라고 볼 수 있다.
연산은 상태가 있는 연산과 없는 연산으로 나눌 수 있다.
상태가 없는 연산
- 이벤트에 대한 처리가 과거 다른 이벤트에 의존하지 않으며 아무런 이력도 유지 하지 않는다.
- 따라서 서로 독립적이고 도착하는 순서에 의존하지 않음으로 병렬화 하기가 쉽다.
- 장애가 발생하더라도 마지막에 처리 했던 지점 부터 재시작하면 된다.
상태가 있는 연산
- 이전에 받은 이벤트의 정보를 유지한다. 새로운 이벤트는 이 상태를 갱신하고, 미래의 이벤트는 이 상태를 이벤트 처리 로직에서 사용 할 수 있다.
- 상태가 있는 스트림 처리 애플리케이션은 상태를 효과적으로 분할하고 장애가 발생할 때 안정적으로 복구해야 하므로 병렬화와 내고장성을 유지하는 것이 큰 과제이다.
데이터 인입과 방출
인입 연산
- 데이터를 가져오는 로직을 구현한 연산자, 데이터 소스라고 한다. (ex. kafka 로부터 데이터 가져오기)
방출 연산
- 데이터 방출을 수행하는 연산자, 데이터 싱크라고 한다. (ex. 파일, 데이터 베이스에 데이터 저장, 다른 API로 전송)
롤링 집계 연산
이벤트가 들어올 때 마다 계속해서 집계를 계산하여 현재 상태를 갱신하는 방식
윈도우 연산
이벤트 연산 결과를 시간이나 갯수와 같은 속성으로 범위를 분할하여 집계를 한다. 여기서 시간이나 갯수와 같은 유한 집합을 버킷(bucket)이라고 한다. 윈도우 연산자의 시멘틱(semantic)을 정확하게 정의하려면 얼마나 많은 이벤트를 버킷에 넣고, 윈도우가 얼마나 자주 결과를 만들어낼지 정해야 한다. 윈도우 시멘틱은 이런 정책을 의미하며, 윈도우 내용을 평가할 시점은 트리거(trigger) 조건을 기반으로 결정한다. 트리거 조건이 충족되면 버킷의 내용을 평가 함수로 전달해 각 버킷 이벤트에 연산 로직을 적용한다.
일반적인 윈도우 시멘틱 종류를 알아보자.
- 텀블링 윈도우 - 고정 범위를 정하여 윈도우드가 서로 겹치지 않는 버킷으로 이벤트를 할당 (ex. 시간 간격으로 정의)
- 슬라이딩 윈도우 - 고정 범위의 버킷으로 이벤트를 할당하지만, 버킷이 서로 중첩되는 구간이 생긴다. 따라서 두 버킷에 포함되는 이벤트도 있을 수 있다. 슬라이딩 윈도우는 길이와 슬라이드로 정의 한다. 슬라이드 값은 새로운 버킷이 생성 될때까지의 간격(빈도)를 의미한다.
- 세션 윈도우 - 사용자 활동이나 세션을 대상으로 버킷을 생성. 세션 윈도우는 세션이 종료됐다고 판단할 수 있는 비활동 시간을 세션 격차라는 값으로 정의하여 이벤트들을 세션으로 그룹화한다.
위의 윈도우 들은 전체 이벤트를 대상으로 동작 하지만, 스트림을 여러 논리적 스트림으로 분할하여 병렬 윈도우로 정의하고 싶을 수도 있다.
예) 서로 다른 센서 장비에서 데이터를 받을 때 스트림을 센서 식별자로 그룹핑해서 윈도우 계산을 하고 싶은 경우
아파치 플링크는 병렬 윈도우의 각 파티션별로 다른 윈도우 정책을 적용할 수 있다.
시간 시멘틱
스트리밍 프로그래밍에서는 시간 개념을 '처리 시간'과 '이벤트 시간'을 분리하여 연산을 수행한다.
처리 시간 - 스트림 처리 연산자가 이벤트를 수신받아 처리한 시간
이벤트 시간 - 이벤트가 실제 발생한 시간
이벤트가 발생한 시간의 순서가 중요한 application 에서는 데이터의 순서가 바뀌더라도 이벤트의 시간을 이용해 처리 해야 결과의 정확성을 보장할 수 있다.
워터마크
데이터 스트림 처리에서 윈도우의 버킷을 결정 할 수 있게 하는 시간적 기준을 정의하는 주요한 개념으로 아래와 같은 중요 요소를 가지고 있다.
1. 이벤트 시간(Event Time) : 데이터가 실제로 발생한 시간
2. 이벤트 처리 시간 (Processing Time): 데이터가 처리 시스템에 도달한 시간
3. 허용 지연 시간(Lateness Tolerance) : 워터마크가 "이벤트 시간"을 기준으로 얼마나 오래 기다릴 것인지 설정하는 값
상태
스트림 처리 프로그래밍에서 무한의 스트림 처리를 진행하는 동안 중간 결과나 데이터는 저장하는 개념.
플링크는 이벤트 기반 과 상태 기반 연산을 통해서 높은 Fault Tolerance(내결함성)을 보장한다.
상태 기반 연산이 가능 하기 위해서는 다음과 같은 요소가 필요하다.
- 상태 관리 - 시스템은 상태 관리를 효율적으로 해야 하고 동시에 상태를 갱신할 때 상태를 보호해야 한다.
- 상태 분할 - 상태를 분할하여 관리가 가능 해야 한다. (키를 기준으로 상태 저장, 연산 기준으로 상태 저장)
- 상태 복구 - 상태를 복구하고 장애시에도 정확한 결과를 내보내야 한다.
결과 보장
결과 보장(Guarantees)은 스트리밍 시스템이 데이터를 처리할 때, 특정상황(장애, 네트워크 문제등)에서도 결과의 정확성과 일관성을 얼마나 보장할 수 있는지를 나타낸다. 스트림 프로그램미에서 일반적으로 세가지 주요 결과 보장 수준이 사용된다.
- At-most-once (최대 1회 처리)
- 각 데이터가 최대 한번만 처리되는 것을 보장
- 데이터가 시스템에서 손실될 가능성이 있음
- At-least-once (최소 1회 처리)
- 각 데이터가 최소 한번 이상 처리됨을 보장
- 데이터가 중복 처리 될 가능성이 있음.
- 데이터 손실은 허용하지 않지만, 동일한 데이터가 여러번 처리 될 수 있음.
- 중복 제거가 필요하면 애플리케이션 레벨에서 처리 해야 함.
- 장애 발생 시, 체크포인트나 커밋포인트를 기준으로 데이터를 재처리
- 예) 금융 거래 기록 - 데이터 손실이 허용되지 않으나 중복은 나중에 제거 가능
- 예) IOT 센서 데이터 수집(손실된 데이터를 복구하는 것이 중요)
- Exactly-once (정확히 1회 처리)
- 각 데이터가 정확히 한번만 처리됨을 보장
- 데이터 손실 및 중복 처리 모두 방지
- 가장 신뢰성이 높은 보장 수준
- 처리 비용과 복잡도가 높음 (체크 포인트 관리, 트랜잭션 시스템 통합등 필요)
- 대부분의 시스템은 분산 시스템 환경에서 이 보장을 달성하기 위해 트랜잭션 및 체크포인트 기술을 활용
- 예) 금융 시스템(결제, 거래 기록 등)
- 주문 처리 시스템(중복 처리나 데이터 손실이 치명적인 경우)
댓글