Zookeeper 및 부분 실패(Partial Failure)

2024. 11. 27. 18:52DATA/Kafka

반응형

Zookeeper 및 부분 실패(Partial Failure)

Zookeeper란?

Zookeeper는 분산 시스템을 위한 중앙 집중식 서비스로, 주로 구성 관리, 동기화, 클러스터 상태 관리리더 선출 등을 처리하는 데 사용된다. Kafka 같은 분산 시스템에서 중요한 역할을 하며, 클러스터의 메타데이터를 관리하고, 분산 환경에서의 상태 관리동기화 문제를 해결하는 데 도움을 준다.

Zookeeper는 클러스터의 노드들 간에 상태를 공유하고, 데이터의 일관성을 유지하는 중요한 역할을 한다. Kafka와 같은 시스템에서는 Zookeeper를 사용하여 브로커의 메타데이터와 파티션 정보, 리더 선출 등을 관리한다.

부분 실패(Partial Failure)란?

부분 실패는 분산 시스템에서 발생할 수 있는 문제 중 하나로, 전체 시스템의 실패는 아니지만 일부 노드 간에 오류가 발생하는 상황을 말한다. 이는 시스템이 부분적으로만 실패하는 상황으로, 특정 구성 요소가 정상적으로 작동하지 않지만 다른 부분은 여전히 운영될 수 있다.

부분 실패에서 발생할 수 있는 문제들:

  1. 네트워크 분리 (Network Partition):
    • 네트워크가 끊기면, 송신자수신자 간의 연결이 끊어지게 된다. 이로 인해 송신자는 수신자가 메시지를 성공적으로 받았는지 확인할 방법이 없다.
    • 이때, 송신자는 메시지를 보내지만, 수신자가 메시지를 받았는지 알 수 없고, 수신자가 메시지를 처리했는지조차 모르게 되는 상황이 발생한다.
  2. 메시지 수신 후 처리 실패:
    • 만약 네트워크가 끊어지지 않았지만 수신자가 메시지를 받았다 하더라도, 처리 도중 시스템 장애프로세스 실패가 발생할 수 있다. 이 경우 수신자는 메시지를 받았지만 처리 과정에서 실패가 일어나 작업이 중단된다.
    • 이때 작업의 성공 여부를 알 수 없게 되어, 송신자는 작업이 정상적으로 완료되었는지 혹은 실패했는지 알 수 없게 된다.

Zookeeper와 부분 실패의 관계

Zookeeper는 분산 시스템에서의 시지의 전송 실패, 수신자 상태 확인 등의 문제를 다루는 데 Zookeeper가 중요한 역할을 한다.

  • 리더 선출 및 클러스터 동기화: Zookeeper는 분산 시스템에서 리더 선출노드 간 동기화를 관리하여, 한 노드가 실패하더라도 다른 노드들이 일관된 상태를 유지하도록 돕는다.
  • 메시지 전달 보장: 메시지가 송신자에서 수신자로 제대로 전달되지 않았거나 수신자가 처리 중 실패한 경우에도, Zookeeper는 클러스터 상태와 노드 간의 정보를 관리하여 시스템이 일관되게 작동하도록 한다.

Zookeeper는 이러한 상황에서 트랜잭션 로그메타데이터 관리를 통해 부분 실패를 관리하며, 시스템의 안정성을 높이는 데 기여한다.

 

 

 

 

 

Zookeeper 아키텍처는 분산 시스템의 동기화와 관리를 돕는 구조로 설계되었다. Zookeeper는 여러 서버들이 협력하여 데이터를 일관되게 유지하고, 장애 복구 및 상태 관리에 대한 기능을 제공한다. Zookeeper 아키텍처에서는 리더(Leader)와 팔로워(Follower)의 역할이 매우 중요하며, 데이터의 일관성과 신뢰성을 보장하기 위해 Write와 관련된 다양한 프로세스가 진행된다.

