2024-01-27 - Githubissues

로그와 세그먼트

log.segment.bytes : 바이트 단위의 최대 세그먼트 크기 지정. 기본값은 1GB log.roll.ms(hours) : 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기. 기본값은 7일

액티브 세그먼트

가장 마지막 세그먼트(쓰기가 일어나고 있는) 파일이며 브로커의 삭제 대상에 포함되지 않음 그 외 세그먼트는 retention 옵션에 따라 삭제 대상으로 지정됨

세그먼트와 삭제주기(cleanup.policy=delete)

retention.ms(minutes, hours) : 세그먼트를 보유할 최대 기간. 기본값 7일 retention.bytes : 파티션당 로그 적재 바이트 값. 기본값 -1(지정하지 않음) log.retention.check.interval.ms : 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격. 기본값 5분

세그먼트의 삭제 cleanup.policy=delete

카프카의 데이터 삭제 단위는 세그먼트이므로 로그 단위(레코드 단위) 개별 삭제는 불가능 로그(레코드)의 메시지 키, 메시지 값, 오프셋, 헤더 등 이미 적재된 데이터에 대해 수정 불가능 데이터 적재 시(프로듀서) 또는 데이터 사용 시(컨슈머) 데이터를 검증하는게 좋음 -> 세그먼트 단위

토픽 압축 cleanup.policy=compact

일반적으로 생각하는 zip 같은 압축(compression)과 다른 개념 여기서 압축은 메시지 키 별 레코드 중 오래된 데이터를 삭제하는 정책임 그러므로 삭제(delete) 정책과 다르게 일부 레코드만 삭제될 수 있음 압축은 액티브 세그먼트를 제외한 데이터가 대상임 -> 레코드 단위

🤔레코드 중 오래된 데이터는 어떻게 선별할까? k3 기준으로 13, 16이 중복됨. 이때 13 삭제

🤔왜 이렇게 하나? key-value data 에서 가장 최신 것을 활용한다고 하면 중복 데이터 중 이전 데이터가 필요없을 때가 있다. materialized view 같은 것을 보여줄 때 배치처리를 하게되는데 이 때 중복 데이터를 미리 제거해두면 프로세싱하기 편하기 때문. 이전 데이터는 out of record 이므로 필요 없으므로 제거해도 무방하다. key value store 에서 가장 최신값만 사용하면 되므로!!!!

Tail/Head Area, Clean/Dirty log

tail area : 압축 정책에 의해 압축 완료된 레코드들. 클린 로그라고도 부름. 중복 메시지 키가 없음 head area : 압축 정책이 되기 전 레코드들. 더티 로그 라고도 부름. 중복된 메시지 키가 있음

🤔중복된 메시지 키는 어떻게 생성되지? 중복 검사 안하고 저장되나? 키 설정에 따라 중복도가 올라갈 순 있겠지

min.cleanable.dirty.ratio

데이터의 압축 시작 시점은 min.cleanable.dirty.ratio 옵션값을 따름 옵션값은 액티브 세그먼트를 제외한 세그먼트에 남아 있는 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수 비율을 의미함

로그 정리를 시도할 빈도를 제어함 (0 ~ 1) 로그 중복으로 낭비되는 공간의 최대 크기를 제한함 (최대 50%의 로그가 중복될 수 있음)

0.5 : 더티 비율이 0.5 넘어가면 압축 수행. 50% 이상 압축된 로그는 정리하지 않음 (기본값) 테일 영역의 레코드 수가 헤드 영역의 레코드 개수와 동일할 경우 압축 실행 0.9 : 한번 압축할 때 많은 데이터가 줄으드므로 효과가 좋음. 단 해당 비율이 될 때 까지 용량을 차지하므로 효율이 좋지않음 0.1 : 압축이 자주 일어나서 가장 최신 데이터만 유지할 수 있음. 단 브로커에 부담을 줄 수 있음

비율이 높을수록 더 적은 횟수로 효율적으로 로그를 정리하지만, 로그에서 낭비되는 공간이 많아짐.

https://kafka.apache.org/documentation/#topicconfigs_min.cleanable.dirty.ratio

브로커의 역할 - 복제(Replication)

데이터 복제(replication) : 카프카를 장애 허용 시스템(fault tolerant system)으로 동작하도록 하는 원동력 복제 이유 : 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함 카프카의 데이터 복제 단위는 파티션 단위로 이루어짐 토픽 생성 시 파티션의 복제 개수(replication factor)도 같이 설정되는데 직접 설정하지 않을 시 브로커에 설정된 옵션값을 따라감 -> 브로커 수 만큼 따라간다는 뜻?🤔 최소값은 1(복제 없음) 최대값은 최대 브로커 개수만큼

복제된 파티션은 리더(leader)와 팔로워(follower)로 구성됨 리더 : 프로듀서 또는 컨슈머와 직접 통신하는 파티션 팔로워 : 나머지 복제 데이터를 가지고 있는 파티션. 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 리더로부터 데이터를 가져와 자신의 파티션에 저장함(복제)

단점 : 복제 수 만큼 용량이 증가 장점 : 데이터를 안전하게 사용할 수 있다. 보통 카프카 운영 시 2 이상의 복제 개수를 정하는 것이 중요하다. 일반적인 경우 2 / 데이터 안정성이 중요할 경우 3 정도

디스크를 사용하는 대신 가용성을 높이기 위해 복제를 활용한다!

브로커에 장애가 발생한 경우

브로커 다운 시 해당 브로커에 있는 리더 파티션은 사용할 수 없음 팔로워 파티션 중 하나가 리더 파티션 지위를 넘겨받음 (승급) 이를 통해 데이터가 유실되지 않고 컨슈머/프로듀서와 데이터를 주고받도록 동작할 수 있음

운영 시 데이터 종류마다 다른 복제 개수를 설정하고 상황에 따라서 토픽마다 복제 개수를 다르게 설정하여 운영하기도 함 데이터가 일부 유실되어도 무관하고 데이터 처리 속도가 중요하다면 1 또는 2로 설정 ㄴ 1은 언제 사용할까? 메트릭 처럼 일부 데이터가 유지되어도 가능한 경우. 예를들어 네비게이션의 GPS 정보에서 분당 60개일 때 2~3개는 유실되어도 상관없음 금융 정보같이 유실이 일어나면 안되는 데이터의 경우 3으로 설정하기도 함

ISR(In-Sync-Replicas)

ISR : 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태 복제 개수 2 일 때 리더 파티션 1과 팔로워 파티션 1개 존재. 리더 파티션에 0~3 오프셋이 있다고 가정 할 때, 팔로워 파티션에 동기화가 완료되려면 0~3까지 오프셋이 존재해야함.

동기화 완료 -> 리더 파티션의 모든 데이터가 팔로워 파티션에 복제됨

unclean.leader.election.enable

리더 파티션의 데이터를 모두 복제하지 못한 상태이고, 싱크가 되지 않은 팔로워 파티션이 리더 파티션으로 선출되면 데이터가 유실될 수 있음 유실 발생 시 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶다면 ISR이 아닌 팔로워 파티션을 리더로 선출하도록 설정할 수 있음 unclean.leader.election.enable=true : 유실을 감수함. 복제가 안된 팔로워 파티션을 리더로 승급 unclean.leader.election.enable=false : 유실을 감수하지 않음. 해당 브로커가 복구될 때까지 중단

so3500 / TIL

2024-01-27 #12