지리적 복제

지리적 복제 (Geo-Replication, 교차 클러스터 데이터 미러링)

이 페이지는 MirrorMaker(버전 2)를 이용해 여러 Kafka 클러스터·데이터센터·지역 간에 데이터를 미러링하는 방법을 다뤄요. 재해 복구, 클러스터 간 데이터 공유, Active/Active HA 같은 시나리오에서 어떻게 복제 흐름(flow)을 정의하는지가 핵심이에요.

출처: 문서

본문

지리적 복제 개요 (Geo-Replication Overview)

Kafka 관리자는 개별 Kafka 클러스터, 데이터센터, 또는 지리적 지역의 경계를 넘는 데이터 흐름을 정의할 수 있습니다. 이러한 이벤트 스트리밍 설정은 조직적, 기술적, 법적 요구 사항으로 자주 필요합니다. 일반적인 시나리오는 다음과 같습니다.

  • 지리적 복제
  • 재해 복구
  • 에지 클러스터를 중앙 집계 클러스터로 공급
  • 클러스터의 물리적 격리(예: 프로덕션 vs 테스트)
  • 클라우드 마이그레이션 또는 하이브리드 클라우드 배포
  • 법적 및 규정 준수 요구 사항

관리자는 Kafka의 MirrorMaker(버전 2)로 이러한 클러스터 간 데이터 흐름을 설정할 수 있습니다. MirrorMaker는 서로 다른 Kafka 환경 간에 데이터를 스트리밍 방식으로 복제하는 도구입니다. MirrorMaker는 Kafka Connect 프레임워크 위에 구축되며 다음 기능을 지원합니다.

  • 토픽 복제(데이터와 구성)
  • 오프셋을 포함한 컨슈머 그룹 복제로 애플리케이션을 클러스터 간에 마이그레이션
  • ACL 복제
  • 파티셔닝 보존
  • 새 토픽과 파티션 자동 감지
  • 여러 데이터센터/클러스터에 걸친 종단 간 복제 지연시간 같은 광범위한 지표 제공
  • 장애 허용 및 수평 확장 가능한 운영

참고: MirrorMaker의 지리적 복제는 Kafka 클러스터 간에 데이터를 복제합니다. 이 클러스터 간 복제는 동일한 Kafka 클러스터 내에서 데이터를 복제하는 Kafka의 클러스터 내(intra-cluster) 복제와 다릅니다.

복제 흐름이란 (What Are Replication Flows)

MirrorMaker로 Kafka 관리자는 하나 이상의 소스 Kafka 클러스터에서 하나 이상의 대상 Kafka 클러스터로, 즉 클러스터 환경을 가로질러 토픽, 토픽 구성, 컨슈머 그룹과 그 오프셋, ACL을 복제할 수 있습니다. 요약하면 MirrorMaker는 커넥터를 사용해 소스 클러스터에서 소비(consume)하고 대상 클러스터에 생성(produce)합니다.

소스에서 대상 클러스터로 향하는 이러한 방향성 흐름을 복제 흐름(replication flow)이라고 합니다. 이들은 MirrorMaker 구성 파일에서 아래에 설명된 대로 {source_cluster}->{target_cluster} 형식으로 정의됩니다. 관리자는 이러한 흐름을 기반으로 복잡한 복제 토폴로지를 만들 수 있습니다.

다음은 몇 가지 예시 패턴입니다.

  • Active/Active 고가용성 배포: A->B, B->A
  • Active/Passive 또는 Active/Standby 고가용성 배포: A->B
  • 집계(예: 많은 클러스터에서 하나로): A->K, B->K, C->K
  • 팬아웃(예: 하나에서 많은 클러스터로): K->A, K->B, K->C
  • 전달: A->B, B->C, C->D

기본적으로 흐름은 (제외된 것을 제외한) 모든 토픽과 컨슈머 그룹을 복제합니다. 하지만 각 복제 흐름은 독립적으로 구성할 수 있습니다. 예를 들어 소스 클러스터에서 대상 클러스터로 특정 토픽이나 컨슈머 그룹만 복제하도록 정의할 수 있습니다.

