【入門編】仮想化環境における時刻同期の課題（NTPとPTP、仮想クロックドリフト） – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！技術メディアの主筆ライター、そして日々システムの裏側でパケットやサーバーと格闘しているSREの「Taka」です。

突然ですが、みなさんはスマートフォンの時計が1秒でもズレていたら、ちょっとソワソワしませんか？
「そんなの、たった1秒でしょ？」と思うかもしれません。しかし、私たちインフラエンジニアが愛してやまない「クラウドや仮想化（サーバーの中に仮想のサーバーを立てる技術）」の世界では、このたった1秒、いや、わずか「1ミリ秒（1000分の1秒）」のズレが、システム全体を大混乱に陥れる大事件に発展してしまうのです。

「仮想化されたサーバーの時間は、なぜか放っておくとズレてしまう」

これは、インフラの世界に足を踏み入れたばかりのエンジニアが、ほぼ確実に一度は頭を抱える定番のトラブルです。
今回は、この「仮想環境における時間のズレ（クロックドリフト）」の謎と、それを防ぐための仕組み（kvm-clockやNTPなど）について、身近な例えを使いながら、一歩ずつ丁寧に紐解いていきましょう！

—

そもそも、なぜ仮想サーバーの時間は「ズレる」のか？

物理的なパソコンやサーバーには、マザーボードという基盤の上に「RTC（リアルタイムクロック）」という、ボタン電池で動く小さな本物の時計が載っています。電源を切っても時間が進み続けるのは、この電池式の時計のおかげです。

しかし、AWS（Amazon Web Services）などのクラウドや、社内の仮想化プラットフォーム上で動く「ゲストOS（仮想サーバー）」には、自分専用の物理的な時計がありません。

では、仮想サーバーはどうやって時間を知るのでしょうか？
答えは、「土台となる物理サーバー（ハイパーバイザー）から、定期的に時間を教えてもらっている」のです。

ここに、時間が狂う最大の原因が隠されています。

映画の「一時停止ボタン」と配達員の例え

仮想化の世界では、1台の強力な物理サーバーの中で、何台もの仮想サーバーが同時に動いています。
物理サーバーのCPU（頭脳）は、超高速で「今はAさんの仮想サーバーの処理をして、次はBさんの処理をして、その次はCさん…」と、作業を切り替えながら処理をこなしています。

これを、「一人の超多忙な配達員（CPU）」が「たくさんの宛先（仮想サーバー）」に順番に荷物を届けている様子に例えてみましょう。

1. 配達員があなたの玄関（仮想サーバーA）に荷物を届けに来ました。
2. その瞬間、配達員は「今の時間は12時00分00秒ですよ」と教えてくれます。
3. 配達員は次の家（仮想サーバーB）へ行ってしまいます。
4. 次に配達員が戻ってくるまでの間、あなたの家（仮想サーバーA）は時間が止まったように静まり返ります（これが「スケジューリング遅延」です）。
5. しばらくして配達員が戻ってきた時、あなたの家の時計は、配達員が留守にしていた時間分だけ遅れて（ズレて）しまうのです。

このように、仮想サーバーが「物理CPUから処理を後回しにされている時間」が積み重なることで、少しずつ、しかし確実に時間が遅れていきます。この現象を専門用語で「仮想クロックドリフト（時間の漂流）」と呼びます。

—

時間がズレると、現場でどんな大惨事が起きる？

「時間がちょっとズレるくらい、大したことないのでは？」と思う方もいるかもしれません。ですが、システムの世界では次のような恐ろしいことが起こります。

「犯人がわからない！」セキュリティログの混乱

悪意のあるアクセスがあった時、Aというサーバーのログには「12:00:01」と記録され、Bというデータベースのログには「11:59:59」と記録されていたら、システムの中で「何がどの順番で起きたのか」という正確なタイムラインがつながらなくなってしまいます。

「ログインできない！」認証エラー

みなさんも使う「ワンタイムパスワード（2段階認証）」などは、スマホとサーバーの「現在の時刻」が完全に一致していることを前提に作られています。サーバーの時間が数十秒ズレるだけで、正しいパスワードを入れても「期限切れ」と判定され、システムに誰もログインできなくなります。

—

時間を合わせる2つの救世主：NTP と PTP

この「時間のズレ」を修正するために、ネットワークを通じて正確な時間を配ってくれる仕組みがあります。それが NTP と PTP です。

NTP（一般的なシステムの守護神）

インターネットを通じて、世界中にある「超正確な原子時計」を持つサーバーから、段階的に時間を分けてもらう仕組みです。一般的なシステムであれば、このNTP（またはその改良版である chrony というソフトウェア）を使えば、実用上まったく問題のない精度（数ミリ秒の誤差）で時間を合わせ続けることができます。

PTP（ミリ秒すら許さないプロの世界）

「0.000001秒の差で株の取引の勝ち負けが決まる」といった金融システムや、超高速な通信を行う5Gの基地局などでは、NTPの精度では足りません。そこで、ネットワークの途中のスイッチ（通信機器）なども巻き込んで、パケットが届くまでの「一瞬の遅延」すら極限まで計算して補正する PTP という超ウルトラ精密な技術が使われます。

