[Kafka 공부] #1 :
Kafka 개념
Kafka 특징
Apache Kafka??
Apache Kafka 사이트상 설명:
Apache Kafka는 오픈 소스 분산형 이벤트 스트리밍 플랫폼으로
고성능의 데이터 파이프 라이닝, 스트리밍 분석,데이터 통합과
업무에 필수적인 어플리케이션을 위한 수많은 기업들에서 사용됩니다.
위키피디아상 설명 :
아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다. 요컨대 분산 트랜잭션 로그로 구성된, 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이다. 디자인은 트랜잭션 로그에 많은 영향을 받았다.
1. 메시지 큐잉 시스템 중의 하나.
메시지 지향 미들웨어(Message Oriented Middleware: MOM)은 비동기 메시지를 사용하는 다른 응용프로그램 사이의 데이터 송수신을 의미하는데 MOM을 구현한 시스템을 메시지큐(Message Queue:MQ)라 한다.
** rabbitMQ, ActiveMQ에서는 브로커(Broker)가 컨슈머(consumer)에게 메시지를 PUSH 하는 방식,
Kafka :컨슈머(Consumer)가 브로커(Broker)로부터 메시지를 직접 가져가는 PULL 방식으로 동작
메시징 시스템(Messaging System) 에 대해서 소개한 설명한 블로그 링크
2. 분산 시스템
3. 시간 데이터 처리
대용량 실시간 로그 처리에 특화
4. TCP 기반 프로토콜로 오버헤드 감소, batch형태로 broker에게 한 번에 전달하는 메시지 전달 방식
* 배칭(batching)이라는 기능이 기본적으로 지원됩니다.
이 기능은 여러 개의 레코드를 하나의 큰 요청으로 묶어서 클러스터에 전달할 수 있는 기능.
이를 이용하면 데이터 양이나 레코드 수가 늘어나도 요청 수 증가를 억제할 수 있어 요청 별로 발생하는 오버헤드를 방지할 수 있습니다.
그래서 클라이언트가 보내는 요청 수를 제어해야 합니다. 이를 위해 Kafka의 ‘요청 쿼터(request quota)’라는 기능을 사용합니다.
5. 데이터 영속성 보장
기존 : 메모리에 저장 -> Kafka: 메시지 파일 시스템에 저장
메시지 많아도 성능 감소되지 않으며, 설정된 수명이 지나면 삭제합니다.
6. Pub/Sub 방식 : PULL방식을 이용하여 데이터 분포 지원
Pub : Publisher(발행), Sub : Subscriber(구독)
Pub/Sub 방식 : 메시지를 특정 수신자에게 직접적으로 보내주는 시스템(PUSH 방식)이 아니고,
메시지를 받기를 원하는 사람이 해당 토픽(topic)을 구독함으로써 메시지를 읽어 올 수 있습니다.(PULL방식)
Kafka 용어 공부하기
[ 저장 단위 ]
record : 저장될 수 있는 자료 단위
partition : 레코드가 저장되는 저장소
offset : 파티션에 각각의 데이터가 위치 포인터로 파티션안의 메시지의 상대적 위치를 나타냅니다.
topic : 파티션들의 그룹 > 카프카 브로커 1대에 1개의 토픽 가능. 메시지 저장소로 메시지는 topic으로 분류됩니다.
(토픽 안에 있는 파티션을 하나의 카프카 브로커에만 설치해야 되는 것은 아님.)
[ 구성요소 ]
프로듀서(Producer) : 토픽에 메시지를 생산(발행); Write
컨슈머(Consumer) : 토픽의 메시지를 소비(구독)
* 하나의 Topic에 여러 개의 Consumer가 각각 다른 목적으로 존재합니다.
* 컨슈머그룹(Consumer Group) : 하나의 목표를 위해서 소비하는 그룹, 즉 하나의 토픽을 읽어가기 위한 Conumser들
: 하나의 Topic을 구독하기 위한 여러 Consumer들의 모음
Group화 하는 이유는, 가용성 때문입니다.
필수조건 : Topic 내의 Partition은 Consumer Group 내의 Consumer와 1:n 매칭이 된다.
하나의 Partition은 하나의 Consumer Group 내의 서로 다른 Consumer가 읽을 수 없다. (반대의 경우는 가능, Consumer가 여러 개 Partition을 읽기는 가능)
각 Consumer들은 하나의 Topic의 각기 다른 Partition의 내용만을 처리한다면,
Consumer의 메시지 처리 순서를 보장하게 됩니다.
※ Group화 되지 않은 Consumer에 장애 발생 시 :
해당 Consumer에 매칭되어 있는 Partition의 메시지를 확인 할 수 없게 됩니다.
※ Group화 된 Consumer에 장애 발생 시 :
해당 Consumer가 처리하던 Partition 정보와 Offset 정보를 알고있기 때문에, Consumer Group 내의 Consumer들과 Partition을 재조정(Rebalance)하여, 문제없이 메시지를 처리할 수 있습니다.
** Consumer를 확장하면 > Partition도 확장되어야 합니다.
이유? 1개의 partition에 1개의 consumer만 접근 가능(consumer는 여러 개 partition 접근 가능) 하기 때문.
| partition 2개 - consumer 2개 (1:1) |
partition 2개 - consumer 4개 (consumer 2개가 논다.) |
 |
 |