주 클러스터에서 보조 클러스터로 데이터 복제를 구성하는 첫 번째 예시(active/passive 설정)는 다음과 같습니다.

# Basic settings
clusters = primary, secondary
primary.bootstrap.servers = broker3-primary:9092
secondary.bootstrap.servers = broker5-secondary:9092

# Define replication flows
primary->secondary.enabled = true
primary->secondary.topics = foobar-topic, quux-.*

지리적 복제 구성 (Configuring Geo-Replication)

다음 섹션에서는 전용 MirrorMaker 클러스터를 구성하고 실행하는 방법을 설명합니다. 기존 Kafka Connect 클러스터나 다른 지원되는 배포 설정에서 MirrorMaker를 실행하려면 KIP-382: MirrorMaker 2.0을 참고하고, 구성 설정의 이름이 배포 모드에 따라 달라질 수 있다는 점을 유의하세요.

다음 섹션에서 다루는 것 외에도 구성 설정에 대한 추가 예제와 정보는 다음에서 확인할 수 있습니다.

  • MirrorMakerConfig, MirrorConnectorConfig
  • 토픽용 DefaultTopicFilter, 컨슈머 그룹용 DefaultGroupFilter
  • connect-mirror-maker.properties의 예제 구성 설정, KIP-382: MirrorMaker 2.0

구성 파일 문법 (Configuration File Syntax)

MirrorMaker 구성 파일은 일반적으로 connect-mirror-maker.properties로 명명됩니다. 이 파일에서 다양한 컴포넌트를 구성할 수 있습니다.

  • MirrorMaker 설정: 클러스터 정의(별칭)를 포함한 전역 설정, 복제 흐름별 커스텀 설정
  • Kafka Connect 및 커넥터 설정
  • Kafka 프로듀서, 컨슈머, admin 클라이언트 설정

예: MirrorMaker 설정 정의(나중에 더 자세히 설명).

# Global settings
clusters = us-west, us-east   # defines cluster aliases
us-west.bootstrap.servers = broker3-west:9092
us-east.bootstrap.servers = broker5-east:9092

topics = .*   # all topics to be replicated by default

# Specific replication flow settings (here: flow from us-west to us-east)
us-west->us-east.enabled = true
us-west->us.east.topics = foo.*, bar.*  # override the default above

MirrorMaker는 Kafka Connect 프레임워크를 기반으로 합니다. Kafka Connect 문서 챕터에서 설명한 Kafka Connect, 소스 커넥터, 싱크 커넥터 설정은 구성 설정 이름을 바꾸거나 접두사를 붙일 필요 없이 MirrorMaker 구성에서 직접 사용할 수 있습니다.

예: MirrorMaker가 사용할 커스텀 Kafka Connect 설정 정의.

# Setting Kafka Connect defaults for MirrorMaker
tasks.max = 5

대부분의 기본 Kafka Connect 설정은 tasks.max를 제외하고 MirrorMaker에 그대로 잘 작동합니다. 하나 이상의 MirrorMaker 프로세스에 워크로드를 고르게 분산하려면 사용 가능한 하드웨어 리소스와 복제할 총 토픽-파티션 수에 따라 tasks.max를 최소 2(가능하면 더 높게)로 설정하는 것이 권장됩니다.

MirrorMaker의 Kafka Connect 설정을 소스 또는 대상 클러스터별로 추가로 커스터마이즈할 수 있습니다(더 정확히는 Kafka Connect 워커 수준 구성 설정을 "커넥터별"로 지정할 수 있습니다). MirrorMaker 구성 파일에서 {cluster}.{config_name} 형식을 사용하세요.

예: us-west 클러스터에 대한 커스텀 커넥터 설정 정의.

# us-west custom settings
us-west.offset.storage.topic = my-mirrormaker-offsets

MirrorMaker는 내부적으로 Kafka 프로듀서, 컨슈머, admin 클라이언트를 사용합니다. 이러한 클라이언트에 대한 커스텀 설정이 자주 필요합니다. 기본값을 오버라이드하려면 MirrorMaker 구성 파일에서 다음 형식을 사용하세요.

  • {source}.consumer.{consumer_config_name}
  • {target}.producer.{producer_config_name}
  • {source_or_target}.admin.{admin_config_name}