—

仮想環境の救世主：kvm-clock（準仮想化クロック）

しかし、NTPやPTPだけで仮想サーバーの「一瞬の時間の立ち止まり（スケジューリング遅延）」をすべて解決しようとすると、インターネット越しに何度も「今何時ですか？」と聞き直さなければならず、ネットワークが時間問い合わせのパケットだらけになってしまいます。

そこで登場したのが、「準仮想化クロック（代表例：kvm-clock）」という魔法のような仕組みです。

これは、土台である物理サーバー（ハイパーバイザー）と、その上で動く仮想サーバー（ゲストOS）が「裏口の直通電話」でつながっているような状態を作ります。

これまでの方法： 仮想サーバーが、自分の中の不正確な仮想時計をベースに時間を刻み、ズレたらNTPで外に聞きに行く。
kvm-clock の方法： 物理サーバーが「私のCPUはこれだけの速度で動いているから、今はこの時間だよ」という情報を、仮想サーバーが直接読み込める「特等席（メモリ上の特定の場所）」に常に置いておきます。仮想サーバーは、外のネットワークに聞きに行くことなく、この特等席のデータをチラッと見るだけで、いつでも物理サーバーと完全に一致した正確な時間を知ることができるのです。

—

実践！自分のLinuxサーバーの設定を見てみよう

「私のサーバーは大丈夫かな？」と気になったあなた。さっそくLinux（CentOSやUbuntuなど）のコマンドラインから、現在の状態を覗いてみましょう！

1. 現在使われている「時計の素（クロックソース）」を確認する

Linuxカーネルが、時間の計算に何を使っているかを確認するコマンドです。以下のファイルを cat コマンドで表示してみましょう。

# 現在システムが使用しているクロックソースを表示します
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

もし、あなたのサーバーがKVMやAWS（EC2）などの仮想環境であれば、画面に以下のように表示されるはずです。

kvm-clock

これこそが、先ほど紹介した「ハイパーバイザー直通の魔法の時計」が正しく使われている証拠です！
（※古い仮想サーバーや一部の環境では tsc や xen と表示されることもあります）

2. 利用可能なクロックソースの一覧を見る

システムが「これらも時計として使えますよ」と認識している候補の一覧を見るには、以下のコマンドを叩きます。

# 利用可能なクロックソースの一覧を表示します
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

実行すると、以下のようにいくつかの候補が表示されます。

kvm-clock tsc acpi_pm

この中で、最も仮想環境に適しており、処理の負担が少ない kvm-clock が自動的に選ばれているのが理想的な状態です。

—

クラウド時代の時刻同期設定（chrony のベストプラクティス）

現在、多くのLinuxディストリビューションでは、昔ながらの ntpd に代わり、より一時的な時間のズレ（一時停止からの復帰など）に強い chrony（クロニー） という仕組みが標準で使われています。

クラウド環境（例：AWS）で仮想サーバーを構築する際の、推奨される chrony.conf（設定ファイル）の書き方を見てみましょう。

# /etc/chrony.conf の設定例

# 1. AWSなどのクラウド環境では、クラウド事業者が用意している「超低遅延な時刻サーバー」を最優先に指定します。
# AWSの場合、169.254.169.123 という特殊なIPで超高精度な時計（Time Sync Service）が提供されています。
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

# 2. 上記のローカル時刻サーバーにアクセスできない場合の、バックアップ用インターネットNTPプール
pool pool.ntp.org iburst

# 3. システム起動時に、もし時間が大きくズレていたら、徐々に直すのではなく「一瞬でドカンと」合わせる設定。
# （3回の更新までは、1秒以上のズレがあれば即座に強制同期します）
makestep 1.0 3

# 4. 物理サーバーの時計（RTC）との同期を有効にする
rtcsync

なぜ 169.254.169.123 を使うの？

これはAWSが提供している「ネットワークの外に出ない、物理的に目と鼻の先にある時刻サーバー」です。インターネットを経由しないため、ネットワークの混雑による遅延がほぼゼロ（マイクロ秒の世界）で、極めて正確な時刻同期が可能になります。

—

まとめ：一歩ずつ理解して、ズレないインフラを作ろう！

今回は、仮想化環境における「時間のズレ」という、一見地味ながらも非常に重要なテーマについて解説しました。

仮想サーバーは、物理CPUの作業の合間に動くため、どうしても時間が遅れがち（仮想クロックドリフト）になる。
一般的なシステムなら NTP（chrony）、超精密な世界なら PTP で時間を合わせる。
仮想環境では、ハイパーバイザー直通の魔法の時計 kvm-clock を使うことで、時間のズレを根本から防ぐ。

日々の運用で「なんかログの時間がズレているな？」「認証エラーが頻発するな？」と思ったら、ぜひ今回の内容を思い出して、/sys/devices/system/clocksource/... や /etc/chrony.conf を確認してみてくださいね。

インフラエンジニアへの第一歩は、こうした「物理と仮想のギャップ」を一つずつ理解していくことから始まります。焦らず、一歩ずつ一緒に学んでいきましょう！

それでは、また次回の技術ブログでお会いしましょう！