DeveloperRio DeveloperRio

www.youtube.com/watch?v=_x9RacHDQY0 카프카를 많이 이용하다보면 2가지 상황이 생긴다. 새로운 컨슈머가 존재하는 토픽을 쓰고 싶은 경우 (토픽의 메세지 form 에 대해 알고 있어야 한다. ) 토픽 스키마를 변경하고 싶은 경우 → 스키마 레지스트리가 위의 문제를 해결해준다. Schema Registry stand-alone, 스키마들을 저장하고 있다. 저장하고 캐쉬도 하고 있다. 클러스터로 관리할 수 있다. API 로 되어 있고 , consumer/ producer 시 이전 버전과의 비교를 한다. produce 타이밍에 스키마를 받아서 맞는 스키마에 맞게 데이터를 만든다.룰을 정하고 그 룰에 맞게 변화하면 성공하고, 룰에 맞지 않으면 실패하게 한다. consume 시엔 스키마에..

www.youtube.com/watch?v=J6adhl3wEj4 Kafka connect 다른 어떤 데이터를 다루는 시스템과 데이터를 주고 받을 때 이용함. 마치 컨슈머나 프로듀서 같이 보인다. 또는 둘다. (하지만 브로커는 아니다) 클러스터 바깥에서 동작한다. 스케일이 가능하고(커넥트 클러스터), 장애 시 회복에 좋다 (fault tolerance ..) 간단한 json config 만으로 커넥터를 쓸 수 있다. 커넥터는 간단한 인터페이스를 가지고 있다. 어떤 곳에서 데이터를 가져오든 다같은 인터페이스다. confluent hub 에 가면 다양한 connector 를 쓸 수 있다. (무료, 유료) 커넥터 허브는 검색이 가능하다...(계속 광고를 하는군... ) 그 뒤로는...계속 직접 만들 생각 하지말..

www.youtube.com/watch?v=b0BEl3ZKxxI 집중해서 들어보았으나...요약하면 카프카 커뮤니티 자랑 ㅎㅎ 커뮤니티 , eco system 잘 되어 있으니 걱정마라. 잘 보고 하시면 됩니다. ← 요약 끝

www.youtube.com/watch?v=Z9g4jMQwog0 KafkaConsumer 클러스터와 연결. 여러가지 설정을 map 으로 담는다. (몇몇 브로커들 주소, 보안 설정들... 등등) 위는 KafkaProducer 사용원칙과 같다. ConsumerRecords consumer 를 통해서 데이터를 읽어보고, 여러 가지 방식으로 우리가 원하는 메세지만 취할 수 있다. 해당 메세지를 consumerRecords 라는 곳에 받을 수 있다. 그리고 그 안에 consumerRecord 들이 들어있다. ConsumerRecord key-value pair 우리는 위 세가지를 이용하여 다루지만 Consumer 는 많은 일을 한다. connection 관리, 클러스터의 metadata 업데이트 등등... 그리고..

www.youtube.com/watch?v=I7zm3on_cQQ KafkaProducer cluster 와 연결하는데 사용함. 해당 클래스에 설정값이 담긴 map 을 넣어 사용한다. (몇몇 브로커들의 주소, 보안적인 설정들 ...등등) ProducerRecord key-value 를 담고 있음. 개발자로서 신경쓰는 건 위의 두 가지 클래스겠지만 프로듀서는 많은 일을 한다. connetion pool 관리, 네트워크 버퍼링, 브로커로부터 ack 를 기다리는 일, 필요한 메세지를 translate 하는 등등 .. 프로그래머가 신경도 될만큼. 어떤 파티션으로 나눌 것인지 결정하는 것도 프로듀서가 결정한다. 커스텀 스키마를 적용하는 것도 프로듀서가 한다. 파티션 기능은 프로듀서가 담당한다고 봐도 된다. 이 단계..

www.youtube.com/watch?v=Vo6Mv5YPOJU Partition in One broker 하나의 브로커에만 파티션이 존재한다면, 문제가 생길 확률이 높다. → Partition 의 복제본을 두어야 한다. (다른 브로커에) Follwer replicas Leader replica 가 존재하고, 복제본을 follwer replica 라 부른다. ( 하나의 리더에 N-1 개의 팔로워가 존재한다) 파티션에 쓰든, 읽든 우리는 Leader 만 다룬다. Leader 에 쓰면, 데이터는 팔로워들로 나누어 진다. 이러한 과정은 개발자 입장에서 신경쓸 필요가 없다. (카프카의 관리자 입장이라면... 신경쓸 수 있다.) 또한 내구성면에서 이러한 설정들을 바꿀 수도 있다. 하지만 거의 신경쓰지 않아도 될 ..

www.youtube.com/watch?v=jHnyBSUVcOU Brokers 카프카는 브로커라 불리는 서버들의 네트워크로 구성된다. 요즘엔 물리적인 서버가 아닌, 클라우드로 구성된다. (컨테이너..) 각각의 브로커는 파티션들을 가지고 요청들을 처리한다. 읽고, 쓰고. 브로커는 파티션의 replication 도 다룬다. 브로커는 굉장히 간단하다. 따라서 확장적인 측면에 굉장히 유리하다.

www.youtube.com/watch?v=y9BStKvVzSs 하나의 토픽이 하나의 노드에만 있다면? 확장성 측면에서 문제가 많을 것이다. 노드의 크기만큼만 저장할 수 있게 된다. 경제적인 면으로도 처음부터 엄청 큰 노드를 쓰고 싶지도 않을 것이다. 한 토픽에만 데이터가 몰리고, 읽기와 쓰기가 많다면 하나의 노드에만 엄청난 부하가 몰릴 것이다. Partitioning 위와 같은 상황이 일어나지 않게 카프카는 Partition 을 제공한다. Partition 은 하나의 토픽(로그) 를 여러 개로 쪼개어 카프카 클러스터의 각각 노드에 저장할 수 있게 한다. 또한 어떤 노드에 저장할 지도 결정해준다. key 가 존재하지 않는 message 라면, round robin 방식으로 저장된다. key 가 존재한다면..