실시간 데이터 처리 챌린지

 

 

Contents

1. 실시간 데이터 처리 소개
2. Udemy 데이터 시스템 발전 여정 소개
3. Kafka 소개
4. Kafka 기본 프로그래밍
5. Spark Streaming 소개
6. Spark Streaming + Kafka 프로그래밍
7. 마무리

 

 

Contents

1. 구글이 데이터 분야에 끼친 영향
2. 데이터 처리의 발전 단계
3. 실시간 데이터 종류와 사용 사례
4. 실시간 데이터 처리 챌린지

 

 

 

 

 

 

 

실시간 데이터 처리 챌린지

실시간으로 데이터를 처리할 때 어떤 챌린지들이 있는지 살펴보자

 

 

 

 

 

 

 

실시간 데이터 처리 단계

 

이벤트 데이터 모델 결정

 

이벤트 데이터 전송/저장

 

이벤트 데이터 처리

 

이벤트 데이터 관리 이슈 모니터링과 해결

 

 

 

 

 

 

 

 

 

 

 

 

 

이벤트 데이터 모델 결정

 

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

 

 

 

 

 

 

 

 

 

 

 

 

이벤트 데이터 모델 전송/저장 (1)

 

Point to Point

Many to Many 연결이 필요

 

Messaging Queue

중간에 데이터 저장소를 두고 생산자와 소비자가 decouple된 상태로 작업

 

 

 

 

 

 

 

 

 

 

 

 

 

이벤트 데이터 모델 전송/저장: Point to Point

 

Throughput은 중요하지만 Latency가 더 중요한 시스템에서 사용 가능

 

많은 API 레이어들이 이런 식으로 동작

 

다수의 Consumer들이 존재하는 경우 데이터를 중복해서 보내야함

 

 

 

 

 

 

 

 

 

 

 

 

 

참고! Backpressure (배압)

 

스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성 (Producer)

하지만 가끔은 데이터 생성이 폭발적으로 늘어날 수 있음

 

다운스트림 단계(Consumer)에서 적시에 처리되어야함

하지만 들어오는 데이터 속도를 따라잡지 못하면 시스템에 데이터가 쌓여 지연되면서 메모리 사용량 증가 등으로 잠재적인 시스템 장애를 초래 가능. 이를 Backpressure 이슈라고 부름

 

Backpressure를 줄이는 방법 중의 하나는 중간에 메세지 큐를 도입하는 것

이 경우 Backpressure 문제를 많이 해결할 수 있지만 완전히 해결할 수는 없음

 

 

 

 

 

 

 

 

 

 

 

 

 

참고! Backpressure (배압)

Point-to-Point 시스템의 경우에도 Consumer/Subscriber쪽에 작은 버퍼가 존재

하지만 버퍼의 크기가 곧 부족해짐 (Overflow)

 

 

 

 

 

 

 

 

 

 

 

이벤트 데이터 모델 전송/저장: Messaging Queue

 

 

 

 

 

 

 

 

 

 

 

 

이벤트 데이터 처리

 

앞서 데이터 저장 모델과 활용 사례에 데이터 처리 모델도 결정됨

 

Point-to-Point 형태의 경우

Consumer쪽의 부담이 커지며 정말 바로바로 데이터가 처리되어야함 (Backpressure)

    - 데이터 유실의 가능성이 큼
Low Throughput Low Latency가 일반적

 

Messaging Queue의 경우

보통 micro-batch라는 형태로 아주 짧은 주기로 데이터를 모아서 처리
    - Spark Streaming이 대표적
다수의 Consumer를 쉽게 만들 수 있다는 장점 존재
Point-to-Point 보다는 운영이 용이