물리 서버 시간 동기화: chrony 소스와 동기화 상태 검증

결제 콜백이 만료된 것으로 처리되거나, 로그인 토큰이 간헐적으로 무효화되거나, 프로세스 간 로그 순서가 뒤바뀌는 현상은 모두 같은 문제에서 비롯될 수 있습니다. 시스템 시계가 안정적으로 동기화되지 않는 것입니다. 시간대를 바꿔도 표시 방식만 달라질 뿐, 시각 오차는 바로잡히지 않습니다. 문제를 조사할 때는 강제 시각 보정 명령부터 실행하지 말고 시간 소스, 동기화 상태, 서비스가 허용할 수 있는 오차부터 확인해야 합니다.

이 글에서는 Debian 12의 chrony를 기준으로 ‘소스 확인—오차 해석—동기화 게이트 설정—복구 검증’ 절차를 정리합니다. AmdMetal 물리 서버는 결제 후 콘솔에서 접속 정보를 확인하고 SSH로 접속합니다. IPv4가 여러 개라면 첫 번째 주소를 사용합니다. 아래 작업은 네트워크 주소를 변경하지 않으며, 관리 포트를 외부에 공개할 필요도 없습니다.

1. 기준 상태 기록: 표시와 보정 구분하기

먼저 시스템 시각, 시간대, 커널 버전, 현재 실행 중인 시각 동기화 서비스를 기록합니다. 서비스 로그는 시간대가 포함된 형식으로 통일하고, 조사 기록에는 UTC도 함께 남기는 것이 좋습니다. 그래야 표시상의 차이를 시계 드리프트로 오인하지 않습니다.

date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
uname -r
systemctl is-active chrony systemd-timesyncd

timedatectl의 동기화 항목은 단서로 활용할 수 있지만, 시간 소스 점검을 대신하지는 못합니다. 다른 시각 동기화 프로세스나 구성 관리 작업이 동시에 시계를 조정하고 있지 않은지도 확인해야 합니다. 호스트에서 실행하는 가상 머신도 각각 점검해야 합니다. 호스트가 정상이라고 해서 게스트 시스템까지 정상인 것은 아닙니다.

chrony가 설치되어 있지 않다면 시스템 패키지 저장소에서 설치할 수 있습니다. 다만 설치 과정에서 서비스가 시작되고 배포판의 기본 설정이 적용될 수 있습니다. 이미 서비스를 운영 중인 서버라면 적용될 설정과 패키지 설치 동작을 먼저 검토해야 합니다. 일단 설치한 뒤 상태를 지켜보는 방식은 피하는 것이 좋습니다.

sudo apt-get update
sudo apt-get install chrony
systemctl status chrony --no-pager

실행 중인 데이터베이스, 인증 서비스, 작업 스케줄러는 벽시계 시각의 급격한 변경에 영향을 받을 수 있습니다. 서비스 동작에 미치는 영향을 평가하기 전에는 date -s나 chronyc makestep을 실행하지 마세요. 시각 동기화 서비스를 반복해서 재시작하며 ‘시간을 고치려는’ 시도도 하지 마세요.

2. 시간 소스 점검: 응답한다고 신뢰할 수 있는 것은 아님

설치 후에는 기본 설정 파일과 여기서 참조하는 파일을 확인합니다. 시간 소스 주소는 조직에서 승인한 것을 사용하세요. 출처가 불분명한 공개 주소를 그대로 복사하거나, 특정 고정 소스를 AmdMetal이 제공하는 인프라로 간주해서는 안 됩니다.

sudo grep -R -E \
'^[[:space:]]*(server|pool|peer|sourcedir|confdir|include|makestep|local|offline)' \
/etc/chrony
chronyc activity
chronyc sources -v
chronyc sourcestats -v

server와 pool은 소스를 정의하며, 포함되는 디렉터리에서 추가 설정을 불러올 수도 있습니다. 중복 소스는 실제 서버를 기준으로 식별해 정리해야 합니다. 이름이 여러 개여도 결국 같은 인프라를 가리킬 수 있으므로, 설정 줄 수만으로 소스의 독립성을 판단해서는 안 됩니다.

sources -v에서 *는 현재 선택된 동기화 소스, +는 시각 계산에 함께 사용되는 소스, ?는 현재 소스 선택에 사용할 수 없는 상태를 뜻합니다. ?는 통신 불가, 샘플 부족 등 여러 원인으로 나타날 수 있습니다. Reach는 8진수로 표시되는 통신 성공 이력입니다. 377은 최근 8번의 폴링에서 모두 응답을 받았다는 뜻이지, 시각이 반드시 정확하다는 뜻은 아닙니다.

소스 이상 시 점검 순서

먼저 이름 해석이 정상인지 확인하고, 소스 주소로 향하는 라우팅과 아웃바운드 정책을 점검한 뒤, 샘플이 계속 갱신되는지 관찰합니다. NTP 응답을 받았다는 사실은 통신이 이루어졌다는 것만 입증합니다. 소스 시각의 이상, 비대칭 지연, 샘플 간 불일치는 여전히 소스 선택에 영향을 줄 수 있습니다. ? 표시를 없애려고 서버 전체의 방화벽 정책을 무작정 완화하지 마세요.

3. 오차 해석: 필드 하나만 보고 판단하지 않기

chronyc tracking
journalctl -u chrony -b --no-pager -n 100