예: 커스텀 프로듀서, 컨슈머, admin 클라이언트 설정 정의.

# us-west cluster (from which to consume)
us-west.consumer.isolation.level = read_committed
us-west.admin.bootstrap.servers = broker57-primary:9092

# us-east cluster (to which to produce)
us-east.producer.compression.type = gzip
us-east.producer.buffer.memory = 32768
us-east.admin.bootstrap.servers = broker8-secondary:9092

정확히 한 번 (Exactly once)

전용 MirrorMaker 클러스터에 대한 정확히 한 번(exactly-once) 의미론은 3.5.0 버전부터 지원됩니다.

새 MirrorMaker 클러스터의 경우, 정확히 한 번 의미론으로 기록되어야 하는 모든 대상 Kafka 클러스터에 대해 exactly.once.source.support 속성을 enabled로 설정하세요. 예를 들어 us-east 클러스터에 대한 쓰기에 정확히 한 번을 활성화하려면 다음 구성을 사용할 수 있습니다.

us-east.exactly.once.source.support = enabled

기존 MirrorMaker 클러스터의 경우 2단계 업그레이드가 필요합니다. exactly.once.source.support 속성을 즉시 enabled로 설정하는 대신, 먼저 클러스터의 모든 노드에서 preparing으로 설정하세요. 이 단계가 완료되면 두 번째 재시작 라운드에서 클러스터의 모든 노드에서 enabled로 설정할 수 있습니다.

어느 경우든 KIP-710에 설명된 대로 MirrorMaker 노드 간 클러스터 내 통신을 활성화하는 것도 필요합니다. 이를 위해 dedicated.mode.enable.internal.rest 속성을 true로 설정해야 합니다. 또한 Kafka Connect에서 사용할 수 있는 많은 REST 관련 구성 속성을 MirrorMaker 구성에 지정할 수 있습니다. 예를 들어 각 노드가 로컬 머신의 8080 포트에서 리슨하는 MirrorMaker 클러스터에서 클러스터 내 통신을 활성화하려면 MirrorMaker 구성 파일에 다음을 추가해야 합니다.

dedicated.mode.enable.internal.rest = true
listeners = http://localhost:8080

참고: 프로덕션 환경에서 클러스터 내 통신을 활성화한다면 각 MirrorMaker 노드가 띄우는 REST 서버를 보호하는 것이 매우 권장됩니다. 이를 수행하는 방법은 Kafka Connect 구성 속성을 참고하세요.

또한 MirrorMaker를 실행할 때 복제된 데이터에서 중단된 트랜잭션의 레코드를 걸러내는 것이 권장됩니다. 이를 위해 소스 클러스터에서 읽는 데 사용되는 컨슈머가 isolation.level이 read_committed로 설정된 상태로 구성되었는지 확인하세요. us-west 클러스터에서 데이터를 복제한다면, 그 클러스터에서 읽는 모든 복제 흐름에 대해 다음을 MirrorMaker 구성 파일에 추가함으로써 수행할 수 있습니다.

us-west.consumer.isolation.level = read_committed

마지막 참고로, 내부적으로 MirrorMaker는 Kafka Connect 소스 커넥터를 사용해 데이터를 복제합니다. 이러한 종류의 커넥터에 대한 정확히 한 번 지원에 대한 자세한 내용은 관련 문서 페이지를 참고하세요.

복제 흐름 생성 및 활성화 (Creating and Enabling Replication Flows)

복제 흐름을 정의하려면 먼저 MirrorMaker 구성 파일에서 각각의 소스와 대상 Kafka 클러스터를 정의해야 합니다.

  • clusters(필수): 쉼표로 구분된 Kafka 클러스터 "별칭" 목록.
  • {clusterAlias}.bootstrap.servers(필수): 특정 클러스터의 연결 정보. "bootstrap" Kafka 브로커의 쉼표로 구분된 목록.

예: 연결 정보를 포함해 primary와 secondary 두 클러스터 별칭 정의.

