Distributed Coordination

Distributed Coordination

4. 전체 개요 (250 자 내외)

분산 조정 (Distributed Coordination) 은 분산 시스템의 핵심 구조로, 노드 간 협업을 위해 합의, 리더 선출, 락, 이벤트 통지 등을 관리한다. ZooKeeper 또는 etcd 와 같은 분산 조정 서비스는 트리 기반의 데이터 모델, 감시 (watches), 순차 Znode, 쿼럼을 통해 일관적이고 내결함성 있는 운영을 지원한다. Paxos·Raft·2PC 및 gossip 방식 등 다양한 알고리즘이 사용되며, 시스템 설계 시 CAP 정리, 장애 대응, 성능 최적화가 주요 고려 요소다.

✅ 작업 5: 핵심 개념

• Consensus (합의): Paxos, Raft 기반으로 다수 노드가 하나의 상태에 동의
• Leader Election (리더 선출): 쿼럼 기반 프로토콜로 역할 위임
• Distributed Lock (분산 락): 상호 배제 및 동시 수정 방지
• Configuration Management: ZooKeeper, etcd 의 트리 기반 키 - 값 데이터
• Event Notification (감시/watches): 상태 변경 알림 서비스
• Quorum (쿼럼): 다수 노드 허용을 위한 합의 기준
• Atomic Transactions (2PC, 3PC): 분산 환경에서 원자성 보장
• CAP Theorem: 일관성·가용성·분할 내성을 이해하고 설계 시 균형 필요

5.1 실무 연관성

• Paxos/Raft: 리더 선출, 상태 복제 구현
• ZooKeeper/etcd: 서비스 디스커버리, 설정 저장소 구현
• 2PC/3PC: 분산 트랜잭션 처리
• Gossip Protocol: 캐시 무결성, 상태 복제 확산
• CAP 설계 전략: 분할·가용·일관성 간 균형

5. 핵심 개념

• 분산 코디네이션 (Distributed Coordination): 여러 노드가 네트워크 환경에서 공동의 상태나 리소스를 안전하게 관리하고, 일관성 있게 동작하도록 조율하는 기술.
• 합의 (Consensus): 여러 노드가 동일한 결정을 내리도록 보장하는 메커니즘. 예: Paxos, Raft, Zab(ZooKeeper Atomic Broadcast).
• 분산 락 (Distributed Lock): 여러 노드가 동일 리소스에 동시 접근하지 않도록 제어하는 메커니즘.
• 리더 선출 (Leader Election): 시스템 내에서 대표 노드를 선정하여 작업을 위임하거나 조율하도록 하는 과정.
• 장애 감지 (Failure Detection): 노드의 장애를 신속하게 감지하여 시스템의 일관성을 유지하는 기능.

5.1 실무 구현 연관성

• API/서비스 동기화: 마이크로서비스 환경에서 서비스 등록/해제, 구성 변경 시 일관성 보장.
• 분산 락 활용: 크론잡, 자원 할당 등에서 중복 실행 방지.
• 장애 복구: 노드 장애 시 자동으로 리더를 재선출하여 무중단 서비스 제공.
• 데이터 일관성: 분산 DB, 캐시 등에서 데이터 동기화 및 일관성 유지.

5. 핵심 개념

5.1 기본 개념들

분산 합의 (Distributed Consensus)

• 여러 노드가 공통된 값이나 결정에 도달하는 과정
• 안전성 (Safety) 과 활성 (Liveness) 보장 필요
• Byzantine Fault Tolerance (BFT) 와 Crash Fault Tolerance (CFT) 구분

논리적 시계 (Logical Clocks)

• 물리적 시계 동기화 없이 이벤트 순서 결정
• 램포트 타임스탬프와 벡터 클럭으로 구현
• 인과관계 (Causality) 추적 가능

리더 선출 (Leader Election)

• 분산 시스템에서 단일 조정자 선택
• Bully Algorithm, Ring Algorithm 등 다양한 기법
• 장애 탐지와 재선출 메커니즘 포함

상호 배제 (Mutual Exclusion)

• 공유 자원에 대한 독점적 접근 보장
• 토큰 기반과 권한 기반 알고리즘
• 데드락과 기아 상태 방지 필요

5.2 실무 구현 연관성

합의 메커니즘의 실무 구현

• 분산 데이터베이스에서 트랜잭션 일관성 보장
• 블록체인 네트워크의 블록 생성과 검증
• 마이크로서비스 간 상태 동기화

시계 동기화의 실무 적용

• 분산 로깅 시스템의 이벤트 순서 결정
• 분산 트랜잭션의 타임스탬프 기반 충돌 해결
• 실시간 협업 도구의 동시 편집 처리

리더 선출의 실무 활용

• Apache Kafka 의 파티션 리더 관리
• Kubernetes 컨트롤러의 리더 선출
• 분산 캐시 시스템의 마스터 노드 결정

6. 심층 조사 및 분석

6.1 배경

