kafka mirrormaker 개요

Apache Kafka 클러스터 간 미러링 또는 복제 기술인 최신 버전의 MirrorMaker 2(MM2)에 대해 살펴봅니다. MirrorMaker 2는 안정성과 확장성을 높이기 위해 Kafka Connect 프레임워크 위에 구축되었으며 마이그레이션, 특수 목적 클러스터(예: 분석, 머신 러닝), 백업, 재해 복구 및 장애 조치, 격리, 집계/분산 또는 축적 파이프라인, 저지연, 엣지 컴퓨팅 및 비용 절감 등 보다 까다로운 지리적 복제 사용 사례에 적합합니다.

1. Replication—Then and Now

아파치 kafka는 기본적으로 분산 스트림 처리 시스템으로, 분산된 생산자가 분산된 카카 클러스터를 통해 분산된 소비자에게 메시지를 전송할 수 있도록 설계되었습니다(“아파치 카카에 대한 시각적 소개” 참조). 내부적으로는 로그 기반 스토리지, 데이터 파티셔닝, 수평적으로 확장 가능한 여러 노드, 리더에서 팔로워 파티션/노드로의 복제를 통해 성능, 확장성, 가용성, 내구성을 보장합니다.

따라서 기본적으로 Kafka 클러스터는 생산자에서 리더 노드로, 내부적으로 리더 노드에서 팔로워 노드로,
마지막으로 소비자 그룹 간에 추가 복제를 통해 소비자에게 메시지를 복제하는 등 여러 가지 방식으로 메시지를 복제합니다.
Kafka는 정확히 한 번만 전송하는 의미론을 지원하지만, 복제는 분명히 Kafka의 기본입니다.

레이턴시가 충분히 낮다면 단일 Kafka 클러스터도 여러 데이터 센터에 걸쳐 확장할 수 있습니다.
예를 들어, 일반적인 Instaclustr 관리형 Kafka 클러스터에는 가용성 향상을 위해 동일한 지역의 여러 AWS 가용성 영역(개별 데이터 센터)에 노드가 배포되어 있습니다.
최대 지연 시간이 100ms 미만인 경우, 여러 데이터 센터에 걸쳐 여러 지역에 걸쳐 “확장된” 클러스터로 실행할 수 있습니다.

그렇다면 단일 카프카 클러스터보다 나은 점은 무엇일까요? 바로 다중 클러스터입니다! 다중 클러스터 Kafka는 일반적인 배포 패턴입니다.
예를 들어, 넷플릭스는 팬아웃 아키텍처를 위한 멀티클러스터 Kafka 패턴을 선구적으로 도입했습니다.
또한 유연성, 가시성, 확장성을 향상시키기 위해 여러 개의 Kafka 클러스터에 배포된 토픽을 생성하고 소비하도록 Kafka 애플리케이션을 설계할 수 있습니다.
마지막으로, 데이터센터 간 복제, 집계 및 기타 복잡한 토폴로지를 통해 잠재적으로 서로 다른 데이터센터 및/또는 지역에서
여러 개의 Kaka 클러스터를 100ms 이상의 지연 시간으로 실행하려는 경우,
하나의 솔루션으로 MirrorMaker2를 사용할 수 있습니다.

MirrorMaker 2(MM2)는 한 Kafka 클러스터에서 다른 클러스터로 토픽을 쉽게 미러링하거나 복제할 수 있도록 설계되었습니다.
이 제품은 Kafka Connect 프레임워크를 사용해 구성(소스 및/또는 싱크 구성 속성)과 확장을 간소화합니다.
토픽의 변경 사항을 동적으로 감지하고 오프셋과 파티션을 포함해 소스 및 대상 토픽 속성이 동기화되도록 합니다.
토픽 이름 변경을 지원하여 더 복잡한 토폴로지와 양방향 흐름, 두 개 이상의 클러스터를 활성화하고 루프를 방지할 수 있습니다.
여러 클러스터에 걸친 복제 지연 시간을 포함한 엔드투엔드 메트릭을 제공합니다.
Kafka 클라이언트가 장애 조치 및 클러스터 변경(예: 재해 복구)을 더 쉽게 감지하고 대응할 수 있도록 오프셋과 오프셋 변환을 위한 도구를 제공합니다.

실제로 MM2의 주요 구성 요소는 다음과 같이 Kafka 커넥터입니다.

