Data Stream
- 지금까진 그냥 아키텍처 공부하면서 그냥저냥 대용량데이터 전송/ ai 모델/ 이미지 영상 데이터 등 큰 데이터 처리를 할 때 돌아가는 기능(서비스)라고 이해했었음
- 그러나 데이터 스트림은 말그대로 "메타"데이터를 처리하는 비동기(?)적인 미들웨어에 가까움
메시지를 알아서 주고 받을수가 없잖아요?
헷갈렸던 점
- 파티션
디스크 파티션과 다른개념
브로커 안의 파티션을 쪼개서 메시지를 병렬처리하여 발행하고(produce) 소비한다(consume)
즉 카프카의 성능은 가상서버/ 혹은 온프렘 서버에 성능 의해 결정됀다
1개 topic : 1개 broker
kafka-partition
-
멀티 컨슈머
컨슈머 그룹으로 관리가능
클러스터 개념으로 컨슈머 그룹에서 멀티 컨슈머가 하나의 토픽을 동시 다발적으로 소비할수도 있다 -
다중 토픽 별 컨슈머
각 토픽별로 컨슈머와 프로듀서가 독립적으로 작동함
topic 간 유기적인 소비와 발행이 가능함 -
코디네이터
파티션과 컨슈머 사이를 관리해줌 (카프카 내부에서 작동)
alb 처럼 그룹 상태 관리, 파티션 할당등 워크로드를 리밸런싱 해줌 ( 토픽 메타데이터처리 등 ) -
디스크 기반? 메모리 기반?
카프카 자체는 디스크 기반 메시지 브로커지만 메모리를 활용해서 성능이 빠른거임.
메시지 저장 :disk
메시지 기록 : topic에 따라 partition별로 (bytecode)로그 형태로 저장
메시지 복구: 디스크 기반이라 데이터 유지가능.
페이지 캐시: file IO를 memroy cache 를 활용함
프로토콜: tcp/ip to disk
배치 처리 : 병렬 처리 속도 향상
- 카프카의 offset
내가 아는 오프셋
- 리버싱 할 때 메모리 레지스트리에 있던 값을찾을때 오프셋이라는 걸 들었는데, 해당 위치를 추적하거나 위치별로 찍어보면, 작동하는 기능이 있음. ret, mov , ptr 등 바꿔서 게임 취약점을 해킹했던 기억이 나는데?!
- 결국 메모리를 사용하는 카프카도 오프셋이라는 기능을 이용해서 메시지 failover를 관리함
위 내용을 좀 정리하자
Data Stream 개념 정리
스트림 vs 배치
배치 처리: [큰 덩어리] → 처리 → [결과]
스트림 처리: [데이터1] → [데이터2] → [데이터3] → 실시간 처리- 메타데이터만이 아님: 실제 비즈니스 데이터도 스트림으로 처리
- 비동기 미들웨어: 맞음! Producer와 Consumer를 분리해주는 중간층
파티션 & 성능
정정할 부분
❌ 1개 topic : 1개 broker
✅ 1개 topic : 여러 partition (여러 broker에 분산 가능)예시:
Topic: user-events (3 partitions)
├── Partition 0 → Broker 1
├── Partition 1 → Broker 2
└── Partition 2 → Broker 3멀티 컨슈머 정리
Consumer Group 내에서
Consumer Group: analytics
├── Consumer A → Partition 0,1
└── Consumer B → Partition 2
한 파티션은 그룹 내 한 컨슈머만 처리 (중복 방지)서로 다른 Consumer Group
Topic: user-events
├── Group1 (analytics) → 모든 메시지 소비
└── Group2 (notification) → 모든 메시지 소비 (독립적)게임 해킹 vs Kafka 오프셋
게임 해킹:
메모리 주소 0x1000 → 체력값
메모리 주소 0x1004 → 돈
Kafka:
Partition 0, Offset 100 → 메시지 위치
Partition 1, Offset 250 → 메시지 위치공통점:
- 위치 추적: 어디서 데이터를 읽을지 지정
- 순차 접근: 다음 위치로 이동
- 복구 가능: 특정 위치로 되돌아가기
추가할 내용
페이지 캐시 심화
1. 메시지 쓰기 → OS 페이지 캐시 → 디스크
2. 메시지 읽기 → 페이지 캐시 (캐시 히트) → 빠른 응답
3. Zero-copy: 커널 → 소켓 직접 전송 (애플리케이션 메모리 거치지 않음)
🏠TECH & GOSSIP