Replication
message 복제하여 클러스터 내 브로커들에 분산시키는 동작
하나의 브로커가 종료되어도 안정성 유지 가능
토픽 생성 시 replication factor 지정 가능
환경에 따른 factor 기준선정 (개발, 운영 등)
Partition
하나의 Topic에 대한 처리량을 높이기위해 병렬 처리가 가능하게 만든것
Partition 수만큼 Consumer 연결 가능
늘리는건 가능하나 줄이는건 불가능
초기에 적게 설정 후 메세지 처리량, 컨슈머 LAG 모니터링하며 늘리는 것 권장
※ 컨슈머 LAG
Producer가보 낸 메세지 수 - Consumer가 가져간 메세지수
Segment
Producer에 의해 Broker로 보내진 메세지는Partition에 저장됨
각 메세지는 Segment 라는 로그 파일 형태로 저장됨
OS의 페이지 캐시 사용하여 디스크 I/O 접근 줄어듬
batch전송, 압축 전송 (gzip, snappy, lz4, zstd)
Offset
Partition 내 메세지가 저장되는위치
64bit 정수 형태
파티션 내 메세지 순서 보장 및 읽은 위치 확인
Replication
토픽 자체 복제가 아닌 토픽의 파티션 복제
원본과의 구분을 위해 Leader, Follower로 구분
Follower 수만큼 브로커 디스크 공간소비
Zookeeper
여러 대의 서버를 앙상블(클러스터)로 구성
살아있는 노드가 과반수 이상 유지된다면 지속적 서비스 가능 (홀수로 구성하는 이유)
znode를 이용하여 카프카 메타 정보가 zookeeper에 저장됨
znode를 통해 broker의 node 관리, Topic 관리, controller 관리
카프카 성장에 따라 zookeep와 성능 한계가 드러나 의존성 제거하려 하는 중
Producer
Topic으로 메세지 전송
Record는 Topic, Partition, Key, Value로 구성
send 메소드를 통해 serializer, partitioner 거침
Record의 Partition 지정하지 않은 경우 Key를 기준으로 Partition 선택
Round Robin 방식으로 동작 (default)
send 메소드 동작 이후 레코드들을 각 파티션별로 잠시 모아둠 (batch)
Consumer
Topic에 저장되어 있는 메세지를 가져오는 역할
컨슈머 그룹, 리밸런싱 등 동작도 수행
Producer가 아무리 빨라도 Consumer가 읽어오지 못하면 자연 발생
Consumer는 반드시 Group에 속함
Group은 각 파티션 리더에게 토픽에 저장된 메세지 가져오기 위한 요청
파티션 수, Consumer 수(Group 내) 일대일 매핑이 이상적
Consumer가 파티션보다 많다고 처리량이 높아지진 않음
Replication된 Topic에 대한 Partition 중 Leader가 모든 읽기, 쓰기 담당
= Producer는 Leader에게만 메세지 보내고 Consumer는 오직 Leader로부터 메세지 가져옴
Follower는 Leader문제 발생시 언제든 새로운 Leader가 될 준비
지속적으로 Partition Leader가 새로운 메세지 받았는지 확인 + 받았으면 복제
Leader와 Follower는 ISR (In Sync Replica)로 묶임
해당 그룹 내 Follower만 새로운 리더 자격
Follower는 Leader 데이터를 따라가고, Leader는 Follower들이 메세지 받음을 대기
Follower가 특정 주기 시간만큼 복제 요청을 하지 않는 경우 ISR그룹에서 추방당함
ISR 점검을 통해 Topic의 상태 확인 가능
ISR 내 모든 팔로워의 복제 완료 시 Leader는 내부적으로 commit 되었다는 표시를 함
마지막 커밋 오프셋 위치를 하이워터마크라고 함
Leader와 Follower 사이 ACK 없음 (성능↑)
Replication을 위한 메세지 요청은 알고 있으나 동작의 성공여부는 알 수 없음
Leader가 push하는 방식이 아닌 Follower가 pull 하는 방식으로 리더의 부하 줄임
