본문 바로가기

Kafka24

로그 컴팩션 💡 이번 포스팅에서는 로그 컴팩션에 대해 정리해 보도록 하겠습니다. 컴팩션은 로그 세그먼트 관리 정책 중 하나로, 로그를 삭제하지 않고 컴팩션하여 보관할 수 있습니다. 로그 컴팩션은 기본적으로는 로컬 디스크에 저장되어 있는 세그먼트를 대상으로 실행되는데, 현재 활성화(active)된 세그먼트는 제외하고 나머지 세그먼트들을 대상으로 컴팩션이 실행됩니다. 카프카에서는 단순하게 메시지를 컴팩션하여 보관하기보다는 메시지의 키값을 기준으로 마지막의 데이터만 보관하는 좀 더 효율적인 방법으로 컴팩션합니다. 이런 컴팩션을 사용하는 대표적인 컨슈머가 바로 __consumer_offsets입니다. 위 이미지와 같이 k1에 대해 k1, v1, v3, v4 가 저장되었다고 했을 경우 마지막 k1에 대한 값은 v4입니다. 따.. 2023. 5. 7.
메시지 로그 세그먼트, 로그 세그먼트 💡 이번 포스팅에서는 메시지 로그 세그먼트에 대해 정리해 보도록 하겠습니다. 카프카의 토픽으로 전송되는 메시지는 각 파티션에 세그먼트, 또는 로그 세그먼트라는 파일에 저장됩니다. 로그 세그먼트에는 메시지의 내용과 메시지의 키, 값, 오프셋, 메시지 크기 같은 정보가 함께 저장되며, 브로커의 로컬 디스크에 저장됩니다. 하나의 로그 세그먼트 크기가 너무 커지면 파일을 관리하기 어려워지기 때문에 기본적으로는 최대 1GB 크기로 설정되어 있습니다. 만약 설정된 크기보다 커지는 경우에 기본적으로 롤링(Rolling) 전략을 사용합니다. 따라서 파티션은 하나 이상의 세그먼트로 구성되며, 각 세그먼트는 일정 시간이 지나거나 용량이 초과될 경우 기존의 세그먼트는 close 하고 새로운 세그먼트를 생성하여 데이터를 저장.. 2023. 5. 7.
컨트롤러 💡 이번 포스팅에서는 컨트롤에 대해 정리해 보도록 하겠습니다. 카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하게 되며, 파티션의 ISR 리스트 중에서 리더를 선출합니다. 리더를 선축하기 위한 ISR 리스트 정보는 안전한 저장소에 보관되어 있어야 하는데, 가용성 보장을 위해 주키퍼에 저장되어 있습니다. 컨트롤러는 브로커가 실패하는 것을 예의주시하고 있으며, 만약 브로커의 실패가 감지되면 즉시 ISR 리스트 중 하나를 새로운 파티션 리더로 선출합니다. 그러고 나서 새로운 리더의 정보를 주키퍼에 기록하고, 변경된 정보를 모든 브로커에게 전달합니다. 파티션의 리더가 다운됐다는 것은 해당 파티션의 리더가 없는 상태를 의미하며, 카프카 클라이언트인 프로듀서나 컨슈머가 해당 파티션으로 읽거나 쓰기가 불가능합니.. 2023. 5. 1.
리더에포크 & 복구 💡 이번 포스팅에서는 리더에포크와 복구에 대해 정리해 보도록 하겠습니다. 리더에포크(LeaderEpoch)는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용됩니다. 리더에포크는 컨트롤러에 의해 관리되는 32비트의 숫자로 표현됩니다. 해당 리더에포크 정보는 Replication 프로토콜에 의해 전파되고, 새로운 리더가 변경된 후 변경된 리더에 대한 정보는 팔로워에게 전달됩니다. 리더에포크는 복구 동작 시 하이워터마크를 대체하는 수단으로도 활용됩니다. 리더에포크 X peter-test01 토픽의 리더 파티션과 팔로워 모두 message1 메시지 Replication에 성공했습니다. 그리고 하이워터마크를 1로 올린 후 리더 파티션이 message2를 저장한 후 팔로워 파티션.. 2023. 5. 1.
ISR(In Sync Replica) 💡 이번 포스팅에서는 ISR(In Sync Replica)에 대해 정리해 보도록 하겠습니다. 이전에 포스팅했던 Replication에서 리더와 팔로워 파티션들은 하나의 논리적 그룹으로 묶여있는데 이를 ISR(In Sync Replication)이라고 합니다. ISR은 리더 파티션과 정상적으로 동기화가 이루어진 팔로워 파티션들로 구성되며, 만약 팔로워 파티션에 문제가 생겨 리더 파티션의 메시지를 가져오지 못하거나 뒤쳐질 경우 해당 팔로워 파티션은 ISR에서 제외됩니다. 📢 ISR을 주기적으로 확인하는 옵션은 다음 두가지 옵션이 있습니다. zookeeper.session.timeout.ms default: 6초 max: 18초 → 브로커가 주키퍼에 연결되어 있어야 합니다. 위 옵션에 설정된 시간 내에 Hea.. 2023. 5. 1.
Replication 💡 이번 포스팅에서는 Replication에 대해 정리해 보도록 하겠습니다. 이전 멀티 노드 카프카 - 1, 멀티 노드 카프카 - 2 포스팅에서 토픽 생성 시 replication-factor 옵션을 통해 토픽의 각 파티션들을 여러 브로커에 복제해 보았습니다. 이번 포스팅에서는 파티션 복제, Replication에 대해 조금 더 자세하게 정리해 보도록 하겠습니다. 멀티 노드 카프카의 핵심은 바로 Replication입니다. Replication을 통해서 개별 노드(브로커)의 장애를 대비하여 높은 가용성을 제공할 수 있기 때문입니다. Replication은 토픽 생성 시 replication-factor 값을 통해 구성할 수 있습니다. 만약 replication-factor가 3이면 리더 파티션, 팔로워 .. 2023. 5. 1.
멀티 노드 카프카 - 2 💡 이번 포스팅에서는 멀티 노드 카프카 구성 시 토픽 생성에 대해 정리해 보도록 하겠습니다. 멀티 노드 카프카 - 1 💡 이번 포스팅에서는 멀티 노드 카프카 구성 방법에 대해 정리해 보도록 하겠습니다. 단일 노드 카프카는 멀티 노드 카프카에 비해 설정이 간편하기 때문에 사용 측면에서는 좋지만, 성능과 soono-991.tistory.com 이전 포스팅에서 구성한 멀티 노드 카프카에서 토픽을 만들어 파티션들이 어떻게 생성되는지 확인해 보겠습니다. 브로커는 총 3개를 만들었으며 각각 9092, 9093, 9094 포트로 설정했습니다. 9092 브로커 1에 토픽을 생성해 보겠습니다. broker 1 broker 2 broker 3 각 브로커별로 생성한 토픽에 대한 파티션들이 분배된 것을 확인할 수 있습니다. .. 2023. 5. 1.
멀티 노드 카프카 - 1 💡 이번 포스팅에서는 멀티 노드 카프카 구성 방법에 대해 정리해 보도록 하겠습니다. 단일 노드 카프카는 멀티 노드 카프카에 비해 설정이 간편하기 때문에 사용 측면에서는 좋지만, 성능과 가용성 또는 장애 복구와 같은 부분은 고려할 때는 장점 외에는 모든 것이 단점입니다. 필수는 아니지만 많은 글들에서 멀티 노드 카프카 설정에서 추천하는 방식은 브로커 3개, 각 토픽별 파티션 3개로 구성하는 것을 추천하고 있습니다. 위와 같이 멀티 노드 카프카로 구성하게 되면 각 토픽별 파티션이 각 브로커별로 분배되어 있는 것을 확인할 수 있습니다. 이렇게 구성했을 때의 장점은 브로커 1이 장애가 발생하더라도 나머지 브로커 2, 브로커 3에서 이미 복제된 파티션이 있기 때문에 리밸런싱을 통해 문제없이 브로커 2, 브로커 3.. 2023. 5. 1.
KafkaConsumer 💡 이번 포스팅에서는 KafkaConsumer에 대해 정리해 보도록 하겠습니다. 이전에 KafkaProducer 객체를 통해 카프카 토픽에 메시지를 전송해 보았습니다. 이번에는 KafkaConsumer 객체를 통해 프로듀서가 전송한 메시지를 읽어오도록 하겠습니다. public static void main(String[] args) { String topicName = "simple-topic"; Properties props = new Properties(); props.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.111.133:9092"); props.setProperty(ConsumerConfig.KEY_DESERIALIZER_CLA.. 2023. 4. 17.
Consumer - 3 💡 이번 포스팅에서는 Consumer -1, Consumer - 2에 이어서 Consumer에 대해 정리해 보도록 하겠습니다. auto.offset.reset 컨슈머가 토픽에 처음 접속하여 메시지를 가져올 때 가장 오래된 처음 오프셋(earliest)부터 가져올 것인지 가장 최근인 마지막 오프셋(latest) 이후부터 가져올 것인지를 설정하는 파라미터이며, earliest와 latest가 있습니다. earliest: 처음 오프셋부터 읽음 latest: 마지막 오프셋부터 읽음 하지만 주의할 점은 컨슈머가 토픽에 처음 접속할 때 __consumer_offsets에 있는 오프셋 정보를 기반으로 메시지를 가져오기 때문에 earliest로 설정한다 해도 무조건 0번 오프셋부터 읽어 들이지는 않습니다. 그리고 컨슈.. 2023. 4. 17.
Consumer - 2 💡 이번 포스팅에서는 Consumer -1에 이어서 Consumer에 대해 정리해 보도록 하겠습니다. 컨슈머는 위와 같이 ConsumerCoordinator, ConsumerNetworkClient, Fetcher, SubscriptionState 등의 주요 내부 객체와 별도의 HeartBeat Thread를 생성합니다. 이전 포스팅에서 정리하지 않은 Fetcher, ConsumerNetworkClient, SubscriptionState에 대해서 정리해 보도록 하겠습니다. Fetcher, ConsumerClientNetwork Fetcher, ConsumerClientNetwork 객체는 브로커의 토픽 파티션에서 메시지를 Fetch 및 Poll을 수행하는 객체입니다. 위 그림들과 같이 컨슈머는 poll.. 2023. 4. 17.
Consumer - 1 💡 이번 포스팅에서는 Consumer에 대해 정리해 보도록 하겠습니다. Consumer(이하 컨슈머)는 프로듀서가 브로커에 전송한 메시지를 읽는 역할을 수행합니다. 컨슈머는 반드시 컨슈머 그룹에 속해야 하며 컨슈머 그룹 내에서 여러 개의 컨슈머들은 토픽 파티션 별로 분배됩니다. 아파치와 컨플루언트 공식 문서에서는 아래와 같이 설명하고 있습니다. 컨슈머는 오프셋 위치에서 시작하는 로그를 받는다고 합니다. 또한 오프셋 위치를 제어할 수 있기 때문에 이미 가져왔던 데이터를 다시 가져오는 것 또한 가능합니다. 이때 오프셋 위치는 __consumer_offset 토픽에 저장합니다. 📢 앞서 컨슈머가 프로듀서가 브로커에 전송한 메시지를 읽어온다고 했는데, 정확히 얘기하면 컨슈머가 subscribe(구독)하고 있는 .. 2023. 4. 16.
Producer - 2 💡 지난번 정리했던 Producer에서 추가 내용이 있어 정리한 포스팅입니다. Producer에 대해 잘 모르시는 분들은 전에 정리했던 Producer 포스팅을 참고하시면 좋을 것 같습니다. Producer 프로듀서는 카프카의 토픽으로 메시지를 전송하는 역할을 담당합니다. 위 이미지는 프로듀서의 전체적인 흐름을 나타낸 것입니다. 먼저 카프카로 전송하기 위한 실제 데이터인 ProducerRecord를 생 soono-991.tistory.com acks acks는 producer가 broker에 메시지를 전송한 결과에 관한 설정인데, confluent kafka 공식 문서의 설명을 살펴보면 다음과 같습니다. 프로듀서가 요청 완료를 고려하기 전에 리더 파티션이 수신해야 하는 승인의 수입니다. 이것은 전송된 레.. 2023. 4. 9.
Partitioner & Partition 💡 이번 포스팅에서는 Partitioner & Partition에 대해 알아보도록 하겠습니다. Topic을 생성할 때 파티션을 지정하지 않을 경우 기본적으로 해당 토픽에 대한 1개의 파티션이 생성이 됩니다. 따라서 토픽은 1개 이상의 파티션으로 구성이 된다고 말할 수 있으며, 파티션의 그룹이라고 말할 수도 있습니다. 위와 같이 하나의 토픽에 대해 파티션이 여러 개 구성되어 있을 경우, 각 파티션은 0번부터 시작해서 순차적으로 이름이 지정됩니다. 그리고 이 파티션에 producer가 보낼 메시지가 저장됩니다. 앞서 Producer 정리 포스팅에서 Producer가 kafka로 메시지를 보낼 때 특정 토픽으로 메시지를 보낸다고 했었습니다. 하지만 조금 더 정확하게 말하자면 특정 토픽으로 메시지를 보내는 것이.. 2023. 4. 8.
kafka CLI 사용하기 - kafka-configs.(sh | bat) 💡 이번 포스팅에서는 kafka-configs.(sh | bat)에 대해 알아보도록 하겠습니다. kafka에서 config는 크게 2 부분으로 나눌 수 있습니다. ✨ Broker, Topic 레벨의 Config ㆍKafka 서버에서 설정되는 Config ㆍTopic의 Config 값은 Broker 레벨에서 지정한 Config를 기본으로 설정하며 별도의 Topic 레벨 Config를 설정할 경우 이를 따름 ㆍ보통 server.properties에 있는 Config는 변경 시 Broker 재기동이 필요한 Static Config이며, Dynamic Config는 kafka-configs를 이용하여 동적으로 config 변경 가능 ✨ Producer와 Consumer 레벨의 Config ㆍKafka 클라이언트.. 2023. 4. 8.

티스토리툴바