[Kafka] 정리_01

Kafka 주요 명령어

kafka-topics.sh = 토픽을 생성하거나 토픽의 설정 등을 변경하기 위해 사용

kafka-console-producer.sh = 토픽으로 메시지를 전송하기 위해 사용함. 기본 옵션 외 추가 옵션을 지정할 수 있고, 이를 통해 다양한 프로듀서 옵션 적용 가능

kafka-console-consumer.sh = 토픽에서 메시지를 가져오기 위해 사용하며, 기본 옵션 외 추가 옵션을 지정할 수 있고, 이를 통해 다양한 컨슈머 옵션 적용 가능

kafka-reassign-partitions.sh = 토픽의 파티션과 위치 변경 등을 위해 사용함

kafka-dump-log.sh = 파티션에 저장된 로그 파일의 내용을 확인하기 위해 사용함

 

 

Kafka 주요 요소

Zookeeper	Apache Project Application. 카프카의 메타데이터 관리 및 브로커의 정상상태 점검을 담당
Kafka(Kafka Cluster)	여러 대의 브로커를 구성한 클러스터 의미
Broker	카프카 애플리케이션이 설치된 서버 또는 노드
Producer	카프카로 메시지를 보내는 역할을 하는 Client
Consumer	카프카에서 메시지를 꺼내가는 역할을 하는 Client
Topic	카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유하다
Partition	병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눔
Segment	프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장되는 파일
Message or Record	프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각

 

Replication

각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작으로, 이 동작 따라서 덕분에 하나의 브로커가 종료되더라도 카프카는 안정성을 취할 수 있다. 

--partition 1, --replication-factor 3

토픽의 파티션에 대한 명령어로, 원본을 포함한 리플리케이션이 3개가 생기는 명령어이다.

안정성을 목적으로 모든 토픽에 대해 각 3개의 리플리케이션으로 설정할 수 있다. 리플리케이션 팩터 수가 커지면 안정성은 높아지지만 그만큼 브로커 리소스를 많이 사용하게 됩니다. 따라서 복제에 대한 오버헤드를 줄여 최대한 브로커를 효율적으로 사용하는 기준이 필요하다. 통상적으로, 테스트나 개발 환경은 리플리케이션 팩터 수를 1로, 로그성 메시지로서 약간의 유실이 허용되는 운영 환경은 리플리케이션 팩터 수를 2로, 유실을 허용하지 않는 운영 환경은 3으로 설정한다.

Partition

하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하게 한 것

- 파티션 번호는 0으로 시작한다.

- 파티션 수를 정하는 기준은 각 메시지 크기나 초당 메시지 건수 등에 따라 달라지므로, 정확하게 예측하기 힘들어 파티션 수를 정하는 기준은 다소 모호하다.

- 파티션 수는 초기 생성 후 언제든지 늘릴 수 있으나, 반대로 한번 늘린 파티션 수는 절대로 줄일 수 없다.

초기에 토픽 생성 시에 파티션 수를 2 또는 4 정도로 생성한 후, 메시지 처리량이나 컨슈머의 LAG 등을 모니터링하면서 조금씩 늘려가는 방법이 가장 좋습니다.

 

*LAG :  프로듀서가 보낸 메시지 수 - 컨슈머가 가져간 메시지 수. 즉 컨슈머에 지연이 없는 지 확인하는 지표

 

Segment

파티션에서 조금 더 확장된 개념

- 프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장되며, 각 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장된다.

- 각 파티션마다 N개의 세그먼트 로그 파일들이 존재한다.

 

Kafka의 핵심 개념

 

1. 분산 시스템

분산 시스템은 네트워크상에서 연결된 컴퓨터들의 그룹을 말하며, 단일 시스템이 갖지 못한 높은 성능을 목표로 한다. 또한 고성능의 특징 외에도 하나의 서버 또는 노드 등에 장애가 발생할 때 다른 서버 또는 노드가 대신 처리하므로 장애 대응이 탁월하며, 부하가 높은 경우 시스템 확장이 용이하다는 장점이 있다. 카프카는 최초 구성한 클러스터의 리소스가 한계치에 도달해 더욱 높은 메시지 처리량이 필요한 경우, 브로커를 추가하는 방식으로 확장이 가능하다. 카프카에서 브로커는 온라인 상태에서 매우 간단하게 추가할 수 있다. 

