Kafka 심화) 클러스터간 데이터 미러링하기

카프카 클러스터 간의 데이터 복제는 미러링 이라고 부를것이다. 아파치 카프카에는 클러스터간 데이터 복제를 수행하기 위한 툴로 미러메이커를 포함하고 있다. 

 

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

지역 및 중앙 클러스터

고전적인 사례로는 수요와 공급에 따라서 가격을 조정해야 하는 회사가 있을 것이다. 이 회사는 사무실을 운영중인 각각의 도시에 데이터 센터를 가지고 각 지역의 수요와 공급에 대한 정보를 수집해서 그에 따라 가격을 조정한다. 이 모든 데이터는 그 후 중앙 클러스터로 미러링되어 비즈니스 분석가들이 회사 단위의 수익 보고를 할 때 사용할 수 있다. 

 

고가용성과 재해복구

 

규제

여러 나라에서 사업을 운영하는 회사의 경우 국가별로 다른 법적, 규제적 요구 조건을 따르기 위해 나라마다 있는 카프카 클러스터별로 서로 다른 설정과 정책을 시행해야 할 수 있다. 

 

클라우드 마이그레이션

 

엣지 클러스터로부터의 데이터 집적

가용성이 높은 집적용 클러스터를 사용한다면 많은 수의 엣지 클러스터로부터 수집된 데이터를 데이터를 분석하는 등의 용도로 사용도리 수 있다. 이러한 전략은 사용할 수 있는 자원이 한정적일 수밖에 없는 엣지 클러스터의 연결성, 가용성, 지속성에 대한 요구 조건을 낮추는데 도움이 된다.

 

다중 클러스터 아키텍처

데이터센터간 통신의 현실적 문제들

- 높은 지연

- 제한된 대역폭

- 더 높은 비용

 

허브 엔 스포크 아키텍처

허브 앤 스포크 아키텍처는 여러개의 로컬 카프카 클러스터와 한개의 중앙 카프카 클러스터가 있는 상황을 상정한 것이다. 

 

이 아키텍처의 단순화된 형태로는 리더와 팔로워 두개의 클러스터만 사용하는 방식이 있다. 

이 아키텍처의 주도니 장점은 항상 로컬 데이터센터에서 데이터가 생성되고 각각의 데이터센터에 저장된 이벤트가 중앙 데이터센터로 단 한 번만 미러링된다는 점이다.  지역 데이터 센터에 있는 애플리케이션은 다른 데이터센터에 있는 데이터를 사용할 수 없다. 

 

액티브-액티브 아키텍처

이 아키텍처의 주된 장점은 인근 데이터센터에서 사용자들의 요청을 처리할 수 있다는 점이다. 또 다른 장점은 데이터 중복과 회복 탄력성이다. 모든 데이터센터가 모든 기능을 동일하게 가지기 때문에 한 데이터센터에 장애가 발생하더라도 사용자 요청을 다른 데이터센터 처리할 수 있는 것이다. 

이 아키텍처의 주된  단점은 데이터를 여러 위치에서 비동기적으로 읽거나 변경할 경우 발생하는 충돌을 피하는 것이 어렵다는 점이다. 

- 사용자가 하나의 데이터센터에 이벤트를 쓰고 또 다른 데이터센터로부터는 이벤트를 읽어오는 상황을 생각해보자. 전자에 쓴 데이터가 후자에 아직 도착하지 않았을 수도 있다. 사용자 입장에서는 위시리스트에 책을 하나 추가하고, 위시리스트를 클릭했는데 정작거기에 방금전 추가한 책이 없는 것이다. 

 

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

첫번째 클러스터의 모든 데이터를 가지고 있다가 첫 번째 클러스터가 완전히 사용할 수 없게 될 경우 대신 사용할 수 있는 두번째 클러스터가 필요할 수 있다. 혹은 지리적 장애 복구가 필요할 수도 있다. 

 

1) 재해 복구 계획하기

 

2) 계획에 없던 장애 복구에서의 데이터 유실과 불일치

 

3) 장애복구 이후 애플리케이션의 시작 오프셋

- 자동 오프셋 재설정 : 아파치 카프카 컨슈머는 사전에 커밋된 오프셋이 없을 경우 어떻게 작동해야 하는지를 결정하는 설정값을 갖는다. 장애 복구 계획에 이 오프셋을 미러링하는 부분이 빠져 있다면, 다음 두가지 옵션중에서 양자택일 해야 할 것이다. 즉, 데이터의 맨 처음부터 읽기 시작해서 상당한 수의 많은 양의 데이털르 처리할 것인지, 아니면 맨 끝에서 시작해서 알려지지 않은 갯수의 이벤트를 건너뛸 것인지? 

- 오프셋 토픽 복제 : 컨슈머는 자신의 오프셋을 __consumer_offset라 불리는 특별한 토픽에 커밋한다. 만약 이 토픽을 DR 클러스터로 미러링해 준다면, DR 클러스터에서 읽기 작업을 시작하는 컨슈머는 이전에 주 클러스터에 마지막으로 커밋한 오프셋으로부터 작업을 재개하게 된다.

- 시간 기반 장애 복구 : 컨슈머가 오전 4시 3분에 해당하는 데이터부터 처리를 재개하도록 할 수 있다. 이 옵션은 장애복구에 있어서 어느정도의 확실성을 보장해야 하는 경우를 권장한다. 

- 오프셋 변환 

 

4) 장애복구가 끝난 후 : 일관성과 순서 보장이 극도로 중요한 상황에서 가장 간단한 해법은 일단 원래 주 클러스터에 저장된 데이터와 커밋된 오프셋을 완전히 삭제한 뒤 새로운 주 클러스터에서 완전히 새것이 된 새 DR 클러스터로 미러링을 시작하는 것이다. 

 

5) 클러스터 디스커버리 관련

 

스트레치 클러스터

스트래치 클러스터는 데이터센터 전체에 문제가 발생했을 때 카프카 클러스터에 장애가 발생하는것을 방지하기 위한 것이다. 하나의 카프카 클러스터를 여러개의 데이터 센터에 걸쳐 설치하는 것이다. 

 

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

미러메이커는 데이터베이스가 아닌 다른 카프카 클러스터로부터 데이터를 읽어오기 위해 소스 커넥터를 사용한다. 미러메이커는 카프카의 컨슈머 그룹 관리 프로토콜을 사용하지 않고 태스크에 파티션을 균등하게 배분함으로써 새로운 토픽이나 파티션이 추가되었을때 발생하는 리벨런스로 인해 지연이 튀어오르는 상황을 방지한다. 미러메이커는 원본 클러스터의 각 파티션에 저장된 이벤틀르 대상 클러스터의 동일한 파티션으로 미러링함으로써 파티션의 의미 구조나 각 파티션 안에서의 이벤트 순서를 그대로 유지한다.