• 분산 시스템은 네트워크 지연, 노드 장애, 메시지 손실 등 다양한 문제에 직면함.
• 단일 장애점 (SPOF, Single Point of Failure) 제거 및 확장성 확보를 위해 분산 코디네이션이 필요.

6.2 목적 및 필요성

• 시스템 신뢰성, 일관성, 가용성 확보.
• 노드 간 협력 및 상태 공유의 안전성 보장.
• 장애 발생 시 빠른 복구 및 서비스 지속성 지원.

6.1 배경 및 필요성

분산 시스템에서는 노드 간의 물리적 분리, 네트워크 지연, 부분적 장애 등으로 인해 전통적인 중앙 집중식 조정 방식이 불가능합니다. 다음과 같은 근본적 문제들을 해결하기 위해 분산 조정이 필요합니다:

• CAP 정리 (CAP Theorem): 일관성 (Consistency), 가용성 (Availability), 분할 내성 (Partition Tolerance) 중 최대 2 개만 동시에 보장 가능
• FLP 불가능성 (FLP Impossibility): 비동기 환경에서 단일 노드 장애 시에도 합의 불가능
• 비잔틴 장군 문제: 악의적 노드 존재 시 합의의 어려움

6.2 주요 기능 및 역할

조정 기능

• 노드 간 일관된 상태 유지
• 충돌하는 연산의 순서 결정
• 장애 노드 탐지 및 복구

동기화 역할

• 분산 트랜잭션 관리
• 공유 자원 접근 제어
• 이벤트 순서 보장

6.3 주요 기능 및 역할

• 분산 락, 리더 선출, 장애 감지, 서비스 디스커버리, 설정 관리, 분산 큐 등.

6.4 특징

• 높은 신뢰성, 내결함성 (Fault Tolerance), 확장성, 강한 일관성 (Strong Consistency) 제공.

6.3 특징

분산성 (Distribution)

• 중앙 조정자 없이 동작
• 노드 간 P2P 통신 기반
• 확장성과 장애 내성 제공

비동기성 (Asynchrony)

• 메시지 전달 시간 보장 없음
• 노드 간 시계 동기화 불필요
• 네트워크 지연 허용

장애 내성 (Fault Tolerance)

• 일부 노드 장애 시에도 동작 지속
• 네트워크 분할 상황 처리
• 악의적 노드 대응 가능

6.4 핵심 원칙

안전성 원칙 (Safety)

• 잘못된 결과 절대 생성 금지
• 일관성 속성 항상 유지
• 무결성 보장

활성 원칙 (Liveness)

• 진행 상황 보장
• 최종적 합의 도달
• 교착 상태 방지

공정성 원칙 (Fairness)

• 모든 노드에 균등한 기회 제공
• 기아 상태 방지
• 우선순위 공정 분배

6.5 핵심 원칙

• CAP 이론 (Consistency, Availability, Partition tolerance) 에서 일관성 및 파티션 허용성을 중시.
• 합의 알고리즘 기반의 상태 동기화.

6.6 주요 원리

• Paxos, Raft, Zab 등 분산 합의 알고리즘 활용.
• 노드 간 상태 복제 및 로그 동기화.

6.7 작동 원리 및 방식

sequenceDiagram
    participant NodeA
    participant NodeB
    participant NodeC
    NodeA->>NodeB: Lock 요청
    NodeB->>NodeC: Lock 상태 확인
    NodeC-->>NodeB: 상태 반환
    NodeB-->>NodeA: Lock 허용/거부 응답

• 각 노드는 상태를 공유하며, 합의 알고리즘을 통해 결정된 리더가 코디네이션 역할을 수행.

6.5 주요 원리와 작동 방식

합의 알고리즘 원리

sequenceDiagram
    participant P1 as Proposer
    participant A1 as Acceptor 1
    participant A2 as Acceptor 2
    participant A3 as Acceptor 3
    participant L as Learner

    Note over P1,L: Paxos 합의 프로토콜
    
    P1->>A1: Prepare(n)
    P1->>A2: Prepare(n)
    P1->>A3: Prepare(n)
    
    A1->>P1: Promise(n, v1)
    A2->>P1: Promise(n, v2)
    A3->>P1: Promise(n, null)
    
    P1->>A1: Accept(n, v)
    P1->>A2: Accept(n, v)
    P1->>A3: Accept(n, v)
    
    A1->>L: Accepted(n, v)
    A2->>L: Accepted(n, v)
    A3->>L: Accepted(n, v)
    
    Note over L: 합의 완료

논리적 시계 동작 원리

graph TD
    A[Process A<br/>Clock: 1] -->|Event| B[Process A<br/>Clock: 2]
    B -->|Send Msg<br/>T=3| D[Process B<br/>Clock: max(1,3)+1=4]
    C[Process B<br/>Clock: 1] --> D
    D -->|Event| E[Process B<br/>Clock: 5]
    
    F[Process C<br/>Clock: 1] -->|Event| G[Process C<br/>Clock: 2]
    G -->|Send Msg<br/>T=3| H[Process A<br/>Clock: max(2,3)+1=4]
    B --> H

