ntpdからchronyへ切り替える本番NTP移行｜同期精度の測定と段階移行設計

ntpdからchronyへ移行する背景と2026年の現状

長年Linux環境でNTP同期を担ってきたntpdは、現在も稼働し続けているシステムが少なくありません。しかし主要ディストリビューションの標準NTPクライアントはchronyへ移行しており、RHEL 8/9系・Ubuntu 20.04以降・Debian 11以降のいずれも、新規インストール時はchronydがデフォルトで採用されています。ntpパッケージ自体のメンテナンスが縮小傾向にある中、本番環境のまま放置するのはリスクになりつつあります。

chronydがntpdと比較して優れている点として、特に注目されるのは次の3点です。第一に、間欠的なネットワーク接続への耐性です。chronydはオフライン状態からの復帰後も参照時計との差を素早く吸収できる設計になっています。第二に、ハードウェアタイムスタンプのサポートです。NICがPTPハードウェアタイムスタンプに対応している場合、chronydはそれを利用してマイクロ秒オーダーの精度を実現できます。第三に、仮想化環境との親和性です。クラウドVM上ではゲストOSのクロックが揺れやすいため、スキュー補正が柔軟なchronydのほうが安定します。

一方で、移行を慎重に進める必要があるのは、時刻同期の乱れがデータベースのトランザクション整合性・ログの順序・証明書の有効期限検証・Kerberosチケットの認証など、業務全体に波及するためです。本記事では「既存ntpd環境の精度測定 → chronydへの段階移行 → 移行後の検証 → 切り戻し手順」まで一貫した運用シナリオとして解説します。

移行前の準備：現在の同期精度を測定する

移行前に現状を数値で把握しておくことで、移行後の比較が可能になります。ntpd稼働中のホストでは以下のコマンドで状態を確認できます。

# 参照サーバの一覧と現在のオフセット・ジッターを確認
ntpq -pn

# 複数回サンプリングしてオフセット推移を記録する想定例（10秒間隔で10回）
for i in $(seq 1 10); do ntpq -c rv | grep -E 'offset|jitter'; sleep 10; done

ntpq -pn の出力では、offset（ミリ秒単位のずれ）と jitter（変動幅）に注目します。オフセットが数十ミリ秒以上あったり、ジッターが大きく揺れているホストは、ntpd側のパラメータか上流NTPサーバの問題を抱えている可能性があります。移行前にこれらを記録しておき、chrony移行後の値と比較する材料にします。

また、/var/log/messages や journalctl -u ntpd でオフセット補正の頻度・ステップ補正の発生有無も確認しておきます。ステップ補正（大きなジャンプ）が頻繁に発生しているホストは、移行後の挙動が変わる可能性があるため注意が必要です。

段階移行の設計：一斉切り替えを避ける理由と手順

本番環境での一斉切り替えは避け、段階移行を採用することが現実的です。以下の流れが一般的です。

• フェーズ1：非本番ホスト（開発・検証環境）でchronyを先行導入し、1週間以上運用して精度と安定性を確認する。
• フェーズ2：本番ホストのうち1〜2台を試験的に切り替え、ログ・オフセット・サービスへの影響を監視する。
• フェーズ3：問題がなければ残りのホストを順次切り替える。クラスタ構成のホストは1台ずつ行う。

切り替えの具体的な手順は以下の通りです。ntpdとchronydは同一ホストで共存できないため、停止・削除の順序を守ります。

# 1. ntpd を停止・無効化
systemctl stop ntpd
systemctl disable ntpd

# 2. ntp パッケージを削除（設定ファイルを残す場合は --nosave を外す）
# RHEL/Rocky/AlmaLinux 系
dnf remove ntp

# Ubuntu/Debian 系
apt remove ntp

# 3. chrony をインストール
# RHEL/Rocky/AlmaLinux 系
dnf install chrony

# Ubuntu/Debian 系
apt install chrony

# 4. chrony の設定ファイルを確認・編集
# RHEL 系: /etc/chrony.conf
# Ubuntu 系: /etc/chrony/chrony.conf
# 参照サーバは ntpd 時代と同じものを指定するか、pool ディレクティブで冗長化する

# 5. chronyd を起動・有効化
systemctl enable --now chronyd

/etc/chrony.conf の基本設定では、pool または server ディレクティブで上流NTPサーバを指定します。社内NTPサーバ（階層型構成）がある場合は、そのアドレスを iburst オプション付きで指定することで起動直後の同期を速めることができます。

# chrony.conf の想定例（社内NTPサーバ 2台 + public NTP を fallback）
server 192.168.10.1 iburst prefer
server 192.168.10.2 iburst
pool ntp.nict.go.jp iburst maxsources 2
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