clusters = primary, secondary
primary.bootstrap.servers = broker10-primary:9092,broker-11-primary:9092
secondary.bootstrap.servers = broker5-secondary:9092,broker6-secondary:9092

둘째, 필요에 따라 {source}->{target}.enabled = true로 개별 복제 흐름을 명시적으로 활성화해야 합니다. 흐름은 방향성이 있다는 것을 기억하세요. 양방향(bidirectional) 복제가 필요하면 양방향으로 흐름을 활성화해야 합니다.

# Enable replication from primary to secondary
primary->secondary.enabled = true

기본적으로 복제 흐름은 소스 클러스터에서 대상 클러스터로 몇몇 특수 토픽과 컨슈머 그룹을 제외한 모두를 복제하고, 새로 생성된 토픽과 그룹을 자동으로 감지합니다. 대상 클러스터에서 복제된 토픽의 이름은 소스 클러스터의 이름이 접두사로 붙습니다(아래 섹션 참고). 예를 들어 소스 클러스터 us-west의 토픽 foo는 대상 클러스터 us-east에서 us-west.foo라는 이름의 토픽으로 복제됩니다.

이후 섹션에서는 이 기본 설정을 요구에 맞게 커스터마이즈하는 방법을 설명합니다.

복제 흐름 구성 (Configuring Replication Flows)

복제 흐름의 구성은 최상위 기본 설정(예: topics)의 조합이며, 그 위에 흐름별 설정이 있으면 적용됩니다(예: us-west->us-east.topics). 최상위 기본값을 변경하려면 해당 최상위 설정을 MirrorMaker 구성 파일에 추가하세요. 특정 복제 흐름에 대해서만 기본값을 오버라이드하려면 {source}->{target}.{config.name} 구문을 사용하세요.

가장 중요한 설정은 다음과 같습니다.

  • topics: 복제할 소스 클러스터의 토픽을 정의하는 토픽 목록 또는 정규식(기본값: topics = .*).
  • topics.exclude: topics 설정이 일치시킨 토픽을 이후에 제외할 토픽 목록 또는 정규식(기본값: topics.exclude = .*[\-\.]internal, .*\.replica, __.*).
  • groups: 복제할 소스 클러스터의 컨슈머 그룹을 정의하는 목록 또는 정규식(기본값: groups = .*).
  • groups.exclude: groups 설정이 일치시킨 컨슈머 그룹을 이후에 제외할 목록 또는 정규식(기본값: groups.exclude = console-consumer-.*, connect-.*, __.*).
  • {source}->{target}.enable: true로 설정해 복제 흐름 활성화(기본값: false).

예:

# Custom top-level defaults that apply to all replication flows
topics = .*
groups = consumer-group1, consumer-group2

# Don't forget to enable a flow!
us-west->us-east.enabled = true

# Custom settings for specific replication flows
us-west->us-east.topics = foo.*
us-west->us-east.groups = bar.*
us-west->us-east.emit.heartbeats = false

추가 구성 설정이 지원되며 대부분의 경우 기본값으로 두면 됩니다. MirrorMaker Configs를 참고하세요.

복제 흐름 보안 (Securing Replication Flows)

MirrorMaker는 Kafka Connect와 동일한 보안 설정을 지원하므로 자세한 내용은 연결된 섹션을 참고하세요.

예: MirrorMaker와 us-east 클러스터 사이의 통신 암호화.

us-east.security.protocol=SSL
us-east.ssl.truststore.location=/path/to/truststore.jks
us-east.ssl.truststore.password=my-secret-password
us-east.ssl.keystore.location=/path/to/keystore.jks
us-east.ssl.keystore.password=my-secret-password
us-east.ssl.key.password=my-secret-password

대상 클러스터의 복제 토픽 커스텀 네이밍 (Custom Naming of Replicated Topics in Target Clusters)

대상 클러스터의 복제된 토픽(때로 remote topics라고 함)은 복제 정책(replication policy)에 따라 이름이 바뀝니다. MirrorMaker는 이 정책을 사용해 서로 다른 클러스터의 이벤트(일명 레코드, 메시지)가 동일한 토픽-파티션에 기록되지 않도록 보장합니다. 기본적으로 DefaultReplicationPolicy에 따라 대상 클러스터의 복제된 토픽 이름은 {source}.{source_topic_name} 형식입니다.

