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

이전까지 우리는 단일 카프카 클러스터를 설치하고, 운영하고, 사용하는 방법을 배웠다.
하지만 하나 이상의 클러스톨 구성되는 카프카 아키텍처를 구성할 수도 있다.

실제로 인프라 전문가가 아니면 이정도의 상황을 직접 구축할 필요는 없겠지만 어떻게 구성되고 돌아가는지는 알고 가자.

---

두 개 이상의 클러스터를 활용하면 운영자가 상호 의존하는 클러스터 사이에 데이터를 지속적으로 복사해 줘야 하는 경우도 있다. 대부분의 데이터베이스에서는 데이터베이스 서버 간에 지속적으로 데이터를 복사하는 행위를 복제라고 한다.

우리는 카프카 내부 노드간의 데이터 교환을 이미 복제라고 불르고 있음으로 카프카 클러스터간의 복제는 미러링이라고 칭할 것이며, 클러스터간 데이터 복제를 수행하기 위한 툴로 미러메이커를 활용할 것이다.

10.1 클러스터간 미러링 활용 예제

• 지역 및 중앙 클러스터

각각의 데이터 센터에 카프카 클러스터가 분산되어 있을 때 미러링이 필요 함

• 고가용성과 재해 복구

어플리케이션이 하나의 카프카 클러스터만 사용하면, 재해가 일어났을 때 복구하기 어렵다.

• 규제

나라별 클러스터 별로 다른 규제 조건이 필요할 수도 있다. 따라서 분리된 클러스터에 서로 다른 데이터를 저장할 수 있다.

• 클라우드 마이그레이션

다양한 클라우드에서의 카프카를 이민시켜야할 때 미러링을 활용할 수 있다.

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

자원이 한정적일 수 있는 엣지 클러스터(IOT)의 경우 하나의 엣지 클러스터가 오프라인이 되도 다른 클러스터에서 정보를 가지고 있어야 한다.

10.2 다중 클러스터 아키텍처

성공적을 사용된 공통 아키텍처 패턴을 살펴보자.

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

• 높은 지연

두 카프카 클러스터간의 네트워크 홉 개수 증가에 따른 통신 지연

• 제한된 대역폭

광역 통신망(WAN)은 단일 데이터센터 내부보다 낮은 밴드위드를 가진다.

• 더 높은 비용

클러스터 간 통신에는 많은 비용이 든다.

---

카프카의 브로커와 클라이언트는 하나의 데이터센터 안에서 실행되도록 설계, 개발, 테스트되어 있다. 개발자들은 브로커와 클라이언트 사이에 낮은 지연, 높은 대역폭을 가진 상황을 상정하며, 타임아웃 기본값이나 버퍼 크기 또한 이에 맞춰 설정되어 있다.

따라서 카프카 브로커를 다른 데이터센터에 나눠서 설치하는 것은 권장되지 않는다.

하나의 데이터 센터 내부의 경우 네트워크 단절이 일어났을 때 카프카 브로커 안에 있는 데이터는 안전하게 보장된다. 따라서 여러 어플리케이션이 다른 데이터센터에 위치한 데이터를 읽어와야할 경우에는 가각의 데이터 센터에 카프카클러스터를 설치하는 것이 더 낫다.

공통적인 데이터 센터의 카프카 클러스터의 특징은 다음과 같다.

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

---

다음부터느 이러한 카프카 클러스터를 구현하기 위한 아키텍처를 설명한다.

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

이 구조는 여러 로컬 카프카클러스터(스포크)에서만 데이터를 생산하고 허브라 불리는 메인 카프카 클러스터에서 이를 미러링한다.

클라이언트의 경우 이 허브 클러스터에만 접속하여 데이터를 읽는다.

• 미러링이 한방향으로 진행됨으로 배포, 설정, 모니터리이 간단하다.
• 어플리케이션은 다른 데이터센터의 데이터를 사용하지 못한다.
• 허브 클러스터는 각 ㄷ이터센터별로 미러링 프로세스를 지정해야 한다.

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

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

• 인근 데이터센터에서 사용자 요청이 처리 가능
• 데이터 중복이 없고, 회복 탄력성이 좋다.
  • 한 데이터 센터가 고장나면 리다이렉션으로 다른쪽을 보게하면 됨
• 데이터에 대한 경쟁상태가 발생할 수 있다.

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

이는 액티브-액티브 아키텍처와 동일하나, 한 클러스터는 미러링만하고, 다른 클러스터는 열일하는 구조이다. 즉 예비용 클러스터를 하나 두는 것이다.

재해 상황을 제외하면 대기 상태로만 있는 클러스터는 분명히 자원의 낭비로 보인다. 재해 상황은 드물기 때문에, 대부분의 경우 아무것도 하지 않는 장비들을 그저 지켜보기만 하게 된다.

10.2.5 스크레치 클러스터

스크레치 클러스터는 데이터센터 전체에 문제가 발생했을 때 카프카 클러스터에 장애가 발생하는 것을 방지하기 위한 것이다.

하나의 카프카 클러스터를 여러 개의 데이터 센터에 설치하는 것을 의미한다.

단순하게 보면 min.insync.replicas설정을 잡아두고, acks=all로 설정하여 각각의 쓰기 작업이 최소 두 개의 데이터센터에 성공한 다음에 응답이 가도록 해주면 되는 것이다.

• 해당 아키텍처는 미러링이 필요없다.(언제든 100%동기화 유지)
• 장애가 나도 유연하게 대처가 가능하다.

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

데이터 미러링을 위해서는 미러메이커라는 툴을 활용한다.

미러메이커는 컨슈머 그룹 관리 프로토콜을 사용하지 않고 테스크에 파티션을 균등하기 배분함으로써 새로운 토픽이나 파티션이 추가되었을 때 발생하는 리밸런스로 인해 지연이 튀어오르는 상황을 방지한다.

미러메키어는 컨슈머 오프셋, 토픽 설정, 토픽 ACL 마이그레이션까지 지원하기에 자동 클러스터 배치에 필요한 완전한 기능을 갖춘 미러링 솔루션이라고 할 수 있다.

또한 앞단에서 말한 아키텍처에 따라 다양한 복제 흐름을 정의할 수도 있다.

10.3.1 미러메이커 설정하기

해당 부분은 직접 미러메이커를 설정할 일이 없음으로 설정 값은 패스하고 기억할만 한 것들만 남긴다.

랙(lag) 이란?

랙 이란 원본 카프카 클러스터의 마지막 메시지 오프셋과 대상 카프카 클러스터의 마지막 메시지 오프셋 차이를 가리킨다.

• 프로듀서/컨슈머 지표 모니터링 메트릭 제공

• 미러 메이커튜닝 가능

요약

2개 이상의 카프카 클러스터가 운용될 필요성과 이에따른 아키텍처 그리고 미러링과 미러메이커의 개념에 대해만 알고 가자.

실제 설치, 모니터링, 배포 자동화 등은 인프라 팀이 해줄 것이다.