하나 이상의 이벤트 스트림을 계속해서 처리하는 것. 요청-응답, 배치 처리와 나란히 놓이는 프로그래밍 패러다임이지 특정 프레임워크가 아니다.
무한한 데이터세트와 그 성질
데이터 스트림은 무한히 늘어나는 데이터세트를 추상화한 것이다. 시간이 흐르면 새 레코드가 계속 추가되므로 끝이 없다. 신용카드 결제, 주식 거래, 택배 배송, 네트워크 이벤트까지 거의 모든 것을 이벤트의 연속으로 볼 수 있다.
이벤트 스트림에는 성질이 셋 있다. 순서가 있어서 이벤트 자체가 다른 이벤트의 전 또는 후에 발생했다는 것을 담는다. 레코드는 불변해서 한 번 발생한 이벤트는 고칠 수 없고, 그래서 스트림은 작업 내역의 기록이 된다. 그리고 재생이 가능하다. 몇 달 전, 몇 년 전의 raw 스트림을 그대로 다시 흘려볼 수 있어야 에러를 수정하거나 새로운 분석 방법을 시도하거나 감사를 수행할 수 있다. 카프카가 이벤트 스트림을 캡처하고 재생할 수 있는 시스템이다.
성질에 데이터의 양은 들어 있지 않다. 초당 수백만 개든 분당 몇 개든 처리 방식은 같다.
정의는 단순하다. 무한한 크기의 데이터세트에서 연속적으로 데이터를 읽어와서 뭔가를 하고 결과를 내보내는 것. 지속적으로 계속되어야 한다는 조건만 있고 특정 프레임워크나 API를 요구하지 않는다.
쓰이는 곳
쓰이는 곳을 보면 감이 온다. 고객 서비스는 변경 사항을 거의 실시간으로 전달받아 처리한다. 사물 인터넷은 센서와 장비에서 오는 이벤트를 대규모로 처리해 유지 관리가 필요한 신호 패턴을 찾는다. 사기 탐지는 신용카드 부정 사용이나 주식 거래 부정을 잡아내는데, 일찍 탐지할수록 이익이 커서 탐지가 오래 걸리고 되돌리기 복잡한 배치보다 실시간이 선호된다.
요청-응답, 배치, 스트림
| 지연 | 처리량 | 블로킹 | |
|---|---|---|---|
| 요청-응답 | 1밀리초 미만에서 몇 밀리초 | 낮다 | 블로킹 |
| 배치 처리 | 몇 분에서 몇 시간 | 크다 | 정해진 시각에 시작 |
| 스트림 처리 | 그 사이 | 크다 | 논블로킹, 연속적 |
요청-응답은 지연이 가장 적고, 요청을 보낸 뒤 응답까지 대기하는 것이 보통이다. DB 세계의 OLTP가 여기 속하고 POS 시스템, 신용카드 결제, 시간 추적 시스템이 예다.
배치 처리는 정해진 시각에 시작해 필요한 입력을 전부 읽고 출력을 전부 쓴 다음 다음 실행까지 대기한다. 데이터 웨어하우스와 BI 시스템이 여기 속한다. 하루에 한 번 적재되고 리포트가 생성되므로 사용자들은 다소 시간이 지난 데이터라는 것을 감안하고 본다. 효율성이 높고 규모의 경제를 달성할 수 있지만, 최근의 비즈니스는 더 짧은 간격의 데이터를 원하고 지연보다 규모의 경제에 초점을 맞춰 설계된 시스템에게 이것은 엄청난 부담이 된다.
스트림 처리는 2밀리초를 기다리는 요청-응답과 8시간 걸리는 배치 사이의 간격을 메운다. 대부분의 비즈니스 프로세스가 연속적으로 발생한다는 통찰에서 나온 방식이다. 리포트가 계속 갱신되고 애플리케이션이 계속 응답할 수만 있다면 굳이 수 밀리초 내의 응답을 기다릴 필요가 없다. 의심스러운 결제 알림, 수요와 공급에 맞춘 실시간 가격 조정, 물품 배송 추적이 여기 맞는다.
스트림 처리가 답이 아닐 때
스트림 처리가 답이 아닐 때가 있다.
데이터 수집이 목적이라면 정말 스트림 처리 시스템이 필요한지, 수집에 최적화된 카프카 커넥트 같은 것으로 충분한지 먼저 생각한다.
밀리초 단위 작업이라면 카프카 스트림즈를 쓰는 것 자체를 다시 고려해야 하고, 대체로 요청-응답이 낫다. 그래도 필요하다면 마이크로배치가 아니라 이벤트 단위 저지연 방식을 고른다.
비동기 마이크로서비스에는 메시지 버스와 잘 통합되고, 업스트림 변경을 로컬 상태에 쉽게 반영할 수 있고, 로컬 상태를 캐시나 구체화된 뷰로 활용할 수 있는 시스템이 필요하다. 반대로 복잡한 분석 엔진에는 로컬 저장소 지원보다 복잡한 집계, 윈도우, 조인을 잘 지원하는 것이 더 중요하다.
무엇을 고르든 배포와 모니터링이 쉬운가, 확장과 축소가 되는가, 실수해서 재처리해야 할 때 어떻게 대응하는가를 함께 본다. 추상에 구멍이 있어서 세부사항을 직접 제어해야 하는지가 실제 생산성을 가른다.