[Chap 03] 카프카 커넥트 ~3.6

[travelbeeee]

현석

• 카프카 커넥트 개념을 받아들이는 챕터여서 개념적인 궁금증은 따로 없습니다.
• '카프카 커넥트는 활용하기 좋겠다' 는 생각을 했습니다.
  • 웹툰은 읽음기록 위주로 카프카를 사용하다가 올해 카프카를 사용하는 스펙이 많이 늘어났는데 매번 프로듀서, 컨슈머 n2c 로 띄우고 하는 작업들을 어느 정도 공통화해서 틀을 만든다면 카프카 커넥트로 처리할 수 있지 않을까....?? ( 웹툰에서 카프카 작업을 아직 안맡아봐서 구체적인 예시는 생각이 안나네요 )
• 카프카 커넥트는 오프셋을 커넥트에서 직접 관리하는데 POSITION_FIELD 값 저장 중에 에러가 나거나 하는 상황이 안생기나...? 생기면 보장을 어떻게 해주는거지...?? ( 카프카에서는 설정을 줄 수 있었는데 카프카 커넥트는 어떤 방식으로 보장할 수 있는지 모르겠습니다. )
  • 분산 모드 커넥트는 관련 정보들을 내부 토픽에 저장 => 카프카를 이용해서 보장해주는 것 같다.

[KKambi]

한비

build.gradle

jar {
  from { 
    configurations.compile.collect { 
      it.isDirectory() ? it : zipTree(it) ..
    }
  }
}

일반적으로 gradle에서 해당 명령어는 다음과 같은 작업 수행

• jar : plain archive, 모든 의존성을 포함하지 않고, 소스코드의 클래스 & 리소스 파일만 포함
• bootJar : executable archive, 실행에 필요한 모든 의존성을 함께 빌드

위의 설정은 jar 명령어가 plain이 아닌 fat jar를 만들게 한다.

SpringBoot 2.5.0부터 gradle을 이용하면 두 가지의 jar가 모두 빌드된다.

[kihyun-yang]

기현

• 카프카 커넥트의 태스크 밸런싱 로직
  • https://voidmainvoid.tistory.com/473
    • Round-robin과 함께 더 적은 숫자의 태스크를 가진 워커에 태스크가 분배되는 방식
    • 일부 태스크는 다른 태스크에 비해 더 많은 리소스(cpu, ram)을 소모할 수도 있는데, 단순히 round-robin과 워커가 갖고 있는 태스크 갯수를 통해 태스크를 분배하는 것은 이상적이지는 않다.
    • 리소스 사용량이 많은 태스크가 일부 워커에 몰릴 수 있기 때문

[meloncha]

민석

kafka va streams vs connect

• kafka : 애플리케이션 간 이벤트 스트림을 공유하는 방법을 제공하는 백엔드 애플리케이션
• kafka streams : kafka 에서 데이터를 변환하는 클라이언트 애플리케이션을 작성하기 위한 API. 데이터 처리 자체는 kafka 브로커가 아닌 클라이언트 애플리케이션 내에서 발생
• kafka connect : kafka 안팎으로 데이터를 이동하기 위한 API. 커넥터를 사용하고 공유하여 DB 같은 애플리케이션 간에 데이터를 이동할 수 있도록 한다. kafka와 다른 애플리케이션을 통합하는 방법을 제공

• Producer : 데이터를 직접 생성하는 애플리케이션 ex) 로그
• Connect Source : 데이터 저장소와 kakfa 사이를 연결하는 애플리케이션 ex) DB, REST API
• Streams : kafka 에서 소비하는 작업에 대한 스트림 처리 및 복잡한 논리 적용하여 가공
• Comsumer : 스트림을 읽고 실시간 작업 수행
• Connect Sink : 스트림을 읽고 대상 저장소에 저장 ex) DB

Kafka Connect Source

• Producer API 위에 구축된 전체 프레임워크
• 커넥터를 사용하여 코드 작성없이 대부분의 소스에서 데이터에 활용할 수 있음

Kafka Connect Sink

• 기존 kafka 커넥터의 생태계를 활용하여 코드 작성없이 스트리밍 ETL (extract, transform, load) 가능. (데이터 추출, 변환, 적재)

참고 : https://medium.com/@stephane.maarek/the-kafka-api-battle-producer-vs-consumer-vs-kafka-connect-vs-kafka-streams-vs-ksql-ef584274c1e

[easyfordev]

이지

• 읽으면서 어려운점은 없었습니다만...
• 역시 카프카 스트림즈처럼 Producer & Consumer 조합과 뭐가 다른가?가 가장 의문이 들었습니다.
  • 반복적인 파이프라인의 경우 값을 외부에서 설정 값으로 주입할 수 있다.는것이 장점인 것 같음
  • 오 코드를 최소화한다! 이게 특장점이구낭
  • 그래도 스트림즈보다는 훨~씬 와닿았다.
    • cf) 스트림즈 : 관심사의 분리를 위해서 사용한다. 로직 처리만을 쓰려고!
• Q. 그리고 분산모드 커넥트의 경우 커넥터를 실행하기 위해 설정하는 config 값을 json형태로 body에 넣어줘서 커넥터를 실행할 수 있다고 하는데...
  • 이거 다같이 운영한다는 관점에서 어떻게 이 config json 관리하는것인가?
  • REST API 말고 명령어로도 커넥터를 실행할 수 있는 것인가?
  • TODO 다음에 구글링해서 답을 알아오자 !!!!!