Gossip Protocol vs Raft

분산 시스템에서 노드 간 정보를 전파하는 방식은 크게 두 가지로 나뉜다. 모든 노드가 평등하게 소문을 퍼뜨리는 Gossip Protocol과, 리더를 선출하여 합의를 이끄는 Raft이다.

둘은 해결하려는 문제 자체가 다르다. Gossip은 “정보 전파”에, Raft는 “합의(consensus)“에 초점을 맞춘다. 그러나 실무에서는 같은 분산 시스템 안에서 함께 사용되기도 하고, 하나를 선택해야 하는 상황도 있다. 각각의 동작 원리와 trade-off를 비교한다.

Gossip Protocol

기본 원리

Gossip Protocol은 이름 그대로 소문이 퍼지는 방식으로 동작한다. 전염병 확산 모델에서 영감을 받아 Epidemic Protocol이라고도 불린다.

1. 각 노드는 주기적으로 클러스터 내 무작위 노드를 선택하여 자신이 알고 있는 상태 정보를 전달한다
2. 정보를 받은 노드는 자신의 상태와 병합(merge)하고, 다음 주기에 또 다른 무작위 노드에게 전달한다
3. 이 과정이 반복되면 모든 노드가 결국 같은 정보를 갖게 된다

중앙 코디네이터가 없다. 모든 노드가 동등하게 정보를 전파하는 탈중앙화 구조이다.

전파 속도

N개의 노드가 있을 때, 하나의 정보가 전체에 전파되는 데 필요한 라운드 수는 O(log N) 이다.

각 라운드마다 정보를 아는 노드 수가 대략 2배로 증가하기 때문이다. 1000대의 노드가 있어도 약 10라운드면 전체에 전파된다. 라운드 주기가 1초라면 약 10초이다.

전파 방식의 분류

Gossip의 전파 방식은 크게 세 가지로 나뉜다.

• Push: 새 정보가 생기면 무작위 노드에게 전달한다. 초기 전파가 빠르다
• Pull: 주기적으로 무작위 노드에게 “새로운 정보 있나?”고 묻는다. 대부분의 노드가 이미 정보를 가진 후반부에 효율적이다
• Push-Pull: 양쪽이 서로의 정보를 교환한다. 가장 빠르게 수렴하며, 실무에서 가장 많이 쓰인다

장애 감지

Gossip Protocol의 핵심 활용처 중 하나가 장애 감지(Failure Detection) 이다.

1. 노드 A가 노드 B에게 PING을 보낸다
2. 일정 시간 내 응답이 없으면 A는 B를 의심(suspect) 상태로 마킹한다
3. A가 Gossip으로 “B가 의심스럽다”는 정보를 전파한다
4. 다른 노드들도 B에게 직접 확인을 시도한다
5. 일정 수 이상의 노드가 B를 의심하면 B를 장애(failed) 로 판정한다

단일 노드의 판단에 의존하지 않고 여러 노드의 관찰을 종합하므로, 네트워크 일시 장애로 인한 오탐(false positive)을 줄일 수 있다.

사용 사례

시스템	Gossip 활용
Redis Cluster	클러스터 상태 전파, PFAIL/FAIL 장애 감지
Cassandra	노드 멤버십 관리, 장애 감지
Consul	Serf(Gossip 라이브러리) 기반 멤버십 관리
DynamoDB	멤버십, 장애 감지

Raft

Raft Consensus Algorithm에서 상세히 다뤘으므로, 여기서는 Gossip과의 비교에 필요한 핵심만 정리한다.

핵심 구조

• 리더 기반: 하나의 리더가 선출되고, 모든 쓰기는 리더를 통해서만 이루어진다
• 로그 복제: 리더가 로그 엔트리를 Follower에게 복제하고, 과반수 확인 후 커밋한다
• 강한 정합성: 커밋된 엔트리는 이후 모든 리더의 로그에 반드시 존재한다 (Leader Completeness)

사용 사례

시스템	Raft 활용
etcd	Kubernetes의 클러스터 상태 저장소
Kafka (KRaft)	Controller 선출, 메타데이터 관리
CockroachDB	Range 단위 데이터 복제
Consul	KV 저장소의 데이터 복제 (Gossip과 병행 사용)

비교

해결하는 문제가 다르다

이 둘을 비교할 때 가장 먼저 이해해야 하는 것은, 해결하려는 문제 자체가 다르다는 점이다.

• Gossip: “클러스터의 모든 노드가 결국 같은 정보를 갖게 하라” (정보 전파)
• Raft: “클러스터의 모든 노드가 같은 순서로 같은 결정에 합의하라” (합의)

Gossip은 “결국(eventually)” 수렴하면 되고, Raft는 “즉시(immediately)” 합의해야 한다. 이 차이가 모든 설계 차이의 근원이다.