| partition 4개 - consumer 2개 (consumer 1개가 2개이상의 partition을 가진다) |
partition 4개 - consumer 4개 (1:1) |
 |
 |
| partition 4개 - consumer 3개 | |
 |
브로커(Broker) : 카프카 서버; 클러스터를 구성.
: 여러 개의 토픽이 있을 수 있다. 하나의 브로커에만 설정되는 것이 아니라 여러개의 브로커에 나누어서 하나의 토픽이 생성될 수도 있다. 정보를 분산 가능!
Zoopkeeper :
클러스터 내의 서버들을 관리하는 역할. 클러스터 최신 설정 정보 관리, 동기화, replication의 리더 채택 등의 클러스터 서버들이 공유하는 데이터(Broker에 분산 처리된 메시지 큐의 정보 관리) 관리합니다. (Kafka 서버를 가동하려면 Zookeeper를 먼저 가동)
* Replication :
- Replication은 특정 Broker에 문제가 생겼을 때, Broker의 역할을 즉각적으로 대신 수행할 수 있도록 하기 위한 용도
- Kafka에서는 Topic 생성 시 Replication 수를 임의로 지정하여 복제본을 만들 수 있습니다.
(Topic을 생성 시 --replication-factor 옵션을 부여하여 복제본(replication)을 생성)
- Replication은 leader와 follower로 구성이 된다. Zookeeper가 leader가 되는 Partition을 지정하고, Partition을 각 Broker마다 복제를 합니다. 이때, leader를 복제하는 Partition을 follower라 합니다.
- leader : Topic의 메시지를 생산(write)하고 소비(read)하는 작업은 모두 leader에서 이루어집니다.
- follower : follower들은 leader를 동기화(싱크, sync)하기만 합니다. 그래서 leader에 장애가 생겼을 경우 follower 중의 하나가 leader 역할을 수행하여 서버 운용에 문제가 없도록 합니다. (In-Syn Replica, ISR)
위 그림은 ,
Broker Server가 3개이고, Topic 1개에 Partition 4개로 구성되어 있고, Replication은 2로 설정되어있습니다. (--replication-factor=2) Zookeeper가 4개의 Partition과 복제본(Replication)을 골고루 나누어 줍니다.
[예제]
- Partition1에 메시지를 쓰는 상황일 때, leader partition이 존재하는 Broker2에서 메시지가 생산됩니다. 그리고 follower인 Broker3에 존재하는 Partition은 leader를 복제합니다. ( ISR )
- 만약, leader Broker가 다운이 되면, follower가 leader로 선출됩니다.
- 예제는 follower가 1개지만 여러 개의 follower가 있다면, Zookeeper가 leader를 알아서 선출해 줍니다.
카프카 커넥트 (Kafka Connect)
Kafka Cluster : Kafka Broker들이 설치되어 있는 그룹.
- 카프카 클러스터의 여러 개의 토픽에 나누어 전달하는 메시지가 들어가고,
- 저장되어 있는 메시지를 소비자 또는 서브 스크라이브가 가져가서 사용합니다.
Kafka Connect
: 별도의 프로그래밍 언어를 사용하지 않고, 데이터를 읽어오고/보내는 작업이 가능
- Source Connect (소스 커넥터): Source Data(원본 데이터 : DB, Excel, Storage, File System)을 가지고 와서 메시지 형태로 Kafka Topic에 저장
- Sink Connect (싱크 커넥터) : Kafka Cluster의 Topic에 저장되어 있는 메시지를 가지고 와서 다른 Target System(DB, 클라우드 등)에 전달
* RestAPI : 서버가 가지고 있는 Resource 상태의 값을 API 형태로 사용 (추가, 변경, 조회, 삭제)
cf)
- Kafka Mirror Maker : 클러스터 간 메시지 복제 시 사용
- ksqlDB : 카프카에서 발생하는 수많은 메시지를 데이터베이스에 저장한다.
