10장 클러스터간 데이터 미러링하기
요약
2개 이상의 카프카 클러스터가 운용될 필요성
이에 따른 아키텍처 그리고 미러링과 미러메이커의 개념에 대해 알아보자
실제 설치, 모니터링, 배포 자동화 등은 인프라 팀이 해줄 것
이전까지 우리는 단일 카프카 클러스터를 설치하고, 운영하고, 사용하는 방법을 배웠다.
하지만 하나 이상의 클러스터가 구성되는 카프카 아키텍처를 구성할 수도 있다.
실제로 인프라 전문가가 아니면 이정도의 상황을 직접 구축할 필요는 없겠지만 어떻게 구성되고 돌아가는지는 알고 가자.
두 개 이상의 클러스터를 활용하면 운영자가 상호 의존하는 클러스터 사이에 데이터를 지속적으로 복사해 줘야 하는 경우도 있다. 대부분의 데이터베이스에서는 데이터베이스 서버 간에 지속적으로 데이터를 복사하는 행위를 복제라고 한다.
우리는 카프카 내부 노드간의 데이터 교환을 이미 복제라고 불르고 있음으로 카프카 클러스터간의 복제는 미러링이라고 칭할 것이며, 클러스터간 데이터 복제를 수행하기 위한 툴로 미러메이커를 활용할 것이다.
10.1 클러스터간 미러링 활용 예제
•
지역 및 중앙 클러스터
◦
각각의 데이터 센터에 카프카 클러스터가 분산되어 있을 때 미러링이 필요 함
•
고가용성과 재해 복구
◦
어플리케이션이 하나의 카프카 클러스터만 사용하면, 재해가 일어났을 때 복구하기 어렵다.
•
규제
◦
나라별 클러스터 별로 다른 규제 조건이 필요할 수도 있다.
◦
따라서 분리된 클러스터에 서로 다른 데이터를 저장할 수 있다.
•
클라우드 마이그레이션
◦
다양한 클라우드에서의 카프카를 migrate시켜야할 때 미러링을 활용할 수 있다.
•
엣지 클러스터로부터의 데이터 집적
◦
자원이 한정적일 수 있는 엣지 클러스터(IOT)의 경우 하나의 엣지 클러스터가 오프라인이 되도 다른 클러스터에서 정보를 가지고 있어야 한다.
10.2 다중 클러스터 아키텍처
성공적으로 사용된 공통 아키텍처 패턴을 살펴보자.
10.2.1 데이터센터간 통신의 현실적인 문제
•
높은 지연
◦
두 카프카 클러스터간의 네트워크 홉 개수 증가에 따른 통신 지연
•
제한된 대역폭
◦
광역 통신망(WAN)은 단일 데이터센터 내부보다 낮은 bandwidth를 가진다.
•
더 높은 비용
◦
클러스터 간 통신에는 많은 비용이 든다.
카프카의 브로커와 클라이언트
•
하나의 데이터센터 안에서 실행되도록 설계, 개발, 테스트되어 있음
•
개발자들은 브로커와 클라이언트 사이에 낮은 지연, 높은 대역폭을 가진 상황을 가정하며, 타임아웃 기본값이나 버퍼 크기 또한 이에 맞춰 설정되어 있음
따라서 카프카 브로커를 다른 데이터센터에 나눠서 설치하는 것은 권장되지 않는다.
하나의 데이터 센터 내부의 경우, 네트워크 단절이 일어났을 때 카프카 브로커 안에 있는 데이터는 안전하게 보장된다.
따라서 여러 어플리케이션이 다른 데이터센터에 위치한 데이터를 읽어와야할 경우에는 각각의 데이터 센터에 카프카 클러스터를 설치하는 것이 더 낫다.
공통적인 데이터 센터의 카프카 클러스터의 특징은 다음과 같다.
•
하나의 데이터센터 당 한 개 이상의 클러스터 설치
•
각각의 데이터센터 간의 각각의 이벤트를 정확히 한 번 씩 복제한다.
•
가능하면, 원격 데이터 센터에 쓰는 것보다 읽어오기만 하는 것이 낫다.
이러한 카프카 클러스터를 구현하기 위한 아키텍처를 설명한다.
10.2.2 허브-앤-스포크 아키텍처
•
스포크: 여러 로컬 카프카클러스터(스포크)에서만 데이터를 생산
•
허브: 허브라 불리는 메인 카프카 클러스터에서 이를 미러링한다.
클라이언트의 경우 이 허브 클러스터에만 접속하여 데이터를 읽는다.
•
미러링이 한방향으로 진행됨으로 배포, 설정, 모니터링이 간단하다.
•
어플리케이션은 다른 데이터센터의 데이터를 사용하지 못한다.
•
허브 클러스터는 각 데이터 센터 별로 미러링 프로세스를 지정해야 한다.
10.2.3 액티브-액티브 아키텍처
2개 이상의 데이터센터가 전체 데이터의 일부 혹은 전체를 공유하면서, 각 데이터센터가 모두 읽기와 쓰기를 수행할 수 있어야 할 경우 사용된다.
•
인근 데이터센터에서 사용자 요청이 처리 가능
•
데이터 중복이 없고, 회복 탄력성이 좋다.
◦
한 데이터 센터가 고장나면 리다이렉션으로 다른쪽을 보게하면 됨
•
데이터에 대한 경쟁상태가 발생할 수 있다.
10.2.4 액티브-스탠바이 아키텍처
•
이는 액티브-액티브 아키텍처와 동일하나, 한 클러스터는 미러링만하고, 다른 클러스터는 처리하는 구조이다.
•
즉 예비용 클러스터를 하나 두는 것이다.
재해 상황을 제외하면 대기 상태로만 있는 클러스터는 분명히 자원의 낭비로 보인다. 재해 상황은 드물기 때문에, 대부분의 경우 아무것도 하지 않는 장비들을 그저 지켜보기만 하게 된다.
10.2.5 스크레치 클러스터
•
스크레치 클러스터
◦
데이터센터 전체에 문제가 발생했을 때 카프카 클러스터에 장애가 발생하는 것을 방지하기 위한 것이다.
•
하나의 카프카 클러스터를 여러 개의 데이터 센터에 설치하는 것을 의미한다.
단순하게 보면 min.insync.replicas설정을 잡아두고
acks=all로 설정하여 각각의 쓰기 작업이 최소 두 개의 데이터센터에 성공한 다음에 응답이 가도록 해주면 되는 것
•
해당 아키텍처는 미러링이 필요없다 ⇒ (언제든 100%동기화 유지)
•
장애가 나도 유연하게 대처가 가능하다.
10.3 아파치 카프카의 미러메이커
데이터 미러링을 위해서는 미러메이커라는 툴을 활용한다.
미러메이커
•
카프카 클러스터 간 데이터 미러링 도구
•
재해 복구, 데이터 백업, 지역 간 데이터 복제에 활용
•
완전한 기능을 갖춘 미러링 솔루션
•
데이터 복제
◦
메시지 복제
◦
토픽 설정 복제
◦
ACL(접근 제어 목록) 마이그레이션
•
오프셋 관리
◦
컨슈머 오프셋 관리
◦
파티션 균등 배분
◦
리밸런싱 최적화
•
리밸런싱 최적화
◦
컨슈머 그룹 관리 프로토콜 미사용
◦
태스크에 파티션 균등 배분
▪
컨슈머 그룹 관리 프로토콜을 사용하지 않고 테스크에 파티션을 균등하기 배분함
◦
새로운 토픽/파티션 추가 시 지연 방지
▪
새로운 토픽이나 파티션이 추가되었을 때 발생하는 리밸런스로 인해 지연이 튀어오르는 상황을 방지한다.
미러 메이커
⇒ 컨슈머 오프셋, 토픽 설정, 토픽 ACL 마이그레이션까지 지원
⇒ 자동 클러스터 배치에 필요한 완전한 기능을 갖춘 미러링 솔루션
카프카 미러메이커의 발전과 특징
•
미러메이커 버전별 특징
◦
초기 버전
▪
단일 컨슈머 그룹 사용
▪
공유 프로듀서로 목적지 클러스터에 쓰기
▪
설정 변경 시 지연, 리밸런싱 문제 존재
◦
미러메이커 2.0
▪
카프카 커넥트 프레임워크 기반
▪
이전 버전의 단점 해결
▪
복잡한 토폴로지 지원
▪
재해 복구, 백업, 마이그레이션 등 지원
•
아키텍처와 동작 방식
◦
구성 요소
▪
소스 커넥터로 데이터 읽기
▪
태스크별 컨슈머-프로듀서 쌍
▪
REST API를 통한 관리
◦
작업 분산
▪
커넥트 워커 노드 간 태스크 할당
▪
유연한 서버 구성 가능
▪
자동화된 태스크 관리
•
주요 기능
◦
데이터 복제
▪
파티션 의미 구조 유지
▪
이벤트 순서 보존
▪
자동 파티션 생성
◦
추가 지원 기능
▪
컨슈머 오프셋 마이그레이션
▪
토픽 설정 복제
▪
ACL 마이그레이션
위에서 언급한 토폴로지 아키텍처에 따라 다양한 복제 흐름 또한 정의 가능
10.3.1 미러메이커 설정하기
직접 미러메이커를 설정할 일이 없을 것 같아 인상 깊었던 부분만 정리
미러메이커 래그 란?
원본 카프카 클러스터의 마지막 메시지 오프셋과 대상 카프카 클러스터의 마지막 메시지 오프셋 차이
•
컨슈머 래그와 다른 개념
•
미러메이커 래그: 전체 클러스터 수준
•
컨슈머 래그: 개별 컨슈머/파티션 수준
•
프로듀서/컨슈머 지표 모니터링 메트릭 제공
•
미러 메이커 튜닝 가능