us-west         us-east
=========       =================
                bar-topic
foo-topic  -->  us-west.foo-topic

구분 문자(기본값: .)는 replication.policy.separator 설정으로 커스터마이즈할 수 있습니다.

# Defining a custom separator
us-west->us-east.replication.policy.separator = _

복제된 토픽의 이름 지정을 더 제어해야 한다면 커스텀 ReplicationPolicy를 구현하고 MirrorMaker 구성에서 replication.policy.class(기본값은 DefaultReplicationPolicy)를 오버라이드할 수 있습니다.

구성 충돌 방지 (Preventing Configuration Conflicts)

MirrorMaker 프로세스는 대상 Kafka 클러스터를 통해 구성을 공유합니다. 이 동작은 동일한 대상 클러스터에 대해 운영되는 MirrorMaker 프로세스 간 구성이 다를 때 충돌을 일으킬 수 있습니다.

예를 들어 다음 두 MirrorMaker 프로세스는 경쟁 상태(racy)가 될 수 있습니다.

# Configuration of process 1
A->B.enabled = true
A->B.topics = foo

# Configuration of process 2
A->B.enabled = true
A->B.topics = bar

이 경우 두 프로세스가 클러스터 B를 통해 구성을 공유하므로 충돌이 발생합니다. 두 프로세스 중 선출된 "리더"가 어느 쪽이냐에 따라 토픽 foo나 bar 중 하나는 복제되지만 둘 다는 아닌 결과가 됩니다.

따라서 동일한 대상 클러스터로의 복제 흐름에 걸쳐 MirrorMaker 구성을 일관되게 유지하는 것이 중요합니다. 이는 예를 들어 자동화 도구를 통하거나, 조직 전체에 단일 공유 MirrorMaker 구성 파일을 사용함으로써 달성할 수 있습니다.

모범 사례: 원격에서 소비, 로컬에 생성 (Best Practice: Consume from Remote, Produce to Local)

지연시간("producer lag")을 최소화하려면 MirrorMaker 프로세스를 데이터를 생성하는 대상 클러스터에 최대한 가깝게 배치하는 것이 권장됩니다. Kafka 프로듀서는 일반적으로 신뢰할 수 없거나 고지연인 네트워크 연결에서 Kafka 컨슈머보다 더 어려움을 겪기 때문입니다.

First DC          Second DC
==========        =========================
primary --------- MirrorMaker --> secondary
(remote)                           (local)

이러한 "원격에서 소비, 로컬에 생성" 설정을 실행하려면 MirrorMaker 프로세스를 대상 클러스터 근처에서, 가능하면 같은 위치에서 실행하고, --clusters 커맨드 라인 파라미터(공백으로 구분된 클러스터 별칭 목록)에 이러한 "로컬" 클러스터를 명시적으로 설정하세요.

# Run in secondary's data center, reading from the remote `primary` cluster
$ bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters secondary

--clusters secondary는 MirrorMaker 프로세스에게 주어진 클러스터(들)이 근처에 있다고 알리고, 다른 원격 위치의 클러스터에 데이터를 복제하거나 구성을 보내는 것을 방지해줍니다.

예: Active/Passive 고가용성 배포 (Example: Active/Passive High Availability Deployment)

다음 예제는 primary에서 secondary Kafka 환경으로 토픽을 복제하되, secondary에서 primary로는 복제하지 않는 기본 설정을 보여줍니다. 대부분의 프로덕션 설정에는 보안 설정 같은 추가 구성이 필요하다는 점을 유의하세요.

# Unidirectional flow (one-way) from primary to secondary cluster
primary.bootstrap.servers = broker1-primary:9092
secondary.bootstrap.servers = broker2-secondary:9092

primary->secondary.enabled = true
secondary->primary.enabled = false

primary->secondary.topics = foo.*  # only replicate some topics

예: Active/Active 고가용성 배포 (Example: Active/Active High Availability Deployment)

