Linked 에서 탄생
데이터 파편화
장애 범위를 단순화 시킬 수 있도록 아파치 카프카(Apache Kafka)
링크드인 내부 데이터 흐름을 개선 쌉가능
각 각의 애플리케이션에서 데이터 처리하는 것 X
중앙집중화
동일 시간 때에 많은 데이터를 전송 가능
Kafka Broker에 보낼 때 배치로 묶어서 보내야함
Kafka Producer에는 배치로 묶어서 보내는 옵션 존재
데이터 처리량 늘리는 방법 : 파티션을 쪼개서 진행
partition 1
partition 2
이런 식으로 나눠서 진행하면 처리량을 늘릴 수 있음
데이터 파이프라인에 데이터가 얼마나 들어올 지 예측 어렵
-> Kafka를 사용하면 가변적인 상황에서 유연하게 사용 가능
💡 데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터의 특성
Kafka는 데이터를 메모리에 저장하지 않고 파일 시스템에 저장
-> 페이지 캐시 메모리 영역을 사용 -> OS 메모리에 저장 시켰다가 사용
Broker에 장애가 발생해도 파일 시스템에 저장하기 때문에 복구 가능
Kafka cluster는 3개 이상의 서버로 구성
일부 서버가 장애 발생하더라고 중단 X(복제해서 사용), 안전하고 지속적으로 데이터 처리 가능
엔드 투 엔드로 각 서비스 애플리케이션으로 부터 데이터를 배치로 모으는 방식
단점
1. 유연하지 않아 실시간으로 생성되는 데이터 전달 X
2. 데이터의 히스토리 파악 어렵
3. 데이터 파편화 되면서 데이터 거버넌스(데이터 표준 및 정책) 지키기 어렵
단점
1. 배치레이어, 스피드레이어가 분리되어있어서 데이터 분석처리할 때 유연 X, 데이터 파편화되는 문제
람다 아키텍쳐의 로직 파편화, 디버깅, 배포, 운영 이슈 제거
-> 스피드레이어에서 데이터 모두 처리
Kafka에서 배치 데이터와 스트림 데이터를 모두 처리
배치데이터를 표현할 때 스냅샷 데이터으로 스트림으로 표현
배치데이터의 변환 기록(Log) time stamp가 기록이 되어야함
| 배치 데이터 | 스트림 데이터 |
|---|---|
| 한정된 데이터 처리 | 무한 데이터 처리 |
| 대규모 배치 데이터를 위한 분산처리 수행 | 지속적으로 들어오는 데이터를 위한 분산처리 수행 |
| 분, 시간 일 단위 처리를 위한 지연 발생 | 분 단위 이하 지연 발생 |
| 복잡한 키 조인 수행 | 단순한 키 조인 수행 |
스트림 데이터 -> 구체화된 뷰 -> 배치로 처리
-> timestamp를 사용하기 때문에 가능함
배치 X, 서빙 X
스피드 레이어 유일
-> 서빙레이어와 스피드레이어에서 이중으로 관리되는 운영 리소스를 줄일 수 있음
가까운 미래에는 Kafka에서 모두 가능하는 방향으로 나아가는 중
자주 사용하는 데이터, 자주 접근하지 않는 데이터 나누어서 처리하는 방식으로 개선 필요
해당 내용은 데브원영님의 아파치 카프카 애플리케이션 프로그래밍을 공부하고 리뷰하는 글입니다.