[데이터 중심 애플리케이션 설계] 스트림 프로세싱

1. 배치 vs 스트림

• 배치 프로세스는 언제 읽기 작업이 완료되었는지 알 수 있다.
• 하지만 실제로는 많은 데이터는 시간이 지남에 따라 점진적으로 도착하기 때문에 무제한이다.
• 일반적으로 스트림(stream)은 시간이 지남에 따라 점진적으로 제공되는 데이터를 의미이다.

 

2. 이벤트 스트림 전송

• 배치 작업에서 또한 스트리밍과 유사한 형태로 작업할 수 있다.
  • 파일이나 DB 를 통해 생산자에서 파일이나 DB로 쓰기 작업을 하고, 소비자로서 주기적인 폴링을 통해 작업을 처리할 수 있다.
  • 낮은 지연의 요구 사항에서 주기적인 폴링 비용으로 인해 소비자에게 알림을 전달하는 방법이 소비자에게 전달하는 방법이 필요하다.
• 이벤트는 JSON, text string, binary form 형태로 인코딩되고 저장된다.

 

3. 메시징 시스템

• 일반적으로 소비자에게 알림을 전달하는 일반적 방법은 메시징 시스템을 활용하는 것이다.

 

(1) 메시지 전달 시 고려사항

• 발행자가 소비자의 소비 속도보다 빠르게 메시지를 전달하는 문제를 대비해 메시지 삭제 전략, queue 에 메시지 버퍼링, 배압 적용 여부에 관해 고려해야 한다.
• 노드 충돌과 일시적 오프라인의 상황에서의 메시지 유실에 관해 고려해야 한다.

 

(2) message broker 기능

• 메시지 스트림 처리를 메시지 브로커를 통해 메시지를 전송하는 방법이다. 데이터를 중앙 집중화시켜 연결, 충돌을 쉽게 견디고 내구성 문제를 브로커로 이전한다.
• 메시지 저장 방식은 메모리, 디스크에 저장하는 방법이 있다.
• 메시치 처리 속도 차이가 발생하면 메시지 삭제, backpressure 에 대해 고려해야 한다.
• 큐잉의 결과는 일반적으로 소비자가 비동기적 처리된다. 발행자는 메시지가 queue 에 버퍼링 여부만 확인하고, 소비자의 처리 여부에 관해 기다리지 않는다.

 

(3) DB 와 비교

• DB 는 명시적으로 제거할 때까지 데이터를 유지하는 반면, 메시지 브로커는 소비자에게 전달하는 순간 자동으로 삭제한다.
• 메시지를 즉각적으로 삭제하기 때문에 메시지 브로커의 working set 은 일반적으로 작다.
• DB 는 검색에 관한 다양한 기능을 제공하는 반면, 메시지 브로커는 특정 패턴을 구독하는 방법을 제공한다.
• DB 는 snapshot 을 통해 시점 관리를 하는 반면, 메시지 브로커는 데이터 변화는 공지한다.

 

(4) 다양한 소비 방식

• load balancing : 각 메시지는 소비자들 중 하나에게만 전달하는 방식이다.
• fan-out : 각 메시지는 구독하는 모든 소비자에게 전달하는 방식이다.

 

(5) 승인과 재전송

• 브로커가 승인을 받지 않고 클라이언트와의 연결이 닫히거나 시간이 지나면, 메시지가 처리되지 않았다고 가정하고, 따라서 다른 소비자에게 메시지를 다시 전달한다.
• 로드 밸런싱과 결합될 때, 재전달 액션에 따라 순서가 변경이 될 수 있으므로 각 큐를 구독하는 소비자는 독립적으로 구성해야 한다.

 

4. 파티션 된 로그

(1) 로그를 이용한 메시지 저장

• 메시지의 저장을 위해 각 메시지마다 단조 증가 순차 번호, 오프셋을 할당해야 한다.
• 높은 쓰로풋을 위해 브로커는 각 파티션에 메시지 순차 번호, 오프셋을 할당하며 싱글 스레드를 할당한다.

 

(2) 소비자 오프셋

• 소비자 오프셋을 통해 메시지 처리 여부를 확인할 수 있다.
• 소비자의 현재 오프셋이 모든 메시지의 오프셋보다 크다면 해당 메시지는 이미 처리됨을 의미한다.
• 순차 증가 sequence number 는 follower 의 재연결을 지원하고, 쓰기를 건너 뛰지 않고 복제를 재개할 수 있는 장점이 있다.

 

(3) 디스크 공간 사용

• 오래된 세그먼트는 제거되거나 압축 스토리지로 이동할 수 있다. 이를 방지하고자 circular buffer 또는 ring buffer 에 데이터를 버퍼링 또는 저장한다.
• 디스크 저장 공간을 계산 가능하다. 6TB 공간, 150MB/s 쓰기 처리량일 경우, 디스크는 11시간 정도 메시지 저장이 가능하다.

 

