카프카의 목적
이벤트 주도의 시스템의 변화가 이미 시작되었음
: 데이터가 정적인 스냅샷 → 이벤트의 연속적인 흐름으로 변경되었기 때문
: 이러한 변화는
- 모든 이벤트가 모든 이들과 연결되는 싱글 플랫폼의 등장
- 실시간으로 반영되는 이벤트의 흐름
- 모든 이벤트들의 흐름을 역사적인 관점에서 볼 수 있게끔 함
를 이끌었음.
카프카는 클라우드 네이티브 + 예전 시스템에서의 장점 일부를 가져옴
- 클라우드 네이티브
- 소셜 네트워크의 이벤트를 공유 가능한 특징
- 온디멘드 : 수요에 맞춰 제공
- 실시간으로 고객과 연결
- 예전 시스템
- 믿을 수 있는 데이터 소스
- 마이크로서비스 아키텍처
- IOT 실시간 연결
카프카는 실시간 이벤트 스트리밍의 표준을 제공함
- 전 세계적인 규모
- 실시간
- 지속적인 저장소 (안정적인 저장소)
- 스트림 처리
고객사례
예) 실시간 사기 탐지, 무인자동차, 실시간 이커머스, 고객 관리, 은행 코어 시스템, 건강 관리…
아파치 카프카의 기본 구조
- 카프카 클러스터의 기본 요소
- 기본 요소들의 근본적인 기능
- 파티션과 세그먼트의 관계성과 카프카에서의 토픽의 의미
Producer(생산자)
카프카에서 데이터를 생성하는 것들을 프로듀서라고 부름.
- 프로듀서들은 카프카로부터 데이터를 보낸다
- 프로듀서들은 카프카로부터 데이터 송신 승인 여부(ACK, NACK) 를 받는다.
- ACK(승인됨)가 수신되면 모든 것이 정상임.
- NACK(승인되지 않음)이 수신되면 생산자는 Kafka가 승인되지 않음을 알게 되며, 어떤 이유로든 데이터를 받아들일 수 없으므로 이 경우 생산자는 자동으로 데이터 전송을 다시 시도함.
broker(브로커)
카프카는 브로커라고 부르는 것으로 구성됨.
- 브로커는 생산자로부터 데이터를 받아 일시적으로 페이지 캐시에 저장하거나 OS가 페이지 캐시를 플러시한 후 디스크에 영구적으로 저장함.
- 브로커는 다운스트림 소비자를 위해 데이터를 준비 상태로 유지함.
- 데이터가 유지되는 기간은 보존 기간( 디폴트 : 1주일 기준 )에 의해 결정됨.
Consumer(컨슈머)
대부분의 경우 카프카에 데이터를 저장하는 것은 의미 없으며, 이 데이터를 사용하고 비즈니스 가치를 창출하는 다운 스트림 소비자가 있어야 진가가 나옴
- 소비자가 Kafka에서 데이터를 조사함
- 각 소비자는 주기적으로 Kafka 클러스터의 브로커 요청하며, 일반적으로 소비자는 무한 루프에서 이 작업을 수행함
- 많은 소비자가 Kafka에서 동시에 데이터를 폴링 가능함
- 서로 다른 여러 소비자가 동일한 데이터를 각자의 속도로 폴링할 수 있음
- 조직된 소비자 그룹은 병렬 처리를 허용하기 위해 태스크를 나눠 진행함.
Architecture(아키텍처)
- 전형적인 MQTT(Message Queueing Telemetry Transport) 구조의 서버
- 메시지를 발행 - 구독하는 방법으로 통신하는 메시지 기반의 송수신 프로토콜
- 저전력과 최소한의 패킷을 통해 통신함.
- MQTT는 TCP/IP 프로토콜 위에서 동작하며 따라서 통신 규약이 아닌 인터넷 같은 TCP/IP 기반의 환경에서 통신해야 됨
- MQTT의 Publisher = Producer
- MQTT의 Broker = Broker
- MQTT의 Subscriber = Consumer
Message
카프카에서 기본 단위로, 키라 불리는 메타 데이터 포함 가능.
메시지를 저장할 파티션을 위해 사용
메시지를 카프카는 배치단위로 저장하며, 이 때 배치는 같은 토픽의 파티션에 쓰여지는 메시지들의 집합임.
메시지 읽기와 쓰기 작업 분리를 위해 일관적인 데이터 형식이 중요함. 따라서 스키마를 부여하는데 일반적으로 사용되는 json이나 xml은 스키마 버전 간의 호환성이 떨어짐. 따라서 apachi avro를 선호함.
Topic과 Partition
카프카에 저장된 단위는 토픽 단위로 분류됨. ( = 이벤트 스트림, 메시지)
토픽은 관련된 이벤트끼리 묶는데 DB의 테이블이나 폴더와 비슷한 개념임.
토픽은 여러 개의 파티션으로 나뉘어짐.
토픽이 카프카에서 일종의 논리적인 개념이라면, 파티션은 토픽에 속한 레코드를 실제 저장소에 저장하는 가장 작은 단위임.
파티션에 메시지가 쓰여질 때는 추가만 가능한 형태로 쓰여짐. 읽을 때는 맨앞부터 끝까지 순서로 읽힘.
파티션은 카프카가 데이터 중복과 확장성을 제공하는 방법 중 하나임.
ZooKeeper
브로커를 관리하는 역할이며, 일종의 컨트롤 타워라고 보면 됨.
따라서 zookeeper 없이는 kafka가 동작할 수 없으며 zookeeper는 앙상블 되어 짝수가 아닌 홀수의 서버로 구성되어 운영되게끔 해야 함.
(최소 3개, 권장은 5개)
