Leader Election 장애와 중복 실행의 관계

분산 시스템에서 리더 선출이 중요한 이유

현대적인 소프트웨어 환경은 단일 서버가 아닌 여러 대의 서버가 협력하여 서비스를 제공하는 분산 시스템으로 이루어져 있습니다. 이때 특정 작업은 전체 시스템에서 오직 한 번만 수행되어야 하는 경우가 많습니다. 예를 들어 매일 새벽 3시에 데이터베이스를 정리하거나, 특정 결제 요청을 처리하는 작업이 동시에 여러 서버에서 실행된다면 데이터가 꼬이거나 중복 결제가 발생하는 치명적인 오류가 생길 것입니다.

이러한 문제를 해결하기 위해 시스템은 여러 서버 중 하나를 ‘리더(Leader)’로 선정합니다. 리더 선출(Leader Election)이란 분산된 노드들 사이에서 누가 대장 역할을 할지 정하는 과정입니다. 리더는 전체를 대표하여 작업을 수행하고, 나머지 노드들은 팔로워(Follower)로서 대기하거나 리더를 보조합니다. 리더 선출은 시스템의 일관성을 유지하기 위한 필수적인 안전장치입니다.

리더 선출 장애가 발생하면 벌어지는 일

리더 선출 과정에서 장애가 발생하면 시스템은 큰 혼란에 빠집니다. 가장 흔한 문제는 ‘스플릿 브레인(Split Brain)’ 현상입니다. 네트워크 단절로 인해 노드들이 서로를 볼 수 없게 되면, 양쪽 그룹에서 각자 자신들을 리더라고 착각하는 상황이 발생합니다. 결과적으로 두 개의 리더가 동시에 작업을 수행하게 되고, 이는 데이터 정합성을 파괴하는 주범이 됩니다.

또 다른 장애 유형은 리더가 죽었는데 새로운 리더를 선출하지 못하는 경우입니다. 이 상황에서는 전체 시스템이 멈추거나 작업이 지연됩니다. 리더 선출 메커니즘이 너무 복잡하거나 타임아웃 설정이 잘못되어 있으면, 정상적인 서버임에도 불구하고 리더 선출 과정에서 탈락하거나 계속해서 리더를 다시 뽑으려는 ‘선출 루프’에 빠지기도 합니다.

중복 실행을 방지하기 위한 기술적 전략

리더 선출이 완벽할 수는 없기 때문에 시스템 설계자는 언제나 장애 상황을 가정해야 합니다. 리더 선출 장애로 인해 작업이 중복 실행되는 것을 방지하기 위해 현업에서는 다음과 같은 전략을 사용합니다.

• 펜싱 토큰(Fencing Token): 리더에게 번호를 부여합니다. 만약 이전 리더가 네트워크 문제로 잠시 차단되었다가 복구되었을 때, 시스템은 더 높은 번호를 가진 새로운 리더의 요청만 수락하고 이전 리더의 요청은 거부합니다.

• 멱등성(Idempotency) 보장: 작업 자체가 여러 번 실행되어도 결과가 동일하도록 설계하는 것입니다. 예를 들어 ‘잔액을 100원 추가하라’가 아니라 ‘잔액을 1100원으로 업데이트하라’는 방식입니다.
• 분산 락(Distributed Lock): Redis나 ZooKeeper와 같은 외부 저장소를 활용하여 잠금을 획득한 서버만 작업을 수행하도록 강제합니다.

리더 선출 방식의 주요 유형과 특성

리더 선출은 크게 합의 알고리즘을 기반으로 하는 방식과 외부 중재자를 사용하는 방식으로 나뉩니다.

합의 알고리즘 기반 방식

Paxos나 Raft 같은 알고리즘이 대표적입니다. 노드들끼리 투표를 통해 리더를 뽑습니다. 과반수 이상의 동의가 필요하므로 네트워크가 분리되어도 다수결의 원칙에 따라 안전한 리더를 선출할 수 있습니다. 시스템 내부에서 자체적으로 해결하므로 외부 의존성이 낮지만, 구현이 매우 복잡하다는 단점이 있습니다.

외부 중재자 방식

ZooKeeper, etcd, Consul 같은 전문 분산 코디네이터를 사용하는 방식입니다. 이 서비스들이 리더 선출을 위한 상태 저장소 역할을 합니다. 개발자가 직접 알고리즘을 짤 필요가 없어 구현이 매우 쉽고 안정적입니다. 다만, 이 외부 시스템 자체가 또 다른 단일 장애 지점이 될 수 있으므로 이들 서비스 또한 클러스터로 구성하여 안정성을 확보해야 합니다.

전문가가 말하는 리더 선출 설계 시 주의사항

