데이터 중심 애플리케이션 설계, 마틴 클레프만 지음. OREILLY.
지난 장에서는 대량의 데이터를 일괄적으로, 한방에 처리하는 방식을 알아보았다. 이번 장에서는 반대로 실시간으로, 조금씩 처리하는 방식을 알아본다.
스트림
정체
= 시간에 따라 점진적으로 생산된 데이터.
다른 책에서도 스트림에 대한 여러가지 정의를 봤지만 이 표현이 제일 깔끔하고 직관적인 것 같다.
모던 자바 인 액션에서 나온 비유로는 기존에 우리가 알던 일반적인 데이터는 비디오 테이프, 그리고 스트림은 넷플릭스 같은 실시간 스트리밍 서비스에 빗댈 수 있다. 그러니까 데이터가 저장 공간에 가만히 머물러 있는게 아니라, 하나씩 스트림에서 나오는 것이다. 스트림 처리를 할 때도 저장된 요소를 한방에 처리하는게 아니라 각 요소별로 하나씩 처리를 해준다.
스트림 처리 vs. 파일 시스템
스트림과 파일 시스템은 결국 데이터를 다루기 위한 방식이기 때문에 공통점이 꽤 있다. 데이터에 대한 read/write 연산이 필요하고 각 데이터를 구분하는 식별자(예: 파일명)가 필요하고, ... 다만 디테일한 방법과 명칭이 좀 다를 뿐이다.
| 구분 | 파일 시스템 | 스트림 |
|---|---|---|
| 데이터를 갖고 있는 주체 | 파일 | 생산자(혹은 발행자, 발송자) |
| 의미를 갖는 데이터의 최소 단위 | 레코드 | 이벤트 |
| 관련된 데이터를 묶는 방법 | 파일 이름 | 토픽, 스트림 |
차이점은 다음과 같다.
| 구분 | 파일 시스템 | 스트림 |
|---|---|---|
| 데이터를 소비하는 시점 | 특정 시각에 소비 | 주기적 소비 |
| 특정 시점에 데이터의 양 | 많음 | 적음 |
| 지연 시간 | 길다 | 짧다 |
| 지속성 | 좋음 | 나쁨 |
즉, 파일 시스템은 대용량 데이터를 파일에 저장해놓고 가끔씩 대량으로 처리하는 반면 스트림은 일시적인 데이터를 자주 소량으로 처리한다.
스트림은 어디서 오고 어디로 가나
스트림 데이터는 언제 만들어질까? 질문을 바꿔보자. 언제 파일이 아닌 스트림 형식으로 데이터를 다루면 좋을까?
- 사용자가 만든 이벤트 (예: 버튼 클릭, 페이지 조회, 스크롤 등...)
- 데이터베이스 write 로그
- 센서에 감지된 이벤트 (예: 리스너가 감지한 이벤트)
주로 로그성 데이터다. 작은 데이터가 모여 대규모 데이터를 만드는 경우가 많다. 그렇다면 이런 데이터는 어떻게 가져와서 어떻게 처리하면 좋을까? 책에서는 스트림이 데이터를 전송하는 방식도 상세히 알려준다.
- 메시징 시스템으로 직접 메시지 보내기
- 메시지 브로커 사용
스트림이 데이터를 내보내는 방식
메시징 시스템
스트림 데이터를 받는 가장 단순한 방법이다. 생산자가 만들어낸 데이터를 소비자가 직접 사용한다. 중간 유통 업체가 없는 직거래다.
메시지 브로커
메시지 큐를 사용한다. 여러 소비자가 하나의 스트림에서 데이터를 받아가야 할 경우, 복수 소비자 처리를 위한 기법에도 종류가 있다. 로드 밸런싱 방식과 팬 아웃 방식이다. 책에서는 각 방식의 장단점을 비교한다.
메시지 브로커 자체에도 종류가 있다. 로그 기반 메시지 브로커와 AMQP/JMS 유형 메시지 브로커가 있다. 로그 기반 메시지 브로커는 AMQP/JMS 방식에 비해 지연시간이 짧고 지속성이 좋다는 장점이 있다. 스트림과 파일 시스템 양쪽의 장점을 취하기 위해 만들어졌기 때문이다.
스트림 처리
스트림을 처리하는 방법은 크게 3가지가 있다.
- 이벤트에서 데이터를 꺼내 DB나 저장소 시스템에 기록하고 다른 클라이언트가 해당 기록을 볼 때
- 이벤트를 사용자에게 직접 보낼 때.
- 예) 이메일 경고, 푸시 알림 전송
- 하나 이상의 입력 스트림을 처리해서 하나 이상의 출력 스트림을 생산할 때.
책에서는 위 3가지 경우 중 마지막, 새로운 출력 스트림을 생산하는 경우를 중점적으로 다룬다. 예를 들면 모니터링, 복잡한 이벤트 처리(CEP, Complex Event Proccessing), 분석과 같은 작업에서 어떻게 스트림을 효과적으로 사용할지 알려준다. 관련 주제로 스트림과 테이블끼리 조인하는 스트림 조인, 그리고 내결함성에 대한 이야기도 나온다.