2. 페이지 캐시

높은 처리량을 얻기 위해 페이지 캐시를 이용한다. 페이지 캐시는 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용한다. 이렇게 페이지 캐시를 사용하면 디스크 I/O에 대한 접근이 줄어드므로 성능을 높일 수 있다. 

3. 배치 전송 처리

카프카는 프로듀서, 컨슈머 클라이언트들과 서로 통신하며, 이들 사이에서 수많은 메시지를 주고 받는다. 이때 발생하는 수많은 통신을 묶어서 처리할 수 있다면, 단건으로 통신할 때보다 네트워크 오버헤드를 줄일 수 있고 장기적으로 더욱 빠르고 효율적으로 처리할 수 있다. 예를 들어, 온라인 상품 구매 프로세스에서 상품의 재고 수량 업데이트 작업과 구매 로그를 저장소로 보내는 작업을 가정하자. 상품의 재고 수량 업데이트 작업은 지연없이 실시간으로 처리되야 하지만, 구매 로그를 저장소로 보내는 작업은 이미 로그가 서버에 기록되어 있으므로 실시간 처리보다는 배치 처리를 이용하는 것이 효율적일 것이다. 카프카는 이러한 장점을 지닌 배치 전송을 권장한다.

4. 압축 전송

카프카는 메시지 전송 시 좀 더 성능이 높은 압축 전송을 사용하는 것을 권장한다. 카프카에서 지원하는 압축 타입은 gzip, snappy, lz4, zstd이다. 압축만으로도 네트워크 대역폭이나 회선 비용을 절감하고, 이를 배치 전송과 결합해 사용한다면 높은 효과를 발휘한다. 높은 압축률이 필요한 경우 gzip, zstd를, 빠른 응답 속도가 필요하다면 lz4, snappy를 권장한다.

5. 토픽, 파티션, 오프셋

- 카프카는 토픽이라는 곳에 데이터를 저장 

- 토픽은 병렬 처리를 위해 여러 개의 파티션이라는 단위로 다시 나뉨. 이와 같은 파티셔닝을 통해 단 하나의 토픽이라도 높은 처리량 수행 가능

- 이 파티션의 메시지가 저장되는 위치를 오프셋이라고 하며, 오프셋은 순차적으로 증가하는 64비트 정수 형태로 되어 있다. 각 파티션에서의 오프셋은 고유한 숫자로, 메시지의 순서를 보장하고 컨슈머에서는 마지막까지 읽은 위치를 알 수 있다.

6. 고가용성 보장

* 고가용성 : 하나의 서버나 노드가 다운되어도 다른 서버 또는 노드가 장애가 발생한 서버의 역할을 대신해 안정적인 서비스를 가능하게 하는 것 

- 리플리케이션을 통해 고가용성을 보장

- 토픽 자체를 복제하는 것이 아닌 토픽의 파티션을 복제

- leader : 토픽의 파티션 원본 / follower : 토픽의 파티션의 리플리케이션

Replication-factor	Leader	Follower
2	1	1
3	1	2
4	1	3

리더의 숫자는 1을 유지한 채, 리플리케이션 팩터 수에 따라 팔로워 수만 증가하게 된다.

- 팔로워의 수만큼 브로커의 디스크 공간도 소비되므로 이상적인 리플리케이션 팩터 수를 유지해야 하며, 일반적으로 카프카에서는 리플리케이션 팩터 수를 3으로 구성하도록 권장

7. 주키퍼의 의존성

*Zookeeper : 카프카의 중요한 메타데이터를 저장하고 각 브로커를 관리하는 중요한 역할

- 하둡의 서브 프로젝트 중 하나

- 카프카를 비롯 아파치 산하 프로젝트 Hadoop, NiFi, HBase 등 많은 분산 애플리케이션에서 코디네이터 역할 담당

- 여러 대의 서버를 앙상블로 구성하고, 살아있는 노드 수가 과반수 이상 유지 시 지속적인 서비스 가능

: 반드시 홀수로 구성되어야함!

 

- Znode를 이용해 카프카의 메타 정보가 주키퍼에 기록, 주키퍼는 이러한 지노드를 이용해 브로커의 노드 관리, 토픽 관리, 컨트롤러 관리 등 매우 중요한 역할을 담당