728x90
Kafka의 탄생 배경
why? 링크드인에서 소스 어플리케이션과 타깃 어플리케이션 개수가 점점 많아지면서 데이터 전송 라인이 복잡해지는 문제를 해결하기 위해
과거 구성도
여러 방법을 시도해 보았으나 더 복잡해짐
현재 구성도 (카프카)
Unified Log라는 중앙 로그를 두어 중앙 집중화 하여 개발자 입장에서도 이전에는 데이터 스토어 백엔드 관리와 백엔드에 따른 포맷, 별도의 앱 개발을 히야 했는데 이젠 카프카에만 데이터를 전달하면 나머지는 필요한 곳 또는 다른 서비스들이 각자 가져갈 수 있어서 자신들 본연의 업무에만 집중할 수 있게 되었다.
메시지 큐 구조를 살린 카프카 내부 구조
- 프로듀서가 보낸 데이터 (메시지, 토픽) 는 특정 하나의 파티션에 적재되고, 차례대로 컨슈머는 파티션에서 가져간다 (FIFO)
- 전체적으로는 메시지큐와 비슷한데 가장 큰 특징적 차이는, 컨슈머가 데이터를 가져가도 파티션의 데이터는 파티션에서 사라지지 않는다는 것이다. (컨슈머가 한번 더 데이터를 가져갈 수 있다.)
- 컨슈머가 어디까지 읽었는 지는 커밋을 통해 기록하고 있다.
'DevOps > Kafka' 카테고리의 다른 글
[카프카 프로그래밍] 파티션 개수와 컨슈머 개수의 처리량 (0) | 2024.06.27 |
---|---|
[카프카 프로그래밍] 토픽과 파티션 (0) | 2024.06.27 |
[카프카 프로그래밍] 브로커의 역할 (0) | 2024.06.23 |
[카프카 프로그래밍] 카프카 생태계와 브로커, 주키퍼 (0) | 2024.06.22 |
[카프카 프로그래밍] 아파치 카프카가 데이터 파이프라인으로 적합한 4가지 이유 (2) | 2024.06.16 |
댓글