2. 주요 원리 및 작동 방식

원리 요약

1. Leader Election: ZAB 나 Paxos/Raft 스타일로 쿼럼 기반 leader 선출
2. Atomic Broadcast: write 요청 시 leader→followers 에 전파, 다수 응답 후 commit
3. Log Ordering: zxid(글로벌 트랜잭션 ID) 로 모든 변경 순서 보장 (nofluffjuststuff.com)
4. Watch Mechanism: 상태 변경 시 이벤트 알림 → client 가 재등록 필요 (tutorialspoint.com)
5. Quorum 기반: read 엔 가용성, write 엔 consistency 보장 → CAP 정리에 따른 설계 균형 (en.wikipedia.org)

작동 흐름

sequenceDiagram
  Client->>ZooKeeper: write /app/config, register watch
  ZooKeeper Leader->>Followers: AppendEntry(zxid, data)
  Followers-->>Leader: ACK
  alt 쿼럼 응답 도달
    Leader->>Client: Commit OK
    Leader->>Followers: Commit broadcast
  end
  Note right of Client: Client receives watch events on changes

6.8 구조 및 아키텍처

아키텍처 다이어그램

graph TD
    Client1 -- Request --> Coordination-Service
    Client2 -- Request --> Coordination-Service
    Coordination-Service -- Sync --> Node1
    Coordination-Service -- Sync --> Node2
    Coordination-Service -- Sync --> Node3
    Node1 -- Heartbeat --> Coordination-Service
    Node2 -- Heartbeat --> Coordination-Service
    Node3 -- Heartbeat --> Coordination-Service

구성 요소 및 역할

필수/선택 구성 요소

6.6 구조 및 아키텍처

필수 구성요소

선택 구성요소

전체 아키텍처

graph TB
    subgraph "분산 조정 아키텍처"
        subgraph "애플리케이션 계층"
            APP[애플리케이션]
        end
        
        subgraph "조정 계층"
            CON[합의 엔진]
            LE[리더 선출기]
            ME[상호 배제 관리자]
            LC[논리적 시계]
        end
        
        subgraph "통신 계층"
            MP[메시지 전달]
            FD[장애 탐지기]
            NT[네트워크 토폴로지]
        end
        
        subgraph "저장 계층"
            LOG[합의 로그]
            STATE[상태 저장소]
        end
    end
    
    APP --> CON
    APP --> LE
    APP --> ME
    CON --> LC
    CON --> MP
    LE --> FD
    ME --> MP
    MP --> NT
    CON --> LOG
    CON --> STATE

1. 구조 및 아키텍처 + 구성 요소

🧩 ZooKeeper 아키텍처 다이어그램

graph LR
  subgraph Ensemble
    Leader
    Follower1
    Follower2
  end
  Client-->Leader
  Client-->Follower1
  Client-->Follower2
  Leader-->Follower1
  Leader-->Follower2
  Follower1-->Leader
  Follower2-->Leader

구성 요소 및 역할

• Ensemble: 최소 3 개의 서버로 구성된 클러스터, 일관성과 내결함성 보장 (en.wikipedia.org, tutorialspoint.com)
• Leader: 쓰기 요청 처리, 로그 순차적 배포 (ZAB/ZAB Atomic Broadcast)
• Followers: 읽기 요청 수행, leader 와 동기화, 쿼럼 형성에 참여
• Client: 세션 유지 (heartbeat), 요청 (읽기·쓰 기), watch 등록 기능 ��citeturn0search16turn0search22
• ZNode: 계층적 상태 저장소, persistent/ephemeral/sequence 타입 존재 (numberanalytics.com)
• Watch: 변경 알림 메커니즘, 일회성이며 재등록 필요
• ZAB 프로토콜: 원자 브로드캐스트, 쓰기 일관성 및 leader fail-over 시 복구 지원 (en.wikipedia.org)

3. 구현 기법

• ZAB (ZooKeeper Atomic Broadcast): leader 선출 + 순차적 로그 복제
• ZNode 계층 구조: 설정, 락, 노드 등록 등에 활용
• Watch 등록 및 이벤트 처리: Pub/sub 스타일의 상태 변경 통보
• Ephemeral ZNode: client 연결 기반 임시 노드 활용 → 서비스 디스커버리, 리더 election 구현
• Sequential ZNode: 순차적 순번 생성 → 분산 락, barrier 구현에 사용

6.9 구현 기법

6.7 구현 기법

Paxos 알고리즘 구현

• 정의: 비동기 환경에서 노드 장애를 허용하는 합의 알고리즘
• 구성: Proposer, Acceptor, Learner 역할 분리
• 목적: 안전성 보장하며 단일 값에 대한 합의 달성
• 실제 예시: Google Chubby, Apache Cassandra

Raft 알고리즘 구현

• 정의: 이해하기 쉬운 리더 기반 합의 알고리즘
• 구성: Leader, Follower, Candidate 상태 기계
• 목적: Paxos 대비 구현 복잡도 감소
• 실제 예시: etcd, Consul, TiKV

