클러스터간 데이터 미러링하기

uchan·2026년 1월 8일
kafka

10. 클러스터간 데이터 미러링하기

10.1 클러스터간 미러링 활용 사례

지역 및 중앙 클러스터, 국가별 규제, 고가용성 및 재해복구 등의 이유로 단일 클러스터보다 다중 클러스터 아키텍쳐로 서비스를 해야되는 상황이 존재한다. 이때 클러스터간 데이터 싱크, 마이그레이션이 이루어 지는데, 카프카 클러스터간 데이터 복제를 미러링이라 하며, 이를 수행하는 툴은 미러메이커라고 한다. (카프카 노드 간 데이터 복사 행위는 복제라고 한다)

10.2 다중 클러스터 아키텍쳐

10.2.1 데이터 센터간 현실적 문제들

데이터 센터 간 통신을 하게 될 때 고려해야 할 사항들이 몇가지 있다.

1. 높은 지연: 클러스터 간 거리나 네트워크 홉 개수가 증가함에 따라 통신지연이 발생한다

네트워크 홉(Hop)이란?
데이터 패킷이 출발지에서 목적지까지 가는 동안 거쳐가는 라우터(Router)나 스위치(Switch)와 같은 중간 네트워크 장비의 수

2. 제한된 대역폭

광역 통신망은 일반적으로 단일 데이터센터 내부보다 훨씬 낮은 대역폭을 가지며, 사용 가능한 대역폭 역시 시시각각 변한다.

3. 더 높은 비용

클러스터가 많을 수록 클러스터 간 통신이 증가하며 서로 다른 데이터센터, 리전, 클라우드 간 데이터를 통신하기 때문에 많은 비용이 발생한다.

아파치 카프카의 브로커와 클라이언트는 하나의 데이터 센터 안에서 실행되도록 설계, 개발, 테스트, 조정되었다. 대부분의 경우 원격 데이터 센터에 데이터를 쓰는 것은 피하는게 좋다.
만약 통신이 단절되었을 때 컨슈머 어플리케이션은 브로커로부터 읽어올 수 없지만 브로커 내부에 데이터가 저장된다. 만약 복구된 후, 브로커로부터 컨슈머가 읽어올 때 다른 데이터센터에 있다면 광역통신망을 통해 여러번 읽어와야한다. 이것보다는 차라리 같은 데이터 센터에 데이터 미러링을 하여 클러스터 복제한 후 컨슈머가 읽는 것이 낫다.

앞으로 소개할 아키텍쳐 대부분에 해당하는 원칙은 다음과 같다.

  • 하나의 데이터센터 당 한 개 이상의 클러스터 설치
  • 각각의 데이터센터 간의 각각의 이벤트를 정확히 한 번 씩 복제한다.
  • 가능하면, 원격 데이터 센터에 쓰는 것보다 읽어오기만 하는 것이 낫다.

10.2.2 허브-앤-스포크 아키텍쳐

여러 개의 로컬 카프카 클러스터와 한개의 중앙 카프카 클러스터가 있는 구조로서 항상 로컬 데이터 센터에서 데이터를 생성하고 중앙 데이터 센터에 단 한번만 미러링이 된다.

   [DC A: Local Kafka]      [DC B: Local Kafka]      [DC C: Local Kafka]
           |                        |                        |
           | NYC->CENTRAL           | LON->CENTRAL           | SF->CENTRAL
           v                        v                        v
                    -------------------------------
                    |      CENTRAL Kafka Cluster   |
                    -------------------------------
                    (전역 컨슈머는 중앙에서 전체 데이터 소비)

해당 아키텍쳐는 데이터가 여러 개의 데이터 센터에서 생성되는 반면, 일부 컨슈머는 전체 데이터를 사용해야 할 경우 사용된다. 각 로컬에 있는 컨슈머는 자기 로컬 내 데이터에만 접근이 가능하다. 만약 모든 클러스터에서 생성된 데이터를 사용해야한다면 중앙에 있는 클러스터로부터 데이터를 읽어오면 된다.

10.2.3 액티브-액티브 아키텍쳐

