실전 카프카 개발부터 운영까지 책을 읽으며 요약한 글입니다.

카프카

카프카는 토픽을 통해 메시지 송수신을 중개해주는 플랫폼입니다. 구독과 소비 형태를 띄는 pubsub 구조를 가지며 데이터를 공급하는 쪽을 producer라고 부르고 데이터를 수신하는 쪽을 consumer라고 부릅니다.

주요 키워드

• 주키퍼(zookeeper): 카프카의 메타데이터를 관리하고 브로커의 정상상태를 점검하는 어플리케이션입니다.
• 브로커(broker): 카프카 어플리케이션이 설치된 서버 또는 노드를 의미합니다
• 카프카 클러스터(kafka cluster): 여러 대의 브로커를 구성한 그룹인 클러스터를 의미합니다.
• 프로듀서(producer): 카프카로 메시지를 보내는 클라이언트를 의미합니다
• 컨슈머(consumer): 카프카 메시지를 수신하고 꺼내가는 클라이언트를 의미합니다.
• 메시지(message): 프로듀서가 전송하거나 컨슈머가 읽어간 데이터를 의미합니다.
• 세그먼트(segment): 브로커의 로컬 디스크에 저장된 메시지 파일을 말합니다.
• 토픽(topic): 동일한 유형의 메시지를 묶는 단위이며 카프카는 메시지를 토픽으로 구분합니다.
• 파티션(partition): 병렬처리와 고성능을 위해 하나의 토픽을 여러 개로 나눈 것을 말합니다.

v2.8 이전의 구성

위에서 서술했듯 카프카는 프로듀서, 컨슈머, 카프카 형태로 구성되며 카프카의 정상 동작을 보장하기 위해 메타데이터를 관리하는 zookeeper라는 coordinator도 같이 구성합니다.

v2.8 이후의 구성

kafka 2.8 버전부터 얼리 억세스로 Kraft 프로토콜(kafka의 event based raft protocol)을 통해 zookeeper를 사용하지 않고 메타데이터를 관리할 수 있습니다. 이전까지는 개발에서만 사용을 추천하였는데 3.3 버전부터는 실제 운영 환경에서도 Kraft 모드를 사용할 수 있습니다.

kraft mode일경우 리더 역할을 하는 브로커의 quorum controller가 자신의 상태를 metadata 토픽으로 전송하고, 같은 quorum 내의 브로커의 quorum controller는 토픽을 구독해서 상태를 내부에 저장하는 형태로 구동합니다.

메타 데이터가 무한히 확장되지 않게 축약되어 주기적으로 로그로 저장되고 만약 파티셔닝으로 브로커가 고장나면 다시 rejoin할 때 메타데이터를 통해 빠르게 놓친 이벤트를 받을 수 있게 되어 가용성이 크게 향상됩니다.

quorum mode로 동작하면 이전과 다르게 만약 리더십이 변경되면 상태 정보가 이미 내부적으로 전부 저장되어 있어 zookeeper에서 메타데이터를 불러오는 동작이 필요없어집니다.

리플리케이션

리플리케이션은 메시지들을 복제해서 (실제로는 파티션 복제) 카프카 클러스터 내의 브로커들에 분산하는 동작을 말합니다. 리플리케이션을 통해 브로커가 종료되어도 카프카는 안전성을 유지할 수 있습니다.

replication-factor 옵션으로 토픽의 리플리케이션을 설정할 수 있는데 1이면 본인 한 개, 3이면 본인 포함 총 세 개의 레플리카가 유지됩니다.

리플리케이션 수가 많으면 그만큼 안전성이 높아지지만 브로커의 리소스가 많이 소모되므로 프로그램에 따라 적당히 유지해야 합니다.

만약 유실이 허용된다면 2개, 허용되지 않으면 3개 이상을 설정해두고 사용하면 좋습니다.

파티션

