[ Concept ] 분산 코디네이터 Zookeeper(주키퍼) 알아가기

---

Intro

 

이전 포스팅에서 Kafka(카프카)의 개념에 대해 알아봤습니다.

이어서 오늘은 Kafka(카프카)와 떨어질 수 없는 사이인 Zookeeper(주키퍼)에 대해 포스팅을 진행해보려고 하는데요.

카프카를 사용하려면 주키퍼까지 알아야 한다니.. 정말 공부할 게 너무 많아서 걱정이네요..😭

 

그럼 바로 주키퍼에 대해 파헤쳐 보겠습니다❗

---

Zookeeper(주키퍼) - 소개

 

 

 

분산 시스템을 설계하다 보면, 가장 큰 문제점 중의 하나가 분산된 시스템 간의 정보를 어떻게 공유할 것이고,

클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 또한, 분산된 서버들간에 동기화를 위한 Lock(락)을 처리하는 것들이 문제로 부딪히는 상황이 발생하는데요.

 

이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템(coordination service)라고 하는데,

아파치 주키퍼(Apache Zookeeper)가 대표적입니다.

 

이 코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보등을 유지하기 때문에,

코디네이션 서비스의 장애는 전체 시스템의 장애를 유발하기 때문에 이중화등을 통하여 고가용성을 제공해야 합니다.

 

주키퍼는 이러한 특성을 제공하고 있는데, 그런 이유로 이미 유명한 분사 솔루션에 많이 사용되고 있습니다.

NoSQL의 한 종류인 Apache HBase, 대용량 분산 큐 시스템인 Kafka등이 그 대표적인 사례이며,

분산 시스템을 코디네이션 하는 용도로 디자인이 되었기 때문에, 데이터 억세스가 빨라야 하며 자체적으로 장애에 대한 대응성을 가져야 합니다.

 

그래서 주키퍼는 자체적으로 클러스터링을 제공하고 장애에도 데이터 유실 없이 fail over/fail back이 가능합니다.

 

사실상 주키퍼의 기능은 별로 없습니다.

디렉토리 구조 기반으로 znode(지노드)라는 데이터 저장 객체를 제공하고,

key-value 식 데이터를 넣고 빼는 기능만을 제공합니다.

 

일단 디렉토리 형식을 사용하기 때문에 데이터를 계층화된 구조로 저장하기 용이합니다.

---

Zookeeper(주키퍼) - znode(지노드)

 

 

 

위에서 간단하게 지노드(znode)를 언급했지만 조금 더 풀어보자면,

분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고받는데, 상태 정보들은 주키퍼의 지노드(znode)에 key-value 형태로 저장하며, 저장된 것을 이용하여 분산 애플리케이션들은 서로 데이터를 주고받게 됩니다.

 

간단한 게 지노드(znode)를 일반 컴퓨터의 파일이나 폴더 개념으로 생각하면 괜찮을 거 같습니다.

지노드(znode)는 우리가 알고 있는 일반적인 디렉터리와 비슷한 형태로서 자식 노드를 가지고 있는 계층형 구조로 구성되어 있습니다.

 

위 사진을 보면 계층형 구조로 상태 정보를 저장하는 걸 확인해 볼 수 있는데,

사진에서 색상 별로 노드가 정리되어 기능에 따라 몇 가지 종류로 나누어지는데 각 노드는 다음과 같습니다.

 

• Persistent Node
  • 노드에 데이터를 저장하면 일부러 삭제하지 않는 이상 삭제되지 않고 영구적으로 저장됩니다.
• Ephemeral Node
  • 노드를 생성한 클라이언트의 세션이 연결되어 있을 경우만 유효합니다.
  • 즉, 클라이언트 연결이 끊어지는 순간 삭제됩니다.
  • 이를 통해서 클라이언트가 연결 유/무를 판단하는 데 사용할 수 있습니다.
    • (클러스터를 구성할 때 클러스터 내에 서버가 들어오면, Ephemeral Node로 등록하면 됩니다.)
• Sequence Node
  • 노드를 생성할 때 자동으로 sequence 번호가 붙는 노드입니다.
  • 주로 분산락을 구현하는데 이용됩니다.

 

znode 알림 기능?

 

주키퍼는 znode에 변화를 감지할 수 있는 Watcher를 등록할 수 있습니다.

Watch 기능은 주키퍼 클라이언트가 특정 znode에 변경이 되었을 때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려줍니다. 그리고 해당 Warcher는 삭제됩니다.

 

---

Zookeeper(주키퍼) - Quorum(투표하다)

 

 

