Network Time Protocol은 다양한 방식으로 클럭 동기화를 한다

요약

NTP는 네트워크로 연결된 컴퓨터들의 시계를 UTC 기준으로 동기화하는 프로토콜이다.
왕복 지연 측정 + 통계적 필터링 + 계층적 시간 분배로 밀리초 수준의 정확도를 달성한다.
분산 시스템에서 로그 분석, 보안 프로토콜, 트랜잭션 순서 판단의 전제 조건이다.

본문

탄생 배경

1985년 David L. Mills가 RFC 958로 NTPv1 발표, 현재 NTPv4(RFC 5905, 2010)
ARPANET 확장 시 컴퓨터마다 시계가 달라 디버깅이 불가능한 문제 해결을 위해 탄생
하드웨어 시계(oscillator)는 제조 편차, 온도, 전압 등으로 하루에 수 초씩 drift

Stratum 계층 구조

Stratum 0: 원자시계, GPS 수신기 (하드웨어 시간 소스)
    |
Stratum 1: Stratum 0에 직접 연결된 서버 (Primary Server)
    |
Stratum 2: Stratum 1에서 시간을 받는 서버
    |
   ...
Stratum 15: 최하위 (Stratum 16 = unsynchronized)

Stratum이 올라갈수록(숫자가 커질수록) 원자시계로부터 멀어지므로 정확도가 떨어진다.

시간 동기화 알고리즘 (핵심)

클라이언트-서버 간 4개의 타임스탬프를 교환한다:

  Client                          Server
    |                               |
    |-------- Request ------------->|
    |  t1 (client send time)        |
    |                          t2 (server receive time)
    |                          t3 (server send time)
    |<------- Response -------------|
    |  t4 (client receive time)     |

Round-trip Delay: delay = (t4 - t1) - (t3 - t2)
Clock Offset: offset = ((t2 - t1) + (t3 - t4)) / 2

offset 공식은 왕복 지연이 대칭적이라는 가정 하에 성립한다. 비대칭일수록 오차가 발생하며, 이것이 NTP의 근본적 한계이다.

필터링과 선택

Clock Filter Algorithm: 최근 8개 샘플 중 delay가 가장 작은 것 선택
Selection Algorithm: 여러 서버 중 falseticker(거짓말하는 서버) 제거
Clustering Algorithm: 가장 신뢰할 수 있는 서버 그룹 선택
Combining Algorithm: 선택된 서버들의 offset을 가중 평균

시계 조정 방식 (Clock Discipline)

offset 크기	조정 방식	설명
< 128ms	Slew (미세 조정)	시계 속도를 점진적으로 조정
128ms ~ 1000s	Step (즉시 조정)	시계를 한 번에 점프
> 1000s	Panic (정지)	NTP가 조정을 포기하고 종료

Slew가 기본인 이유: 시계가 역행하면 로그 순서 꼬임, cron job 중복 실행, build 깨짐 등 심각한 문제 발생.

NTP가 해결하는 문제

로그 분석: 서버 간 시계 차이로 인과 관계 추적 불가 → NTP로 수 ms 이내 동기화
보안 프로토콜: Kerberos는 5분 이상 시계 차이 시 거부, TOTP 동작 불가
데이터 일관성: Last-Write-Wins DB에서 잘못된 시계가 최신 데이터 덮어쓰기 위험

분산 시스템에서의 한계

NTP로 아무리 시계를 맞춰도 수 밀리초의 오차가 존재한다. 이 오차 범위 내에서 발생한 두 이벤트의 순서는 판별할 수 없다.

NTP 오차 ±5ms일 때:
  Server A: event_a = 10:00:00.003
  Server B: event_b = 10:00:00.006
  → event_a가 먼저인가? 오차 범위 내이므로 확신 불가

인과적 순서가 중요한 시스템에서는 [램포트 시계](램포트 시계 (Lamport Clock)는 분산시스템에서 이벤트 순서를 결정하기 위한 논리적 시계다.)이나 [벡터 시계](벡터 시계 (Vector Clock)는 이벤트의 인과관계를 추적해서 램포트 시계의 동시성 구별 한계를 해결한다.)를 함께 사용해야 한다.

NTP vs PTP vs Chrony

항목	NTP	PTP (IEEE 1588)	Chrony
정확도	수 ms (WAN)	나노초~마이크로초	수백 us ~ 수 ms
H/W 지원	불필요	필요 (H/W timestamping NIC)	불필요
사용처	범용 서버, 클라우드	금융 트레이딩, 5G	클라우드 VM, 컨테이너

Chrony는 NTP 프로토콜의 다른 구현체로, VM suspend/resume에 강건하고 수렴 속도가 빠르다. 현재 RHEL 7+, Ubuntu 18.04+ 기본.

실무에서의 접근: 물리적 + 논리적 시계 조합

시스템	접근 방식
Google Spanner	GPS + 원자시계 TrueTime API (오차 구간 명시적 반환)
CockroachDB	NTP + Hybrid Logical Clock (물리적 시간 + 논리적 카운터)
Amazon DynamoDB	Vector Clock 기반 (물리적 시간 비의존)