많은 개발자가 리더 선출을 구현할 때 ‘타임아웃’을 너무 짧게 잡는 실수를 범합니다. 네트워크는 불안정하며, 가비지 컬렉션(GC)으로 인해 서버가 아주 잠시 멈추는 현상(Stop-the-world)이 발생할 수 있습니다. 이때 서버가 죽었다고 판단하고 리더를 새로 뽑아버리면, 기존 리더가 다시 깨어났을 때 중복 실행 문제가 발생합니다.

따라서 전문가들은 ‘하트비트(Heartbeat)’ 주기를 충분히 길게 설정하고, 리더 선출 과정에서 충분한 여유 시간을 가질 것을 권장합니다. 또한, 리더가 작업을 수행하기 전 반드시 현재 자신이 여전히 리더인지 확인하는 ‘상태 체크’ 과정을 코드에 포함하라고 조언합니다. 이를 통해 네트워크 일시적 단절에 따른 리더 교체 상황에서도 데이터 오염을 예방할 수 있습니다.

자주 묻는 질문과 답변

질문: 리더 선출이 실패하면 서비스는 즉시 중단되나요?

답변: 반드시 그렇지는 않습니다. 많은 시스템이 리더 선출 실패 시 ‘읽기 전용 모드’로 전환하거나, 마지막으로 알려진 상태를 유지하여 최소한의 서비스는 제공하도록 설계됩니다. 하지만 쓰기 작업이 필요한 서비스라면 리더 선출 전까지는 작업을 대기열에 쌓아두는 것이 일반적입니다.

질문: Redis만 사용하면 리더 선출이 완벽한가요?

답변: Redis의 SETNX 명령어를 이용한 락은 매우 편리하지만, Redis가 클러스터 모드일 때 특정 노드가 장애가 나면 락 정보가 유실될 위험이 있습니다. 이 경우 Redlock 알고리즘을 고려해야 하지만, 완벽한 정합성을 보장하려면 ZooKeeper나 etcd를 사용하는 것이 훨씬 안전합니다.

질문: 비용 효율적으로 리더 선출을 구현하려면 어떻게 해야 하나요?

답변: 처음부터 복잡한 분산 시스템을 구축하기보다는, 서비스 규모에 맞춰 단계적으로 접근해야 합니다. 소규모 시스템이라면 데이터베이스의 고유 제약 조건(Unique Constraint)을 활용한 ‘행 단위 락’으로도 충분히 리더 선출과 유사한 효과를 낼 수 있습니다. 이후 트래픽이 증가하면 그때 외부 코디네이터 서비스를 도입하는 것이 비용과 운영 측면에서 가장 효율적입니다.

흔한 오해와 진실

리더 선출을 단순히 ‘한 명을 뽑는 과정’으로만 생각하면 오산입니다. 리더 선출은 ‘모든 노드가 누가 리더인지 합의하는 과정’입니다. 즉, 후보가 리더가 되었다고 생각하는 것보다, 나머지 노드들이 그 후보를 리더로 인정하는 것이 훨씬 중요합니다. 많은 장애가 후보는 리더가 되었다고 생각하는데 팔로워들은 여전히 이전 리더를 따르고 있을 때 발생합니다.

또한, 리더가 죽어야만 리더 선출이 일어난다고 생각하는 것도 오해입니다. 리더가 정상적으로 작동 중이라도 네트워크 지연으로 인해 다른 노드들이 리더가 죽었다고 오해하여 선출 과정을 시작할 수 있습니다. 이러한 ‘불필요한 리더 교체’를 방지하기 위해 시스템은 항상 실제 상태와 네트워크 상태를 분리해서 판단해야 합니다.

안정적인 분산 시스템을 위한 체크리스트

• 리더 선출 알고리즘이 네트워크 파티션을 견딜 수 있는가?

• 리더가 작업을 수행할 때 다른 노드가 동시에 작업을 수행하지 못하도록 락이 걸리는가?
• 시스템이 중단되었을 때 작업 상태를 복구할 수 있는 로그가 기록되는가?
• 리더 선출 과정에서 타임아웃과 재시도 정책이 적절하게 설정되어 있는가?
• 리더의 상태를 주기적으로 체크하고 이상 징후를 알림으로 받을 수 있는가?

리더 선출은 분산 시스템의 심장과 같습니다. 심장이 멈추면 시스템 전체가 마비되고, 심장이 두 개가 뛰면 데이터가 오염됩니다. 이 과정을 완벽하게 제어하는 것은 어렵지만, 위에서 언급한 설계 원칙과 기술적 전략들을 깊이 이해하고 적용한다면 장애 발생 확률을 획기적으로 낮출 수 있습니다. 기술적인 완벽함보다는 장애가 발생했을 때 시스템이 어떻게 안전하게 대응할 것인가에 초점을 맞추는 것이 실무에서 가장 중요한 핵심입니다.