Zookeeper 아키텍처 구성 요소

  1. Leader (리더):
    • Zookeeper 클러스터에서 리더 서버는 데이터 쓰기 작업을 관리한다. 리더는 클러스터에서 단 하나의 노드만 존재하며, 모든 쓰기 요청을 선택적으로 처리한다. 리더는 데이터를 Write하고 Commit을 승인한다.
  2. Follower (팔로워):
    • 팔로워는 리더의 작업을 따르며 읽기 작업을 처리한다. 팔로워는 리더와 통신하여 Propose 단계에서 데이터를 업데이트하고, ACK (Acknowledge)를 보낸다.
    • 팔로워들은 리더의 데이터를 동기화하여 클러스터 간의 일관성을 유지한다.
  3. Zookeeper 클러스터:
    • Zookeeper는 여러 개의 서버(Leader + Follower)로 구성되어 있으며, 이들이 Zookeeper ensemble을 형성한다.
    • Zookeeper의 데이터ZNode라는 단위로 관리되며, 트리 구조로 저장된다.

Forward Write (쓰기 동작 흐름)

Zookeeper에서 데이터의 쓰기 작업은 아래와 같은 프로세스를 거친다:

  1. Propose (제안):
    • 클라이언트가 데이터를 리더에게 전송한다. 이때 리더는 데이터를 제안(propose)한다. 리더는 데이터를 여러 팔로워에게 전파하여, 데이터의 일관성과 동기화를 보장한다.
  2. ACK (Acknowledgment, 승인):
    • 팔로워는 리더에게 제시된 데이터를 받아들이고, ACK를 전송하여 데이터를 성공적으로 받았음을 알린다.
    • 리더는 각 팔로워로부터 ACK를 수신한 후, 데이터의 안정성 및 일관성을 보장한다.
  3. Commit (커밋):
    • 리더는 모든 팔로워로부터 ACK를 받은 후에 데이터를 최종적으로 Commit한다. 이 시점에서 데이터는 영구적으로 저장된다.
    • 이 과정이 완료되면 데이터가 클러스터의 모든 노드에 동기화되고, 클러스터의 모든 노드에서 일관성을 유지한다.

Zookeeper의 Write 처리 흐름

  1. 리더에게 요청: 클라이언트는 리더 서버에게 쓰기 요청을 보낸다.
  2. Propose 단계: 리더는 받은 요청을 다른 팔로워에게 전달하고, 팔로워들은 이를 수락하고 ACK를 보낸다.
  3. ACK 수신: 리더는 각 팔로워로부터 ACK를 받은 후 데이터를 확정한다.
  4. Commit 단계: 리더는 Commit을 실행하여 데이터를 영구적으로 기록하고, 클러스터 전체에 동기화된다.

이러한 Propose/ACK/Commit 절차는 Zookeeper 클러스터의 일관성신뢰성을 보장하는 중요한 요소이다. 이 과정에서 장애 복구클러스터 상태 관리가 원활하게 이루어진다.

Zookeeper 아키텍처에서의 역할

  • Leader: 쓰기 요청을 처리하고, 데이터를 클러스터에 동기화시킴.
  • Follower: 읽기 요청을 처리하며, 리더의 데이터를 동기화하여 일관성을 유지.
  • Zookeeper 클러스터: 여러 개의 리더와 팔로워들이 협력하여 데이터의 신뢰성을 보장하고, 부분 실패 상황에서도 안정적으로 동작할 수 있도록 지원.

Zookeeper 아키텍처의 주요 특징

  • 강력한 일관성: Zookeeper는 동기화된 데이터 저장소로, 데이터의 일관성을 유지하기 위해 WAL (Write-Ahead Log)와 ZNode를 사용한다.
  • 장애 복구: 리더 서버가 실패하면 새로운 리더를 선출하여 클러스터가 중단 없이 동작할 수 있도록 한다.
  • 데이터 복제: Zookeeper는 데이터를 복제하여 여러 서버에 분산 저장하며, 장애가 발생해도 데이터 손실을 방지한다.

 

 

 

 

Zookeeper 데이터 모델 - ZNode

Zookeeper의 데이터 모델은 ZNode라는 기본 단위를 중심으로 구성된다. ZNode는 Zookeeper에서 데이터를 저장하는 가장 작은 단위로, 트리 형태로 데이터를 구조화하여 관리한다. ZNode는 디렉토리와 파일처럼 데이터를 관리하는데, 디렉토리와 파일을 구분하여 사용할 수 있다.

Zookeeper의 ZNode 구조

