클라우드 VM의 시계: 가상화 시간이 어긋나는 이유

가상 머신의 시계가 어긋나는 근본 이유

물리 서버 위에 가상 머신(VM)을 여러 개 돌리는 가상화 환경에서, 각 VM은 자기 시계를 별도로 가진다. 그러나 다음 같은 메커니즘 때문에 VM 시계는 호스트 시계와 점점 어긋난다.

• CPU 스케줄링: 호스트는 한정된 CPU를 여러 VM에 나눠준다. VM이 “일시 정지”된 동안 시간이 흐르지만 VM 입장에서는 그 시간을 인지하지 못한다.
• HW 타이머의 가상화: 실제 하드웨어 타이머를 VM에 직접 노출하지 않고, 소프트웨어 타이머로 시뮬레이션한다.
• 스냅샷·라이브 마이그레이션: VM을 일시 정지하고 다른 호스트로 옮길 때 그 사이의 시간이 “건너뛰어진다”.

이 효과들이 누적되어 일반 VM의 시계는 1일에 1~10초씩 어긋날 수 있다. NTP가 없으면 1주 안에 분 단위 오차로 늘어난다.

각 클라우드의 시간 동기화 서비스

주요 클라우드 제공사는 자체 시간 동기화 서비스를 제공한다.

AWS — Amazon Time Sync Service

• 모든 EC2 인스턴스에서 169.254.169.123 IP로 접근.
• 위성 GPS·원자시계 기반 Stratum 1 서버 직접 연결.
• 일반 인터넷 NTP보다 안정적 — 같은 데이터센터 안의 통신만 사용.
• 2017년부터 leap smear 적용 — 윤초를 24시간에 분산.

GCP — Google Public NTP

• time.google.com (또는 time1·time2·time3·time4.google.com).
• 마찬가지로 leap smear 적용.
• 일반 사용자도 접근 가능 — 외부 인터넷에서도 사용 가능한 무료 NTP.

Azure — Azure Time Sync

• VM 호스트 자체와 직접 동기화 (호스트가 PTP로 정밀 동기화됨).
• 호스트 시계 ↔ VM 시계의 차이를 계속 보정.

이 서비스들의 정확도는 일반 인터넷 NTP보다 좋은 경우가 많다. 이유는 단순하다 — 같은 데이터센터 안에서 통신하므로 네트워크 지연이 매우 작다.

“라이브 마이그레이션”이 만드는 미세한 점프

클라우드 VM이 다른 호스트로 옮겨지는 “라이브 마이그레이션” 중에는 다음 일이 일어난다.

1. 원본 호스트에서 VM이 약 100ms 정도 일시 정지.
2. 메모리·디스크 상태가 새 호스트로 전송.
3. 새 호스트에서 VM이 다시 실행.

이 100ms 동안 VM의 시계는 멈춰 있다가 갑자기 “현재 시각”으로 점프한다. 100ms는 작은 값이지만, 정밀 거래·로그 분석 시스템에서는 의미 있는 차이를 만들 수 있다.

가상화 시계의 “Anti-Pattern”

VM에서 흔히 발생하는 시계 관련 문제는 다음과 같다.

• NTP 동기화 미설정: 신규 VM에서 자동으로 시간 동기화가 켜져 있는지 확인. 일부 OS 이미지는 default가 OFF.
• VM 부팅 직후의 큰 점프: VM이 처음 부팅되면 시계가 호스트 시간으로 초기화된 후, NTP가 다시 한 번 보정한다. 그 사이 약 30초 동안 시계가 두 번 점프할 수 있다.
• 긴 일시정지 후 재개: VM을 며칠 멈췄다가 다시 시작하면 “며칠 분의 시계 어긋남”이 즉시 보정되며 큰 점프가 발생.
• 컨테이너의 시계 공유: Docker 컨테이너는 호스트의 시계를 공유한다. 컨테이너 안에서 별도 NTP를 돌리는 것은 불필요하고 충돌을 만든다.

왜 이게 학생에게 중요한가

학교 수강신청 서버도 사실상 클라우드 또는 자체 가상화 인프라에서 운영된다. 우리가 학교 서버시간을 측정해 KST와 비교할 때, 학교 서버 자체가 “호스트 시계 + NTP 보정”을 거친 후의 시간을 보여준다. 이 보정의 미세한 차이가 우리가 측정하는 “서버 시간차”의 일부다.

일반적으로 이 차이는 ms 단위라서 일상 사용에 영향이 거의 없다. 그러나 “0.1초가 갈리는” 수강신청에서는 무시할 수 없는 변수가 된다.