리더가 10초 동안 사라진 원인은 election timeout이었나 네트워크였나?

결론부터 쓰면, 원인은 네트워크 장애가 아니라 election timeout 랜덤 범위가 너무 좁게 설정된 구성 문제였다. 순간적인 지연 스파이크가 팔로워들의 타임아웃을 거의 동시에 만료시켰고, 그 결과 표가 갈리는 split vote가 반복됐다. 강한 일관성을 택한 대가로 지불하는 지연이 설계 여유 부족과 만나면 어떻게 증폭되는지를 보여준 사례다.

  • election timeout은 절대값이 아니라 랜덤 범위의 폭이 안정성을 좌우한다
  • 리더 공백은 네트워크 손실보다 "동시 타임아웃"에서 더 자주 발생한다
  • 로그 복제 지연은 평균 RTT보다 뒤처진 팔로워의 재추격 비용에서 커진다
  • 강한 일관성은 지연을 예측 가능하게 만드는 대신 여유 설계를 요구한다

무엇이 어떻게 깨졌나

5노드 클러스터에서 배치 작업이 시작된 직후 write 커밋 지연의 p99가 2ms에서 900ms로 치솟았다. 3초 후 리더가 스스로 팔로워로 강등됐고, 곧이어 두 노드가 거의 동시에 후보로 나서면서 표가 갈렸다. 이 split vote가 세 차례 반복되는 동안 클러스터는 쓰기를 커밋하지 못했고, 새 리더가 확정된 것은 최초 지연 스파이크 이후 약 10초 뒤였다.

네트워크 파티션이 리더를 끊어놓았나?

아니다. 사고 구간의 패킷 손실률은 0.1% 미만이었고 RTT p99도 순간적으로 180ms를 넘긴 것 외에는 대부분 정상 범위였다. Raft 설계 자체가 전제하는 "메시지 전파 시간이 선거 타임아웃보다 훨씬 짧아야 한다"Raft 논문는 조건은 평상시엔 충분히 지켜지고 있었다. 손실률과 RTT만 보면 파티션 가설은 성립하지 않았다.

디스크 fsync 지연이 리더를 쓰러뜨렸나?

부분적으로 관여했지만 단독 원인은 아니었다. 배치 작업으로 디스크 큐 대기시간이 순간 40ms까지 늘었고, 이는 로그 append 직후의 fsync를 지연시켜 하트비트 응답 지연에 일부 기여했다. 그러나 40ms는 당시 설정된 election timeout 하한(150ms)보다 훨씬 작은 값이어서, 이것만으로 리더 강등과 반복적인 split vote를 설명하기엔 부족했다.

재시도 폭주가 로그 복제를 막았나?

막지 않았다. 클라이언트 재시도 트래픽은 커밋 지연 스파이크 이후에 증가했을 뿐, 최초 리더 강등 시점보다 늦게 나타났다. 즉 재시도 폭주는 원인이 아니라 결과였다. 뒤처진 팔로워를 따라잡기 위해 nextIndex를 줄여 재전송하는 절차가 지연을 더 늘리긴 했지만, 이는 리더가 이미 불안정해진 이후의 부수 현상이었다.

실제 원인은 무엇이었나

election timeout이 150~160ms의 좁은 랜덤 범위로 설정돼 있었다는 점이 핵심이었다. 배치 작업이 만든 짧은 스케줄링 지연이 하트비트를 살짝 늦췄을 때, 좁은 랜덤 범위 탓에 여러 팔로워가 거의 동시에 타임아웃을 넘겨 동시에 후보가 됐다. Raft 논문이 150~300ms 폭의 랜덤화를 권장하는 이유가 바로 이 동시 후보 난립을 줄이기 위한 것인데, 운영 설정이 그 폭을 절반 이하로 좁혀둔 상태였다.

무엇을 바꿨나

election timeout 랜덤 범위를 150~300ms로 넓히고, 하트비트 간격과 타임아웃 하한 사이의 여유를 늘렸다. etcd 계열 운영 가이드가 네트워크 p99 지연에 맞춰 기본 election timeout을 1000ms에서 5000ms로 올려 조정하는 사례etcd 튜닝 문서를 참고해, 우리 환경의 p99 RTT 대비 최소 3배 이상 여유를 두는 기준을 새로 세웠다. 별도의 로컬 부하 실험에서는 랜덤 범위를 넓힌 뒤 동시 후보 발생 빈도가 눈에 띄게 줄었다.

일반화 가능한 교훈

election timeout은 "얼마나 짧게 잡을 것인가"가 아니라 "네트워크 p99 대비 얼마나 여유롭고, 랜덤 폭이 얼마나 넓은가"로 설계해야 한다. 이 기준은 특정 구현체에 묶이지 않는다. Dragonboat 같은 통합형 엔진이 단일 Raft group에서 평균 1.3ms, P99 2.6ms의 낮은 지연을 보여줄 수 있는 것Dragonboat도, 결국 리더 선출 경로가 안정적으로 짧게 유지된다는 전제 위에서만 의미가 있다. 강한 일관성 시스템의 체감 지연은 평상시 RTT가 아니라, 지연이 튀는 드문 순간에 타임아웃 설계가 얼마나 여유를 남겨두는가로 결정된다.

핵심 정리

  • 리더 공백의 원인은 네트워크 손실이 아니라 election timeout 랜덤 범위 부족이었다
  • 짧은 스케줄링·디스크 지연은 단독 원인이 아니라 좁은 타임아웃 폭을 만났을 때 증폭됐다
  • 재시도 폭주와 로그 재추격 비용은 원인이 아니라 리더 불안정 이후의 결과였다
  • 재발 방지는 랜덤 범위 확대와 네트워크 p99 대비 여유 확보로 이뤄졌다
  • 강한 일관성 시스템에서는 평균 지연보다 타임아웃 설계의 여유 폭이 안정성을 좌우한다

더 알아보기

분산 일관성과 합의: 시스템 설계의 기본 축 — 이 주제의 종합 가이드