• MirrorSourceConnector는 로컬 클러스터에서 원격 클러스터로 레코드를 복제하고 오프셋 동기화를 활성화합니다
• MirrorCheckpointConnector는 소비자 오프셋 동기화를 관리하고, 체크포인트를 방출하며, 페일오버를 활성화합니다.
• 마지막으로, MirrorHeartbeatConnector는 하트비트, 복제 흐름 모니터링, 복제 토폴로지의 클라이언트 검색(원래 MirrorMaker보다 더 복잡할 수 있음)을 제공합니다.

MM2에 Kafka 커넥터를 사용하는 것은 영리한 아이디어입니다. 일반적인 Kafka 커넥터는 소스 또는 싱크 커넥터의 두 가지 유형으로 제공되며, 외부 시스템에서 Kafka 클러스터로 데이터를 유입하거나 유출할 수 있게 해줍니다. 하지만 MM2는 여러 Kafka 클러스터에서 작동하는데, 그렇다면 Kafka Connect는 어떻게 도움이 될까요? MM2 커넥터는 특별한 것으로 밝혀졌으며, 실제로 소비자(Kafka 소스 클러스터에서 읽기)와 생산자(Kafka 싱크 클러스터에 쓰기)라는 한 쌍의 Kafka 클라이언트가 함께 작동하는 것으로 나타났습니다.

따라서 MM2는 특히 지역 복제 등 보다 유연한 사용 사례, 확장성, 사용 편의성을 지원한다는 점에서 기존 MirrorMaker보다 크게 개선된 제품입니다.

• Source/primary/upstream topic/cluster: 레코드가 복제되는 위치(원본).
• Sink/target/destination/downstream topic/cluster : 레코드가 복제되는 위치(대상).
• Mirror flow: 소스 클러스터에서 대상 클러스터로 토픽의 단방향 복제
• Local/target cluster : Kafka 연결 클러스터의 경우, Kaka 클러스터가 직접 연결됩니다.
• Remote topic: 대상 클러스터의 토픽
• Remote cluster : Kafka 커넥터(소스/업스트림 클러스터)에서 사용하는 모든 비로컬 Kafka 클러스터.
• Active/active clusters: 이는 고가용성(HA) 아키텍처를 위한 데이터베이스 패턴이지만 MM2에도 적용할 수 있습니다. 각 클러스터는 쓰기와 읽기 모두에 사용하는 로컬 애플리케이션이 있다는 점에서 “활성”입니다. 그러나 클러스터 간에 데이터를 복제(양방향)하여 두 애플리케이션이 어느 클러스터에서 생성된 모든 메시지를 수신하도록 함으로써 HA를 보장합니다.
• Active/passive clusters: 이는 유사한 패턴이지만 한 번에 하나의 활성 애플리케이션/클러스터만 있습니다. 데이터는 활성 클러스터에서 수동 클러스터로 복제되며(단방향), 애플리케이션은 활성 클러스터에 장애가 발생한 경우에만 수동 클러스터로 전환됩니다. 이는 MM2의 이러한 패턴에 대한 좋은 설명입니다.

MM2의 경우, 패턴이 활성/활성 또는 활성/수동(또는 다른 것)인지는 흐름의 수, 흐름 방향, 복제된 토픽, 장애 조치를 위한 클라이언트 지원을 포함한 애플리케이션 설계 등의 조합에 따라 달라집니다. 즉, 액티브/액티브의 경우 동일한 토픽을 미러링하는 양방향의 두 개의 흐름이 있어야 하며, 미러링된 토픽을 사용하여 각 클러스터에서 실행되는 생산자와 소비자가 있는 애플리케이션이 있어야 합니다.

kafka mirrormaker 원칙

• rule 1 : 각 미러 흐름은 단일 대상 Kafka 클러스터와 연결된 Kafka Connect 클러스터에서 실행
  이 규칙은 단지 후속 규칙의 컨텍스트를 설정할 뿐입니다.
  MM2는 Kafka Connect 위에서 실행되기 때문입니다. 따라서 논리적으로 연결된 Kafka 대상 클러스터가 있는 Kafka Connect 클러스터가 필요합니다.

• rule 2 : 단방향 복사
  각 MM2 복제 흐름은 단방향이며 하나의 소스 클러스터에서 하나의 대상 클러스터로 주제를 복제합니다
  (예: 클러스터 A에서 클러스터 B로):

cluster_A → cluster_B

이것은 액티브/패시브 패턴에 필요한 기본 흐름입니다.
그러나 단순히 한 클러스터에서 다른 클러스터로 데이터가 공유되는 패턴에도 사용되며 두 클러스터에서 동시에 애플리케이션이 실행될 수 있습니다.

