Chronyで分散環境の時刻同期を再設計する｜複数タイムソース設定とNTPアクセス制御の実装手順

分散環境で時刻がずれると何が壊れるか

Kubernetesクラスターやマイクロサービス構成では、複数ノードのタイムスタンプが一致していることを前提とした処理が至るところに存在します。分散トレーシングのスパン順序、Kafka・Redisのイベント順序保証、TLS証明書の有効期間検証、etcdのRaftコンセンサス——いずれも時刻の整合性が崩れると静かに、しかし確実に誤動作します。

現場でよく見られるトラブルとして、ノード間で数十秒の時刻ずれが発生した際に、正常なリクエストが「証明書の有効期限切れ」として拒否されるケースがあります。また、ログ収集基盤（LokiやElasticsearchなど）に投入されるイベントが時系列で並ばず、インシデント調査の際に原因特定が困難になるケースも少なくありません。

このような問題の根本には「NTP設定が初期構築時のままで見直されていない」という運用上の盲点があります。本記事では、Chronyを用いた複数タイムソース設定とNTPアクセス制御の実装を、背景理解から検証・切り戻しまで一本で整理します。

なぜ今Chronyが選ばれるのか

かつてLinux環境のNTPクライアントといえばntpdが定番でしたが、RHEL 7世代（2014年）以降、多くのディストリビューションはChronyをデフォルトとして採用しています。2026年現在、RHEL 9・Ubuntu 22.04以降・Debian 12ではすべてChronyが標準パッケージとして提供されており、ntpdをわざわざ導入する理由は限られた特殊用途を除いてほぼありません。

Chronyがntpdより優れている点は大きく三つあります。第一に、ネットワーク接続が断続するラップトップや仮想マシンでの収束が速いこと。第二に、ハードウェアタイムスタンプ（PTP連携）への対応が充実していること。第三に、chronycコマンドによるリアルタイムな状態確認と動的な設定変更ができることです。

分散環境では特に「起動直後の大きな時刻ずれを素早く修正する能力」が重要です。Chronyのmakestepディレクティブはこの需要に応えるもので、ntpdのデフォルト動作（ずれが大きすぎると同期を拒否する）とは異なる設計思想を持っています。

複数タイムソースの設定手順

Chronyの設定ファイルは /etc/chrony.conf（RHEL系）または /etc/chrony/chrony.conf（Debian/Ubuntu系）に置かれます。以下の手順では、外部パブリックプールと組織内NTPサーバーを組み合わせる構成を例にとります。

pool と server ディレクティブの使い分け

poolディレクティブは、DNSラウンドロビンで複数のIPアドレスを解決するプールFQDNに使います。serverディレクティブは単一ホストを指定する際に使います。分散環境での推奨構成は次のとおりです。

# /etc/chrony.conf（例）

# 外部パブリックプール（フォールバック用・優先度低）
pool 2.pool.ntp.org iburst maxsources 3

# 組織内NTPサーバー（優先）
server ntp1.example.internal iburst prefer
server ntp2.example.internal iburst prefer

# ローカルクロックを最後の砦として設定（孤立ノード対策）
local stratum 10

# 起動時に大きなずれがあれば一気にステップ修正（3回以内、1秒超のずれ）
makestep 1.0 3

# ドリフトファイル（周波数誤差の記録）
driftfile /var/lib/chrony/drift

# ログ設定
logdir /var/log/chrony
log tracking measurements statistics

iburstは起動直後に連続してパケットを送信し、初期同期を高速化するオプションです。preferを付けたソースは、精度が許容範囲内であれば他のソースより優先して選択されます。

ソース優先度と除外設定

特定のソースを同期計算から除外しつつ監視だけしたい場合は noselect オプションを使います。これは新しいNTPサーバーを本番投入前に監視だけしたいシナリオで有用です。

# 監視のみ（同期には使わない）
server ntp-candidate.example.internal iburst noselect

noselectを外すだけで本番適用に昇格できるため、段階的なNTPインフラ移行に役立ちます。また、maxdistanceディレクティブで許容する根本誤差の上限を設定しておくと、品質の低いソースが誤って採用されることを防げます。デフォルト値は1.5秒ですが、金融系や厳密な順序保証が必要な環境では maxdistance 0.1 程度まで絞る運用もあります。

NTPアクセス制御の実装

Chronyをサーバーモードで動かしてクラスター内の他ノードに時刻を配信する場合、アクセス制御が不可欠です。適切に設定しないと、不正なクライアントからの問い合わせや攻撃的なリクエストを受け付けてしまいます。

allow と deny ディレクティブ

Chronyでは allow と deny ディレクティブでクライアントのCIDR単位のアクセス制御を設定します。評価順序は設定ファイルに記載した順番ではなく、最も具体的なマッチが優先される「ロンゲストマッチ」方式です。

