Kafka 입문 (4)

10강. Apache Kafka Connect

 

https://youtu.be/UURmOj6Eaoo

반복적인 데이터 파이프라인을 효과적으로 배포/관리하는 방법으로 카프카 커넥터를 사용한다.

카프카 커넥트는 공식 컴포넌트다. 공식이라고 들이미는 것 자체가 나름 비중이 있다는 것이겠지?

 

카프카 커넥트는 커넥트(Connect)와 커넥터(Connector)로 이루어져 있다. 대충 비슷해 보이지만 다른 개념이니 주의.

 

Connector

-> 실질적으로 데이터를 처리하는 코드가 담긴 jar 패키지.

-> 템플릿처럼 특정 동작을 하는 코드 뭉치

-> 파이프라인에 필요한 여러 동작/설정/메서드 등이 포함되어 있다.

예시) 토픽에서 오라클 DB에 데이터를 저장하고 싶다

-> 커넥터에 INSERT 메서드를 구현하고 커넥터 실행

 

커넥터는 Sink Connector와 Source Connector로 이루어져 있다.

싱크 커넥터는 특정 토픽에 있는 데이터를 특정 저장소(오라클, MySQL, ElasticSearch 등)에 저장하는 역할을 한다.

-> 컨슈머와 같은 역할

소스 커넥터는 DB로부터 데이터를 가져와서 토픽에 넣는 역할을 한다.

-> 프로듀서 역할

예시) 토픽의 데이터를 오라클의 특정 테이블에 넣고 싶다

-> 싱크 커넥터 사용

 

Connect

-> 커넥터를 동작하도록 실행해주는 프로세서. 파이프라인으로 동작하는 커넥터를 동작하려면 커넥트를 실행시켜야 한다.

 

커넥트는 단일 실행 모드 커넥트와 분산 모드 커넥트로 이루어져 있다.

-> 단일 실행 모드 커넥트는 간단한 데이터 파이프라인 구성이나 개발용으로 주로 사용한다.

-> 실질적으로 상용에 사용하려면 분산 모드 커넥트를 사용한다.

 

분산 모드 커넥트는 여러 개의 프로세스를 한 개의 클러스터로 묶어서 운영하는 방식.

-> 2개 이상의 커넥트가 하나의 클러스터 구성 : 일부 커넥트에 장애가 발생해도 파이프라인 failover 가능

 

커넥트를 실행할 때, 커넥터가 어디에 위치하는지 config 파일에 위치를 지정해야 한다.

-> 커넥터 jar 패키지가 있는 디렉터리를 config 파일에 지정

-> 커넥트 실행 시 jar 파일의 커넥터들을 모아 커넥터를 실행할 수 있도록 준비 상태에 돌입

 

실행 중인 커넥트에서 커넥터를 실행하려면 REST API를 통해 커넥터 실행

 

커넥트를 활용하면 파이프라인 구성 시 추가적인 개발 및 배포가 필요 없다.

-> 파이프라인을 만들 때 REST API를 통해 커넥터를 통한 파이프라인들이 분산해서 생성된다.

 

 

echo `
{
	"name" : "my-first-pipeline",
    "config" : {
    	"connector.class" : "com.dvwy.OracleSinkConnector",
        "connection.url" : "jdbc:oracle://localhost:3306/mydb",
        "topics" : "my-test-topic",
        "table" : "my-first-stream-table"
	}
}
` | curl -X POST -d @- http://localhost:8083/connectors --header "content-Type:application/json"

예시) 오라클에 데이터를 저장하는 OracleSinkConnector가 있다.

-> 특정 토픽의 데이터를 특정 테이블로 보내기 : JSON으로 설정을 만들고, 해당 body를 REST API를 통해 커넥트에 명령

-> 커넥트에 파이프라인 생성

-> 동일한 토픽의 데이터를 다른 테이블로 보내기 : 똑같이 JSON으로 설정을 만들고 타겟 토픽/싱크 테이블 이름만 수정

 

반복적인 개발, 배포, 모니터링 구축 등의 일련의 과정을 효율적으로 반복 가능

오픈소스로 공개된 자료가 많아 활용이 쉽다

---

??강. Confluent, AWS MSK 간단 비교

 

Confluent는 링크드인에서 카프카를 개발한 개발자들이 나와서 만든 기업이다. 주로 카프카의 프리미엄 버전을 제공한다.

설치형, SaaS형 아파치 카프카를 제공하고 있다. 또한 카프카는 자바 클라이언트로만 제공되는데 컨플루언트는 다른 언어용 클라이언트도 제공하고 있다.

그리고 카프카의 개발자들이 만든 회사라 그런지 지속적으로 구조 개선을 이루어나가고 있다. 가장 단적인 예시가 zookeeper를 벗어나려는 시도다. 

-> https://www.ciokorea.com/news/235594

아파치 카프카, ‘주키퍼(ZooKeeper)’ 제거한다

※ 컨플루언트 카프카에서 이러한 변화가 이루어진다는 것이 아니라, 컨플루언트에서 근무하는 개발자들이 이러한 변화를 주도하고 있다는 의미

 

컨플루언트는 카프카를 클라우드 형태로도 제공하는데, MongoDB Atlas처럼 어떤 클라우드를 선택할지의 설정 등을 웹 콘솔에서 지정할 수 있다.

 

 

MSK는 AWS의 관리형 서비스다. 

주키퍼를 관리해주고, 별도의 모니터링 솔루션 없이도 CloudWatch로 모니터링이 가능하다.

또한 다양한 설정을 콘솔에서 할 수 있어 러닝커브가 적다고 한다(그런가?)

하지만 MSK는 확장성에 제한이 있다.

-> https://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/limits.html

Amazon MSK 할당량 - Amazon Managed Streaming for Apache Kafka

-> MSK 서버리스의 경우 할당량이 더 빡빡해 보인다.

-> 브로커 인스턴스 유형에 따라 파티션 수 제한 : https://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/bestpractices.html#partitions-per-broker

모범 사례 - Amazon Managed Streaming for Apache Kafka

---

데브원영 님의 동영상 중 Confluent와 MSK를 설명한 부분은 나중에 추가 예정.

여기까지가 내 기준에서 Kafka 기초다. 이후 내용은 실습 내용 작성 예정.