- LinkedIn에서 개발한 실시간 이벤트 기반 애플리케이션 개발을 지원하는 오픈소스 분산형 스트리밍 플랫폼
- 기존 end-to-end 방식 App-DB 연결 방식이 시스템 복잡도가 높아지면서 관리가 어려워짐
- 모든 이벤트/데이터 흐름을 중앙에서 관리하기 위해 만듬 (목표: 모든 시스템으로 전송, 실시간 처리, 분산형)
Kafka 적용 후 LinkedIn 데이터 처리
- 3가지 주요 기능
- 애플리케이션에서 데이터 또는 이벤트 스트림을 게시, 구독할 수 있게 함
- 안정적인 방식으로 레코드를 장기 저장 허용
- 레코드를 실시간으로 처리하기 위한 실시간 액세스 지원
- 4가지 주요 API
- Producer API - 애플리케이션에서 어떤 Kafka 토픽에 스트림을 게시
- Consumer API - 애플리케이션에서 하나 이상의 토픽을 구독하고 저장도니 스트림을 입수, 처리
- Streams API - Producer와 Consumer 사이에서 복잡한 처리 기능을 추가
- Connector API - 개발자가 재사용 가능한 생산자/소비자인 커넥터를 빌드할 수 있음
- 주요 Use Case
- 실시간 스트리밍 데이터 파이프라인 - 엔터프라이즈 시스템 간에 데이터/이벤트 레코드 전송
- 실시간 스트리밍 애플리케이션 - 레코드 또는 이벤트 스트림에 의해 구동되는 애플리케이션
ex) 재고 업데이트, 클릭 분석 토대 개인별 추천/광고 사이트 등
- 특징
- 토픽은 레코드/메시지를 키, 값 및 타임스탬프로 구성된 튜플로 저장함
- 토픽은 파티션이라는 일련의 순서 대기열로 세분화될 수 있음(오프셋이라는 순차 ID가 할당됨)
- Offset - Queue의 Head index
- 보존 시간을 설정할 수 있으며 보존 시간 동안 영속성을 가짐
- 토픽/파티션에서 각 서버에 부하를 공유하여 토픽/파티션을 확장할 수 있음
- 한 번 늘린 파티션은 줄일 수 없음
- 파티션은 리더인 한 개 서버와 팔로워 서버들로 구성되며 리더가 배포/영속성을 처리하는 동안 팔로워는 복제 서비스를 제공함
- 분산 메시지큐의 메타 정보는 중앙의 Zookeeper(코디네이션 시스템)가 관리함
Brocker/Partition/Replica 예시, 출처: https://www.youtube.com/watch?v=XyuqoWUCdGA
- RabbitMQ와 비교
- Kafka: 토픽별 여러 개의 구독자를 가짐 vs. RabbitMQ: 메시지별 각각 하나의 소비자만 가짐
- Kafka: 지속적 vs. RabbitMQ: 소비 후 삭제됨
- Kafka: TCP only vs. RabbitMQ: AMQP, MQTT, STOMP 지원
-> Kafka는 스트림 처리 플랫폼, RabbitMQ는 메시지 브로커
- Tool별 사용처 구분
- Kafka: 대용량 데이터 처리, 실시간, 고성능, 고가용성 필요, 이벤트의 저장이 필요한 경우
- RabbitMQ: 트래픽은 작지만 복잡한 라우팅 처리, 정확한 요청-응답 필요한 경우
- Redis: 이벤트 데이터를 DB에 따로 저장, consumer 알람 도착 보장이 불필요한 경우