[DEV] 15주차. Kafka와 Spark Streaming 기반 스트리밍 처리 (1)

1. 구글이 데이터 분야에 끼친 영향

구글의 탄생

1) 구글 검색 엔진의 등장

• 그 전까지의 검색 엔진은 기본적으로 웹 페이지 상의 텍스트를 보고 랭킹을 결정
  • 알타비스타, 야후, ..
  • 검색 결과 페이지에 온갖 종류의 스팸 웹 페이지들이 넘쳐나기 시작
• 구글은 웹 페이지들 간의 링크를 기반으로 중요한 페이지를 찾아서 검색 순위 결정
• 2004년 여름에 상장됨

2) 2021년 검색 마케팅 플랫폼으로 확장

• 안드로이드 개발로 모바일 생태계 지배

• Youtube 인수를 통한 스트리밍 시장 석권

• 다양한 논문 발표와 오픈소스 활동으로 개발자 커뮤니티에 큰 영향을 끼침

페이지 랭크

• 더 중요한 페이지는 더 많은 사이트들로부터 링크를 받는다는 관찰에 기초
• 중요한 페이지가 링크를 건 페이지들 역시 상대적으로 중요한 페이지라는 관찰에 기초

• 이를 기반으로 계산을 반복하면 웹 상의 모든 페이지들에 중요도 점수를 부여할 수 있음
• 하지만, 대용량 컴퓨팅 인프라와 소프트웨어 없이는 계산이 불가능
• 나중에 구글 검색엔진 아키텍처를 논문으로 공개
  • 웹 페이지 본문 텍스트가 아닌 링크 텍스트의 중요성 + 링크를 건 원문 페이지의 중요도 고려

검색엔진의 데이터 처리

• 주기적 검색 인덱스 빌딩 (배치 프로세싱)

기술적 진보와 공유 -> 빅데이터 시대의 도래

• 검색엔진은 기본적으로 대량의 데이터를 처리하게 됨
• 수백 조 개의 웹페이지를 크롤하고 거기서 나온 텍스트로부터 인덱스 추출
• 웹페이지 그래프를 기반으로 페이지 랭크 계산
• 검색시 대용량 인덱스를 뒤져서 최적의 결과를 찾아내야 함
• 다양한 언어 지원 필요
• 사용자 검색어와 클릭 로그를 기반으로 한 각종 마이닝
  • 동의어 찾기
  • 통계 기반 번역
  • 검색 입력 자동 완성

• 구글랩 논문 발표
  • 2003, The Google File System
  • 2004, MapReduce: Simplified Data Processing on Large Cluster
• 이를 바탕으로 하둡이라는 오픈소스 프로젝트가 시작됨
  • 이 기술이 빅데이터 처리를 가능하게 해줌
  • 또한, 하둡을 시작으로 오픈소스 활동이 한층 더 활발해짐
  • 이러한 기반 기술들이 머신러닝, 인공지능의 발전을 가속화함
• 검색엔진 관련 논문 발표 이후
  • AlphaGo
  • TensorFlow
  • Kubernetes
  • Transformer Architecture
  • BERT

2. 데이터 처리의 발전 단계

• 배치 중심 -> 실시간으로 발전

데이터 처리의 일반적인 단계

• 데이터 수집
• 데이터 저장
• 데이터 처리
  • 이 과정에서 서비스 효율을 높이거나 의사결정을 더 과학적으로 하게 됨

데이터 저장 시스템의 변천

• Data Warehouse
• Data Lake
• Cloud Data Platform & Messaging Queue (Kafka/Kinesis)
• Data Mesh -> 분산 시스템

데이터 처리의 고도화

• 처음에는 배치로 시작
  • 이 경우 처리할 수 있는 데이터의 양이 중요
• 서비스가 고도화되면 점점 더 실시간 처리에 대한 요구가 생기기 시작
  • Realtime 처리 vs. Semi Realtime 처리
  • 동일 데이터 소비가 필요한 케이스 증가: 다수의 데이터 소비자 등장

처리량 vs. 지연시간

• 처리량 (Troughput)
  • 주어진 단위 시간동안 처리할 수 있는 데이터의 양
  • 클수록 처리할 수 있는 데이터의 양이 크다는 것을 의미
  • 배치 시스템에서 더 중요 (데이터 웨어하우스 등)
• 지연 시간 (Latency)
  • 작을수록 응답이 빠름을 의미
  • 실시간 시스템에서 더 중요 (프로덕션 DB 등)
• 대역폭 (Bandwidth) = 처리량 x 지연시간

SLA (Service Level Agreement)

• 서비스 제공업체와 고객 간의 계약 또는 합의
  • 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 기술
  • 통신, 클라우드 컴퓨팅 등 다양한 산업에서 사용됨
• 사내 시스템들 간에 정의하기도 함
  • 지연시간, 업타임 등이 주로 사용됨

3. 실시간 처리

배치 처리