정합성

• Gossip: Eventual Consistency. 전파에 시간이 걸리므로, 특정 시점에 노드마다 다른 정보를 가질 수 있다. 결국에는 수렴한다
• Raft: Strong Consistency. 커밋된 데이터는 과반수가 확인한 것이므로, 리더를 통해 읽으면 항상 최신 데이터를 얻는다

리더의 유무

• Gossip: 리더가 없다. 모든 노드가 동등하다. 따라서 단일 장애점(SPOF)이 없다
• Raft: 리더가 있다. 리더가 죽으면 새 리더를 선출할 때까지 쓰기가 불가하다. 다만 자동 선출되므로 SPOF는 아니다

확장성

• Gossip: 수천 대 이상으로 확장 가능하다. 각 노드가 매 주기마다 일부 노드에게만 통신하므로, 노드 수가 늘어도 개별 노드의 부하는 크게 증가하지 않는다. 전파 시간은 O(log N)으로 느리게 증가한다
• Raft: 일반적으로 3~7대의 소규모 클러스터에 적합하다. 모든 쓰기가 과반수 응답을 기다려야 하므로, 노드가 많아질수록 쓰기 지연이 증가한다

네트워크 비용

• Gossip: 각 노드가 주기마다 소수의 노드에게만 메시지를 보낸다. 전체 통신량은 O(N)이다
• Raft: 리더가 모든 Follower에게 AppendEntries를 보낸다. 리더의 통신량이 O(N)이고, 리더에 부하가 집중된다

장애 허용

• Gossip: 노드가 일부 죽어도 나머지가 계속 전파한다. 과반수 같은 제약이 없어 소수만 살아있어도 동작한다
• Raft: 과반수가 살아있어야 한다. 5대 중 3대 이상, 3대 중 2대 이상이 정상이어야 쓰기가 가능하다

전체 비교 요약

	Gossip	Raft
목적	정보 전파	합의 (consensus)
정합성	Eventual	Strong
리더	없음 (탈중앙화)	있음 (리더 기반)
확장성	수천 대	3~7대
전파/합의 속도	O(log N) 라운드	즉시 (1 RTT)
장애 허용	소수만 살아도 동작	과반수 필요
순서 보장	없음	있음 (로그 순서)
적합한 용도	멤버십, 장애 감지, 상태 전파	데이터 복제, 리더 선출, 설정 저장

함께 사용되는 경우

Gossip과 Raft는 배타적이지 않다. 오히려 같은 시스템 안에서 역할을 나눠 함께 사용하는 경우가 많다.

Consul이 대표적이다:

• Gossip (Serf): 수백~수천 대의 노드 멤버십 관리, 장애 감지를 담당한다. 새 노드가 합류하거나 기존 노드가 떠나는 것을 빠르게 전파한다
• Raft: KV 저장소의 데이터 복제를 담당한다. 서비스 등록, 설정 값 등 정합성이 중요한 데이터는 Raft로 합의한다

이런 조합이 자연스러운 이유는, 두 프로토콜이 서로 다른 규모와 정합성 요구사항을 담당하기 때문이다.

• 멤버십은 노드 수가 많고 eventual consistency로 충분하다 → Gossip
• 데이터 복제는 노드 수가 적지만(서버 3~5대) strong consistency가 필요하다 → Raft

flowchart TB
    subgraph "Consul 아키텍처"
        subgraph "Gossip 레이어 (전체 노드)"
            N1["Agent"]
            N2["Agent"]
            N3["Agent"]
            N4["Agent"]
            N5["Agent"]
            N1 <-->|Gossip| N2
            N2 <-->|Gossip| N3
            N3 <-->|Gossip| N4
            N4 <-->|Gossip| N5
        end
        subgraph "Raft 레이어 (서버 노드만)"
            S1["Server (Leader)"]
            S2["Server (Follower)"]
            S3["Server (Follower)"]
            S1 -->|Log Replication| S2
            S1 -->|Log Replication| S3
        end
    end

선택 기준

어떤 프로토콜을 사용할지는 요구사항에 따라 명확하게 갈린다.

• “이 데이터가 모든 노드에서 정확히 같아야 하는가?” → Raft
• “이 정보가 결국 전파되기만 하면 되는가?” → Gossip
• “노드가 수백~수천 대인가?” → Gossip (Raft는 확장성 한계)
• “둘 다 필요한가?” → Consul처럼 레이어를 분리하여 병행

References

• Epidemic Algorithms for Replicated Database Maintenance (Demers et al., 1987)
• SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol
• In Search of an Understandable Consensus Algorithm (Ongaro & Ousterhout, 2014)
• HashiCorp Consul Architecture
• Serf - Gossip Protocol