ZNode는 계층적 트리 구조로 데이터를 저장하며, 각 ZNode는 경로(path)를 가지고 있다. 이 구조는 파일 시스템의 디렉토리와 파일 시스템처럼 작동한다. 각 ZNode는 다음과 같은 속성을 가진다:

  1. 데이터: ZNode는 데이터를 저장할 수 있으며, 최대 1MB 크기의 데이터를 저장할 수 있다. 이 데이터는 ZNode에 연관된 값을 나타낸다.
  2. 상태 정보: 각 ZNode는 그 자체의 메타데이터를 저장하는데, 이 메타데이터에는 버전 정보, 시간 정보, 부모-자식 관계 등의 정보가 포함된다.
  3. 자식 ZNode: ZNode는 다른 ZNode를 자식으로 가질 수 있으며, 이 계층 구조를 통해 트리 형태로 데이터를 관리한다.

Zookeeper에서 사용되는 주요 ZNode 유형

  1. 디렉토리와 파일처럼 사용:
    • 디렉토리: ZNode를 디렉토리처럼 사용하여, 그 안에 다른 ZNode를 하위로 생성하고 관리할 수 있다. /app1과 /app2와 같은 디렉토리 구조를 만들 수 있다.
    • 파일: 데이터를 파일처럼 저장하여 사용한다. 각 ZNode는 1MB 크기까지 데이터를 저장할 수 있기 때문에 작은 파일을 저장하는 용도로 사용된다.
  2. ZNode의 경로 예시:
    • /app1: app1이라는 ZNode는 디렉토리처럼 사용되며, 그 하위에 다른 ZNode들이 있을 수 있다.
    • /app2: app2는 또 다른 디렉토리 또는 파일처럼 사용할 수 있으며, 이 안에 여러 데이터를 저장하거나 하위 ZNode들을 생성할 수 있다.

Zookeeper ZNode의 주요 특성

  1. 영속성(Persistent) vs. 임시(EPHEMERAL):
    • Persistent ZNode: 이 ZNode는 클라이언트가 연결을 종료해도 삭제되지 않으며, 명시적으로 삭제될 때까지 계속 존재한다.
    • Ephemeral ZNode: 이 ZNode는 클라이언트와의 연결이 끊어지면 자동으로 삭제된다. 이 특성은 Zookeeper에서 세션 기반의 상태 저장 등에 유용하게 사용된다.
  2. 순서 지정:
    • ZNode를 순서 지정할 수 있다. , /app1/child-0000001과 같이 자식 노드에 번호를 자동으로 추가하는 방식으로 순서를 매길 수 있다. 이는 순차적 작업 또는 오더링이 중요한 데이터를 관리하는 데 사용된다.

예시: Zookeeper의 ZNode 구조

/
├── /app1
│   ├── /app1/service1
│   ├── /app1/service2
│   └── /app1/service3
└── /app2
    ├── /app2/config
    └── /app2/status

 

 

  • /app1과 /app2는 디렉토리처럼 사용되고,
  • /app1/service1, /app1/service2, /app2/config와 같은 ZNode는 그 안에 저장되는 데이터를 나타낸다.

Zookeeper ZNode의 주요 기능

  1. 데이터 저장:
    • Zookeeper는 데이터를 ZNode에 저장하고, 이 데이터를 여러 분산 시스템에서 공유하며 동기화할 수 있다.
  2. 분산 락:
    • Zookeeper는 분산 락을 구현할 때 사용될 수 있다. , 임시 ZNode를 생성하여 한 서버에서만 특정 작업을 수행할 수 있도록 제어할 수 있다.
  3. 노드 변경 감지:
    • Zookeeper는 노드의 데이터 변경이나 자식 노드의 추가/삭제모니터링할 수 있어, 클러스터 상태를 실시간으로 파악하고 반응할 수 있게 한다.
  4. 노드의 상태 관리:
    • Zookeeper는 분산 시스템에서의 상태 관리에 매우 유용한다. , 특정 시스템의 상태 정보를 ZNode에 저장하고, 시스템 상태가 변경되면 이를 다른 시스템에 실시간으로 알리는 방식으로 사용된다.

결론

Zookeeper에서의 ZNode는 데이터 저장, 분산 락, 상태 관리 등을 효율적으로 처리하는 핵심적인 역할을 한다. ZNode는 계층적 구조로 데이터를 관리할 수 있으며, 영속적 혹은 임시적으로 데이터를 저장하고 처리할 수 있다. Zookeeper는 이러한 구조를 통해 분산 시스템의 일관성을 유지하며, 실시간으로 데이터를 동기화하고 상태를 관리하는 데 중요한 역할을 한다.

반응형