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

리더 선출과 중복 실행의 상관관계 이해하기

분산 시스템을 설계하거나 운영하다 보면 반드시 마주하게 되는 난제가 있습니다. 여러 대의 서버가 동시에 같은 작업을 수행하지 않게 하면서도, 특정 서버가 고장 났을 때 시스템이 멈추지 않게 하려면 어떻게 해야 할까요? 바로 여기서 리더 선출(Leader Election)이라는 개념이 등장합니다. 리더 선출은 여러 노드 중 단 하나에게만 권한을 부여하여 작업을 주도하게 만드는 메커니즘입니다. 이 과정에서 발생하는 장애와 그로 인한 중복 실행 문제는 시스템의 안정성을 결정짓는 가장 핵심적인 요소입니다.

리더 선출이 왜 중요한가

분산 환경에서는 ‘일관성’을 유지하는 것이 매우 어렵습니다. 예를 들어, 매일 새벽 3시에 데이터베이스의 백업을 생성하는 작업을 한다고 가정해 봅시다. 만약 5대의 서버가 모두 동시에 백업을 시작한다면 데이터베이스에 엄청난 부하가 걸리거나 백업 파일이 꼬이는 사고가 발생할 것입니다. 이를 방지하기 위해 리더 선출을 도입합니다. 리더로 선출된 단 한 대의 서버만 백업을 수행하고, 나머지 서버들은 대기 상태를 유지하는 것입니다. 리더가 죽으면 즉시 다른 서버가 리더가 되어 작업을 이어받으므로 가용성과 일관성을 동시에 확보할 수 있습니다.

리더 선출 장애가 중복 실행으로 이어지는 과정

리더 선출 과정에서 가장 빈번하게 발생하는 장애는 ‘스플릿 브레인(Split Brain)’ 현상입니다. 이는 네트워크 단절 등으로 인해 시스템이 두 개의 그룹으로 나뉘어, 각 그룹이 서로를 리더라고 착각하는 상황을 말합니다. 이 문제가 발생하면 다음과 같은 심각한 결과를 초래합니다.

• 중복 작업 실행: 두 리더가 동시에 동일한 비즈니스 로직을 수행하여 데이터가 이중으로 기록됨

• 데이터 정합성 파괴: 서로 다른 리더가 상충하는 데이터를 처리하여 시스템의 상태가 꼬임
• 리소스 낭비: 여러 대의 서버가 동일한 자원을 점유하려다 교착 상태(Deadlock) 발생

주요 장애 패턴

• 네트워크 파티션: 네트워크가 일시적으로 끊기면서 기존 리더와 새로운 리더가 동시에 존재하는 경우
• 지연된 가비지 컬렉션(GC): 리더 서버가 긴 GC 타임아웃으로 인해 응답을 못 하면, 시스템은 리더가 죽었다고 판단하고 새로운 리더를 뽑습니다. 이후 기존 리더가 깨어나면서 자신이 여전히 리더라고 믿고 작업을 수행합니다.
• 시계 동기화 실패: 서버 간의 시간 차이가 커서 리더 자격 유효기간을 잘못 계산하는 경우

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

리더 선출 장애를 완전히 피할 수는 없지만, 장애가 발생했을 때 중복 실행을 막는 방어 기제는 반드시 필요합니다. 현업에서 가장 많이 사용하는 전략들은 다음과 같습니다.

펜싱 토큰 활용하기

펜싱 토큰(Fencing Token)은 리더가 작업을 수행할 때마다 증가하는 일련번호입니다. 리더가 바뀌면 토큰 번호도 올라갑니다. 데이터베이스나 저장소는 마지막으로 처리한 토큰 번호보다 낮은 번호를 가진 요청은 무조건 거부합니다. 이렇게 하면 과거의 리더가 뒤늦게 작업을 시도해도 시스템은 이를 인지하고 차단할 수 있습니다.

낙관적 잠금 적용

데이터베이스 레코드에 버전 번호를 부여하고, 업데이트할 때마다 현재 버전이 맞는지 확인하는 방식입니다. 만약 다른 리더가 이미 데이터를 수정했다면 버전 번호가 바뀌어 있을 것이므로, 늦게 도착한 리더의 요청은 실패하게 됩니다.

멱등성 설계

