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

리플리케이션을 3개로 설정한 후 브로커에 배치된 상태입니다. 토픽의 파티션이 리플리케이션되어 안정성을 보장하며, 리플리케이션 팩터 수는 안정성과 비례하지만 브로커 리소스를 많이 사용하게 되므로 적절한 팩터 수를 조절할 것을 권장합니다.
하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하도록 만든 것을 의미합니다. 나뉜 파티션 수만큼 컨슈머를 연결할 수도 있습니다.

프로듀서를 이용해 보낸 메시지는 특정 토픽의 파티션에 저장되며, 각 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장됩니다.

지금까지의 토픽, 파티션, 세그먼트의 관계도는 아래와 같습니다.

카프카를 사용하는 주된 이유는 높은 처리량, 빠른 응답 속도, 안정성입니다. 왜 이런 특징을 갖고 있는지 알아볼 것입니다.
카프카는 더 높은 메시지 처리량을 보장하기 위해 브로커를 추가하여 확장하는 것이 가능합니다.
디스크 I/O에 대한 접근을 줄이기 위해 애플리케이션이 사용하지 않는 일부 메모리를 사용하여 캐싱합니다.
메시지를 단건이 아닌 묶어서 처리할 수 있어 네트워크 오버헤드를 줄일 수 있습니다.
메시지를 압축하여 네트워크 대역 폭이나 회선 비용을 줄일 수 있으며 배치 전송과 결합해 사용하면 더 높은 효과를 볼 수 있습니다.
카프카는 토픽에 데이터를 저장하며 이메일 주소와 유사한 개념이라고 이해하기 쉽습니다.
각 토픽은 병렬 처리를 위해 여러 파티션 단위로 나뉩니다. 그리고 파티션의 메시지가 저장되는 위치를 오프셋이라고 하며 순차적으로 증가하는 숫자(64bit) 형태로 되어 있습니다.

오프셋을 이용하면 메시지의 순서를 보장하고 컨슈머는 마지막까지 읽은 위치를 알 수 있습니다.
리플리케이션 기능을 이용하여 토픽의 파티션을 복제할 수 있습니다. 카프카에서는 원본과 리플리케이션을 구분하기 위해 리더와 팔로워라는 이름을 사용합니다.

일반적으로 운영 환경에서 리플리케이션 팩터 수를 3으로 구성할 것을 권장합니다.
주키퍼는 여러 대의 서버를 클러스터로 구성하고, 살아있는 노드 수가 과반수 이상 유지된다면 서비스가 가능한 구조입니다. 따라서 주키퍼는 홀수로 구성해야 합니다.
지노드(znode)를 이용해 카프카의 메타 정보가 주키퍼에 기록되며, 이 정보를 활용하여 브로커의 노드, 토픽, 컨트롤러 관리 등의 역할을 수행합니다.

프로듀서는 특정 토픽으로 메시지를 전송해야 하므로 레코드에서 토픽과 밸류(메시지 내용)은 필수 항목입니다. 선택 옵션을 사용하면 특정 파티션으로 메시지를 전달할 수 있으며, 지정하지 않으면 기본적으로 라운드 로빈 방식으로 파티션을 선택하여 메시지를 보관합니다.
프로듀서에서 카프카로 메시지를 바로 전송하지 않고 파티션에 보관하는 이유는 재치 전송을 하기 위함입니다. 또한 전송을 실패하면 재시도 동작이 이뤄집니다.
프로듀서가 카프카의 토픽으로 메시지를 전송하면 브로커들의 로컬 디스크에 저장됩니다. 그리고 컨슈머를 이용해 토픽에 저장된 메시지를 가져올 수 있습니다.
컨슈머 그룹은 하나 이상의 컨슈머들이 모여 있는 그룹을 의미하고, 컨슈머는 반드시 컨슈머 그룹에 속하게 됩니다. 이 컨슈머 그룹은 각 파티션의 리더에게 카프카 토픽에 저장된 메시지를 가져오기 위한 요청을 보냅니다. 일반적으로 일대일 맵핑이 이상적이며, 컨슈머 수가 더 많게 하는 것은 대기하는 컨슈머가 증가하므로 비효율적인 구성입니다.

그룹 내의 컨슈머는 서로의 정보를 공유합니다. 만약 컨슈머01에 문제가 생겨 종료된다면 컨슈머02, 03이 작업을 대신해 peter-01 토픽의 파티션0를 컨슘합니다.