# NTPサーバーとして動作させる設定（chrony.conf）

# デフォルトはすべて拒否
deny all

# 組織内ネットワークからの問い合わせを許可
allow 10.0.0.0/8
allow 172.16.0.0/12
allow 192.168.0.0/16

# 特定サブネットの例外拒否（開発・実験ネットワークを除外）
deny 10.99.0.0/16

# 管理インターフェース（chronyc -a）へのアクセスを127.0.0.1のみに限定
cmdallow 127.0.0.1
cmddeny all

cmdallow / cmddeny はNTPプロトコルの問い合わせではなく、chronycの管理コマンドに対するアクセス制御です。リモートから chronyc -h でchronydを操作できるポートを開けている場合は必ず設定してください。

ポートと systemd-timesyncd の競合に注意

Ubuntu 22.04以降では systemd-timesyncd がデフォルトで有効になっており、Chronyと同時に起動するとUDPポート123の競合が発生します。Chronyを採用する場合は必ず systemd-timesyncd を無効化してください。

sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chronyd

RHEL 9系ではこの競合は発生しませんが、コンテナイメージをベースに構築する場合や、クラウドの初期化スクリプト（cloud-init）がtimesyncdを有効化するケースがあるため、プロビジョニング後に確認する習慣をつけておくと安全です。

設定後の検証と切り戻し手順

設定変更後は必ず同期状態を確認します。chronycはリアルタイムで詳細な状態を取得できるため、積極的に使いましょう。

# ソース一覧と状態を表示（*が選択中のソース）
chronyc sources -v

# 同期精度・オフセット・ストラタムを確認
chronyc tracking

# アクセス制御の確認
chronyc accheck 192.168.1.100

# リアルタイムのソース統計
chronyc sourcestats

chronyc sourcesの出力で先頭に * が付いているソースが現在選択中のものです。^（サーバー）や =（ピア）などのシンボルと合わせて、複数ソースが正常に認識されているかを確認します。Reach列が 377（8回分すべての応答あり）になっていれば通信は安定しています。

切り戻しが必要になった場合の手順は以下のとおりです。設定ファイルのバックアップは変更前に必ず取得しておきましょう。

• 変更前の設定ファイルを /etc/chrony.conf.bak として保存しておく
• sudo cp /etc/chrony.conf.bak /etc/chrony.conf で復元
• sudo systemctl restart chronyd でデーモンを再起動
• chronyc tracking でオフセットが縮小していることを確認
• 大きなオフセットが残る場合は chronyc makestep を手動実行して即時修正

なお、chronyc makestep は時計をジャンプさせるため、ログのタイムスタンプに非連続が生じます。インシデント記録が重要な本番環境では実行タイミングをログに残しておくことを推奨します。

2026年現行環境での差分と注意点

Chrony 4.x系（RHEL 9標準は4.5、Ubuntu 24.04は4.5以降）では、いくつかの動作変更と新機能追加があります。運用担当者が把握しておくべき差分を整理します。

• NTS（Network Time Security）対応：Chrony 4.0以降はRFC 8915準拠のNTSをサポートします。server time.cloudflare.com iburst nts のように nts オプションを追加するだけで暗号化された時刻同期が可能です。パブリックNTPサーバーへの問い合わせをMITM攻撃から保護したい環境では積極的に採用が進んでいます。
• refclock ディレクティブのGPS/PTP連携：ベアメタルサーバーでGPS受信機やPTPハードウェアクロックを接続している場合、refclock PPS /dev/pps0 lock NMEA のような設定で高精度同期が実現できます。クラウド仮想マシンでは通常不要ですが、エッジ環境や工場内ネットワークでは注目されている構成です。
• SELinux / AppArmorポリシー：RHEL 9のデフォルトSELinuxポリシーはchronydのログ出力先として /var/log/chrony を許可していますが、カスタムパスに変更する場合はポリシーの追加が必要です。ausearch -c chronyd でAVCログを確認してください。
• コンテナ環境での制約：Podman/Dockerコンテナ内でchronydを動かすことは技術的には可能ですが、ホストとコンテナでクロックを共有するLinuxの仕様上、コンテナからの時刻変更はホストにも影響します。Kubernetes環境では基本的にノードホスト側でchronydを管理し、コンテナはホストの時刻を参照する設計が標準です。

分散環境における時刻同期の設計は、一度構築して終わりではなく、ノード増減やネットワーク構成の変更に合わせて継続的に見直す必要があります。chronyc sources の定期監視をモニタリングスタック（PrometheusのNTPエクスポーターなど）に組み込んでおくことで、ずれの兆候を早期に検知できる体制が整います。Chronyが提供するディレクティブの組み合わせは柔軟なため、環境の要件に応じて段階的に設定を洗練させていくアプローチが現実的です。