3.7 카프카 미러메이커2

카프카 미러메이커2

• 서로 다른 두 개의 카프카 클러스터 간에 토픽을 복제하는 애플리케이션

• 사용하는 이유는 토픽의 모든 것을 복제할 필요성이 있기 때문 ex) → 고유한 메시지 키, 메시지 값, 파티션, ... → 동일한 파티션에 동일한 레코드가 들어가는것

• 분산 모드 커넥트를 운영하는 경우 커넥트에서 미러메이커2를 사용하여 토픽을 복제할 수 있다.

• 단방향 복제, 양방향 복제, ACL 복제, 새 토픽 자동 감지, 등의 기능

미러메이커1

• 레거시 버전의 미러메이커

• 토픽 복제의 충분한 기능을 가지고 있지 않다. ex) → 복제된 데이터의 파티션 정보가 다르다. → 복제하는 토픽이 변경되면 재시작이 필요했다. → exactly once delivery를 보장하지 못했다. → 클러스터의 양방향 토픽 복제가 지원되지 않았다.

• 2019년 말 카프카 2.4.0 출시와 함께 미러메이커2가 출시 되었다.

단방향 토픽 복제

• 카프카 바이너리 디렉토리의 config/connect-mirror-maker.properties 파일을 수정

/**
	* 복제할 클러스터의 닉네임 작성
	* 토픽이 복제될 때 접두사(prefix)로 붙게 된다.
	* ex) A -> B 인 경우 A.click_log로 토픽이 생성
	* 복제된 토픽이 어디에 위치하는지 명확히 제시하는 클러스터 이름으로 작성
	*/
clusters = A, B

// 클러스터 접속 정보
A.bootstrap.servers = a-kafka:9092
B.bootstrap.servers = b-kafka:9092

// 클러스터 A에서 클러스터 B로 test 토픽을 복제
A->B.enabled = true
A->B.topics = test

// 복제 X
B->A.enabled = false
B->A.topics = .*

// 복제되어 신규 생성된 토픽의 복제 개수
replication.factor=1

// 토픽 복제에 필요한 데이터를 저장하는 내부 토픽의 복제 개수
checkpoints.topic.replication.factor=1
heartbeats.topic.replication.factor=1
offset-syncs.topic.replication.factor=1
offset.storage.replication.factor=1
status.storage.replication.factor=1
config.storage.replication.factor=1

실행

$ bin/connect-mirror-maker.sh config/connect-mirror-maker.properties

지리적 복제(Geo-Replication)

액티브 -스탠바이(Active-standby) 클러스터 운영

• 서비스 애플리케이션들과 통신하는 카프카 클러스터 외에 재해 복구를 위해 임시 카프카 클러스터를 하나 더 구성하는 운영 방식

• ex) 한국의 데이터 센터(액티브)에서 일본의 데이터 센터(스텐바이)로 미러 메이커를 통한 복제 → 단방향 복제

액티브-액티브(Active-active) 클러스터 운영

• 글로벌 서비스를 운영할 경우 서비스 애플리케이션의 통신 지연을 최소화하기 위해 2개 이상의 클러스터를 두고 서로 데이터를 미러링하면서 사용하는 운영 방식

• ex) 한국과 영국의 유저 데이터를 각 지역의 운영중인 클러스터로 복제를 통해 지연을 줄인다. → 양방향 복제

허브 앤 스포크(Hub and spoke) 클러스터 운영

• 각 팀에서 소규모 카프카 클러스터를 사용하고 있을 때 각 팀의 카프카 클러스터의 데이터를 한개의 카프카 클러스터에 모아 데이터 레이크로 사용하는 운영 방식

• ex) 주문, 배송, 구매, 회원, 장바구니 등등의 데이터를 한 곳의 데이터 레이크에 복제 → 단방향 복제 or 양방향 복제(특정팀에서 필요한 다른팀의 데이터를 Consume)