• 주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리
  • 보통 daily / hourly, 더 짧아지면 5분 정도까지는 배치 처리 가능
  • 데이터를 모아서 처리
• 처리량 (Throughput)이 중요

• 처리 시스템 구조
  • 분산 파일 시스템 (HDFS, S3)
  • 분산 처리 시스템 (MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
  • 처리 작업 스케줄링에 보통 Airflow 사용

실시간 처리

• 연속적인 데이터 처리
  • realtime vs. semi-realtime (micro batch)
• 지연시간 (처리속도, Latency)이 중요
• 배치로 처리하기엔 job을 띄우는데 Overhead가 걸림
• 저장소, 프로세싱 기술 측면에서도 배치와는 다른 형태의 기술이 필요
  • kafka, spark streaming

특징

• 배치 처리 다음의 고도화 단계
  • 시스템 관리 등의 복잡도 증가
  • 실시간이기 때문에 데이터 유실의 위험이 있음
• 초 단위의 계속적인 데이터 처리
  • 이러한 데이터를 보통 Event라 부름
  • Event는 바뀌지 않는 데이터라는 특징이 있음 (immutable)
  • 계속해서 발생하는 Event들을 Event Stream이라고 부름
  • Kafka에서는 Event Stream을 Topic이라고 부름
• Kafka, Kinesis, Pub-Sub 등은 메시지 큐를 중간에 두고 생산자, 소비자를 연결
  • 메시지 큐: 실시간으로 생기는 데이터를 저장하는 저장소
  • 다수의 데이터 소비자를 지원하는 데 큰 문제가 없음
    • pointer만 유지해주면 독립적으로 데이터 읽어감
    • 데이터의 retention policy 정해서 관리 (kafka: 일주일)
• 다른 형태의 서비스들이 필요해지기 시작
  • 이벤트 데이터를 저장하기 위한 메시지 큐: Kafka, Kinesis, Pub/Sub, ..
  • 이벤트 처리를 위한 처리 시스템: Spark Streaming, Samza, Flink, ..
  • 이러한 형태의 데이터 분석을 위한 애널리틱스/대시보드: Druid

처리 시스템 구조

• Producer(Publisher)가 데이터 생성
• 생성된 데이터를 메시지 큐와 같은 시스템에 저장
  • Kafka, Kinesis, PubSub 등의 시스템 존재
  • 데이터 스트림(Kafka의 Topic)마다 별도의 데이터 보유 기한 설정 (Retention Policy)
• Consumer(Subscriber)가 큐로부터 데이터를 읽어서 처리
  • Consumer마다 별도 포인터 유지
  • 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함 (Consumer Group)

Lambda Architecture

• 배치 레이어와 실시간 레이어 두 개를 별도로 운영

• 다양한 아키텍처 존재

• 첫번째 아키텍처
  • 실시간 레이어는 배치 레이어 사이의 gap을 줄여주는 느낌
• 두번째 아키텍처
  • 데이터 수집 자체를 streaming message queue에
  • 실시간 레이어와 배치 레이어를 별도로 놓고 각각 필요한 용도에 사용

장점

• 즉각적인 인사이트 발견
• 운영 효율성 향상
• 사고와 같은 이벤트에 대한 신속 대응
• 더 효율적인 개인화된 사용자 경험
• IoT 및 센서 데이터 활용
• 사기 탐지 및 보안
• 실시간 협업 및 커뮤니케이션

단점

• 전체적으로 시스템이 복잡해짐
  • 배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않음
  • 실시간 처리는 실제 사용자와 관련된 일에 사용될 확률이 더 높기 때문에 시스템 장애 대응이 중요해짐
    • 배치 추천 vs. 실시간 추천
    • DevOps의 영역으로 들어가기 시작함
• 이에 따른 운영 비용 증가
  • 배치 처리는 잘못되어도 데이터 유실 이슈가 적지만, 실시간 처리는 데이터 유실의 가능성이 커지기 때문에 항상 데이터 백업에 신경을 써야함!

Realtime vs. Semi-Realtime

• Realtime
  • 짧은 Latency
  • 연속적인 데이터 스트림
  • 이벤트 중심 아키텍처: 수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조
  • 동적 및 반응형: 데이터 스트림의 변화에 동적으로 대응하여 실시간 분석, 모니터링 및 의사 결정 수행
• Semi-Realtime
  • 합리적인 Latency
  • 배치와 유사한 처리 (Micro-batch)
  • 적시성과 효율성 사이의 균형: 처리 용량과 리소스 활용도를 높이기 위해 일부 즉각성을 희생하기도 함
  • 주기적인 업데이트

4. 실시간 데이터 사례

Online Service

• 온갖 종류의 Funnel Data
  • Funnel: 깔대기
  • Product Impressions, Clicks (Click Stream), Purchase, …
  • User Registraion (회원 등록 버튼 클릭 -> 상세 정보 입력 -> … -> 등록 버튼)
    • 어느 부분에 오래 머무는지 (어려움을 느끼는지),, ~
• Page View and Performance Data
  • 페이지 별로 렌더링 시간(생성하는데 얼마나 걸렸는지)을 기록하면 나중에 문제 발생 시 원인 파악이 쉬워짐
    • 디바이스 타입에 따라 기록 (데스크탑, 모바일, ..)
  • 페이지 별로 에러 발생 시 에러 이벤트 등록

• 사용자 등록, 사용자 로그인, 방문자 발생

• 이러한 사용자 행동 데이터들의 데이터 모델 정의와 수집이 중요해짐
  • 데이터가 제대로 수집된 후에 저장과 소비도 가능
  • 이벤트 데이터 수집만 전담하는 팀도 생기기 시작

Retail Business

• 재고 업데이트
  • 재고 추가 또는 품절과 같은 재고 수준의 변화 반영
• 주문 이벤트
  • 주문 배치, 주문 상태 업데이트 및 주문 이행
• 배송 이벤트
  • 배송된 상품의 상태 및 위치 업데이트 기록

IoT

• 센서 판독값
  • IoT 장치에서 수집한 온도, 습도, 압력 등 측정값 기록 이벤트
• 장치 상태 업데이트
  • 온라인/오프라인 상태 또는 배터리 잔량과 같은 장치 상태 이벤트
• 알람 이벤트
  • 동작 감지나 임계값 초과 등 특정 조건에 의해 트리거되는 이벤트

Event 데이터 처리를 필요로 하는 사례

• Realtime Reporting
  • A/B Test Anaylytics
  • Marketing Campaign Dashboard
  • Infrastructure Monitoring
• Realtime Alerting
  • Fraud Detection
  • Realtime Bidding
  • Remote Patient Monitoring
• Realtime Prediction (ML Model)
  • Personalized Recommendation

5. 실시간 데이터 처리 챌린지

처리 단계

• 이벤트 데이터 모델 결정
• 이벤트 데이터 전송/저장
• 이벤트 데이터 처리
• 이벤트 데이터 관리 이슈 모니터링과 해결

이벤트 데이터 모델 결정

• 최소 Primary Key와 Timestamp 필요
  • Timestamp 일반적으로 epoch 등으로 표시 + timezone: UTC
  • 사용자 정보가 필요할 수도 있음
  • 이벤트 자체에 대한 세부 정보 필요

이벤트 데이터 전송/저장

Point to Point

• Many to Many 연결 필요
• Latency가 존재하지 않음
• Producer에서 Consumer로 바로 연결
• Producer에서 데이터가 생성되는 속도가 Consumer가 데이터를 소비하는 속도보다 빠를 경우 데이터가 밀려서 유실되는 문제가 발생할 수 있음 : Backpressure 문제

• Latency가 Throughput보다 더 중요한 시스템에서 사용
• 많은 API 레이어들이 이러한 방식으로 동작
  • API가 Consumer
• 다수의 Consumer들이 존재하는 경우 데이터를 중복으로 보내야 함

• Backpressure
  • 스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성됨 (Producer)
    • 하지만 가끔 데이터 생성이 폭발적으로 늘어날 수 있음
  • 다운스트림 단계(Consumer)에서 적시에 처리되어야 함
  • 하지만 들어오는 데이터 속도를 따라잡지 못하면 시스템에 데이터가 쌓여 지연되면서 메모리 사용량 증가 등으로 잠재적인 시스템 장애를 초래할 수 있음 : Backpressure 이슈!
  • 이를 줄이는 방법 중 하나가 중간에 메시지 큐를 도입하는 것
    • 이 경우 Backpressure 문제를 많이 줄일 수 있지만 완전히 해결할 수는 없음
  • Point-to-Point 시스템의 경우에도 Consumer/Subscriber 쪽에 작은 버퍼가 존재하지만 금방 overflow가 발생함

Messaging Queue

• 중간에 메시지 저장소를 두고 Producer와 Consumer가 decouple된 상태로 작업
• 이 경우에도 Retention 기간이 지날 때까지 Consumer가 데이터를 소비하지 못하면 데이터가 유실될 수 있음, 그러나 확률은 위보다 낮음
• 다수의 Consumer들이 공통의 데이터를 소비할 수 있다는 장점
• Producer 별로 Topic이 생성됨

이벤트 데이터 처리

• Point-to-Point의 경우
  • Consumer 쪽의 부담이 커지며, 정말 데이터가 바로바로 처리되어야 함
    • 데이터 유실의 가능성이 크기 때문
  • Low Throughput Low Latency 가 일반적
• Messaging Queue의 경우
  • 보통 micro-batch 형태로 아주 짧은 주기로 데이터를 모아서 처리
    • Spark Streaming이 일반적
  • 다수의 Consumer를 쉽게 만들 수 있다는 장점
  • Point-to-Point 보다는 운영이 용이함