物理サーバーの時刻同期：chrony の参照元と同期外れを検証

決済コールバックが期限切れと判定される、ログイントークンがときどき無効になる、プロセス間でログの時系列が逆転する。これらは、システムクロックが安定して同期していないという共通の問題から生じている可能性があります。タイムゾーンを変更しても表示が変わるだけで、時刻のずれは修正されません。調査では、いきなり強制的な時刻補正コマンドを実行するのではなく、時刻源、同期状態、業務上許容できる誤差から確認します。

本記事では Debian 12 の chrony を例に、「参照元の確認—ずれの解釈—同期ゲートの設定—復旧の検証」という手順を整理します。AmdMetal の物理サーバーは、支払い後にコンソールで認証情報を確認し、SSH で接続します。IPv4 が複数ある場合は、最初のアドレスを使用します。以下の操作でネットワークアドレスを変更することはなく、管理ポートを外部に公開する必要もありません。

1. 基準となる状態を記録し、表示と補正を区別する

まず、システム時刻、タイムゾーン、カーネルバージョン、現在の時刻同期サービスを記録します。業務ログはタイムゾーンを含む時刻形式に統一し、調査記録には UTC も併記するとよいでしょう。表示上の違いをクロックのドリフトと取り違えずに済みます。

date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
uname -r
systemctl is-active chrony systemd-timesyncd

timedatectl の同期に関する項目は手がかりにはなりますが、時刻源の確認の代わりにはなりません。ほかの時刻同期プロセスや構成管理タスクが、同時にクロックを調整していないかも確認します。ホスト上の仮想マシンも個別に点検が必要です。ホストが正常だからといって、ゲスト OS も正常とは限りません。

chrony が未インストールの場合は、システムのパッケージリポジトリからインストールできます。ただし、インストールによってサービスが起動し、ディストリビューションの初期設定が適用される可能性があります。すでに業務が稼働しているサーバーでは、有効になる設定とパッケージのインストール時の動作を先に確認し、ひとまずインストールして様子を見るという進め方は避けてください。

sudo apt-get update
sudo apt-get install chrony
systemctl status chrony --no-pager

稼働中のデータベース、認証サービス、タスクスケジューラは、壁時計の時刻が不連続に変わる影響を受けることがあります。業務への影響を評価するまでは、date -s や chronyc makestep を実行しないでください。時刻同期サービスの再起動を繰り返して「時刻を直そう」とすることも避けます。

2. 時刻源を確認する：到達できることと信頼できることは別

インストール後は、メインの設定ファイルと、そこから参照されるファイルを確認します。時刻源のアドレスには、組織が承認したものを使用してください。出所の不明な公開アドレスをそのまま流用したり、特定の固定ソースを AmdMetal が提供するインフラとみなしたりしないでください。

sudo grep -R -E \
'^[[:space:]]*(server|pool|peer|sourcedir|confdir|include|makestep|local|offline)' \
/etc/chrony
chronyc activity
chronyc sources -v
chronyc sourcestats -v

server と pool は時刻源を定義します。読み込み対象のディレクトリから、追加設定が取り込まれる場合もあります。重複する時刻源は、実際のサーバーを基準に整理します。複数の名前が最終的には同じインフラを指していることもあるため、設定行の数だけで独立性を判断してはいけません。

sources -v の * は現在選択されている同期元、+ は時刻の合成に使われる参照元、? は現在選択に利用できない参照元を示します。? は、到達不能やサンプル不足などによって表示されることがあります。Reach は到達履歴を8進数で表したものです。377 は直近8回のポーリングすべてで応答があったことを示しますが、時刻の正確さを保証するものではありません。

時刻源に異常がある場合の確認順序

最初に名前解決を確認し、次に参照先アドレスへのルーティングと送信ポリシーを点検して、その後でサンプルが継続的に更新されているかを観察します。NTP の応答が届くことから分かるのは、通信が成立しているという点だけです。参照元の時刻異常、遅延の非対称性、サンプル間の不一致は、引き続き時刻源の選択に影響します。? を消すためだけに、サーバー全体のファイアウォール設定を安易に緩めないでください。

3. ずれを読み解き、単一の項目だけで判断しない

chronyc tracking
journalctl -u chrony -b --no-pager -n 100

