DDIA Chapter 11: 스트림 처리

지난장 배치에서는 유닉스의 배치처리 방식과 맵리듀스를 기반으로 한 분산파일 시스템에대해서 알아보았습니다. 많이 혼란스럽고 어려운 장이였는데요, 이번 장에서는 스트림 처리에 대해서 알아봅니다. 배치를 기반으로 하는 설명이 나온다고 해서 많이 어려울 줄 알았는데 일부 읽을만한 내용들이 있어서 재밌었습니다.

---

 

 

목차

• 신규개념(New)
• 1. 배치와 스트림 처리의 차이
• 2. 메시징 시스템
  • 2.1 메시징 시스템 기본
  • 2.2. 생산자 -> 소비자로 메시지 전달하기
• 3. 스트림 처리
  • 3.1. 스트림이 할 수 있는 일
  • 3.2. 스트림의 예시
  • 3.3. 스트림 분석
• 4. 참고문헌

 

 

신규개념(New)

개념	설명
스트림(stream)	시간 흐름에 따라 점진적으로 생산된 데이터
레코드(record)	이벤트, 특정 시점에 일어난 사건에 대한 세부사항을 포함하는 작고 독립된 불변 객체
생산자(producer)	publisher, sender
소비자(consumer)	subscrier, recipient
트리거(trigger)	테이블에 대한 이벤트에 반응해 자동으로 실행되는 작업
메시징 시스템(Messaging system)	로그 데이터, 이벤트 메시지 등 API로 호출할 때 보내는 데이터를 처리하는 시스템
윈도우(window)	집계하는 시간의 간격

1. 배치와 스트림 처리의 차이

	배치	스트림
정의	입력으로 파일 집합을 읽어 출력으로 새로운 파일 집합을 생성하는 기술	연속적으로 발생하는 데이터를 실시간 혹은 준 실시간으로 처리하는 기술
활용예시	검색 색인, 추천시스템, 분석	실시간 로그 분석, 거래 모니터링, 실시간 알림 시스템 등
출력	파생 데이터(요약 데이터ㅡ 결과 리포트 등)	실시간으로 처리된 이벤트 결과(알림 등)
특징	끝이 있음(작업 단위가 명확)	영원히 끝나지 않음(데이터 흐름이 지속적으로 발생)

2. 메시징 시스템

2.1 메시징 시스템 기본

새로운 이벤트에 대해서 소비자에게 알려주고 쓰이는 일반적인 방법은 메시징 시스템(messaging system) 이다. 메시징 시스템을 이해하기 위해서 다음 블로그에서 글 발췌했다.

(Amendment) 메시징 시스템의 이해

https://victorydntmd.tistory.com/343

메시징 시스템( Messaging System )의 이해

 

위는 자동 메일 발송 시스템으로 3가지 시스템이 혼재

• 회원가입을 했을 때, 이메일을 발송하는 MemberService
• 주문완료가 되었을 때, 이메일을 발송하는 OrderService
• 메일을 실제 발송하는 MailService

이렇게 서비스가 분리되었을 때 프로세스는 다음과 같습니다.

1. MemberService에서 회원가입, OrderService에서 주문완료 이벤트가 발생
2. Messaging Client로 메일 전송에 필요한 데이터( 받는/보내는 사람 이메일 주소, 메시지 제목/내용 등.. )를 API 호출
3. Messaging Client에서 MOM을 구현한 소프트웨어(ex. kafka)로 메시지를 생산
4. MailService에서 메시지가 존재하는지 구독하고 있다가 메시지가 존재하면 메시지를 소비
5. MailService에서 API 정보들을 통해 User에게 메일 발송

이러한 구조를 Publish/Subscribe 또는 Producer/Consumer라고 합니다.
인용 끝

발행(publish), 구독(subsribe) 모델에서 시스템에서  생산자가 소비자가 메시지를 처리하는 속도보다 빠르게 메시지를 전송하는 경우 3가지 선택지 존재

• 메시지를 버림
• 큐에 메시지를 버퍼링
• 배압(backpressure), 흐름제어(flow control) 
  • 유닉스 파이프와 TCP의 예시

이 경우 메시지의 유실이 허용할지 말지 등의 규칙은 어플리케이션마다 다르며 이는 배치 시스템와 대조적인 특징. 배치 시스템은 실패한 태스크를 자동으로 재시도하고 실패한 태스크가 남긴 출력을 자동으로 폐기하기 때문

2.2. 생산자 -> 소비자로 메시지 전달하기

• 직접 전달하기
  • 대부분의 메시지 시스템이 중간노드 없이 전달
  • 소비자가 오프라인인 경우 잃어버릴 가능성 있음. 생산자 장비가 죽어있는 경우 재시도하려고 하는 버퍼를 잃어버릴 가능 성 있음
• 메시지 브로커(메시지 큐) 이용하기
  • 메시지 스트림을 처리하는데 최적화된 데이터베이스의 일종
  • 브로커(서버)에 데이터가 모이기 때문에 클라이언트의 상태변경(접속, 접속 해제, 장애)등에 대응 하기 좋음
  • 큐 대기시 소비자는 일반적으로 비동기로 동작
    • 생산자는 브로커가 해당 메시지를 버퍼에 넣었는지만 확인하고 소비자가 메시지를 처리하기까지 기다리지 않는 장점

3. 스트림 처리

3.1. 스트림이 할 수 있는 일

1. 이벤트에서 데이터를 꺼내 데이터베이스(또는 캐시, 검색 색인 등)에 기록하고 다른 클라이언트가 시스템에 해당 데이터를 질의하게 하는 일
2. 이벤트를 직접 사용자에게 보내는 일(Ex 이메일 경고, 푸시 알람)
3. 하나 이상의 입력 스트림을 처리해 하나 이상의 출력 스트림을 생산
   • 이 스트림을 처리하는 코드 뭉치를 연산자(Operator), 작업(job)이라 불림

3.2. 스트림의 예시

• 사기 감시 시스템: 신용카드 사용 패턴의 변화로 카드 도난 감지
• 거래 시스템: 금융시장의 Rule base 거래
• 제조 시스템: 공장 기계상태 모니터링 및 오작동 감지
• 군사 첩보 시스템: 침략자의 공격 신호가 있으면 경보 발령

3.3. 스트림 분석

• 특정 유형의 이벤트 빈도 측정
• 특정 기간에 걸친 이동 평균(Rolling aveage) 계산
• 이전 시간 간격과 현재 통계 값의 비교(추세를 감지, 높거나 낮은 지표 경고)

(Amendment)스트리밍 분석이란?

https://cloud.google.com/learn/what-is-streaming-analytics?hl=ko

https://cloud.google.com/learn/what-is-streaming-analytics?hl=ko

 

4. 참고문헌

• 메시징 시스템의 이해