벡터 클럭 구현

• 정의: 분산 시스템에서 인과관계 추적하는 논리적 시계
• 구성: 각 프로세스별 카운터 벡터
• 목적: 동시 이벤트 탐지 및 인과관계 보존
• 실제 예시: Amazon DynamoDB, Riak

토큰 기반 상호 배제

• 정의: 토큰 소유자만 임계 영역 접근 허용
• 구성: 토큰 순환 메커니즘
• 목적: 데드락 없는 상호 배제 보장
• 실제 예시: Raymond’s Algorithm, Suzuki-Kasami Algorithm

12. Paxos Vs Raft Vs ZAB 비교

📊 비교표

📌 분석 요약

• Paxos는 이론적으로 안전하지만 구현 및 이해가 어려움.
• Raft는 실무 적용에 인기 높은 대체재로, 후보 선출 (term), AppendEntries 등을 단순화하여 부담 최소화.
• ZAB는 ZooKeeper 용으로 설계돼 Raft 와 유사하나 ZNode 기반 트리 구조에 최적화됨.

13. 2PC 및 3PC 분산 트랜잭션 프로토콜

🧩 2 단계 커밋 (2PC)

1. prepare 단계: coordinator -> 참가자들, 준비 여부 요청
2. commit 단계: 모두 OK 면 commit, 아니면 rollback
3. 장애 시 blocking 문제: 한 참가자 실패 시 전체 정지

🛡 3 단계 커밋 (3PC)

• pre-commit 단계 추가: commit 확신 단계로 non-blocking 목표
• 네트워크 파티션 대응 강화
• 하지만 여전히 복잡하며 실제 도입은 적음

14. CAP 트레이드오프 설계

분산 조정에서 CAP 일관성 (Consistency), 가용성 (Availability), 파티션 내성 (Partition Tolerance) 간 균형을 맞추는 설계 전략입니다.

🔍 선택 기준

설계 시 고려사항

• 사용 패턴: 읽기 중심 vs 쓰기 중심
• 장애 유형: 장애 빈도, 영향 범위
• 일관성 모델: linearizability → CP, eventual consistency → AP

✅ 다음 단계 안내

이제 주요 주제인 분산 조정 내부 메커니즘 (Paxos/Raft/ZAB), 분산 트랜잭션 (2PC/3PC), CAP 이론 설계까지 정리되었습니다.
필요하다면 다음과 같은 심화 내용을 제공할 수 있습니다:

• Java/Python 기반 Paxos·Raft 실전 구현 코드
• 2PC/3PC 트랜잭션 시뮬레이션 및 장애 복구 로직
• 특정 환경 (CI/CD, 마이크로서비스) 에서 CAP 트레이드오프 문서 예제

필요한 주제나 추가 항목을 말씀해 주세요.

이번에는 Paxos 의 구조 및 코드 구현 예시, Raft 구현 간략 소개, 그리고 분산 트랜잭션 (2PC/3PC) 의 Java 기반 시뮬레이션 개념 코드를 중심으로 심층 분석합니다.

15. Paxos 구현 예시 (Python)

🧩 구성 요소

• Proposer: 제안자, 값을 제안하고 다수 응답을 기다림
• Acceptor: 승낙자, 제안을 저장하고 응답
• Learner: 학습자, 합의 결과를 수신

🧭 메시지 흐름 다이어그램 (mermaid)

sequenceDiagram
  Proposer->>Acceptor: PREPARE(n)
  Acceptor-->>Proposer: PROMISE(n, last_accepted)
  Proposer->>Acceptor: ACCEPT(n, value)
  Acceptor-->>Proposer: ACCEPTED(n)
  Proposer->>Learner: COMMIT(value)

🧑‍💻 Python 코드 예시 (단순 버전)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

import threading
import random

class Acceptor:
    def __init__(self, name):
        self.name = name
        self.promised_n = 0
        self.accepted = (None, None)  # (n, value)
    def on_prepare(self, n):
        if n > self.promised_n:
            self.promised_n = n
            return True, self.accepted
        return False, self.accepted
    def on_accept(self, n, value):
        if n >= self.promised_n:
            self.promised_n = n
            self.accepted = (n, value)
            return True
        return False

class Proposer:
    def __init__(self, proposer_id, acceptors):
        self.n = proposer_id
        self.acceptors = acceptors
        self.majority = len(acceptors)//2 + 1
    def propose(self, value):
        promises = []
        highest = (0, None)
        for a in self.acceptors:
            ok, (n2, v2) = a.on_prepare(self.n)
            if ok:
                promises.append(a)
                if v2 and v2[0] > highest[0]:
                    highest = v2
        if len(promises) < self.majority:
            return False
        chosen = highest[1] or value
        accepts = sum(a.on_accept(self.n, chosen) for a in promises)
        if accepts >= self.majority:
            for a in promises:
                pass  # learner 통보 생략
            print(f"Value chosen: {chosen}")
            return True
        return False

