카프카 기본 구성
카프카는 데이터를 받아서 전달하는 데이터 버스(Data Bus) 역할을 한다. 메시지를 만드는 쪽을 프로듀서(Producer)이라 하고 데이터를 꺼내 소비하는 쪽을 컨슈머(Consumer)라고 한다. 주키퍼는 카프카의 정상 동작을 보장 하기 위해 메타데이터(metadata)를 관리하는 코디네이터(Coordinator)라고 할 수 있다.
구성 주요 요소
주키퍼(Zookeeper): 아파치 프로젝트 애플리케이션 이름이다. 카프카 메타데이터(metadata) 관리 및 브로커의 정상상태 점검(health check)을 담당한다.
카프카(Kafka) 또는 카프카 클러스터(Kafka Cluster): 아파츠 프로젝트 애플리케이션 이름이다. 여러 대의 브로커를 구성한 클러스터를 의미한다.
브로커(Broker): 카프카 애플리케이션이 설치된 서버 혹은 노드
프로듀서(Producer): 카프카로 메시지를 보내는 역할을 하는 클라이언트
컨슈머(Consumer): 카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트
토픽(Topic): 카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유하다.
파티션(Partition): 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것을 말한다.
세그먼트(Segment): 프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장되는 파일을 말한다.
메시지(Message) 또는 레코드(Record): 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각을 말한다.
리플리케이션(Replication)
각 메시지를 여러개로 복제해서 카프카 클러스터 내 브로커들에게 분산시키는 동작을 의미한다. 하나의 브로커가 종료되더라도 카프카는 안정성을 유지할 수 있다. 카프카 토픽을 생성하거나 변경할시 --replication-factor 3와 같은 옵션으로 리플리케이션 옵션을 줄 수 있다. 숫자는 몇개의 리플리케이션을 유지할 것인지를 나타내는 것이고 해당 숫자는 원본을 포함한 숫자이다. 즉 예시로 든 3은 원본을 제외한 복제본 2개가 추가로 생성한다는 듯이다.
리플리케이션 팩터 수가 커지면 안정성은 높아지지만 브로커 리소스를 그만큼 많이 먹게된다. 복제에 대한 오버헤드를 줄여서 브로커를 효율적으로 사용하는 것을 권장한다.
다음과 같은 기준으로 리플리케이션 팩터 수를 결정하는 것을 권장한다.
- 테스트나 개발 환경: 리플리케이션 팩터 수를 1로 설정
- 운영 환경(로그성 메시지로서 약간의 유실 허용): 리플리케이션 팩터 수를 2로 설정
- 운영 환경(유실 허용하지 않음): 리플리케이션 팩터 수를 3으로 설정
안정성을 높이고자 하면 팩터 수를 4또는 5이상으로도 설정할 수 있다.
파티션(Partition)
하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러개로 나눠 병렬 처리할 수 있게 만든 것을 파티션(Partition)이라고 한다. 이렇게 하나를 여러 개로 나누면 분산 처리도 가능하다. 이렇게 하면 분산 처리도 가능하다. 이렇게 나뉜 파티션 수만큼 컨슈머를 연결할 수 있다.
파티션 번호는 0번 부터 시작한다.
파티션 수도 토픽을 생성할 때 옵션으로 설정하게 되는데 파티션 수를 정하는 기준이 모호한 경우가 많다. 파티션 크기는 늘리는 건 가능하지만 절대 줄일 수가 없다. 그러므로 초기에 토픽을 생성할 때 파티션 수를 작게 2또는 4정도로 생성한 후 메시지 처리량이나 컨슈머 LAG등을 모니터링 하여 조금씩 늘려가는것이 가장 좋다.
세그먼트(Segment)
메시지는 토픽의 파티션에 저장이되고 각 메시지들은 세그먼트(Segment) 로그 파일의 형태로 브로커 로컬디스크에 저장이된다. 각 파티션마다 N개의 세그먼트 로그 파일들이 존재한다.