카프카 기본 개념과 구조
카프카는 다음과 같은 장점이 있다.
- 높은 처리량
- 빠른 응답 속도
- 우수한 안정성
카프카의 처리량을 높이기 위해 설계된 분산 시스템, 페이지 캐시, 배치 전송 및 주키퍼의 역할에 대해서 알아본다
카프카를 구성하는 주요 요소
- Zookeeper : 카프카의 메타데이터 관리 및
브로커의 정상상태 점검을 담당 - Kafka, Kafka Cluster : 여러 대의
브로커를 구성한 클러스터를 의미 - Broker : 카프카 어플리케이션이 설치된 서버 또는 노드
- Producer : 카프카로
메세지를 보내는 역할을 하는 클라이언트를 총칭 - Consumer : 카프카에서
메세지를 꺼내가는 역할을 하는 클라이언트를 총칭 - Topic : 카프카는
메세지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유(Unique) - Partition : 병렬 처리 및 고성능을 얻기 위해
하나의 토픽을 여러 개로 나눈 것 - Segment : 프로듀서가 전송한 실제 메세지가
브로커의 로컬 디스크에 저장되는 파일 - Message:, Record : 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는
데이터 조각 (객체)
리플리케이션
각 메세지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에게 분산시키는 동작을 의미.
하나의 브로커가 종료되더라도 카프카는 안정성을 유지 할 수 있다
카프카에서 토픽이 리플리케이션 되는것이 아니라, 토픽의 파티션이 리플리케이션이 되는 것
카프카 > 토픽 > 파티션 > 세그먼트 > 레코드 의 개념을 가지고 이해해 보자
리플리케이션의 팩터 수가 커지면 안정성은 높아지지만, 그만큼 브로커 리소스를 많이 사용하게 된다. 따라서 복제에 대한 오버헤드를 줄여서 최대한 브로커를 효율적으로 사용하는것을 권장한다
- 테스트나 개발 환경 : 리플리케이션
팩터 수를 1로 설정 - 운영 환경(로그성 메세지로서 약간의 유실 허용): 리플리케이션
팩터 수를 2로 설정 - 운영 환경(유실 허용하지 않음): 리플리케이션
팩터 수를 3으로 설정
책의 저자가 팩터 수를 3일 경우에도 충분한 메세지 안정성도 보장하고, 적절하게 디스크 공간을 사용 할 수 있었다고 한다.
파티션
하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하게 만든 것
단, 나뉜 파티션 수만큼 컨슈머를 연결 할 수 있지만 컨슈머 수 > 파티션 수 가 되지 않도록 한다
파티션 수는 초기 생성 이후 언제든지 늘릴 수 있지만, 반대로 한 번 늘린 파티션 수는 절대로 줄일 수 없다. 그러므로 초기에 토픽을 생성할 때 파티션 수를 작게 생성 후 메세지 처리량이나 컨슈머의 LAG 등을 모니터링 하면서 조금씩 늘려가는 방법이 가장 좋다
세그먼트
프로듀서를 이용해 보낸 메세지들은 특정 토픽의 특정 파티션에 저장되어 있다. 각 메세지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크(클러스터 서버 내)에 저장됩니다.
실제 서버내의 kafka-logs 디렉토리 경로로 이동하면 로그 관련 폴더들이 존재한다. 이 때
[토픽-파티션]의 폴더로 이동해서 보면 .log파일이 존재하는데 해당 파일을 hexdump를 보여주는 xxd 명령어를 이용해서 확인하면 프로듀서의 내용을 확인할 수 있다
--> xxd log파일 이름
카프카 핵심 개념
분산 시스템
네트워크 상에서 연결된 컴퓨터들의 그룹을 말하며, 단일 시스템이 갖지 못한 높은 성능을 목표로 한다. 또한 하나의 서버 또는 노드 등에 장애가 발생할 때 다른 서버 또는 노드가 대신 처리하므로 장애 대응이 탁월하며, 부하가 높은 경우에는 시스템 확장이 용이하다는 장점이 있다.
페이지 캐시
운영체제는 성능을 높이기 위해 꾸준히 진화하고 개선되고 있는데, 특히 페이지 캐시의 활용이 대표적이다. 카프카 역시 OS의 페이지 캐시를 활용하는 방식으로 설계되어 있다. 페이지 캐시는 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 어플리케이션이 사용하지 않는 일부 잔여 메모리를 활용한다. 이렇게 페이지 캐시를 이용하면 디스크 I/O에 대한 접근이 줄어드므로 성능을 높일 수 있다.
카프카가 OS의 페이지 캐시를 이용한다는 것은 카프카가 직접 디스크에서 읽고 쓰기를 하지 않고 페이지 캐시를 통해 읽고 쓰기를 한다고 이해 하면 된다.
배치 전송 처리
카프카는 프로듀서, 큰슈머 클라이언트들과 서로 통신하며, 이들 사이에서 수많은 메세지를 주고 받는다. 이때 발생하는 수많은 통신을 묶어서 처리할 수 있어서 단건으로 통신할 때에 비해 네트워크 오버헤드를 줄일 수 있을 뿐만 아니라 장기적으로 더욱 빠르고 효율적으로 처리가 가능하다
다음은 실시간과 배치에 대해서 기차에 탑승하는 예이다.
| 그룹 분류 | 탑승 방식 | 기차에 탑승하는 승객 수 | 필요한 기차 수 |
|---|---|---|---|
| 실시간 | 승객 개개인이 도착하자마자 출발 | 1명 | 10대 |
| 배치 | 모든 승객을 기다린 후 출발 | 10명 | 1대 |
2개 그룹에서 최종 승객이 도착하는 시점은 서로 비슷할 것이다. 하지만 적은 기차수를 이용한 배치가 좀더 효율적으로 보인다. 상품의 재고 수량 업데이트 작업은 지연 없이 실시간으로 처리되어야 하지만, 구매 로그를 저장소로 보내는 작업은 이미 로그가 서버에 기록되어 있으므로 실시간 처리보다는 배치 처리를 이용하는 편이 효율적이다. 이러한 이유로 카프카에서는 배치 전송을 권장한다.
압축 전송
카프카는 메세지 전송 시에 좀더 성능이 높은 압축 전송을 사용하는것을 권장한다.
압축 타입은 gzip, snappy, lz4, zstd 등등..
토픽, 파티션, 오프셋
토픽은 병렬 처리를 우해 여러 개의 파티션이라는 단위로 다시 나뉜다. 카프카에서는 이와 같은 파티셔닝을 통해 단 하나의 토픽이라도 높은 처리량을 수행할 수 있다. 이 파티션의 메세지가 저장되는 위치를 오프셋이라고 부르며, 오프셋은 순차적으로 증가하는 숫자(64비트 정수) 형태로 되어 있다. 각 파티션에서의 오프셋은 고유한 숫자로, 카프카에서는 오프셋을 통해 메세지의 순서를 보장하고 컨슈머에서는 마지막까지 읽은 위치를 알 수도 있다.
우리가 흔히 사용하는 메일 전송 시스템에서 이메일 주소 정도의 개념으로 이해하자
프로듀서에서 토픽의 이름(이메일주소)를 지정하여 보낸다. 또한 보낼 때 특정 토픽의 특정 파티션을 지정하여 보낼 수 도 있다.
고가용성 보장
카프카는 분산 시스템이기 때문에 하나의 클러스터가 다운되어도 다른 클러스터가 장애가 발생한 서버의 역할을 대신해 안정적인 서비스가 가능하다. 이러한 고가용성을 보장하기 위해 카프카에서는 리플리케이션 기능을 제공한다.
토픽자체를 복제하는 것이 아니라 토픽의 파티션을 복제하는것이다.
원본과 리플리케이션을 구분하기 위해 흔히 마스터, 미러 같은 용어를 사용하는데 카프카에서는 리더(Leader)와 팔로워(Follower)라고 부른다.
리플리케이션 팩터 수에 따른 리더와 팔로워 수
| 리플리케이션 팩터 수 | 리더 수 | 팔로워 수 |
|---|---|---|
| 2 | 1 | 1 |
| 3 | 1 | 2 |
| 4 | 1 | 3 |
표와 같이 리더의 숫자는 1을 유지한 채 리플리케이션 팩터 수에 따라 팔로워 수만 증가하게 된다. 즉 팔로워의 수가 많다고 딱히 좋은게 아니다. 팔로워의 수만큼 결국 브로커의 디스크 공간도 소비되므로 이상적인 리플리케이션 팩터 수를 유지해야 하며, 카프카에서는 리플리케이션 팩터 수를 3으로 구성하도록 권장한다.
리더는 프로듀서, 컨슈머로부터 오는 모든 읽기와 쓰기 요청을 처리하며, 팔로워는 오직 리더로부터 리플리케이션하게 된다.
주키퍼의 의존성
많은 아파치 프로젝트인 하둡(Hadoop), 나이파이(NiFi), 에이치베이스(HBase)등 많은 분산 어플리케이션에서 코디네이터 역할을 하는 어플리케이션으로 사용되고 있다.
주키퍼는 여러 대의 서버를 클러스터로 구성하고, 살아 있는 노드 수가 과반수 이상 유지된다면 지속적인 서비스가 가능한 구조이다. 따라서 주키퍼는 반드시 홀수로 구성해야 한다
주키퍼의 주된 기능은 결국 카프카의 메타데이터를 저장하고, 각 브로커를 관리하는 역할이다.
하지만 점점 주키퍼 성능의 한계가 드러나기 시작했고, 카프카에서 주키퍼에 대한 의존성을 제거 하려고 하고 있다( 카프카3.0이상은 주키퍼가 없이 동작이 되지만 아직 상용화가 힘들다)