(4) 오래된 메시지 재생하기

• 오프셋은 소비자의 통제 하에 있으므로, 필요한 경우 쉽게 조작할 수 있다.
• 파생된 데이터는 반복 가능한 변환 프로세스를 통해 입력 데이터와 명확하게 분리된다.

 

5. 시스템 동기화 유지

• DB 는 최신 데이터를 업데이트하면서 캐시, 인덱스 등의 업데이트도 필요하다. 하지만 배치를 이용한 덤프는 느린 단점이 있다. 이중 쓰기는 경쟁 조건과 원자성을 보장할 수 없는 단점이 있다.

 

6. 변경 데이터 캡처(Change Data Capture)

(1) change data capture 구현

• CDC 는 시스템의 기록의 모든 변화를 보장하는 메커니즘이다.
• 해당 작업은 비동기 처리되므로, 소비자가 반영될 때까지 기다리지 않는다.
• 예시로는 MySQL binlog 가 있다.

 

(2) 로그 압축(log compaction)

• 초기 스냅샷을 구성할 때, 모든 로그 히스토리를 알아야 하는 단점이 있다.
• 로그 압축은 같은 키의 데이터의 최신 본만 관리하는 것을 의미한다.
• 로그 압축을 사용하면 새로운 소비자의 오프셋이 0부터 시작 가능하다.
• apache kafka 에서는 log compaction 기능을 제공한다.

 

(3) change stream 의 API 제공 사례

• MongoDB 는 oplog, Kafka Connect 와 같은 서비스를 제공한다.

 

이벤트 소싱

(1) evnet sourcing?

• CDC 와 event sourcing 은 추상화 레벨 차이가 있다. CDC 는 낮은 레벨, event sourcing 은 application level 의 추상화에 해당한다.
• event sourcing 은 사용자의 활동을 불변 이벤트를 기록한다는 점에서 의미가 있다. 이는 버그 방지와 같은 장점이 있다.

 

(2) 이벤트 로그에서 현재 상태 도출

• 로그 이벤트를 통해 현재 상태의 스냅샷을 구성할 수 있다.

 

(3) 명령과 이벤트

• 애플리케이션은 command 가 실행하기 이전에 우선 유효성 검증을 해야 한다.
• 소비자는 이벤트 스트림을 거절할 권한이 없기 때문에 명령 메시지를 생성되기 이전에 동기적으로 검증을 처리해야 한다.

 

상태, 스트림과 불변성

(1) 불변 이벤트의 장점

• 불변의 사건의 추가 전용 로그를 사용하면, 무슨 일이 일어났는지 진단하고 문제에서 복구하는 것이 훨씬 쉽다.
• 불변 이벤트는 또한 현재 상태보다 더 많은 정보를 포착한다.

 

(2) 같은 이벤트 로그를 통한 다양한 뷰

• 데이터가 읽히는 양식에서 쓰여지는 형태를 평가하고, 다른 읽기 보기를 허용함으로써 많은 유연성을 얻을 수 있습니다. 이 아이디어는 때때로 명령 쿼리 책임 분리(CQRS)로 알려져 있다.

 

(3) 동시성 제어

• 원자 단위로 작업을 결합하기 위해서는 트랜잭션과 같은 기능이 필요하다.
• 사용자 작업은 한 곳에 한 번만 쓰기만 하면 되므로 원자성(atomicity) 을 제공할 수 있다.

 

(4) 불변성의 한계

• 성능적, 관리적인 이유로 인해 불변 이벤트를 영구 보관하는데 한계가 있다. (e.g. 개인 정보 정책)

 

시간에 대한 추론

(1) 이벤트 시간 vs 프로세싱 시간

• 이벤트 시간과 프로세싱 시간의 혼동은 나쁜 데이터를 초래할 수 있다.

 

(2) 언제 준비되었는지 알기

• 이벤트 시간 측면에서의 문제는 특정 창에 대한 모든 이벤트를 언제 받았는지, 또는 아직 다가올 이벤트가 있는지 확신할 수 없다는 것이다.
• 디바이스가 오프라인으로 인해 이벤트를 버퍼링하고 난 후, 서버로 전송하는 경우 이벤트 생성 시점, 서버 전송 시점, 서버 수신 시점 중에 선택해야 한다. 서버 수신 시간과 서버 전송 시간을 뺴면 오프셋을 추정할 수 있다.

 

(3) 윈도우 종류

• 텀블링 윈도우
• 호핑 윈도우
• 슬라이딩 윈도우
• 세션 윈도우

 

(4) 스트림 조인

• 스트림-스트림 조인
• 스트림-테이블 조인
• 테이블-테이블 조인