Reference time は継続的に更新されている必要があります。Leap status が Not synchronised の場合は、正常と判定できません。System time は、chrony が推定する残りの補正量です。ゼロに近い値であっても、実際の UTC に対する誤差が小さいことまで独立に裏付けられたわけではありません。

Last offset と RMS offset はサンプルや統計の状況を示し、Root delay と Root dispersion は基準時計までの経路や不確かさを判断する手がかりになります。これらは参照元の状態と合わせて読む必要があります。小数値を1つだけ抜き出して、合格の根拠にしてはいけません。

複数のポーリング周期を含むように、結果を連続して何回か記録することをお勧めします。コールドスタート後の収束過程、ネットワーク復旧後のサンプルの再蓄積、安定稼働中の状態は、それぞれ分けて判断します。1回の観測値を小さくしようと設定変更を繰り返すと、どの変更が効果をもたらしたのか分からなくなります。

4. 待機に上限のある同期ゲートを設ける

時刻に依存する業務では、起動時やデプロイ時のチェックに、待機回数を限定した同期判定を組み込めます。以下の値はあくまで実装例です。実際のしきい値は、トークンの有効期間、監査要件、業務テストに基づいて決めるもので、サービス上の保証ではありません。

chronyc waitsync 12 0.05 0 5

このコマンドは5秒間隔で最大12回確認します。同期状態に入り、残りの補正量が 0.05 秒未満になることが条件です。第3引数のゼロは、skew に追加の制限を設けないことを意味します。正常終了はこれらの条件を満たしたことを示すだけで、実際の UTC に対する誤差が50ミリ秒未満であることを保証するものではありません。

自動化処理では必ず終了コードを確認し、失敗時の出力を握りつぶさないようにします。

if chronyc waitsync 12 0.05 0 5; then
    printf '%s\n' 'Clock gate passed'
else
    printf '%s\n' 'Clock gate failed' >&2
    exit 1
fi

ゲートの判定に失敗した場合は、関連する起動処理を止めて運用担当者に通知します。時刻をステップさせる修復を自動で実行してはいけません。network-online.target が扱うのはネットワークの準備状態だけであり、時刻同期の完了を示すものではありません。

ゲートの失敗経路も検証する

隔離したテスト環境で、利用可能な参照元がないときにゲートがゼロ以外の終了コードを返すことを確認します。その後、参照元を復旧して成功経路も検証します。ずれを作るために、本番の物理サーバーでシステム全体の時刻を変更しないでください。すべてのサービスに同時に影響するうえ、障害の前後関係を判断するためのログも損なわれます。

5. 復旧後に確認し、説明可能な証跡を残す

参照元を手動でオフラインにしていた場合は、ネットワークの復旧を確認してから chronyc online を実行します。サンプルを補充する必要がある場合は、設定済みの参照元に対して chronyc burst 4/4 を1回実行し、その後で参照元の選択状態と tracking の結果を再確認できます。ループで呼び出し、無意味なリクエストを発生させないでください。

makestep を確認する際は、特に makestep 1.0 3 のような設定に注意します。この設定では、起動後の最初の数回のクロック更新で、ずれがしきい値を超えた場合に時刻を直接ステップさせることが許可されます。サービスを再起動すると、この段階に再び入る可能性があります。そのため、「とりあえず再起動」はリスクのない操作ではありません。大幅な時刻のステップがどうしても必要な場合は、影響を受ける業務を先に隔離し、復旧計画を整えておきます。

最終確認には、次の項目を含めます。

• 適切な参照元が選択され、基準時刻が継続的に進んでおり、古いサンプルを長時間参照し続けていない。
• 残りの補正量と不確かさが業務上のしきい値を満たし、連続観測で明らかな悪化が見られない。
• ゲートの成功経路と失敗時の終了動作を両方検証し、アラートを受信できる。
• プロセスの生存確認だけでなく、認証、コールバック、ログの時系列について業務側で再テストを行っている。
• 設定変更、コマンド出力、観測期間を記録し、ログ内の参照元アドレスはアクセス権限に従って管理している。

処理時間の計測やタイムアウト制御には、単調増加クロックを優先して使用し、業務上のタイムスタンプには壁時計を使用します。アプリケーションの時間計測方法と、ホストの同期状態の確認を切り分けることで、1回の時刻補正によって正常な処理時間が負の値になる事態を防ぎ、その後の障害記録も説明可能な状態に保てます。

よくある質問