코딩마을방범대
Zookeeper의 개념과 Kafka와의 상관관계 본문
KRaft, Kafka, Zookeeper는 모두 분산 시스템에서 메시지 큐잉과 데이터 관리를 위해 사용되는 기술이다.
기본적으로 사용할 때 Kafka와 Zookeeper를 같이 사용하는데, KRaft 사용 시 Zookeeper를 사용하지 않아도 된다고 한다.
Kafka
kafka는 일전에 작성한 포스트를 참고하면 된다.
간단히 말해서 고성능의 분산 메시징 시스템으로, 스트리밍 데이터를 처리하고 저장하는데 사용된다.
메시지 브로커가 존재하여 토픽을 이용해 생산자(Producer)와 소비자(Consumer) 간의 메시지를 중개한다.
아파치 카프카(Apache Kafka)
우선 메시지 큐와 관련된 용어들을 함께 알아본 뒤에 카프카에 대해 알아볼 것이다! 메시지 지향 미들웨어(MOM; Message Oriented Middleware)응용 소프트웨어 간의 비동기적 데이터 통신을 위한
sweet-rain-kim.tistory.com
Zookeeper
분산 시스템에서의 동기화, 구성 관리, 이름 서비스 등을 제공하는 중앙 집중형 서비스이다.
Zookeeper의 데이터는 메모리(znode)에 저장되고, 영구 저장소에 스냅샷을 저장하여 데이터의 내구성을 확보한다.
분산 시스템의 일부분이기 때문에 동작을 멈춘다면 분산 시스템이 멈출 수 있다.
(이 때문에 안전성을 확보하기 위해 클러스터를 홀수로 구축하는 것을 권고한다.)
Zookeeper와 Kafka의 혼용
서버의 상태를 감지하기 위해 사용되며 새로운 토픽이 생성되었을 때, 토픽의 생성과 소비에 대한 상태를 저장한다.
(여기서 Kafka 혼용 구축 시 Server로 Zookeeper, Client로 Kafka로 구성된다.)
Zookeeper와 Kafka는 대규모 환경에서는 다른 서버에 두는 것이 좋다.
주키퍼 앙상블(=여러 서버로 구성된 클러스터)은 홀수로 구성되어 과반수 이상이 장애가 발생하면 중단되고,
카프카는 그렇지 않아도 되기 때문에 다른 서버에 두는 것을 권장한다.
특징
- 순차적 일관성: 클라이언트의 업데이트는 전송된 순서대로 적용 된다.
- 원자성: 업데이트가 성공하거나 실패한다. 부분 결과가 없다.
- 단일 시스템 이미지: 클라이언트는 연결된 서버에 관계없이 동일한 서비스 보기를 보게 된다.
즉, 클라이언트가 동일한 세션을 사용하여 다른 서버로 장애 조치하더라도 클라이언트는 시스템의 이전 보기를 볼 수 없다. - 안정성: 업데이트가 적용되면 클라이언트가 업데이트를 덮어쓸 때까지 해당 시간부터 지속된다.
- 적시성: 시스템의 클라이언트 보기는 특정 시간 범위 내에서 최신 상태로 보장된다.
| API | 설명 |
| create | 트리의 위치에 노드 생성 |
| delete | 노드를 삭제 |
| exists | 노드가 위치에 존재하는지 테스트 |
| get data | 노드에서 데이터를 읽음 |
| set data | 노드에 데이터 쓰기 |
| get children | 노드의 자식 목록을 검색 |
| sync | 데이터가 전파되기를 기다림 |
주키퍼를 짝수로 구성한 경우 생기는 문제점?
서버에 문제가 생겼을 경우 과반수 이상의 데이터를 기준으로 일관성을 맞추기 때문에 클러스터를 홀수로 구축하는 것으로 권고한다.
하지만 짝수로 구성한다고 크게 문제는 없다.
다만, 짝수로 구성한 경우 쿼럼을 형성할 때 비례적으로 노드 수가 더 필요하므로 잘 사용되지 않는다.
예시.
| 문제 발생 서버 수 | 6대로 구성 | 5대로 구성 |
| 2대 | 4대가 동작함 이상 X |
3대가 동작함 이상 X |
| 3대 | 3대가 동작함 작동 중지 |
2대가 동작함 작동 중지 |
쿼럼(Quorum)
합의체가 의사를 진행시키거나 의결을 하는 데 필요한 최소한도의 인원수
예시.
- 과반수 서버로 이루어진 그룹
- 5대의 앙상블(클러스터)일 때 정상적인 서버 3대를 쿼럼이라고 한다.
- 한 서버에서 일어난 변경이 앙상블 내의 다른 서버로 전파되어 복제될 때, 이용가능한 수준까지 이루어졌다는 최소 기준.
쿼럼이 5개 중 3개일 때 시나리오
1. zookeeper가 쿼럼 3대에게 쓰기 작업을 복제한다.
- 3대에 장애가 발생한 경우 서비스 중단
- 2대에 장애가 발생한 경우 서비스 지속
2. 쿼럼 1대와 쿼럼에 포함되지 않았던 2대를 이용해 새로운 쿼럼을 구성한다.
3. 기존 쿼럼 1대의 작업을 다른 서버들에게 복제한다.
- 쓰기 요청을 유실하지 않고 계속 사용 가능
znode(지노드)
zookeeper가 상태 정보를 Key-Value 형태로 저장한다.
각 노드에 저장되는 데이터는 일반적으로 바이트에서 킬로 바이트 범위로 작다.
지노드에 저장된 정보를 이용하여 분산 애플리케이션(클라이언트)들은 서로 데이터를 주고받게 된다.
| 분류 | 설명 |
| Persistent Node (영구노드) | 클라이언트 연결과 무관하게 존재하며, 명시적으로 삭제되지 않는 한 영구적으로 유지됨 (클러스터의 설정이나 상태 정보를 저장하는 데 사용) |
| Ephemeral Node (임시노드) | 클라이언트가 연결되어 있는 동안만 존재하며, 연결이 종료되면 자동으로 삭제됨 (지노드를 생성한 세션이 활성 상태일 때 존재 클라이언트의 세션 상태나 현재 활성화된 노드의 상태를 나타내는 데 사용) |
| Sequence Node (순차노드) | 노드에 부여된 인덱스 |
Watcher
1. 주키퍼를 사용하는 클라이언트 A가 주키퍼에게 Watcher 등록을 요청한다.
2. 주키퍼를 사용하는 클라이언트 B가 주키퍼에게 ZNode를 수정한다고 말한다.
3. 클라이언트 A에게 변경 이벤트를 전달한다.
특징
- 캐시 유효성 검사 및 조정된 업데이트를 허용하기 위해 데이터 변경, 액세스 제어 목록(ACL) 변경 및 타임스탬프에 대한 버전 번호를 포함하는 상태 구조를 유지
(지노드의 데이터가 변경될 때마다 버전 번호가 증가함) - 클라이언트가 데이터를 검색할 때 데이터 버전도 수신함
- 네임스페이스의 각 지노드에 저장된 데이터는 부분적으로 읽기/쓰기가 가능한 것이 아니라 전체 단위로만 읽고/쓰기가 가능함(원자적)
네임스페이스(namespace)
특정한 이름을 가진 객체들이 서로 충돌하지 않도록 구분하는 방법이다.
네임스페이스 내의 각 znode는 고유한 경로를 가지며, 이를 통해 데이터에 접근하고 조작할 수 있다.
CAP 정리
아래 조건을 모두 충족하는 분산 시스템은 없다는 정리이다.
- Consistency(일관성): 모든 노드가 같은 데이터를 볼 수 있다.
- Availability(가용성): 성공, 실패 여부와 상관 없이 요청에 대한 결과를 반환할 수 있다.
- Partition-tolerance(분할 내성): 메시지 전달이 실패하거나 문제가 발생하더라도 전체 시스템이 원활하게 동작할 수 있다.
예시.
- 두 개의 ATM기와 한 명의 유저가 있다고 가정한다.
- ATM기의 기능에는 입금, 인출 기능이 있다. 입금하거나 인출하면 잔액을 업데이트한 후 거래를 완료한다.
- ATM의 기기 이름을 각각 A, B라고 가정한다.
- A기기를 사용하려고 하지만 B기기와 통신이 안되는 경우가 발생했다고 생각해본다.
- 이 문제는 네트워크 문제 때문일 수도 있고 B기기의 문제 때문일 수도 있다.
- 여기에서 CAP정리를 확인할 수 있다. 일관성과 가용성 중에 하나만 선택할 수 있다.
- 일관성(Consistency): 입금이나 인출을 할 수 없다고 사용자에게 말하고 기다린다.
- 가용성(Availability): 우선 처리를 해주고 B가 치유되면 대화하여 다시 잔금을 동기화한다.
참고사이트
[🧙Kafka] 카프카 정리 - 주키퍼(ZooKeeper)란?
'🎃 기타 > 상식 ❗' 카테고리의 다른 글
| Intellij IDEA 단축키 설정하는 방법 (0) | 2025.01.16 |
|---|---|
| KRaft의 개념과 Kafka와의 상관관계 (2) | 2024.11.28 |
| [JAVA] 원시타입(Primitive Type)과 참조타입(Reference Type) & Object와 Wrapper (0) | 2024.09.27 |
| [JAVA] 메서드 정의의 기본 구조 (0) | 2024.09.27 |
| HikariCP에서 발생하는 연결이 반복해서 열리고 닫히는 현상 (0) | 2024.08.29 |