Leader가 새로운 트랜잭션을 수행하기 위해서는 자신을 포함하여 과반수 이상의 서버의 합의를 얻어야 합니다.

 

주키퍼는 3대 혹은 5대 이상의 홀수로 구성하는데,

그 이유는 Quorum 기반 알고리즘으로 이루어져 있기 때문입니다.

 

여기서 쿼럼은 다른 말로 "정족수"라고 번역이 되는데,

어떤 의사 결정을 하는 합의체(Zookeeper Ensemble(앙상블))가 의사를 체결하기 위한 최소한의 인원수를 뜻합니다.

 

즉, 과반수 이상이 필요하다는 건데

그 이유는 분산 코디네이션 환경에서 예상치 못한 장애가 발생하더라도 분산 시스템의 일관성을 유지시키기 위해서 사용합니다.

 

 

간단한 상황 예시를 들어보겠습니다.

 

앙상블이 주키퍼 서버 3대로 구성이 되어있다? 

 

그렇다면 쿼럼은 과반수 이상으로 2가 되기 때문에 주키퍼 장비 1대가 장애가 생겨도 정상 동작합니다.

---

앙상블이 주키퍼 서버 5대로 구성이 되어있다?

 

쿼럼은 과반수 이상으로 3이 되기 때문에 주키퍼 장비가 2대가 장애가 생겨도 정상 동작합니다.

---

 

즉, 홀수로 주키퍼 서버로 구성하는 이유는 3대를 쓰나 4대를 쓰나 과반수 이상이 되는 것은 한대로 동일하기 때문에 홀수개의 서버로 구성합니다.

 

이해도를 높이기 위해

위 트랜잭션 처리 그림에서 보이는 전달 방식을 하나씩 풀어서 알아보겠습니다.

 

• Request -> Leader
  • 새로운 트랜잭션 요청이 Follower에게 도착할 경우, Follower는 Leader에게 요청을 전달합니다.
• Propose
  • Propose는 Leader가 쿼럼(Quorum)을 구성하는 서버들에게 트랜잭션을 수행해도 되는지 여부를 요청하는 과정을 의미합니다.
• Ack
  • 쿼럼(Quorum)을 구성하는 서버들은 Leader로부터 Propose 요청을 받으면, 트랜잭션을 수행해도 된다는 Ack 응답을 Leader에게 전송합니다.
• Commit
  • 모든 쿼럼(Quorum)으로부터 Ack를 받으면, Leader는 트랜잭션을 처리하라는 Commit 명령을 broadcast 형태로 모든 Follower에 전파합니다.
  • 주키퍼에서는 Commit 명령을 전달할 때, ZAB(Zookeeper Atomic Broadcast) 알고리즘을 사용합니다.
  • Atomic Broadcast는 broacast 방식 중 하나로, 멀티 프로세스 시스템에서 모든 프로세스에게 동일한 순서로 메시지가 전달되는 것을 의미합니다.

---

Kafka - Zookeeper

 

 

정리해 보자면

분산 시스템에 반드시 필요로 하는 것이 코디네이터 서비스 시스템이라는 것을 알았습니다.

그 대표적인 것이 주키퍼인데, 그렇다면 카프카에서 주키퍼는 어떤 용도로 사용될까요?

 

이전 포스팅에서도 언급을 했지만 복습해 보자면

카프카의 주키퍼 클라이언트는 카프카의 브로커를 관리하고 조정하는 데 사용합니다.

 

 

카프카는 메시지를 주고받는 Pub/Sub 외에는 아무것도 하지 않는 분산 처리 플랫폼이라서

브로커 상태를 저장하지 않기 때문에 상태 관리를 위해서만 주키퍼를 사용합니다.

 

이때 생산자(Producer)와 소비자(Consumer)는 카프카의 브로커 정보를 가지고 있습니다.

만약 동적으로 브커로의 상태가 변경되는 경우 이를 주키퍼가 생산자와 소비자에게 알려줍니다.

 

일반적으로 카프카 메시지 브로커와 주키퍼는 1:1 관계로 구성되며

만약 생산자가 특정 카프카 브로커로 메시지를 생산했을 때 이를 실패하면 주키퍼가 다른 정상 서버로 생산자와 소비자에게 브로커를 알리는 방식으로 운영됩니다.

---

마치며

 

오늘 포스팅으로 카프카와 주키퍼에 대한 정리글을 마치겠습니다❗

저도 실무에서 프로젝트를 진행하면서 접했는데 간단하게 생각할 수 없어서

검색을 통해서 찾아보면서 지식을 쌓아가고 있는데요.. 알아가는 과정에서 쉽지 않았습니다..😅

 

다음 포스팅에서 뵙겠습니다🤚