[TIL - 66일 차] Kafka와 Spark Streaming 기반 스트리밍 처리 (1)

실시간 데이터 처리 소개

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

구글은 하둡 등을 통한 배치 프로세싱부터, Tensorflow, K8s 등 다양한 형태로 데이터 분야에 영향을 끼쳤다.

구글 검색 엔진의 등장

• 2004년부터 세계 최고의 검색엔진으로 등장
• 다양한 논문 발표와 오픈소스 활동으로 개발자 커뮤니티에 큰 영향을 끼침
• 구글 검색 엔진 이전
  • 웹의 텍스트와 사용자의 입력 키워드의 매칭 정도가 가장 높은 웹 문서를 상위에 노출
  • 검색 결과 페이지에 온갖 종류의 스팸 웹 페이지가 넘쳐나기 시작
• 구글 검색 엔진
  • 웹 페이지 간의 링크를 기반으로 중요한 페이지를 찾아 상위에 노출
  • 이 알고리즘을 래리 페이지(발표자)의 이름을 따서 페이지 랭크라고 부름
  • 페이지 랭크 논문 발표 이후 차세대 검색엔진이 나옴

페이지 랭크 소개

• 더 중요한 페이지는 더 많은 다른 사이트로부터 링크(인용)를 받는다는 관찰에 기초
• 중요한 페이지가 링크를 건 페이지 역시 상대적으로 중요한 페이지라는 관찰에 기초
• 이를 기반으로 계산을 반복하면 웹 상의 모든 페이지에 중요도 점수 부여 가능
  • 대용량 컴퓨팅 인프라와 소프트웨어 없이는 불가능
  • 나중에 구글 검색엔진 아키텍처를 논문으로 외부에 공개
  • 배치 프로세싱 : 주기적(몇 개월)으로 해당 프로세스를 진행하여 랭크 업데이트

주기적 검색 인덱싱 빌딩

기술적 진보와 공유 : 빅데이터 시대

• 검색 엔진은 기본적으로 대량의 데이터 처리
• 수백 조개의 웹페이지를 크롤하고 거기서 나온 텍스트로부터 색인 추출
• 웹페이지 그래프를 기반으로 페이지랭크 계산
• 검색 시 대용량 인덱스를 찾아 최적의 결과를 찾아내야 함
• 다양한 언어 지원이 필요
• 사용자 검색과 클릭 로그를 바탕으로 한 각종 마이닝
  • 동의어 찾기
  • 통계기반 번역 (statistical translation)
  • 검색 입력 자동 완성 (auto-completion)
• 검색엔진 관련 논문 발표 이후 구글 : 알파고, Tensorflow, K8s, 트랜스포머, BERT

빅데이터 처리의 발전 단계

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

• 데이터 수집 (Data Collection)
• 데이터 저장 (Data Storage)
• 데이터 처리 (Data Processing)

데이터 저장 시스템의 변천

• 중앙 시스템
  • 1980년대 후반 : Data Warehouse (Top-down) -> 필요한 정보를 생각 후 DW에 적재
  • 2000년대 후반 : Data Lake (Bottom-up) -> 일단 저장 후 필요한 것만 사용
  • 2010년대 중반 : Cloud Data Platform, Messaging Queue (Kafka/Kinesis)
• 분산 시스템
  • 2021년 : Data Mesh -> 데이터 팀은 중앙에서 인프라 제공, 각 팀에서 데이터 활용하는 형태

데이터 처리의 고도화

• 초반에 배치로 시작하는 경우 처리할 수 있는 데이터의 양이 중요
• 서비스가 고도화되면 실시간 처리 요구가 생기기 시작함
  • Realtime 처리 (Event 처리) vs Semi Realtime 처리 (짧은 주기)
  • 동일 데이터 소비가 필요한 케이스 증가 : 다수의 데이터 소비자 등장

처리량 (Throughput) vs 지연 시간 (Latency)

• 처리량 (Throughput)
  • 단위 시간 동안 처리할 수 있는 데이터의 양
  • 클수록 처리할 수 있는 데이터의 양이 큼
  • 배치 시스템 (DW)에서 중요
• 지연 시간 (Latency)
  • 데이터를 처리하는 데 걸리는 시간
  • 작을수록 응답이 빠름을 의미
  • 실시간 시스템 (프로덕션 DB)에서 중요
• 대역폭 (Bandwidth) = 처리량 * 처리 시간

Bandwidth

Realtime vs Semi-Realtime

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

SLA (Service Level Agreement)

• 서비스 제공업체와 고객 간의 계약 또는 합의
  • 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술
  • SLA는 통신, 클라우드 컴퓨팅 등 다양한 산업에서 사용
• 사내 시스템 간에도 SLA를 정의하기도 함
  • 이 경우 지연 시간이나 업타임 등이 보통 SLA로 사용
  • 데이터 시스템이라면 데이터의 시의성(FreshnesS)도 중요한 포인트

배치 처리