2개 이상의 데이터 센터가 전체 데이터의 일부 혹은 전체를 공유하면서, 각 데이터 센터가 모두 읽기와 쓰기를 수행할 수 있어야할 때 사용된다.

   -----------------------           -----------------------
   |  DC A: Kafka Cluster | <=====>  |  DC B: Kafka Cluster |
   -----------------------           -----------------------

이 아키텍쳐의 주된 장점은 인근 데이터 센터에서 사용자들의 요청을 처리할 수 있다는 점이다. 허브-앤-스포크 아키텍쳐는 사용할 수 데이터가 제한되어있지만(로컬에서), 액티브-액티브 아키텍쳐는 이러한 제한이 없고 성능상으로도 이점이 있다. 또한 여러 개의 데이터 센터에서 액티브 서버가 운영되기 때문에 데이터 중복과 회복 탄력성 측면에서도 이점이 있다.

그러나 해당 아키텍쳐는 데이터에 대한 경쟁상태로 인해 충돌이 발생할 수 있다. (예를 들어, 비동기적으로 읽거나 변경할 경우로서, A 에서 데이터를 보냈지만 B 에서는 아직 도착하지 않아 오류가 발생하는 경우)
또한 같은 데이터가 클러스터 사이를 오가면서 끊없이 순환 미러링되는 경우가 발생할 수 있다.

간단한 예시

  • A에서 orders를 B로 복제, B는 eu.orders로 저장.
  • B 커넥터가 eu.orders도 패턴에 포함해 다시 A로 복제 → A에 us.eu.orders 생성.
  • A 커넥터가 us.eu.orders를 다시 B로 복제 → B에 eu.us.eu.orders…

이를 방지하기 위해 B 커넥터가 eu. 를 보고서 더이상 보내지 않도록 막는 네이밍 컨벤션 방법 등이 있다.

10.2.4 액티브-스탠바이 아키텍처

액티브-스탠바이 아키텍처는 액티브-액티브 아키텍처와 달리 나머지 하나를 미러링만 하고 준비상태로만 두는 구조이다. 이는 재해 상황 등에서 액티브 서버가 죽었을 때 SRE 팀에서는 준비해둔 스탠바이 서버를 동작시킴으로써 빠르게 복구할 수 있는 구조이다.

재해 상황 시 SRE 팀에서는 빠르게 복구하기 위해 다음과 같이 준비한다.

  1. 재해 복구 계획하기
    RTO(복구 시간 목표), RPO(복구 지점 목표)를 계획한다. 자동화된 장애 복구에서는 RTO 가 낮은 수준으로 측정될 것이며, 실시간으로 미러링이 이루어진다면 RPO 또한 낮은 수준으로 측정될 것이다.

  2. 데이터 유실과 불일치
    데이터 미러링하는(비동기적으로) 과정에서 프로덕션 클러스터보다 DR(재해복구) 클러스터가 뒤쳐진다. 따라서 얼마나 뒤쳐지는지 모니터링해야한다. 또한 예상치 못한 장애 발생 시 데이터 유실이 발생할 수 있음을 명심해야한다.

  3. 장애복구 이후 어플리케이션 시작 오프셋
    DR 클러스터로 이동한 뒤 어느 시점으로 읽어올지 결정해야한다. 어디서부터 읽느냐에 따라 중복을 최소화하고 또는 유실을 최소화할 수 있다. 추가로 이 경우 특별히 시간을 기준으로 하는 경우도 있고, 오프셋 변환할 때 주 클러스터와 DR 클러스터 간 오프셋이 어긋난 점을 고려하여 복구하는 경우도 있다.

  4. 장애 복구가 끝난 뒤
    DR 클러스터가 주 클러스터가 된 후 새로운 클러스터(또는 예전 주 클러스터)로 데이터 미러링을 시작한다. 이때 미러링을 어디서부터 시작해야될 지 난감할 수 있다. 이럴 때는 이전에 저장된 데이터 및 커밋된 오프셋을 다 날려버리고 새로 위임된 주 클러스터로부터 새로 받는 것이 나을 수 있다.

  5. 클러스터 디스커버리 관련
    이제 DR 클러스터 -> 주 클러스터로 바뀌었으니 이전 프로듀서, 컨슈머는 새로운 클러스터와 연결해야한다. 만약 프로듀서, 컨슈머 어플리케이션에 클러스터 호스트를 하드코딩했다면 이것은 어려운 일이 될 것이다.

