Leader Election이란?
분산 시스템은 여러 대의 서버(노드)가 함께 동작하며 하나의 서비스를 제공합니다. 그런데 특정 작업은 여러 노드가 동시에 수행하면 오히려 문제가 생깁니다. 예를 들어 데이터 정합성을 맞추는 작업이나 스케줄링처럼 ‘단 하나의 주체’만 처리해야 하는 일이 있죠. 이럴 때 여러 노드 중 하나를 ‘리더(Leader)’로 선출해 해당 작업을 전담시키는 절차를 Leader Election이라고 합니다.
비유하자면, 여러 지점을 가진 회사에서 중요한 의사결정을 각 지점장이 제각각 내리면 혼선이 생기겠죠. 그래서 지점장들 중 한 명을 대표로 뽑아 최종 결정을 맡기는 것과 같습니다. 대표가 갑자기 자리를 비우면(장애가 나면) 남은 지점장들이 다시 모여 새 대표를 뽑는 과정도 필요합니다.
동작 원리와 대표적인 방법
Leader Election은 크게 ‘누가 리더인지 합의하는 과정’과 ‘리더 장애 시 재선출하는 과정’으로 나뉩니다. 대표적인 방식은 다음과 같습니다.
- Bully 알고리즘: 노드마다 고유 ID를 부여하고, 가장 높은 ID를 가진 노드가 리더가 됩니다. 리더가 죽으면 나머지 노드 중 가장 ID가 큰 노드가 새 리더로 선출됩니다.
- Raft 합의 알고리즘: 노드들이 투표를 통해 과반수 이상의 지지를 얻은 후보를 리더로 선출합니다. 리더는 주기적으로 하트비트를 보내 자신이 살아있음을 알리고, 응답이 끊기면 팔로워들이 새 선거를 시작합니다.
- ZooKeeper 기반 선출: 각 노드가 임시 순번 노드를 생성하고, 가장 작은 순번을 가진 노드가 리더가 됩니다. 리더 노드가 사라지면(세션 종료) 다음 순번 노드가 리더로 승격됩니다.
이 과정에서 공통적으로 중요한 것은 ‘하트비트(생존 신호)’와 ‘과반수 합의’입니다. 리더가 정상 동작 중인지 주기적으로 확인하고, 문제가 생기면 빠르게 새 리더를 뽑아야 서비스 중단 시간을 최소화할 수 있습니다.
실무에서 왜 사용할까?
Leader Election은 Kafka, Zookeeper, etcd, Kubernetes 같은 시스템의 핵심 동작 원리입니다. 예를 들어 Kafka는 파티션마다 리더 브로커를 선출해 해당 파티션의 읽기/쓰기를 전담시키고, 리더가 다운되면 팔로워 중 하나가 즉시 리더로 승격되어 서비스가 끊기지 않도록 합니다. Kubernetes의 컨트롤 플레인도 여러 개의 컨트롤러 매니저 중 하나만 활성 상태로 동작하도록 Leader Election을 사용합니다.
결국 Leader Election은 단일 장애점(Single Point of Failure)을 피하면서도, 동시에 ‘하나의 주체만 특정 작업을 수행해야 하는’ 요구사항을 동시에 만족시키는 방법입니다. 분산 시스템을 설계할 때 이 개념을 이해하고 있으면, 왜 특정 노드가 특정 순간에만 쓰기 작업을 처리하는지, 장애 발생 시 시스템이 어떻게 스스로 복구하는지 훨씬 명확하게 파악할 수 있습니다.