• 주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리
• 처리량 (Throughput)이 중요
• 처리 주기는 보통 분, 시간, 일 단위
• 처리 시스템 구조
  • 분산 파일 시스템 (HDFS, S3)
  • 분산 처리 시스템 (MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
  • 처리 작업 스케줄링에 보통 Airflow 사용

배치 처리

실시간 처리

• 연속적인 데이터 처리 (realtime vs semi-realtime)
• 이 경우 지연 시간(Latency)도 중요
• 배치 처리 다음의 고도화 단계 : 시스템 관리 등의 복잡도가 증가

실시간 처리

• 초 단위의 계속적인 데이터 처리
  • 이런 데이터를 Event라고 부르며, 이벤트의 특징은 바뀌지 않는 데이터 (Immutable)
  • 계속해서 발생하는 Event들을 Event Stream이라 부름

실시간 처리

• 다른 형태의 서비스가 필요해지기 시작
  • 이벤트 데이터를 저장하기 위한 메시지 큐 : Kafka, Kinesis, Pub/Sub 등
  • 이벤트 처리를 위한 처리 시스템 : Spark Streaming, Samza, Flink 등
  • 이런 형태의 데이터 분석을 위한 분석 툴/대시보드 : Druid
• 처리 시스템 구조
  1. Producer (Publisher)에서 데이터 생성
  2. 생성된 데이터를 메시지 큐와 같은 시스템에 저장
     • Kafka, Kinesis, Pub/Sub 등의 시스템 존재
     • 데이터 스트림(Kafka에서는 토픽)마다 별도의 데이터 보유 기한 설정
  3. Consumer (Subscriber)에서 큐로부터 데이터를 읽어서 처리
     • Consumer마다 별도 포인터 유지
     • 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함

처리 시스템 구조

람다 아키텍처 (Lambda Architecture)

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

람다 아키텍처 (1)

람다 아키텍처 (2)

데이터 실시간 처리의 장점

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

데이터 실시간 처리의 단점

• 전체적으로 시스템이 복잡해짐
  • 배치 시스템은 주기적으로 동작하며 보통 실제 사용자에게 바로 노출되는 일을 하지 않음
  • 실시간 처리의 경우 실제 사용자와 관련된 일에 사용될 확률이 높기에 시스템 장애 대응이 중요해짐
• 운영비용 증가
  • 실시간 처리는 데이터 유실의 가능성이 있어 항상 데이터 백업에 신경을 써야 함

실시간 데이터 종류와 사용 사례

온라인 서비스의 Event

• 온갖 종류의 Funnel Data
  • 상품 정보 노출, 클릭, 구매 등
  • 회원 등록 (등록 버튼 -> 상세 정보 입력 -> ... -> 등록 버튼)
• Page Views and Performance Data
  • 페이지/디바이스 별로 렌더링 시간을 기록하면 나중에 문제 발생 시 원인 파악이 쉬워짐
  • 페이지 별로 에러 발생 시 에러 이벤트 등록
• 사용자 행동 데이터의 데이터 모델 정의와 수집이 중요
  • 데이터가 제대로 수집된 후에 정장과 소비도 가능
  • 이벤트 데이터 수집만 전담하는 팀도 생기기 시작함

소매업

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

IoT

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

유스 케이스

• Realtime Reporting : A/B test 분석, 대시보드, 인프라 모니터링
• Realtime Alerting : 이상치 탐지, 환자 모니터링 
• Realtime Prediction (ML Model) : 개인 추천

실시간 데이터 처리 챌린지

실시간 데이터 처리 단계

1. 이벤트 데이터 모델 결정
2. 이벤트 데이터 전송 / 저장
3. 이벤트 데이터 처리
4. 이벤트 데이터 관리, 이슈 모니터링 및 해결

이벤트 데이터 모델 결정

• 최소 Primary Key와 Timestamp가 필요
• 사용자 정보가 필요할 수도 있음
• 이벤트 자체에 대한 세부 정보 필요

이벤트 데이터 모델

이벤트 데이터 전송 / 저장

• Point to Point
  • Producer와 Consumer가 바로 연결 (Many to Many 연결)
  • 지연 시간 (Latency)가 중요한 시스템에서 사용 가능
  • 다수의 Consumer가 존재하는 경우 데이터를 중복해서 보내야 함
  • Producer 속도 > Consumer 속도 : backpressure 발생 가능 -> 시스템 장애 초래
  • backpressure (배압) : 들어오는 속도를 따라잡지 못해 시스템에 데이터가 쌓이는 것

Point to Point

Backpressure

• Messaging Queue
  • 중간에 데이터 저장소를 두고 Producer와 Consumer가 decouple 된 상태로 작업
  • backpressure 완화 : Messaging Queue를 두더라도 처리 속도의 차이가 크면 발생 가능

Messaging Queue

이벤트 데이터 처리

• Point to Point
  • Consumer의 부담이 커지며 데이터가 바로바로 처리돼야 함
  • Low Throughput, Low Latency가 일반적
• Messaging Queue
  • 보통 micro-batch 형태로 짧은 주기로 데이터를 모아서 처리 (Spark Streaming)
  • 다수의 Consumer를 쉽게 만들 수 있다는 장점 존재
  • Point to Point보다 운영 용이