Kafka ‐ 기본 개념 및 Zookeeper vs Kraft 차이점 - dnwls16071/Backend_Study_TIL GitHub Wiki
📚 Zookeeper와 Kraft 모드 동작 차이점 정리
- Zookeeper 모드의 경우 민감한 정보를 Zookeeper에 저장할 때, 패스워드 인코더를 정의해 특정 알고리즘으로 인코딩할 수 있다.
- 허나 Kraft 모드의 경우 민감한 정보를 저장할 때 암호화되지 않은 채로 저장될 수 있다.
- Zookeeper가 더 좋고.. Kraft가 더 좋고.. 이런 개념이 아니라 "주어진 상황에 맞는" Kafka를 사용하면 된다.
📚 Kafka Topic(토픽)
- 하나의 토픽은 여러 파티션으로 구성되며 파티션은 0번부터 시작한다.
- 컨슈머가 토픽 내부의 파티션에서 데이터를 가져가더라도 데이터는 삭제되지 않는다.
- 카프카 파티션을 늘리는 것은 가능하지만 그에 따라 컨슈머 역시도 늘려야 한다.(무조건적으로 늘리는 것이 정답은 아니다.)
📚 Kafka Broker(브로커)
- 카프카 브로커는 카프카가 설치되어 있는 서버 단위를 말한다.
- 보통 3개 이상의 브로커로 구성하여 사용하는 것을 권장한다.
- 만약 partition이 1이고, replication이 2라면 원본 1개, 복제본 1개를 말하는 것이다.
- 다만 브로커 개수에 따라서 replication 개수가 제한된다.
- 여기서 원본 파티션은 리더 파티션이라고 부르고 나머지 복제 파티션은 팔로워 파티션이라고 부른다.
- 프로듀서가 토픽의 파티션에 데이터를 전달할 때 바로 리더 파티션에 전달된다.
- 프로듀서에는 ack라는 상세 옵션이 존재한다.
- 이 ack를 통해 고가용성을 유지할 수 있는데 이 옵션은 partition의 replication과 관련이 있다.
- 프로듀서가 전송한 데이터가 브로커들에 정상적으로 저장되었는가에 대한 전송 성공 여부를 확인하는 데에 사용하는 옵션이다.
- 0, 1, -1 중 하나로 설정할 수 있다. 설정값에 따라 데이터의 유실 가능성이 달라진다.
1(default) : 리더 파티션에 데이터가 저장되면 전송 성공으로 판단한다.0 : 프로듀서가 전송한 즉시 브로커에 데이터 저장 여부와 상관없이 성공으로 판단한다.-1 : 토픽의 min.insync.replicas 개수에 해당하는 리더 파티션과 팔로워 파티션에 데이터가 저장되면 성공하는 것으로 판단한다.
❓적정 Replication 개수 : 많으면 많을수록 좋은 것이 아니라는 점
- Replication 개수가 많아지면 브로커의 리소스 사용량도 늘어나게 된다.
- 카프카에 들어오는 데이터의 양과 저장 시간을 잘 고려해 Replication 개수를 정하는 것이 좋다.
- 추천 Replication 개수 : 3
📚 파티셔너
- 파티셔너는 데이터를 토픽에 있는 파티션 중 어떤 파티션에 넣을 것인지를 결정하는 역할을 합니다.
- 레코드에 포함된 메시지 키 또는 메시지 값에 따라서 파티션의 위치가 결정된다.
- 프로듀서를 사용할 때 파티셔너를 따로 설정하지 않으면 UniformStickyPartitioner로 동작한다.
- 해당 파티셔너는 메시지 키가 있을 때와 없을 때가 다르게 동작한다.
- 메시지 키가 있는 경우는 다음과 같이
hash를 통해 해시 값을 찾아 어느 파티션으로 들어갈지를 결정한다.
- 메시지 키가 없는 경우는 파티션에 적절히 분배가 된다.
- 커스텀으로도 파티셔너를 구성할 수 있다.
📚 컨슈머 렉(Lag)
- 컨슈머가 아직 읽지 못한 메시지의 수
- 컨슈머의 처리 속도가 느리거나 프로듀서가 메시지를 너무 많이 전송할 경우 따라가지 못해서 Lag가 발생한다.