토픽의 처리량을 높이기 위해 토픽을 여러 개로 나눠 병렬 처리를 가능하게 만든 것을 파티션이라고 합니다. 파티션이 나뉜 수만큼 컨슈머를 연결할 수 있어 처리량이 높아집니다.

파티션이 여러개이면 메시지는 파티션마다 분산되어 저장되고, 파티션에 연결된 컨슈머가 메시지를 가져가 분리되어 처리하게 됩니다.

partition 옵션으로 설정할 수 있으며 파티션의 시작 번호는 0부터 시작합니다.

파티션은 늘리는 것은 맘대로 가능하지만 한 번 늘리면 줄이는 것이 불가능하므로 초기에 파티션 수를 작게 생성하고 LAG에 따라 점차 늘리는 것이 좋습니다.

https://eventsizer.io/partitions 에서 파티션 수를 계산할 수 있지만 어플리케이션마다 기준이 다를 수 있으므로 참고로만 활용하면 됩니다.

세그먼트

파티션으로 보내진 메시지는 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장됩니다. 세그먼트에는 해당 메시지의 내용이 저장되고, 컨슈머가 데이터를 가져갈 때 세그먼트를 참조해 메시지를 가져가게 됩니다.

카프카 특징

분산 시스템

카프카는 분산 시스템으로 성능이 높고 확장이 쉬우며 높은 장애 대응 능력을 지닙니다.

만약 시스템 리소스가 한계에 다다르면 브로커를 추가해 쉽게 스케일아웃이 가능하고, 이러한 동작을 어플리케이션이 운영중인 상황에도 반영할 수 있습니다.

페이지 캐시

카프카는 높은 처리량을 위해 OS의 페이지 캐시를 활용합니다. 페이지 캐시를 사용하게 되면 실제 디스크가 아닌 메모리에서 데이터를 가져올 수 있어 I/O 접근시간이 줄어들게 됩니다.

배치 전송

카프카는 프로듀서와 컨슈머들과 통신하며 수많은 메시지를 주고받습니다. 단건으로 메시지를 송수신하면 네트워크 오버헤드가 많으므로 카프카는 배치 처리를 통해 메시지를 모아서 처리합니다.

압축 전송

카프카는 메시지 전송시 압축 전송을 지원하며 사용을 권장합니다. 지원하는 압축 타입은 gzip, snappy 등 다양합니다. 일반적으로 gzip이나 zstd를 사용하며 빠른 응답속도가 요구된다면 lz4나 snappy를 권장합니다.

압축을 이용하면 네트워크 대역폭과 회선 비용이 줄어들며 배치 전송과 결합하면 더욱 높은 효과를 가져다줍니다.

토픽, 파티션, 오프셋

카프카는 메시지를 토픽 단위로 구분짓고, 토픽은 병렬 처리를 위해 다시 여러 개의 파티션으로 나뉩니다. 각 파티션마다 메시지가 저장되는 위치를 오프셋이라 하고, 오프셋은 각 파티션마다 고유합니다.

메시지는 오프셋을 통해 순서가 보장되고 각 컨슈머가 마지막으로 읽은 위치도 이를 통해 알 수 있습니다.

고가용성

카프카는 분산 시스템의 특징으로 고가용성을 보장합니다. 하나의 서버나 노드가 죽어도 다른 서버나 노드가 역할을 대신해 안정적으로 서비스가 가능하게 해주는데 이는 위에서 설명한 리플리케이션 기능을 통해 제공됩니다. 원본과 레플리카를 구분하기 위해 카프카에서는 리더와 팔로워라고 부릅니다.

리플리케이션은 토픽이 아닌 파티션 자체를 복제합니다. 또, 리더는 하나만 존재하게 되는데 팔로워가 늘수록 브로커의 디스크 공간이 소모되므로 적절한 수의 팔로워를 유지해야 합니다. 일반적으로 3을 권장합니다.

실전 카프카 개발부터 운영까지 3장