generated from Learning-Is-Vital-In-Development/study-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
53 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
# 10장 - 클러스터간 데이터 미러링하기 | ||
|
||
복제: 같은 클러스터에 속한 카프카 노드 간의 데이터 교환 | ||
|
||
미러링: 카프카 클러스터간 데이터 복제 | ||
|
||
카프카는 클러스터간 데이터 복제를 수행하기 위한 툴로 **미러메이커**를 포함하고 있다. | ||
|
||
## 클러스터간 미러링 활용 사례 | ||
|
||
- 지역 및 중앙 클러스터: 분산된 환경의 데이터센터에 카프카 클러스터가 설치되어 있는 경우 | ||
- 고가용성과 재해 복구 | ||
- 법적 규제 | ||
- 클라우드 마이그레이션: 온프레미스 서버와 클라우드간 데이터 동기화 | ||
- 엣지 클러스터로부터의 데이터 집적: IoT 클라이언트로부터 수집된 데이터를 분석하는 용도 | ||
|
||
## 다중 클러스터 아키텍처 | ||
|
||
- 데이터센터간 통신을 하게 될 경우 high latency, limited bandwidth, higher cost가 문제가 된다. | ||
- 아파치 카프카의 브로커와 클라이언트는 하나의 데이터센터 안에서 실행되도록 설계, 개발, 테스트, 조정되었기에 낮은 지연, 높은 대역폭을 가진 상황을 상정하였다. 따라서 서로 다른 데이터센터에 나눠서 설치하는 것은 권장하지 않는다. | ||
- 대부분의 경우, 원격 데이터센터에 데이터를 쓰는 것은 피하는 것이 좋지만, 그래야 할 경우 더 높은 통신 지연과 네트워크 에러 발생 가능성을 감수해야 한다. | ||
|
||
### 허브-앤-스포크 아키텍처 | ||
|
||
- 여러 개의 로컬 카프카 클러스터와 한 개의 중앙 카프카 클러스터로 구성되어 있다. | ||
- 데이터가 여러 개의 데이터센터에서 생성되는 반면, 일부 컨슈머는 전체 데이터를 사용해야 할 경우 사용된다. | ||
- 항상 로컬 데이터센터에서 데이터가 생성되고, 각각의 데이터센터에 저장된 이벤트가 중앙 데이터센터로 단 한 번만 미러링되기에 단순하고 간편한 것이 장점이다. | ||
- 지역 데이터센터에 있는 애플리케이션은 다른 데이터센터에 있는 데이터를 사용할 수 없는 것이 단점이다. | ||
|
||
### 액티브-액티브 아키텍처 | ||
|
||
- 2개 이상의 데이터센터가 전체 데이터의 일부 혹은 전체를 공유하면서, 각 데이터센터가 모두 읽기와 쓰기를 수행할 수 있어야 할 경우 사용된다. | ||
- 인근 데이터센터에서 사용자들의 요청을 처리할 수 있는 장점이 있다. | ||
- 데이터 중복과 회복 탄력성에 강하다. | ||
- 데이터를 여러 위치에서 비동기적으로 읽거나 변경할 경우 발생하는 충돌을 피하기 어렵다. | ||
- 두 데이터센터 간의 데이터 일관성을 유지하는 것이 어렵다. | ||
- 만약 동일한 데이터세트를 여러 위치에서 비동기적으로 읽고 써야 하는 문제를 해결하기 쉽다. | ||
|
||
### 액티브-스탠바이 아키텍처 | ||
|
||
- 프로덕션용 클러스터와 장애 복구용 클러스터를 두는 방식이다. | ||
- 설치가 간단하고, 거의 대부분의 활용 사례에서 사용할 수 있다. | ||
- 현재로서는 일체의 데이터 유실이나 중복 없이 카프카 클러스터를 완벽하게 복구하는 것은 불가능하다. | ||
|
||
## 미러메이커 | ||
|
||
- 두 데이터센터 간의 데이터 미러링을 위해 존재한다. | ||
- 미러메이커는 데이터베이스가 아닌 다른 카프카 클러스터로부터 데이터를 읽어오기 위해 소스 커넥터를 사용한다. | ||
- 각각의 태스크가 한 쌍의 컨슈머와 프로듀서로 이루어지고, 커넥트 프레임워크가 각각의 태스크를 필요에 따라 서로 다른 커넥트 워커 노드로 할당하기에, 여러 태스크가 하나의 서버에 수행할 수도 있고, 여러 개의 서버에서 나눠서 수행할 수도 있다. | ||
- 미러메이커를 커넥트 안에서 실행시킴으로써 관리해야 할 클러스터의 수를 줄일 수 있다. | ||
- 미러메이커는 카프카의 컨슈머 그룹 관리 프로토콜을 사용하지 않고 태스크에 파티션을 균등하게 배분함으로써 새로운 토픽이나 파티션이 추가되었을 때 발생하는 리밸런스로 인해 지연이 튀어오르는 상황을 방지한다. | ||
- 미러메이커는 원본 클러스터의 각 파티션에 저장된 이벤트를 대상 클러스터의 동일한 파티션으로 미러링함으로써 파티션의 의미 구조나 각 파티션 안에서의 이벤트 순서를 그대로 유지한다. | ||
- 미러메이커는 데이터 복제뿐만 아니라 컨슈머 오프셋, 토픽 설정, 토픽 ACL 마이그레이션까지 지원하기에 자동 클러스터 배치에 필요한 완전한 기능을 갖춘 미러링 솔루션이라 할 수 있다. |