카프카의 내부 동작 원리

카프카 리플리케이션

리플리케이션 동작 개요

카프카는 브로커의 장애에도 불구하고 연속적으로 안정적인 서비스를 제공함으로써 데이터 유실을 방지하며 유연성을 제공합니다. 리플리케이션 동작을 위해 토픽생성시 필숫값으로 replication factor라는 옵셥을설정해야합니다.

카프카는 리플리케이션 팩터라는 옵션을 이용해 관리자가 지정한 수만큼의 리플리케이션을 가질 수 있기 때문에 N개의 리플리케이션이 있는 경우 N-1까지의 브로커 장애가 발생해도 메시지 손실 없이 안정적으로 메시지를 주고받을 수 있습니다.

리더와 팔로워

토픽 상세보기 명령어를 실행해 보면 출력 내용 중 파티션의 리더 라는 부분이 있습니다. 모두 동일한 리플리케이션이라 하더라도 리더만의 역할이 따로 있기 때문에 카프카에서 리더를 특별히 강조해 표시합니다.
내부적으로 모두 동일한 리플리케이션들을 리더와 팔로워로 구분하 각자의 역할을 분담 시킵니다. 리더는 리플리케이션 중 하나가 선저오디며 모든 읽기와 쓰기는 그 리더를 통해서만 가능합니다.
이때 팔로워들 역시 대기만 하고 있는것이 아니라 리더에 문제가 발생하거나 이슈가 있을 경우를 대비해 언제든지 새로운 리더가 될 준비를해야합니다.

리더와 팔로워는 ISR이라는 논리적 그룹으로 묶여 있습니다.
리더는 ISR 내 모든 팔로워가 메시지를 받을 때까지 기다립니다. 하지만 팔 로워가 네트워크 오류, 브로커 장애 등 여러 이유로 리더로부터 리플리케이션하지 못하는 경우도 발생할 수 있습니다. 이렇게 뒤처진 팔로워는 이미 리더와의 데이터가 불일치한 상 태에 놓여 있으므로, 만약 이 팔로워에게 새로운 리더를 넘겨준다면 데이터의 정합성이나 메시지 손실 등의 문제가 발생할 수 있습니다. 따라서 파티션의 리더는 팔로워들이 뒤처지 지 않고 리플리케이션 동작을 잘하고 있는지를 감시합니다. 즉 리더에 뒤처지지 않고 잘 따 라잡고 있는 팔로워들만이 ISR 그룹에 속하게 되며, 리더에 장애가 발생할 경우 새로운 리더 의 자격을 얻을 수 있는 것입니다.
리더는 해당 팔로워가 리플리케이션 동작에 문제가 발생했다고 판단해 ISR 그룹에서 추방합니다.

ISR 내에서 모든 팔로워의 복제가 완료되면, 리더는 내부적으로 커밋되었다는 표시를 하게 됩니다. 마지막 커밋 오프셋 위치는 하이워터마크highwatermark라고 부릅니다.

커밋의 위치

커밋된 메시지를 유지하기위해 로컬 디스크의 replication-offset-checkpoint라는 파일에 마지막 커밋 오프셋 위치를 저장합니다
만약 특정 토픽 또는 파티션에 복제가 되지 않거나 문제가 있다고 판단되는 경우, replication-offset-checkpoint라는 파일의 내용을 확인하고 리플리케이션되고 있는 다른 브로커들과 비교해 살펴보면, 어떤 브로커, 토픽, 파티션에 문 제가 있는지를 파악할 수 있습니다.

카프카 ack통신

ack통신은 쉽게생각하면 리더의 데이터를 팔로워들이 동기화 해주는것이다.
여타 메시징 시스템들은 리플리케이션 동작에서 리더와 팔로워가 메시지를 잘 받았는지 확인하는 ACK 통신을 하지만, 카프키는 ACK 단계를 제거했습니다.이렇게 ACK 통신을 제외한 카프카의 리더는 메시지를 주고받는 기능에 더욱 집중할 수 있습니다.
이를 가능하게 하는 것은 리더와 팔로워들의 리플리케이션 동작 방식은 리더가 푸시하는 방식이 아니라 팔로워들이 풀하는 방식으로 동작하기때문입니다.

리더에포크와 복구

리더에포크는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하 기 위한 용도로 이용됩니다.
브로커가 복구 동작을 하는데 왜 리더에포크가 필요할까?
장애 발생시 복구과정

• 장애 복구 과정에서 하이워터마크차이로 메시지가 손실됄 수 있다
• 리더에포크 사용시 복구과정*
• 삭제 동작을 하기에 앞서 리더에포크 요청 과 응답 과정을 통해 팔로워의 하이워터마크를 올릴 수 있었고, 메시자 손실은 발생하지 않습니다.

컨트롤러

카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하게 되며，파티션의 ISR 리스트 중에서 리더를 선출합니다. 리더를 선출하기 위한 ISR 리스트 정보는 안전한 저장소에 보관되어 있어야 하는데, 가용성 보장을 위해 주키퍼에 저장되어 있습니다
컨틀로러는 브로커가 실패하는 것을 지켜보고 있다가 실패가 감지되면 ISR리스트 중 하나를 새로운 파티션 리더로 선출합니다.

제어된 종료 방법

controlled.shutdown.enable = true 설정이 브로커의 설정 파일인 server.properties에 적용되어야 합니다.

로그(로그세그먼트)

ヲト프카의 토픽으로 들어오는
메시지(레코드)는 세그먼트라는 파일에 저장됩니다.
메시지는 정해진 형식에 맞추어 순차적으로 로그 세그먼트 파일에 저장됩니다. 로그 세그먼 트에는 메시지의 내용만 저장되는 것이 아니라 메시지의 키 밸류, 오프셋, 메시지 크기 같은 정보가 함께 저장되며, 로그 세그먼트 파일들은 브로커의 로컬 디스크에 보관됩니다.
로그세그먼트의 최대 크기는 1GB
이보다 커지면 롤링전략적용 즉 클로즈하고 세로운 세그먼트생성하기대문에 로그 관리 계획을 수립해 둬야합니다.
관리방법
-삭제
-컴팩션

로그 세그먼트 삭제

관리자가 server, properties에 해당 옵션을 따로 명시하지 않았다면 로그 세그먼트는 삭제 정책이 적용됩니다.
retention.ms 옵션을조정해서메시지를삭제해보겠습니다.카프카 에서기본제공히는도구중kafka-configs.sh 명령어를이용합니다

로그 세그먼트 컴팩션

로그를 삭제하지 않고 컴팩션하여 보관할 수 있습니다. 로그 컴팩션은 기본적으로 로컬 디스크에 저장되 어 있는 세그먼트를 대상으로 실행되는데, 현재 활성화된 세그먼트는 제외하고 나머지 세그 먼트들을 대상으로 컴팩션이 실행됩니다.
용량문제를 해결하기 위해 카프카에서 로그 세그먼트를 컴팩션하면 메시지 (레코드)의 키값을 기준으로 마지막의데 이터만 보관하게 됩니다.

• 최종상태 즉 메시지의 벨류만 사용자에게 노출시키거나할때 사용

장점
로그 컴팩션의 장점은 바로 빠른 장애 복구입 니다. 장애 복구 시 전체 로그를 복구하지 않고, 메시지의 키를 기준으로 최신의 상태만 복구 합니다. 따라서 전체 로그를 복구할 때보다 복구 시간을 줄일 수 있다는 장점이 있습니다.
키값을 기준으로 최종값만 필요한 워크로드에 적용하는 것이 바람직합니다