다음 예제는 두 클러스터 사이에서 양방향으로 토픽을 복제하는 기본 설정을 보여줍니다. 대부분의 프로덕션 설정에는 보안 설정 같은 추가 구성이 필요하다는 점을 유의하세요.

# Bidirectional flow (two-way) between us-west and us-east clusters
clusters = us-west, us-east
us-west.bootstrap.servers = broker1-west:9092,broker2-west:9092
Us-east.bootstrap.servers = broker3-east:9092,broker4-east:9092

us-west->us-east.enabled = true
us-east->us-west.enabled = true

복제 "루프" 방지에 대한 참고(토픽이 원래 A에서 B로 복제된 다음, 복제된 토픽이 다시 B에서 A로 복제되는 식): 위 흐름을 동일한 MirrorMaker 구성 파일에 정의하는 한, 두 클러스터 간 복제 루프를 방지하기 위해 topics.exclude 설정을 명시적으로 추가할 필요가 없습니다.

예: 다중 클러스터 지리적 복제 (Example: Multi-Cluster Geo-Replication)

이전 섹션의 모든 정보를 더 큰 예제에 함께 넣어 봅시다. 각 데이터센터에 두 개의 Kafka 클러스터(예: west-1, west-2)가 있는 세 개의 데이터센터(west, east, north)가 있다고 상상해 보세요. 이 섹션의 예제는 (1) 각 데이터센터 내 Active/Active 복제와 (2) 교차 데이터센터 복제(XDCR)에 대해 MirrorMaker를 구성하는 방법을 보여줍니다.

먼저 구성에서 소스·대상 클러스터와 그 복제 흐름을 정의합니다.

# Basic settings
clusters: west-1, west-2, east-1, east-2, north-1, north-2
west-1.bootstrap.servers = ...
west-2.bootstrap.servers = ...
east-1.bootstrap.servers = ...
east-2.bootstrap.servers = ...
north-1.bootstrap.servers = ...
north-2.bootstrap.servers = ...

# Replication flows for Active/Active in West DC
west-1->west-2.enabled = true
west-2->west-1.enabled = true

# Replication flows for Active/Active in East DC
east-1->east-2.enabled = true
east-2->east-1.enabled = true

# Replication flows for Active/Active in North DC
north-1->north-2.enabled = true
north-2->north-1.enabled = true

# Replication flows for XDCR via west-1, east-1, north-1
west-1->east-1.enabled  = true
west-1->north-1.enabled = true
east-1->west-1.enabled  = true
east-1->north-1.enabled = true
north-1->west-1.enabled = true
north-1->east-1.enabled = true

그런 다음 각 데이터센터에서 하나 이상의 MirrorMaker를 다음과 같이 실행합니다.

# In West DC:
$ bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters west-1 west-2

# In East DC:
$ bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters east-1 east-2

# In North DC:
$ bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters north-1 north-2

이 구성으로 어떤 클러스터에 생성된 레코드든 데이터센터 내에서, 그리고 다른 데이터센터로도 복제됩니다. --clusters 파라미터를 제공함으로써 각 MirrorMaker 프로세스가 근처 클러스터에만 데이터를 생성하도록 보장합니다.

참고: --clusters 파라미터는 기술적으로 여기서 필수가 아닙니다. MirrorMaker는 그것 없이도 잘 작동합니다. 그러나 데이터센터 간 "producer lag"로 처리량이 저하되고 불필요한 데이터 전송 비용이 발생할 수 있습니다.

지리적 복제 시작 (Starting Geo-Replication)

필요한 만큼 적거나 많은 MirrorMaker 프로세스(노드, 서버)를 실행할 수 있습니다. MirrorMaker는 Kafka Connect를 기반으로 하므로, 동일한 Kafka 클러스터를 복제하도록 구성된 MirrorMaker 프로세스들은 분산 설정으로 실행됩니다. 서로를 찾고, 구성을 공유하고(아래 섹션 참고), 작업을 로드 밸런싱하는 등입니다. 예를 들어 복제 흐름의 처리량을 높이려면 추가 MirrorMaker 프로세스를 병렬로 실행하는 것이 한 가지 옵션입니다.

