클라우드 시간이 다른 이유
클라우드의 가상 머신은 독특한 시간 관리 문제에 직면합니다. 하이퍼바이저는 게스트 OS가 알지 못한 채 VM을 일시 정지, 마이그레이션, 스냅샷할 수 있어 극단적인 경우 게스트 시계가 수초 또는 수분씩 드리프트될 수 있습니다.
AWS: Amazon 시간 동기화 서비스
AWS는 모든 EC2 인스턴스에서 링크-로컬 주소 169.254.169.123으로 접근할 수 있는 Stratum 1 NTP 서버 집합을 제공합니다. 각 AWS 리전의 GPS 및 원자 시계에 연결되며 윤초 스무딩을 사용합니다.
# EC2의 /etc/chrony.conf
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
# 동기화 상태 확인
chronyc tracking
Google Cloud: Google 공개 NTP
# GCP VM의 /etc/chrony.conf
server metadata.google.internal iburst
# 공개 Google NTP 서버 사용
server time.google.com iburst
Azure: Windows Time 서비스와 Chronyd
# Azure Linux VM
server 168.63.129.16 iburst # Azure 시간 서버
# Windows VM
w32tm /query /status
컨테이너와 Kubernetes 시간
컨테이너는 호스트 커널의 시계를 공유합니다 — 독립적으로 동기화할 수 없습니다. EC2/GCP VM/Azure VM이 올바르게 동기화되면 모든 컨테이너가 정확한 시간을 상속합니다.
클라우드 시간 모범 사례
- 클라우드 제공업체의 로컬 NTP 엔드포인트 사용 (AWS: 169.254.169.123) — 가장 정확하고 지연이 낮음
- EC2에서
minpoll 4 maxpoll 4로 적극적인 동기화 설정 chronyc tracking으로 오프셋을 모니터링하고 10ms 이하 유지