makestep 1.0 3 は起動後3回以内に限り、1秒以上のずれがあった場合にステップ補正を許可する設定です。本番稼働後のステップ補正を抑制したい場合は回数を絞るか、この行を削除して段階補正（slew）のみにすることも検討します。ただし初回起動時のずれが大きい環境では、ステップ補正なしだと同期完了に時間がかかる点に注意が必要です。

移行後の検証：chronyc で同期精度を確認する

chronydが起動したら、以下のコマンドで同期状態を確認します。

# 参照サーバの一覧と選択状態を表示
chronyc sources -v

# 詳細なトラッキング情報（オフセット・周波数誤差・RMS誤差）
chronyc tracking

# 時刻補正の実行ログ（直近の同期履歴）
chronyc sourcestats -v

chronyc tracking の出力で確認すべき主要なフィールドは次の通りです。

• System time：現在のシステム時刻と参照時計とのオフセット（秒単位）。通常は数十マイクロ秒〜数ミリ秒の範囲に収まることが期待されます。
• Frequency：クロックの周波数誤差（ppm）。値が小さいほど安定。
• RMS offset：オフセットのRMS値。これが移行前のntpdと比較して大幅に悪化していないことを確認します。
• Stratum：参照サーバの階層。上流が正しく解決されているかの確認に使います。

chronyc sources -v で参照サーバの前に ^* が付いていれば、そのサーバが優先参照として選ばれています。^? は未応答、^x は偽サーバ判定（Falseticker）として除外されていることを示します。

移行後1時間程度は chronyc tracking を定期的に実行し、オフセットが収束していることを確認します。想定例として、移行直後は数ミリ秒のオフセットが残ることがありますが、数十分以内に収束するのが通常の挙動です。収束しない場合は上流NTPサーバの応答状態・ファイアウォール設定・iburst オプションの有無を再確認します。

切り戻し手順と注意点

切り戻しが必要になった場合でも、ntpdの再インストール自体は容易です。ただし以下の点に注意が必要です。

# 1. chronyd を停止・無効化
systemctl stop chronyd
systemctl disable chronyd

# 2. ntp を再インストール
# RHEL/Rocky/AlmaLinux 系
dnf install ntp

# Ubuntu/Debian 系
apt install ntp

# 3. 以前の /etc/ntp.conf を復元（バックアップを事前に取得しておくこと）
cp /etc/ntp.conf.bak /etc/ntp.conf

# 4. ntpd を起動
systemctl enable --now ntpd

切り戻しの際に注意すべき点として、chronyとntpのdriftファイルは互換性がありません。chronydは /var/lib/chrony/drift、ntpdは /var/lib/ntp/drift（またはディストリビューションによって異なるパス）に別々に保存されています。切り戻し後は再度ntpdがdriftを学習するまでに時間がかかるため、初回起動後のオフセット収束を改めて確認します。

また、makestep 相当のntpd設定（tinker panic 0 や tinker step）を元の設定ファイルに含めていたかどうかも確認します。切り戻し後に大きなオフセットが残っている場合、サービスによっては認証・ログ・DB書き込みに影響が出ることがあります。

2026年現在のディストリビューション差分と注意点

2026年時点の主要ディストリビューションにおける標準NTPの扱いは以下の通りです。

• RHEL 9 / Rocky Linux 9 / AlmaLinux 9：ntpパッケージは公式リポジトリから削除済みです。chronydが唯一の標準NTPデーモンとして提供されます。RHEL 8系もchronydが標準ですが、ntpパッケージはまだ提供されています（非推奨扱い）。
• Ubuntu 22.04 / 24.04：systemd-timesyncdがデフォルトで有効になっています。chronydはapt installで追加可能で、インストールするとsystemd-timesyncdを自動的に無効化します。ntpパッケージも提供されていますが、maintenanceの優先度は低下しています。
• Debian 12（bookworm）：chronyがデフォルトのNTPクライアントとして採用されました。ntpdはリポジトリに残りますが、メタパッケージからの自動選択はされません。

なお、systemd-timesyncdはSNTPクライアントであり、サーバとして機能しません。社内で階層型NTPサーバを構成している環境や、精度要件が高いシステムでは、chronydを明示的にインストールして使用することが推奨されます。

クラウド環境（AWS・GCP・Azure）では、インスタンス起動時にホスト側の時刻同期機構が介入するケースがあります。AWSではAmazon Time Sync Service（169.254.169.123）、GCPではメタデータサーバ経由の時刻同期が提供されており、これらをchronyの参照サーバとして優先指定することで、より低レイテンシで安定した同期が得られます。既存の chrony.conf にこれらが含まれていない場合は、クラウド環境への移行・再構築のタイミングで見直すことが有効です。

移行作業自体はシンプルですが、本番環境では「事前測定 → 段階移行 → 収束確認 → 全体展開」の順序を守ることで、時刻同期の乱れによる連鎖的な障害を防ぐことができます。ディストリビューションの標準化の流れに乗り、ntpd環境が残っているシステムは計画的なchrony移行を検討する時機にあります。