MirrorMaker 프로세스를 시작하려면 다음 명령을 실행하세요.

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

시작 후 MirrorMaker 프로세스가 처음으로 데이터 복제를 시작하기까지 몇 분이 걸릴 수 있습니다.

선택적으로 앞서 설명한 대로 --clusters 파라미터를 설정해 MirrorMaker 프로세스가 근처 클러스터에만 데이터를 생성하도록 할 수 있습니다.

# Note: The cluster alias us-west must be defined in the configuration file
$ bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters us-west

컨슈머 그룹 복제를 테스트할 때 유의: 기본적으로 MirrorMaker는 kafka-console-consumer.sh 도구로 만든 컨슈머 그룹을 복제하지 않습니다. 커맨드 라인에서 MirrorMaker 설정을 테스트하는 데 이 도구를 사용할 수 있기 때문입니다. 이러한 컨슈머 그룹도 복제하려면 groups.exclude 구성을 그에 맞게 설정하세요(기본값: groups.exclude = console-consumer-.*, connect-.*, __.*). 테스트를 마친 후 구성을 다시 업데이트하는 것을 잊지 마세요.

지리적 복제 중지 (Stopping Geo-Replication)

다음 명령으로 SIGTERM 신호를 보내 실행 중인 MirrorMaker 프로세스를 중지할 수 있습니다.

$ kill <MirrorMaker pid>

구성 변경 적용 (Applying Configuration Changes)

구성 변경을 적용하려면 MirrorMaker 프로세스(들)를 재시작해야 합니다.

지리적 복제 모니터링 (Monitoring Geo-Replication)

모든 정의된 복제 흐름이 올바르게 실행 중인지 확인하기 위해 MirrorMaker 프로세스를 모니터링하는 것이 권장됩니다. MirrorMaker는 Connect 프레임워크 위에 구축되며 source-record-poll-rate 같은 Connect의 모든 지표를 상속합니다. 또한 MirrorMaker는 kafka.connect.mirror 지표 그룹 아래에서 자체 지표를 생성합니다. 지표는 다음 속성으로 태그됩니다.

  • source: 소스 클러스터의 별칭(예: primary).
  • target: 대상 클러스터의 별칭(예: secondary).
  • topic: 대상 클러스터의 복제된 토픽.
  • partition: 복제되는 파티션.

지표는 각 복제된 토픽에 대해 추적됩니다. 소스 클러스터는 토픽 이름에서 추론할 수 있습니다. 예를 들어 primary->secondary로 topic1을 복제하면 다음과 같은 지표가 생성됩니다.

  • target=secondary
  • topic=primary.topic1
  • partition=1

다음 지표가 생성됩니다.

# MBean: kafka.connect.mirror:type=MirrorSourceConnector,target=([-.w]+),topic=([-.w]+),partition=([0-9]+)
record-count            # number of records replicated source -> target
record-rate             # average number of records/sec in replicated records
record-age-ms           # age of records when they are replicated
record-age-ms-min
record-age-ms-max
record-age-ms-avg
replication-latency-ms  # time it takes records to propagate source->target
replication-latency-ms-min
replication-latency-ms-max
replication-latency-ms-avg
byte-rate               # average number of bytes/sec in replicated records
byte-count              # number of bytes replicated source -> target

# MBean: kafka.connect.mirror:type=MirrorCheckpointConnector,source=([-.w]+),target=([-.w]+),group=([-.w]+),topic=([-.w]+),partition=([0-9]+)

checkpoint-latency-ms   # time it takes to replicate consumer offsets
checkpoint-latency-ms-min
checkpoint-latency-ms-max
checkpoint-latency-ms-avg

이 지표들은 생성 시점(created-at)과 로그 추가(log-append) 타임스탬프를 구분하지 않습니다.

더 알아보기 (Learn more)

  • 복제 흐름은 방향성이 있으니 양방향이 필요하면 양쪽을 모두 활성화해야 해요.
  • 대상 클러스터의 복제 토픽은 {source}.{topic} 형식으로 이름이 붙어요.
  • --clusters 파라미터로 MirrorMaker를 대상 근처에 배치하면 지연시간을 줄일 수 있어요.