10.2.5 스트레치 클러스터

액티브-스탠바이 아키텍쳐는 카프카 클러스터에 장애가 났을 때 다른 클러스터로 옮겨서 어플리케이션들이 통신할 수 있도록 하는 아키텍쳐다. 만약 데이터 센터 전체에 문제가 발생했을 때는 어떻게 해야할까? 이때 사용하는 것이 스트레치 클러스터다.

하나의 카프카 클러스터를 여러 개의 데이터 센터에 걸쳐 설치한다. 즉, 다중 클러스터가 아니고 단지 하나의 클러스터이다. 복제 매커니즘 또한 카프카 브로커들이 서로 동기화된 상태로 유지시키는 방법이다. 따라서 각각의 파티션이 하나 이상의 데이터센터에 분산해서 레플리카를 저장하도록 랙 설정을 정의해주고, min.insync.replicase 설정을 잡아주고, acks 설정을 all 로 잡아줌으로써 각각의 쓰기 작업이 최소 두 개의 데이터센터에서 성공한 다음에야 응답이 가도록 한다. 즉, 동기적인 복제이다.
이 기능을 사용할 경우, 브로커는 컨슈머의 랙 설정과 자신의 랙 설정을 맞춰본 뒤 로컬 레플리카가 최신 상태인지 확인하고 로컬 데이터센터로부터 데이터를 읽어오기 때문에 데이터 센터가 통신도 줄일 수 있다.

그러나 이 방법은 말그대로 하나의 클러스터를 의미하기 때문에 어플리케이션이나 카프카에 장애가 발생하면 복구하기 힘들다.

10.3 아파치 카프카의 미러메이커

아파치 카프카는 두 데이터센터 간의 데이터 미러링을 위해 미러메이커라 불리는 툴을 포함한다. 초기 미러메이커는 단순하게 컨슈머로 복제할 토픽을 읽은 뒤 프로듀서로 목적 클러스터에 데이터를 보낸 반면, 2.0부터는 카프카 커넥트 프레임워크 기반으로 개발하여 이전 단점들을 극복하였다.

미러메이커에서 각각의 태스크는 한 쌍의 컨슈머(소스 커넥터)와 프로듀서로 이루어져 있다. 그리고 카프카의 컨슈머 그룹 관리 프로토콜을 사용하지 않고 태스크에 파티션을 균등하게 배분함으로써 파티션-컨슈머 리밸런싱이 발생하지 않아 지연이 튀어오르는 상황을 방지한다.

그리고 미러메이커는 단순히 데이터 복제 뿐만 아니라 컨슈머 오프셋, 토픽 설정, 토픽 ACL 마이그레이션까지 지원하기에 자동 클러스터 배치에 필요한 오나전한 기능을 갖춘 미러링 솔루션이라 할 수 있다.

10.3.1 미러메이커 설정하기

미러메이커의 설정값을 살펴보자. 데이터 센터가 뉴욕과 런던에 위치해 있다 가정하자.

clsuters = NYC, LON # 클러스터 별칭 정의
NYC.bootstrap.servers = kafka.nyc.example.com:9092
LON.bootstrap.servers = kafka.lon.example.com:9092 # 각 클러스터에 대한 부트스트랩 서버 지정
NYC->LON.enabled = true # source -> target 형태로 복제 흐름을 활성화시킨다.
NYC->LON.topics = .* # 복제 흐름에서 미러링되는 토픽들을 지정한다. 만약 프로덕션 토픽만 복제하고 싶다면 prod.* 와 같이 넣으면 된다.
  • NYC, LON 과 같이 별칭을 부여함으로써 로컬 토픽과 원격 토픽 간 구분을 지어 무한히 순환 복제되는 사태를 방지한다.
  • 또한 컨슈머 오프셋 마이그레이션도 진행되어 장애 발생 시 DR 클러스터에서 별도 마이그레이션 없이 주 클러스터의 커밋 지점에 해당하는 오프셋 지점부터 작업을 재개할 수 있다.
  • 그 외에도 토픽 설정 및 ACL 마이그레이션, 미러메이커 내 커넥터 태스크 개수 조정 등을 설정할 수 있다.

