6. 카프카 내부 메커니즘

[im1sun]

2 컨트롤러
컨트롤러는 일반적인 카프카 브로커의 기능에 더해서 파티션 리더를 선출하는 역할을 추가적으로 맡습니다.

브로커들은 주키퍼의 컨트롤러 노드에 변동이 생겼을 때 알림을 받기 위해서 노드에 와치를 설정합니다.

컨트롤러 브로커가 멈추거나 주키퍼와의 연결이 끊어질 경우, Ephemeral노드가 삭제됩니다. 이후 다른 브로커가 와치를 통해 컨트롤러가 없어졌다는 것을 알아차리게 되고 주키퍼에 컨트롤러 노드를 생성합니다.

3 복제
카프카는 분산되고, 분할되고, 복제된 커밋 로그 서비스라고 표현되기도 합니다. 개별적인 노드에는 필연적으로 장애가 발생할 수 밖에 없고, 카프카는 이러한 상황속 신뢰성과 지속성을 보장하는 방식이기 때문입니다.

카프카는 데이터를 토픽단위로 조직화합니다. 각 토픽은 1개이상의 파티션으로 분할되며, 각 파티션은 다시 다수의 레플리카를 가질 수 있습니다. 각각의 레플리카는 브로커에 저장되는데, 대개 하나의 브로커는 수백 개에서 수천 개의 레플리카를 저장합니다.

레플리카는 2종류가 있습니다.

리더 레플리카
각 파티션에는 리더 역할을 하는 레플리카가 하나씩 있습니다. 모든 쓰기 요청은 리더 레플리카로 주어지며, 일겅올 때는 리더 레플리카, 팔로워레플리카 둘다 사용합니다.

팔로워 레플리카
팔로워는 클라이언트의 요청을 처리할 수 없으며, 메시지를 복제함으로써 최신상태를 유지하는 역할을 수행합니다. (리더 레플리카가 크래쉬가 날 경우 승격되기위해)

4 요청 처리
쓰기 요청
카프카 브로커로 메시지를 쓰고 있는 프로듀서가 보낸 요청

읽기 요청
카프카 브로커로부터 메시지를 읽어오고 있는 컨슈머나 팔로워 레플리카가 보낸 요청

어드민 요청
토픽 CRUD 어드민 요청

4.1 쓰기 요청
acks설정 변수는 쓰기 작업이 성공한 것으로 간주되기 전 메시지에 대한 응답을 보내야 하는 브로커의 수를 의미합니다.

acks=1 : 리더만이 메시지를 받았을 때
acks=all : 모든 인-싱크 레플리카들이 메시지를 받았을 때
acks=0 : 메시지가 보내졌을 때

4.2 읽기 요청
읽기 요청또한 파티션 리더를 맡고 있는 브로커에게 전송됩니다. 파티션 리더는 요청이 유효한지 확인하고, 메시지를 가져와 클라이언트에게 전송합니다
컨슈머는 모든 인-싱크 레플리카에 복제된 메시지들만을 읽을 수 있습니다. 따라서 어떠한 이유로 브로커들 사이의 메시지 복제가 늦어지면, 새 메시지가 컨슈머에 도달하는 데 걸리는 시간도 길어집니다.

컨슈머가 많은 수의 파티션으로부터 이벤트를 읽어오는 경우가 있을 때, 카프카는 읽기 세션 캐시를 활용합니다. 이는 모든 메타데이터를 캐시하며, 성능을 향상시킵니다.

5 물리적 저장소
카프카의 기본 저장 단위는 파티션 레플리카입니다. 파티션은 다른 브로커들 사이에 분리될 수 없으며, 같은 브로커의 서로 다른 디스크에 분할 저장되는 것도 불가능 합니다.

5.3 파일 관리
카프카는 영구히 데이터를 저장하지도, 데이터를 지우기전에 모든 컨슈머들이 메시지를 읽어갈 수 있도록 기다리지도 않습니다. 카프카는 오래되면 지운다 또는 용량이 넘어가면 지운다 라는 규칙에 의거하여 메시지를 관리합니다.

하나의 파티션은 여러 개의 세그먼트로 분할되며, 각 세그먼트는 1GB 또는 1주일치의 데이터 만큼 저장됩니다. 카프카가 파티션 단위로 메시지를 쓰는 만큼 각 세그먼트 한도가 다 차면 세그먼틀르 닫고 새로운 세그먼트가 생성됩니다. (현재 쓰여지는 세그먼트를 액티브 세그먼트라고 불리웁니다.)

5.4 파일 형식
세그먼트는 하나의 데이터 파일 형태로 저장되며, 파일 안에는 메시지와 오프셋이 저장됩니다.

이러한 메시지는 압착과 삭제 보존정책에 의하여 관리됩니다. 메시지는 다음과 같은 두 영역을으로 나뉘게 됩니다.