# 테스트 코드
acceptors = [Acceptor(f"A{i}") for i in range(5)]
p = Proposer(1, acceptors)
p.propose("Alpha")

설명:

• prepare 단계에서 다수 응답 확보
• accept 단계에서 값 승인 후 다수에게 commit

실무에서는 네트워크 통신, 장애 처리, 재전송, QoS 로직 등을 추가해야 합니다.

16. Raft 구현 개요

• Leader election via term & Vote RPC
• AppendEntries RPC로 로그 복제
• Commit index 관리 및 Snapshot 과 압축 기능
• etcd, Consul 등에서 라이브러리 제공

직접 구현보다 hashicorp/raft (Go), raftos (Python) 과 같은 오픈소스 활용을 권장합니다.

17. 2PC/3PC Java 기반 시뮬레이션 개념 코드

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// Coordinator 역할: Prepare, Commit/Abort
public class Coordinator {
    List<Participant> parts;
    public boolean twoPhaseCommit() {
        boolean allOk = parts.stream().allMatch(p -> p.prepare());
        parts.forEach(p -> { if(allOk) p.commit(); else p.abort(); });
        return allOk;
    }
}
// Participant 역할: 분산 트랜잭션 참가자
public class Participant {
    String name;
    public boolean prepare() {
        return new Random().nextBoolean();  // 랜덤 준비 상태
    }
    public void commit(){ System.out.println(name + " commit"); }
    public void abort(){ System.out.println(name + " abort"); }
}
// 실행
public static void main(String[] args){
    Coordinator c = new Coordinator();
    c.parts = Arrays.asList(new Participant("P1"), new Participant("P2"));
    boolean ok = c.twoPhaseCommit();
    System.out.println("Global " + (ok ? "Commit" : "Abort"));
}

3PC 는 여기에 pre-commit 단계를 추가해 비차단성을 목표로 확장할 수 있습니다.

18. CAP 설계 문서화 예시

1
2
3
4
5
6
7
8
9

### [서비스 X]의 CAP 트레이드오프 분석

| 요구사항         | 선택 요소 | 이유 |
|------------------|----------|------|
| 데이터 일관성 필요 | C (Consistency) | 금융 거래 로그 정확성 때문 |
| 분산 환경 운영 | P (Partition tolerance) | 멀티 리전 구성 시 가용성 유지 |
| 가용성 | 약간 희생 | 네트워크 분할 시 일관성 우선 보장 |

→ 설계: CP 시스템 채택 (예: etcd, ZooKeeper), 분할 복제, leader 읽기 중심 방식

이로써 Paxos 구현, Raft 개요, Java 기반 2PC 예시, CAP 설계 문서화까지 마무리했습니다. 더 알고 싶은 내용 (예: log compaction, 장애 회복, 프로토콜 시뮬레이션 도구, Java Curator 레시피 등) 이 있다면 말씀해주세요!

6.8 장점

7. 장점

장점

단점 및 문제점

8. 단점과 문제점 그리고 해결방안

단점

문제점

6.9 단점과 문제점 그리고 해결방안

단점

문제점

7. 도전 과제

실무 환경 및 기술 트렌드를 반영해 다음과 같이 정리했습니다.

12. 도전 과제

6.10 도전 과제

성능 최적화 과제

• 원인: 합의 과정의 네트워크 라운드트립 오버헤드
• 영향: 시스템 응답 시간 증가, 처리량 감소
• 해결 방법: Multi-Paxos, 배칭, 파이프라이닝 기법

확장성 과제

• 원인: 노드 수 증가에 따른 통신 복잡도 O(n²) 증가
• 영향: 대규모 시스템에서 성능 저하
• 해결 방법: 계층적 합의, 위원회 기반 프로토콜

보안 과제

• 원인: 악의적 노드나 네트워크 공격 위협
• 영향: 시스템 무결성 침해 가능성
• 해결 방법: BFT 알고리즘, 암호학적 서명

6. 분류 기준에 따른 종류 및 유형