10.3.2 다중 클러스터 토폴로지

다중으로 데이터 미러링하는 경우가 존재한다. 위 예시에서 NYC -> LON 뿐만 아니라 반대 방향으로도 복제하여, 즉 양방향으로 복제 흐름을 활성화하였다 가정하자. (액티브-액티브 토폴로지)
이 경우에도 원격 토픽 앞에 클러스터 별칭을 붙임으로써 동일한 이벤트가 순환 복제되는 것을 방지한다.

clsuters = NYC, LON
NYC.bootstrap.servers = kafka.nyc.example.com:9092
LON.bootstrap.servers = kafka.lon.example.com:9092
NYC->LON.enabled = true
NYC->LON.topics = .*
LON->NYC.enabled = true
LON->NYC.topics = .*

위와 같이 설정하면 NYC <-> LON 간 양방향으로 복제 흐름 생성된다. 만약 SF 라는 클러스터를 추가하여 NYC -> LON, SF 로 팬아웃(하나의 소스에서 여러 대상으로)되는 토폴로지를 생성하고 싶다면 위 설정에 SF cluster 별칭을 추가하고 NYC->SF.enabled = true 등 설정해주면 된다.

10.3.3 미러메이커 보안

모든 데이터센터 간 트래픽에 보안을 적용하는 것이 중요하다. 미러메이커의 경우 원본과 대상 클러스터 양쪽에 대해 보안이 적용된 브로커 리스터를 사용하도록 설정되어야 하며, 각 클러스터에 대해 클라이언트 쪽 보안 옵션들 역시 설정되어야 한다.

NYC.security.protocol=SASL_SSL
NYC.sasl.mechanism=PLAIN
NYC.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule \
required username="MorroMaker" password="MirrorMaker-password";

만약 클러스터에 인가가 설정되어 있을 경우, 미러메이커에 적용되는 자격 증명에는 원본과 대상 클러스터에 대한 적절한 권한이 부여되어야 한다.

10.3.4 프로덕션 환경에 미러메이커 배포하기

미러메이커는 대게 회사들이 자체적으로 시동 스크립트를 가지고 있다. ansible, puppet 등을 이용하여 설정 옵션을 관리하여 자동화된 배포 시스템을 사용할 수도 있고, 도커 컨테이너를 이용하여 실행시킬 수도 있다. 또한 미러메이커는 상태라는 게 없기 때문에 디스크 공간을 필요로 하지 않는다. (필요한 데이터와 상태는 카프카에 저장된다)

또한 미러메이커는 가능한 대상 데이터센터에서 실행시키는 것이 좋다. 만약 NYC -> SF 로 복제 흐름을 생성한다면 SF 쪽에서 실행중인 미러메이커가 NYC 에서 데이터를 읽어오도록 하는 것이 좋다는 의미다. 이러한 이유는 장거리 통신 중 네트워크 불안정할 때 단순히 읽지 못할 뿐 데이터는 원본 카프카 클러스터에 보관되기 때문에 비교적 안전하다. 만약 반대로 NYC 쪽에서 보내도록 한다면 네트워크 장애가 발생했을 때 데이터가 유실될 가능성이 있다.
만약 SF -> NYC 가 필요한다면 다음과 같은 상황일 것이다.

  • 데이터 센터 간 암호화가 적용되어 데이터를 전송할 때
  • on-prem -> cloud 클러스터로 미러링할 때