Reference time은 계속 갱신되어야 합니다. Leap status가 Not synchronised라면 정상 상태로 판정할 수 없습니다. System time은 chrony가 추정한 잔여 보정량입니다. 이 값이 0에 가깝다고 해서 실제 UTC와의 오차가 작다는 사실까지 독립적으로 입증된 것은 아닙니다.

Last offset과 RMS offset은 샘플 및 통계 상태를 나타냅니다. Root delay와 Root dispersion은 기준 시계까지의 경로와 불확실성을 파악할 단서를 제공합니다. 이 필드들은 소스 상태와 함께 해석해야 합니다. 소수점 숫자 하나만 떼어 내 정상 판정의 근거로 삼아서는 안 됩니다.

여러 폴링 주기를 포함하도록 결과를 여러 차례 연속해서 기록하는 것이 좋습니다. 콜드 스타트 후 수렴하는 과정, 네트워크 복구 후 샘플을 다시 쌓는 과정, 안정적인 운영 상태는 구분해서 판단해야 합니다. 한 번 측정한 값을 줄이려고 설정을 계속 바꾸면 어떤 변경이 효과를 냈는지 파악하기 어려워집니다.

4. 대기 횟수가 제한된 동기화 게이트 설정

시각에 의존하는 서비스는 시작 또는 배포 점검 과정에 대기 한도가 있는 동기화 검증을 추가할 수 있습니다. 아래 수치는 엔지니어링 예시일 뿐입니다. 실제 임계값은 토큰 유효 기간, 감사 요건, 서비스 테스트 결과를 바탕으로 정해야 하며, 서비스 보장 수치가 아닙니다.

chronyc waitsync 12 0.05 0 5

이 명령은 5초 간격으로 최대 12번 확인합니다. 동기화 상태에 진입하고 잔여 보정량이 0.05초 미만이어야 합니다. 세 번째 인수가 0이면 skew에 별도 제한을 두지 않습니다. 성공 종료는 이 조건들이 충족되었다는 뜻이며, 실제 UTC와의 오차가 50밀리초 미만임을 보장하지는 않습니다.

자동화 작업은 반드시 종료 코드를 확인해야 하며, 실패 출력을 무시해서는 안 됩니다.

if chronyc waitsync 12 0.05 0 5; then
    printf '%s\n' 'Clock gate passed'
else
    printf '%s\n' 'Clock gate failed' >&2
    exit 1
fi

게이트 검증에 실패하면 관련 시작 단계를 중단하고 운영 담당자에게 알려야 합니다. 시각을 급격히 변경하는 복구 작업을 자동으로 실행해서는 안 됩니다. network-online.target은 네트워크 준비 상태만 다루며, 시계 동기화가 완료되었다는 근거가 될 수 없습니다.

게이트의 실패 경로 검증

격리된 테스트 환경에서 사용 가능한 소스가 없을 때 게이트가 0이 아닌 종료 코드를 반환하는지 확인합니다. 그다음 소스를 복구해 성공 경로도 검증합니다. 오차를 만들기 위해 운영 중인 물리 서버의 시스템 전체 시각을 변경하지 마세요. 모든 서비스에 동시에 영향을 주며, 사고의 선후관계를 판단하는 데 필요한 로그도 왜곡됩니다.

5. 복구 후 검수와 해석 가능한 증거 보관

소스를 수동으로 오프라인 처리했다면 네트워크가 복구되었는지 확인한 뒤에만 chronyc online을 실행합니다. 샘플을 보충해야 한다면 설정된 소스에 대해 chronyc burst 4/4를 한 번 실행한 다음, 소스 선택 상태와 tracking 결과를 다시 관찰할 수 있습니다. 의미 없는 요청이 발생하도록 반복 호출하지 마세요.

makestep을 검토할 때는 특히 makestep 1.0 3과 같은 설정에 주의해야 합니다. 이 설정은 시작 후 처음 몇 차례의 시계 업데이트에서 오차가 임계값을 넘으면 시각을 즉시 변경하도록 허용합니다. 서비스를 재시작하면 이 단계에 다시 진입할 수 있으므로, ‘일단 재시작’하는 것은 위험이 없는 조치가 아닙니다. 큰 폭의 시각 변경이 꼭 필요하다면 영향을 받는 서비스를 먼저 격리하고 복구 계획을 마련해야 합니다.

최종 점검에는 다음 항목을 포함해야 합니다.

• 적절한 소스가 선택되었고 기준 시각이 계속 갱신되며, 오래된 샘플에 장시간 머무르지 않는다.
• 잔여 보정량과 불확실성이 서비스 임계값을 충족하고, 연속 관찰 중 뚜렷한 악화가 없다.
• 게이트의 성공 경로와 실패 종료를 모두 검증했으며, 알림을 수신할 수 있다.
• 프로세스가 살아 있는지만 확인하는 데 그치지 않고 인증, 콜백, 로그 정렬을 서비스 측에서 다시 테스트했다.
• 설정 변경 내역, 명령 출력, 관찰 구간을 보관하며, 로그에 포함된 소스 주소는 접근 권한에 따라 관리한다.

소요 시간 측정과 타임아웃 제어에는 단조 시계를 우선 사용하고, 서비스 타임스탬프에는 벽시계를 사용해야 합니다. 애플리케이션의 시간 측정 방식과 호스트의 동기화 검수를 구분해야 한 번의 시각 보정으로 정상적인 소요 시간이 음수가 되는 일을 막을 수 있고, 이후 장애 기록도 해석 가능하게 유지할 수 있습니다.

자주 묻는 질문