(제목 변경: " 분류 기준에 따른 종류 및 유형 " (기존: " 분류 기준에 따른 종류 및 유형 “))

13. 분류 기준에 따른 종류 및 유형

6.11 분류 기준에 따른 종류 및 유형

6.12 실무 사용 예시

9. 실무 사용 예시

8. 실무 사용 예시

9. 활용 사례: 서비스 디스커버리 (ZooKeeper 기반)

시나리오

마이크로서비스 A, B, C 가 ZooKeeper 를 통해 서로를 발견 (Discover) 하고 통신.

구성도 (mermaid)

flowchart LR
  subgraph ZooKeeper-Ensemble
    Z1[Leader]
    Z2[Follower]
    Z3[Follower]
  end
  ServiceA --> Zk(creates /services/A/1)
  ServiceB --> Zk(creates /services/B/1)
  ServiceC --> Zk(watches /services)
  Z2 -- Notify --> ServiceC

Workflow

1. A, B 가 /services/A/1, /services/B/1 Ephemeral ZNode 등록
2. C 는 /services 디렉토리를 watch
3. A 또는 B 시작/종료 시 C 는 이벤트 수신
4. C 는 서비스 주소를 업데이트하고 consumer or router 에 반영

역할

• Ephemeral ZNode: 마이크로서비스 registry
• Watcher: 동적 서비스 탐색
• 쿼럼 Root: 장애 발생 시 ensemble 에서 서비스 변경 가용 보장

차이

• 디스커버리 기능 제외 시 C 는 수동 조회 필요 → 자동화 미지원, 장애 감지 지연

10. 활용 사례

사례: 마이크로서비스 환경에서 ZooKeeper 를 통한 서비스 디스커버리 및 리더 선출

• 시스템 구성: 여러 마이크로서비스 인스턴스, ZooKeeper 클러스터, 클라이언트
• 워크플로우:
  1. 각 서비스 인스턴스가 ZooKeeper 에 자신의 상태 등록
  2. ZooKeeper 가 서비스 상태를 모니터링하며, 장애 발생 시 자동으로 리더 선출
  3. 클라이언트는 ZooKeeper 를 통해 현재 가용한 서비스 목록을 조회
• 다이어그램:

graph LR
    S1[Service 1] --> ZK[ZooKeeper]
    S2[Service 2] --> ZK
    S3[Service 3] --> ZK
    ZK --> C[Client]

• 주제의 역할: 서비스 상태 동기화, 장애 시 리더 자동 선출, 서비스 목록 제공
• 유무 차이: 분산 코디네이션이 없으면 서비스 장애 시 수동 복구 필요, 일관성 저하

6.13 활용 사례

Apache Kafka 의 분산 조정 활용

Kafka 는 대규모 실시간 데이터 스트리밍을 위해 분산 조정을 핵심적으로 활용합니다.

시스템 구성:

• Kafka Cluster: 여러 브로커 노드로 구성
• Zookeeper Ensemble: 메타데이터 관리 및 조정 서비스
• Producer/Consumer: 데이터 생산/소비 클라이언트

시스템 구성 다이어그램:

graph TB
    subgraph "Kafka 클러스터"
        B1[Broker 1<br/>Leader for P1]
        B2[Broker 2<br/>Leader for P2]
        B3[Broker 3<br/>Follower]
    end
    
    subgraph "Zookeeper 앙상블"
        Z1[Zookeeper 1]
        Z2[Zookeeper 2] 
        Z3[Zookeeper 3]
    end
    
    subgraph "클라이언트"
        P[Producer]
        C[Consumer]
    end
    
    B1 <--> Z1
    B2 <--> Z2
    B3 <--> Z3
    Z1 <--> Z2
    Z2 <--> Z3
    Z3 <--> Z1
    
    P --> B1
    P --> B2
    B1 --> C
    B2 --> C

활용 사례 Workflow:

sequenceDiagram
    participant P as Producer
    participant B1 as Broker 1 (Leader)
    participant B2 as Broker 2 (Follower)
    participant Z as Zookeeper
    participant C as Consumer

    Note over P,C: Kafka 분산 조정 워크플로우
    
    P->>Z: 메타데이터 요청
    Z->>P: 파티션 리더 정보 반환
    
    P->>B1: 메시지 전송
    B1->>B2: 복제 동기화
    B2->>B1: ACK
    B1->>P: 전송 완료
    
    Note over B1,B2: 리더 장애 시
    B1--XB2: 연결 끊어짐
    B2->>Z: 리더 장애 감지
    Z->>B2: 새 리더로 선출
    
    C->>Z: 새 리더 정보 요청
    Z->>C: 업데이트된 메타데이터
    C->>B2: 메시지 소비

분산 조정의 역할:

1. 리더 선출: 각 파티션의 리더 브로커 결정
2. 메타데이터 일관성: 토픽, 파티션 정보 동기화
3. 장애 복구: 브로커 장애 시 자동 failover
4. 부하 분산: 파티션 재분배를 통한 균등 분산

분산 조정 유무에 따른 차이점:

6.14 구현 예시

다음은 Kafka 와 유사한 분산 메시지 브로커에서 리더 선출을 구현하는 Python 예제입니다:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168

import time
import threading
import random
from enum import Enum
from typing import Dict, List, Optional

class NodeState(Enum):
    """노드 상태 정의"""
    FOLLOWER = "follower"      # 팔로워 상태
    CANDIDATE = "candidate"    # 후보자 상태  
    LEADER = "leader"         # 리더 상태

class DistributedBroker:
    """분산 메시지 브로커의 분산 조정 구현"""
    
    def __init__(self, node_id: int, cluster_nodes: List[int]):
        self.node_id = node_id                    # 현재 노드 ID
        self.cluster_nodes = cluster_nodes        # 클러스터 내 모든 노드 ID
        self.state = NodeState.FOLLOWER          # 초기 상태는 팔로워
        self.current_term = 0                    # 현재 선출 주기
        self.voted_for = None                    # 투표한 후보
        self.leader_id = None                    # 현재 리더 ID
        self.last_heartbeat = time.time()        # 마지막 하트비트 시간
        self.election_timeout = random.uniform(5, 10)  # 선출 타임아웃 (초)
        self.heartbeat_interval = 2              # 하트비트 간격 (초)
        self.votes_received = 0                  # 받은 투표 수
        self.running = False                     # 실행 상태
        
    def start(self):
        """브로커 노드 시작"""
        self.running = True
        self.last_heartbeat = time.time()
        
        # 백그라운드 스레드에서 선출 타이머 실행
        threading.Thread(target=self._election_timer, daemon=True).start()
        
        print(f"[Node {self.node_id}] 브로커 시작됨 - 상태: {self.state.value}")
    
    def _election_timer(self):
        """선출 타이머 - 리더 부재 시 새 선출 시작"""
        while self.running:
            time.sleep(1)
            
            # 팔로워이고 하트비트 타임아웃 발생 시 선출 시작
            if (self.state == NodeState.FOLLOWER and 
                time.time() - self.last_heartbeat > self.election_timeout):
                self._start_election()
    
    def _start_election(self):
        """새로운 리더 선출 시작"""
        self.state = NodeState.CANDIDATE
        self.current_term += 1
        self.voted_for = self.node_id
        self.votes_received = 1  # 자신에게 투표
        
        print(f"[Node {self.node_id}] 선출 시작 - Term: {self.current_term}")
        
        # 다른 노드들에게 투표 요청
        for node_id in self.cluster_nodes:
            if node_id != self.node_id:
                self._request_vote(node_id)
        
        # 과반수 득표 시 리더가 됨
        majority = len(self.cluster_nodes) // 2 + 1
        if self.votes_received >= majority:
            self._become_leader()
    
    def _request_vote(self, target_node: int):
        """다른 노드에게 투표 요청 (실제로는 네트워크 통신)"""
        # 실제 구현에서는 네트워크를 통해 투표 요청 메시지 전송
        # 여기서는 시뮬레이션을 위해 확률적으로 투표 승인
        vote_granted = random.choice([True, False])
        
        if vote_granted:
            self.votes_received += 1
            print(f"[Node {self.node_id}] Node {target_node}로부터 투표 획득")
    
    def _become_leader(self):
        """리더로 상태 변경"""
        self.state = NodeState.LEADER
        self.leader_id = self.node_id
        
        print(f"[Node {self.node_id}] 리더로 선출됨! Term: {self.current_term}")
        
        # 리더는 주기적으로 하트비트 전송
        threading.Thread(target=self._send_heartbeat, daemon=True).start()
    
    def _send_heartbeat(self):
        """리더가 팔로워들에게 하트비트 전송"""
        while self.running and self.state == NodeState.LEADER:
            # 모든 팔로워에게 하트비트 전송
            for node_id in self.cluster_nodes:
                if node_id != self.node_id:
                    self._send_heartbeat_to_node(node_id)
            
            time.sleep(self.heartbeat_interval)
    
    def _send_heartbeat_to_node(self, target_node: int):
        """특정 노드에게 하트비트 전송"""
        print(f"[Node {self.node_id}] 하트비트 전송 -> Node {target_node}")
        # 실제로는 네트워크를 통해 하트비트 메시지 전송
    
    def receive_heartbeat(self, leader_id: int, term: int):
        """다른 노드로부터 하트비트 수신"""
        if term >= self.current_term:
            self.current_term = term
            self.state = NodeState.FOLLOWER
            self.leader_id = leader_id
            self.last_heartbeat = time.time()
            self.voted_for = None
            
            print(f"[Node {self.node_id}] 리더 {leader_id}로부터 하트비트 수신")
    
    def handle_partition_request(self, topic: str, partition: int, message: str):
        """파티션 메시지 처리 (리더만 처리 가능)"""
        if self.state != NodeState.LEADER:
            return {"error": "Not a leader", "leader_id": self.leader_id}
        
        # 리더만 메시지 처리 및 팔로워들에게 복제
        print(f"[Node {self.node_id}] 메시지 처리: {topic}:{partition} -> {message}")
        
        # 팔로워들에게 복제 요청
        self._replicate_to_followers(topic, partition, message)
        
        return {"status": "success", "leader_id": self.node_id}
    
    def _replicate_to_followers(self, topic: str, partition: int, message: str):
        """팔로워 노드들에게 메시지 복제"""
        for node_id in self.cluster_nodes:
            if node_id != self.node_id:
                print(f"[Node {self.node_id}] 복제 전송 -> Node {node_id}: {message}")
                # 실제로는 네트워크를 통해 복제 메시지 전송
    
    def get_cluster_status(self) -> Dict:
        """클러스터 상태 정보 반환"""
        return {
            "node_id": self.node_id,
            "state": self.state.value,
            "term": self.current_term,
            "leader_id": self.leader_id,
            "cluster_size": len(self.cluster_nodes)
        }

# 사용 예시
if __name__ == "__main__":
    # 3노드 클러스터 생성
    cluster_nodes = [1, 2, 3]
    
    # 각 노드 생성 및 시작
    brokers = []
    for node_id in cluster_nodes:
        broker = DistributedBroker(node_id, cluster_nodes)
        broker.start()
        brokers.append(broker)
    
    # 시뮬레이션 실행
    time.sleep(15)  # 15초 동안 실행
    
    # 클러스터 상태 출력
    for broker in brokers:
        status = broker.get_cluster_status()
        print(f"노드 {status['node_id']}: {status['state']} (Term: {status['term']}, Leader: {status['leader_id']})")
    
    # 리더에게 메시지 전송 테스트
    leader_broker = next((b for b in brokers if b.state == NodeState.LEADER), None)
    if leader_broker:
        result = leader_broker.handle_partition_request("user-events", 0, "User login event")
        print(f"메시지 처리 결과: {result}")

10. 구현 예시 (Python)

ZooKeeper 기반 분산 락 예시—kazoo 라이브러리 사용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

from kazoo.client import KazooClient
from kazoo.recipe.lock import Lock

zk = KazooClient(hosts='127.0.0.1:2181')
zk.start()

lock = Lock(zk, "/distributed_lock/mylock")
if lock.acquire(timeout=10):
    try:
        # 임계 영역 작업 수행
        print("Lock acquired, critical task executing")
    finally:
        lock.release()
        print("Lock released")
else:
    print("Timeout: Could not acquire lock")

zk.stop()

• kazoo 의 Lock 은 내부적으로 sequence znode 와 watch 를 사용하여 fair, deadlock-free 락 제공
• 실무에서는 재시도 로직, 타임아웃, 예외 처리, 세션유지/재연결 관리를 추가할 것을 권장

11. 구현 예시 (Python)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# ZooKeeper를 이용한 분산 락 구현 예시
from kazoo.client import KazooClient

# ZooKeeper 서버 연결
zk = KazooClient(hosts='127.0.0.1:2181')
zk.start()

# 분산 락 획득
lock = zk.Lock("/mylockpath", "my-identifier")
with lock:  # 락 획득 및 자동 해제
    # 락이 잡힌 상태에서 실행할 코드
    print("임계구역 진입")

zk.stop()

설명: Kazoo 는 Python 용 ZooKeeper 클라이언트 라이브러리. 위 코드는 분산 락을 획득하여 임계구역을 안전하게 처리하는 예시.

5. 실무 적용 시 주의사항

• Ensemble 크기: odd-number 최소 3, 장애 허용 필요 노드 수 ≥ quorum
• Client 재연결 대응: 세션 타임아웃/재연결 시 ephemeral ZNode 삭제 주의
• Watch 처리: 재등록 로직과 누락 대응 설계 필수
• 비즈니스 목적에 적절한 consistency 설정: 읽기 일관성 요구 시 leader 픽
• 로그 스냅샷 주기 관리: 디스크 사용량 최적화, 복구 성능 확보

14. 실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

A. 적용 고려사항

6.15 실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

6.16 최적화하기 위한 고려사항 및 주의할 점

B. 최적화 고려사항

15. 최적화하기 위한 고려사항 및 주의할 점

16. 기타 사항

• 최신 트렌드로는 클라우드 네이티브 환경에서 etcd, Consul, ZooKeeper 의 활용이 증가.
• 서비스 메시 (Service Mesh) 와의 연계, 컨테이너 오케스트레이션 (Kubernetes 등) 에서의 필수 요소로 자리잡음.

주제와 관련하여 주목할 내용

✅ 작업 9: 주목할 내용 정리

7. 주제와 관련하여 주목할 내용

8. 반드시 학습해야할 내용

✅ 작업 10: 반드시 학습할 내용

반드시 학습해야할 내용

용어 정리

용어 정리

용어 정리

참고 및 출처

• Distributed Consensus in Distributed Systems - GeeksforGeeks
• GitHub - Distributed Consensus Reading List
• A Survey of Distributed Consensus Protocols for Blockchain Networks
• Raft and Paxos: Consensus Algorithms for Distributed Systems - Medium
• Leader Election in Distributed Systems - Amazon Builders’ Library
• Clock Synchronization in Distributed Systems - GeeksforGeeks
• Vector Clocks in Distributed Systems - GeeksforGeeks
• Lamport’s Logical Clock - GeeksforGeeks
• Consensus Mechanisms - Ethereum.org
• Distributed Coordination Algorithms - Eax360

참고 및 출처

• Paxos (computer science) (cs.umbc.edu, restate.dev, geeksforgeeks.org, medium.com, en.wikipedia.org, en.wikipedia.org)
• CAP theorem
• Gossip protocol
• Distributed Coordination-Based Systems (GeeksforGeeks) (geeksforgeeks.org)

참고 및 출처

• ZooKeeper 공식 문서
• etcd 공식 문서
• Consul 공식 문서
• Paxos Algorithm 설명
• Raft Consensus Algorithm
• CAP Theorem 설명