• rule 3 : 하나 이상의 토픽 복사
  각 MM2 복제 플로우는 하나 이상의 토픽을 복제하도록 구성할 수 있습니다.
  하나 이상의 토픽 이름을 지정하거나 모든 토픽을 포함하여 여러 토픽에 대한 정규식을 지정할 수 있습니다.

• rule 4 : 각 소스 토픽은 정확히 하나의 원격 토픽에 복제
  각 소스 토픽은 정확히 하나의 원격 토픽(대상 클러스터의 대상 토픽)에 복제됩니다. 레코드도 동일한 파티션에서/또는 동일한 파티션으로 복사됩니다.

• rule 5 : 자동 원격 토픽 생성
  소스 토픽이 대상 클러스터에 존재하지 않는 경우 동일한 구성(예: 파티션 수)으로 만들어집니다. 하지만 새 토픽의 이름은 무엇일까요?

• rule 6 : Multiple mirror flows
  여러 개의 MM2 미러 플로우를 사용할 수 있으므로 양방향 플로우를 포함하여 둘 이상의 클러스터 간에 복잡한 토폴로지를 구현할 수 있습니다.

Fan out (1 source cluster, multiple target clusters):

clusterA → clusterB
clusterA → clusterC

Fan in (aggregation, multiple source clusters to 1 target cluster):

clusterA → clusterC
clusterB → clusterC

Pipe (forwarding from 1 cluster to another and so on):

clusterA → clusterB → clusterC

Bidirectional

clusterA → clusterB
clusterB → clusterA

양방향 흐름은 활성/활성 패턴의 기초를 형성할 수 있지만, 이를 위해서는 동일한 토픽이 양방향으로 복제되어야 한다는 점에 유의하세요. 각 방향으로 서로 다른 토픽이 복제되는 경우 요청/응답과 같은 다른 패턴을 지원할 수 있습니다(즉, 클러스터A의 애플리케이션이 토픽에 대해 클러스터B에 메시지를 보내고 토픽에 대해 클러스터B로부터 결과를 포함한 응답을 클러스터A로 수신하는 경우).

Use Cases

Disaster Recovery Kafka는 고도로 분산되어 있고 높은 수준의 내결함성을 제공하지만, 재해는 여전히 발생할 수 있으며 데이터를 일시적으로 사용할 수 없거나 완전히 손실될 수 있습니다. 이러한 위험을 완화하는 가장 좋은 방법은 다른 데이터 센터의 다른 Kafka 클러스터에 데이터 사본을 보관하는 것입니다. MirrorMaker는 소비자 오프셋을 대상 클러스터로 변환하고 동기화합니다. 이렇게 하면 클라이언트를 비교적 원활하게 전환하여 서비스 중단이 거의 또는 전혀 없이 즉시 대체 배포로 이동할 수 있습니다.

Closer Read/Writes Kafka 생산자 클라이언트는 짧은 지연 시간을 달성하기 위해 로컬에 쓰는 것을 선호하는 경우가 많지만, 비즈니스 요구사항에 따라 데이터를 여러 지역에 배포된 여러 소비자가 읽어야 하는 경우가 많습니다. 이 경우 VPC 피어링으로 인해 배포가 쉽게 복잡해질 수 있습니다. MirrorMaker는 모든 복잡한 복제를 처리할 수 있으므로 로컬 메커니즘을 더 쉽게 쓰고 읽을 수 있습니다.

Data Analytics 집계는 또한 데이터 파이프라인의 한 요소로, 지역 Kafka 클러스터의 데이터를 하나의 클러스터로 통합해야 할 수도 있습니다. 그런 다음 이 집계 클러스터는 분석 및 시각화를 위해 해당 데이터를 다른 클러스터 및/또는 데이터 시스템으로 브로드캐스트합니다.

Supported Topologies

• Active/Passive or Active/Standby high availability deployments - (ClusterA => ClusterB)
• Active/Active HA Deployment - (ClusterA => ClusterB and ClusterB => ClusterA)
• Aggregation (e.g., from many clusters to one): (ClusterA => ClusterK, ClusterB => ClusterK, ClusterC => ClusterK)
• Fan-out (opposite of Aggregation): (ClusterK => ClusterA, ClusterK => ClusterB, ClusterK => ClusterC)
• Forwarding: (ClusterA => ClusterB, ClusterB => ClusterC, ClusterC => ClusterD)