가장 근본적인 해결책은 어떤 작업을 여러 번 수행하더라도 결과가 단 한 번 수행한 것과 동일하도록 만드는 것입니다. 예를 들어, ‘잔액에 100원을 더하라’는 연산보다는 ‘현재 잔액을 1100원으로 업데이트하라’는 방식이 훨씬 안전합니다. 멱등성이 보장되면 리더 선출 과정에서 일시적인 중복 실행이 발생하더라도 비즈니스 결과에는 영향을 주지 않습니다.

흔한 오해와 진실

오해: 분산 합의 알고리즘(Raft, Paxos)을 쓰면 중복 실행이 절대 없다.

진실: 알고리즘은 리더를 선출하는 과정의 일관성을 보장할 뿐, 애플리케이션 레벨의 로직 중복까지 완벽히 차단해주지는 않습니다. 리더가 작업을 완료하기 직전에 네트워크가 끊기면, 새로운 리더가 작업을 다시 시작할지 말지 판단하는 것은 여전히 개발자의 몫입니다.

오해: 리더 선출 타임아웃을 짧게 잡으면 장애가 빨리 복구된다.

진실: 타임아웃을 너무 짧게 잡으면 네트워크가 조금만 불안정해도 리더가 계속 교체되는 ‘리더 플래핑(Leader Flapping)’ 현상이 발생하여 시스템 전체 성능이 급격히 저하됩니다.

전문가의 조언

분산 시스템 전문가들은 리더 선출에만 의존하지 말고 ‘방어적 프로그래밍’을 병행할 것을 강조합니다. 리더 선출은 시스템의 효율을 높이기 위한 수단일 뿐, 데이터의 무결성을 보장하는 마지막 보루가 되어서는 안 됩니다. 항상 “만약 리더가 두 명이라면?”이라는 가정을 하고 코드를 작성하세요. 또한, 분산 락(Distributed Lock)을 사용할 때는 반드시 TTL(Time to Live)을 설정하여, 리더가 비정상 종료되더라도 락이 영구적으로 점유되지 않도록 해야 합니다.

비용 효율적인 활용 방법

리더 선출을 위해 매번 복잡한 분산 시스템을 구축하는 것은 비용이 많이 듭니다. 상황에 맞게 다음과 같은 도구를 활용하는 것이 경제적입니다.

• 소규모 프로젝트: Redis의 SETNX 명령어를 활용하여 간단한 분산 락을 구현하세요.
• 중규모 시스템: Zookeeper나 etcd와 같이 리더 선출 기능을 내장한 검증된 코디네이터 서비스를 활용하세요.
• 클라우드 네이티브: 쿠버네티스(Kubernetes)를 사용 중이라면 자체적으로 제공하는 리더 선출 리스(Lease) 객체를 활용하는 것이 가장 비용 효율적입니다.

자주 묻는 질문과 답변

질문: 리더 선출이 자주 실패합니다. 무엇이 문제일까요?

답변: 대개 네트워크 불안정이나 서버의 과부하가 원인입니다. 리더 선출을 위한 하트비트(Heartbeat) 메시지가 제시간에 도달하지 못하는지 모니터링하고, 필요하다면 타임아웃 설정을 튜닝해보세요.

질문: 멱등성을 구현하기 너무 어렵습니다. 다른 방법은 없나요?

답변: 작업 이력을 추적하는 ‘상태 테이블’을 별도로 두세요. 작업 요청을 수행하기 전에 해당 작업 ID가 테이블에 존재하는지 확인하고, 있다면 이미 처리된 것으로 간주하고 스킵하는 방식입니다.

질문: 리더가 죽었을 때 서비스 중단 시간을 최소화하려면 어떻게 해야 하나요?

답변: 하트비트 주기를 적절히 조정하고, 리더 선출이 발생할 때 애플리케이션이 즉시 기존 작업을 중단하고 상태를 재확인하도록 하는 ‘신호 처리(Signal Handling)’ 로직을 구현하는 것이 좋습니다.

분산 시스템에서 완벽한 리더 선출은 존재하지 않습니다. 리더 선출은 확률적으로 리더가 한 명일 가능성을 높여주는 도구일 뿐입니다. 따라서 개발자는 장애가 발생했을 때 중복 실행을 어떻게 방지할 것인가에 대한 안전장치를 항상 마련해 두어야 합니다. 이러한 방어적 설계가 시스템의 신뢰성을 완성합니다.