미러메이커를 프로덕션 환경에 배포할 때는 아래와 같이 모니터링이 필수다.

  • 카프카 커넥트 모니터링 (커넥터 상태 모니터링)
  • 미러메이커 지표 모니터링 (미러링 처리량과 복제 지연 모니터링)
  • 랙 모니터링 (대상 클러스터가 원본 클러스터에서 얼마나 뒤쳐져있는지 모니터링)
  • 프로듀서/컨슈머 지표 모니터링
  • 카나리 테스트 (소스 클러스터의 특정한 토픽에 테스트용 이벤트 하나 보내고 대상 클러스터에서 확인)

여기서 랙(lag)이란 원본 카프카 클러스터의 마지막 메시지 오프셋과 대상 카프카 클러스터의 마지막 메시지 오프셋 사이의 차이를 의미한다.

10.3.5 미러메이커 튜닝하기

미러메이커는 수평 확장이 가능한 시스템이다. 랙의 크기에 따라 처리량을 조절하려면 커넥터 테스크 개수를 조절하면 된다. 미러메이커 처리량은 데이터센터, 하드웨어 등 다양한 요소의 영향을 받기 때문에 kafka-performance-producer 로 부하테스트를 통해 확인할 수도 있다.

만약 서로 다른 데이터센터 사이에 미러메이커를 돌리고 있다면, TCP 스택을 튜닝해주는 것이 실질 대역폭을 증가시키는 데 도움이 될 수 있다. 또한 미러메이커가 사용하는 프로듀서나 컨슈머를 튜닝할 수도 있다.

10.4 기타 클러스터간 미러링 솔루션

미러메이커는 아파치 카프카의 일부로서 배포되는 만큼, 지금까지는 미러메이커를 자세히 살펴보았다. 그러나 실전에서 사용하기에는 미러메이커 역시 어느정도 한계가 있다. 따라서 미러메이커의 한계와 복잡성을 극복하기 위해 나온 다른 몇몇 솔루션들을 살펴보자.

10.4.1 우버 uReplicator

레거시 미러메이커에서는 파티션-컨슈머 리밸런싱이 발생하여 미러링이 지연되는 이슈가 있었는데 우버한테는 치명적이였다. 이를 극복하기 위해 우버는 uReplicator 인스턴스에 할당된 토픽 목록과 파티션들을 관리하는 중앙집중화된 컨트롤러를 Apache Helix 를 사용해 구현하였다. 일명 Helix 컨슈머는 Helix 에서 주어지는 할당 파티션 변경을 받아 처리하여 리밸런스를 회피한다.

10.4.2 링크드인 브루클린

우버와 마찬가지로 링크드인에서도 레거시 미러메이커를 사용하면서 겪은 어려움을 극복하기 위해 브루클린이라는 자체적인 데이터 스트리밍 시스템 위에 미러링 솔루션을 구축하였다. 브루클린은 카프카를 포함한 서로 다른 종류의 데이터 저장소 사이에 데이터를 스트리밍해 줄 수 있는 분산 서비스이다. 데이터 파이프라인을 구축하기 위해 사용될 수 있는 범용 데이터 수집 프레임워크로서 브루클린은 다음과 같은 활용 사례를 지원한다.

  • 서로 다른 데이터 저장소와 스트림 처리 시스템 사이를 연결해서 데이터를 주고 받을 수 있게 한다.
  • 서로 다른 데이터 저장소에 대해 CDC 이벤트를 스트리밍해준다.
  • 클러스터 간 카프카 미러링을 제공한다.

10.4.3 컨플루언트 미러링 솔루션

Confluent Replicator 는 컨플루언트에서 내놓은 미러링 솔루션이다. 해당 솔루션은 미러메이커 2.0과 마찬가지로 카프카 커넥터를 기반으로 개발되었다.

컨플루언트는 다음과 같은 기능을 제공한다

  • 컨플루언트 리플리케이터 (미러링 툴)
  • 멀티 리전 클러스터 (멀티 리전 운용에 고가용성 보장)
  • 클러스터 링킹 (클러스터 간 각각의 오프셋을 보존한 채 복제 수행)
profile
uchan
이전 포스트

Python FastAPI 파헤쳐보기

다음 포스트

카프카 보안

0개의 댓글