개발배경
분산 시스템에서는 클러스터간의 통신이나 데이터를 처리하는데 있어서 고민이 많이 있었습니다.
분산 시스템에서의 고민거리
- 분산된 시스템 같의 정보를 어떻게 공유할 것인가
- 클러스터에 있는 서버들의 상태를 어떻게 체크할 것인가
- 분산된 서버들 간에 동기화를 위해 잠금(Lock)을 어떻게 처리할 것인가
이러한 고민과 분산 시스템을 처리해주고 관리의 필요성이 생겼습니다.
분산된 서버들끼리 통신할 때 리소스를 공유하려다 보면 자원 점유 문제가 발생하는데, 이를 처리하기 위한 대표적인 해결책으로 리소스 락을 볼 수 있습니다. 이 리소스는 Lock, Unlock하는데도 관리해주는 시스템이 필요합니다.
코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보 등을 유지하기 때문에 코디네이션 시스템의 장애는 전체 시스템 장애로 이어지는 장애 전파 특성이 있습니다.
따라서 고가용성을 제공하는 것이 필수입니다.
🧸 주키퍼란
분산 코디네이션 서비스
다수의 노드에서 수행되는 분산 처리 어플리케이션은 단일 노드에서 수행되는 어플리케이션보다 매우 고려해야할 요소가 많은데, 그 중 가장 주요한 것은 부분 실패(Partial Failure)다.
한 노드 안에서 프로그램이 수행될 때는 걱정하지 않아도 될 요소인 네크워크를 통해서 메시지가 전송되는 부분이 종종 문제가 된다. 특히 메세지를 전송하고 네트워크가 끊겼을 때 송신자는 수신자가 메세지를 성공적으로 수신했는지조차 알 수 없게 된다. 어쩌면 메시지를 받고 처리를 하고 나서 응답을 못준 것일 수도 있고, 메세지 전송 자체가 실패된 것일 수도 있다. 작업이 성공한 것인지 실패한 것인지 여부조차 알 수 없는 것이다.
주키퍼는 이러한 부분 실패를 안전하게 처리하기 위한 분산 처리 도구를 제공한다.
주키퍼의 3가지 특징
- 클러스터링 : 주키퍼는 홀수로 구성된 클러스터로 구성합니다.클러스터의 과반수 이상이 정상적으로 동작하면, 주키퍼는 정상적으로 작동합니다.
- 데이터베이스 : 주키퍼는 키-값 기반의 데이터베이스를 제공합니다. 주키퍼는 데이터베이스를 사용하여 분산 시스템의 구성, 동기화, 상태 관리등을 수행합니다.
- 복제 : 주키퍼는 데이터베이스의 모든 데이터를 복제합니다. 따라서, 주키퍼 클러스터의 일부 서버가 장애가 발생하더라고, 데이터의 손실 없이 시스템을 유지할 수 있습니다.
이러한 특징으로 유명한 분산 솔루션에서 많이 사용합니다.
- Kafka
- HBase(NoSQL)
분산 시스템을 코디네이션하는 용도로 사용하기 위해서는 다음과 같은 사항을 고려해야 합니다.
- Data Access가 빨라야합니다.
- 자체적으로 장애 대응이 필요합니다.
🦆 장점
주키퍼는 클러스터링 기능을 자체적으로 지원하며, 이러한 코디네이션 서비스 시스템에 있어서 아주 쉽게 적용이 가능하다는 장점이 있으며 기능은 간단합니다.
-
설정관리
클러스터의 설정 정보를 최신으로 유지하기 위한 시스템 -
클러스터 관리
클러스터의 서버가 추가되거나 제외될 때 그 정보를 클러스터 내 서버들이 공유하기 위한 시스템입니다. -
리더 채택
다중 어플리케이션 주 어떤 노드를 리더로 산출할 지 정하는 로직을 만듭니다. -
락, 동기화
클러스터에서 쓰기 연산이 빈번할 경우 클러스터 전체를 동기화를 통해 데이터 불일치를 방지합니다.
분산 시스템에서 어떤 노드에게 연산을 시킬지 결정하는 것도 하나의 역할이라고 볼 수 있습니다. 여러 노드들 중 유휴 상태인 노드를 찾는 로직을 어떤식으로 할지 정하는 리더 채택이 그 역할을 합니다.
🎈 주키피의 구조
구성
-
Request Processor : Write 요청 처리
-
Zab (Zookeeper Atomic Broadcast Protocol) : Request Processor에서 처리한 요청을 트랜잭션을 생성하여 모든 서버에게 전파한다. [Leader-Propose] -> [Follower-Accept] -> [Leader-Commit] 단계로 구성된다.
-
In-memory DB : Znode의 정보가 저장되며, 로컬 파일시스템에 Replication을 구성할 수 있다.
코디네이션 서비스 시스템은 분산 시스템의 일부분이 되어 동작하기 때문에 앞서 말한 것처럼 코디네이션 시스템이 중단되면 분산 시스템도 중단되는 장애 전파가 발생하게 됩니다.
Zookeeper는 안정성을 확보하기 위해 다수의 Server를 사용하는 서버 클러스터 구조를 이용합니다. 이는 k8s와 유사한 구조로 서버 클러스터는 1개의 Leader와 N개의 Follower로 구성되어 있고, 이를 주키퍼 앙상블(Zookeeper Ensemble)이라고도 합니다.
순서는 Client(여기서는 Kafka)가 주키퍼 서버들로 이뤄진 앙상블(Ensemble)에 접근하여 Znode의 데이터를 읽거나 데이터를 업데이트합니다. 앙상블 내 주키퍼 서버들은 조율된 상태이고, 항상 동일한 데이터를 가지고 있어 어느 서버에서 데이터를 읽어도 같은 데이터로 불러오게 됩니다.
Client(Kafka)가 어떤 설정값 혹은 메타데이터를 주키퍼에 쓸 때 아래와 같이 동작합니다.
- 특정 서버에 접속하여 서버 데이터 업데이트
- 해당 서버는 Leader 서버에 데이터가 업데이트 되었음을 전송
- Leader 서버는 업데이트 신호를 받고, 다른 Follower 서버들에게 브로드캐스트(Broadcast) 형식으로 전송
- 나머지 Follower 서버들도 데이터 업데이트
위 4가지 과정을 통해 주키퍼는 데이터를 항상 일관성 있게 유지하도록 합니다.
🥂 주키퍼 데이터 모델(Znode)
상태 정보들은 주키퍼의 지노드(znode)라고 불리는 곳에 Key-Value 형태로 저장하며, 지노드에 저장된 것을 이용하여 분산 어플리케이션들은 서로 데이터를 주고받게 된다.
Znode를 일반 컴퓨터의 파일이나 폴더 개념으로 생각하면 쉽습니다.
지노드(Znode)는 우리가 알고 있는 일반적인 디렉토리와 비슷한 형태로서 자식노드를 가지고 있는 계층형 구조로 구성되어 있다.
🗳️ 투표하다(Quorum)
Leader가 새로운 트랜잭션을 수행하기 위해서는 자신을 포함하여 과반수 이상의 서버의 합의를 얻어야 한다.
주키퍼는 3대 혹은 5대 이상의 홀수로 구성하는데, 그 이유는 Quorum 기반 알고리즘으로 이루어져 있기 때문이다.
여기서 쿼럼은 다른말로 "정족수"라고 번역이 되는데, 어떤 의사 결정을 하는 합의체(주키퍼 앙상블)이 뭔가에 대한 의사를 체결하기 위한 최소한의 인원수를 뜻한다. (과반수 이상이 필요한것)
그 이유는 분산 코디네이션 환경에서 예상치 못한 장애가 발생하더라도 분산 시스템의 일관성을 유지시키기 위해서 사용한다.
예시
앙상블이 주키퍼 서버 3대로 구성이 되어 있다면 쿼럼은 2 (과반수 이상)이 되기 때문에 주키퍼 장비가 1대가 장애가 생겨도 정상 동작
앙상블이 주키퍼 서버 5대로 구성이 되어 있다면 쿼럼은 3 (과반수 이상)이 되기 때문에 주키퍼 장비가 2대가 장애가 생겨도 정상 동작
즉, 홀수로 주키퍼 서버로 구성하는 이유는 3대를 쓰나 4대를 쓰나 과반수 이상이 되는것은 한대로 동일하기 때문에 홀수개의 서버로 구성한다.
🦦 Kafka에서의 주키퍼는
우리가 분산 시스템에 반드시 필요로 하는 것이 코디네이터 서비스 시스템이라는 것을 알았고, 그 대표적인 것이 주키퍼라는 것을 알았습니다. 그렇다면 카프카에서 주키퍼는 어떤 용도로 사용될까요?
카프카의 주키퍼 클라이언트는 카프카의 브로커를 관리하고 조정하는 데 사용합니다.
카프카는 메세지를 주고 받는 Pub/Sub 외에는 아무것도 하지않는 분산 처리 플랫폼입니다.
따라서 브로커 상태를 저장하지 않기 때문에 상태 관리를 위해서만 주키퍼를 사용합니다.
이 때 Producer와 Consumer는 카프카의 브로커 정보를 가지고 있습니다. 만약 동적으로 브로커의 상태가 변경(스케일 아웃 되는 등)되는 경우 이를 주키퍼가 Producer와 Consumer에게 알려줍니다.
일반적으로 카프카 메시지 브로커와 Zookeeper는 1:1로 구성되며 만약 Producer가 특정 카프카 브로커로 메시지를 생산했을 때 이를 실패하면 주키퍼가 다른 정상 서버로 Producer와 Consumer에게 브로커를 알리는 방식으로 운영됩니다.
🔗
https://zookeeper.apache.org/doc/r3.1.2/zookeeperOver.html
https://xangmin.tistory.com/169
https://dreamcoding.tistory.com/88
https://blog.neonkid.xyz/302
