時刻同期モードの種類

NTPクライアントがNTPサーバより時刻を受け取った時に、自分の現在時刻と受け取った時刻に乖離があった場合の同期方法を調整できます。

有名なものでは、「slewモード」と「stepモード」がありますが、実は同期モードはもっと種類があります。

今回は有名なものでNTPクライアントの設定の基本となるslewモードとstepモードにフォーカスして説明していきます。

以下はNTPクライアントにて設定可能な同期モードの一覧です。
※NTPクライアントソフトによりサポートしていないモードもありますので、使用しているソフトウェアを確認下さい。

調整方法	動作概要	主な使用条件	システムへの影響	設定オプション例
Slew調整	システムクロックの進行速度を微調整して徐々に目標時刻に近づける	小さなオフセット（通常500ms未満）	時間の連続性が保たれ、アプリケーションへの影響が少ない	-x (slew-only)
Step調整	システム時刻を一度に目標値にジャンプさせる	大きなオフセット（通常500ms以上）	時刻の不連続が発生し、一部のアプリケーションに問題を起こす可能性	tinker step (閾値調整)
Panic調整	非常に大きなオフセットを検出した場合に調整を拒否する保護機能	異常な時刻差（通常1000秒以上）	NTP調整を停止し、手動介入が必要になる	tinker panic (閾値調整)
Kernel調整	カーネルのPLL/FLL機能を使用して高精度調整	カーネルでNTPサポートが有効な現代のOS	最も精度の高い調整が可能	kernel enable/disable
Burst/Iburst	初期同期時や再同期時に複数のパケットを短時間で送信	初期同期や再接続時の高速同期	初期同期が高速化、一時的なネットワーク負荷増加	burst, iburst
Step-Tick	システムティック単位で小さなステップ調整を行う	Kernel PLL/FLLが利用できない環境	Slew調整よりやや粗い調整になる	enable step-ticks
adjtime調整	システムのadjtime()関数を使用した古典的な調整	古いシステムやカーネルNTP機能未対応環境	現代の方式に比べて精度が劣る	（レガシーモード）
Update-Leap	うるう秒情報を処理する専用の調整モード	うるう秒の挿入/削除イベント発生時	うるう秒の滑らかな処理（スムージング）	leapfile /path/to/leapfile
Adaptive調整	ネットワーク状況に応じて自動的にポーリング間隔を調整	変動するネットワーク環境	状況に応じた最適化、負荷とパフォーマンスのバランス	minpoll/maxpoll

slewモードはシステム時刻の連続性を保つことを重視した調整方法です。

時刻のズレを一気に修正するのではなく、徐々に目標時間まで近づけていきます。

近づけ方としては、時刻が進んでいる場合は、1秒をほんの少し長くします。(1.001秒のように。)

1秒が少し長くなることで、進んでいたシステムの時刻は徐々に目標時刻に近づいていくというものです。

もちろん逆に時刻が遅れいている場合は、i秒をほんの少し短くするようにして修正していきます。

この方法では、1秒の時刻ズレを直すのに、2000秒(33分)かかると言われており、本当にゆっくりと直していきます。

では、なぜこのような面倒な方法を取るのでしょうか？

例えば、自分の時計が10分早かったことに気づいたときに、一気に時計を10分前に戻したとします。

このとき、OSのログはどのように出力されるでしょうか？

まるで急に時間が戻ってしまったかのようになり、ログの前後関係がわからなくなってしまいますね。


このように時刻が急に巻き戻ってしまうと、不都合のある機能が多いため、急な時間変更をせずにズレを修正する方法が「slewモード」です。

NTPクライアントの設定では、このslewモードがデフォルトとなっていることが多いです。

NTPのstepモードは、コンピュータシステムの時刻同期における特定の動作方式です。

stepモードに設定されているNTPクライアントはNTPサーバとの定期的な時刻同期にて検出された時刻の差を毎回即時に修正を行います。

修正されるたびに、システム時刻は先に進んだり、前に戻ったりを繰り返すことになりますので、同期モードとしてstepモードを選択するケースは少ないです。


ただし、slewモードにて徐々に修正する用設定していたとしても、標準設定においては時刻の誤差が大きい場合にはstepモードにて時刻を即時修正する挙動となっている点に注意が必要です。

具体的には、現在の時刻と正確な時刻の差が一定のしきい値（通常は約128ミリ秒）を超えた場合、段階的な調整ではなく一度に時刻をジャンプさせて合わせます。

この方式は主にシステム起動時や長時間ネットワークから切断されていた場合など、クロックが大幅にずれている状況で有効です。

ただし、stepモードによる急激な時刻変更は一部のアプリケーションに問題を引き起こす可能性があります。

特にデータベースやログシステムなど時間の連続性に依存するシステムでは、時刻が突然前後にジャンプすることで処理順序の混乱や認証の問題が生じることがあります。

そのため、どの程度のズレであればslewモードで修正させて、どこからはstepモードとするのかがNTPクライアント側での設計要素となります。

slewモードの章でも記載しましたが、1秒の修正に約33分かかりますので、例えば5分のズレを直すとなると「約166.7時間(約7日)」かかる計算になります。


その間はずっと時間がズレたままとなってしまいますので、一般的には「128ミリ秒」までのズレであればslewモードとし、それ以上のズレではstepモードとするパターンです。

128ミリ秒であれば、約256秒（約4分16秒）で修正できるレベルのズレとなります。

時刻同期のメインであるslewモードとstepモードに設定可能なオプションのモードを追加した組み合わせパターン例を作成しました。

飽くまでも参考例になりますので、どのパータンを採用するかは各システムにて検討が必要です。

組み合わせパターン	含まれる調整方法	典型的な用途	メリット	デメリット
標準構成 (デフォルト)	Slew + Step + Kernel + Adaptive	一般的なサーバ/デスクトップ環境	バランスの取れた調整、ほとんどの状況に対応	時刻ジャンプの可能性あり
高安定性優先	Slew-only + Kernel + Adaptive	データベース、トランザクションシステム	時刻の連続性保証、アプリケーション影響最小化	大きな時刻ずれの修正に時間がかかる
高精度優先	Kernel + Step + Burst/Iburst	計測システム、タイムスタンプ重要環境	可能な限り正確な時刻を維持	時刻ジャンプによるアプリケーション影響リスク
初期同期高速化	Step + Iburst + Kernel	システム起動時の素早い同期が必要な環境	迅速な初期同期、起動後の時刻精度確保	初期のネットワーク使用量増加
保守的構成	Slew + Panic(低閾値) + Adaptive	変更に敏感なミッションクリティカルシステム	異常な時刻変更を確実に防止	管理者の手動介入が必要になる場合が増加
レガシー環境用	adjtime + Step-Tick	古いOS、特殊なハードウェア環境	広い互換性、特殊環境でも動作	精度と効率性が低下
うるう秒対応構成	標準構成 + Update-Leap	うるう秒に厳密な対応が必要なシステム	うるう秒の正確な処理、時刻の一貫性維持	うるう秒ファイルの定期的な更新が必要
仮想環境最適化	Slew + Kernel + Adaptive(広範囲)	仮想マシン、コンテナ環境	仮想環境特有の時刻ジッターに対応	より広いポーリング範囲が必要
モバイル/省電力構成	Adaptive(長間隔) + Step + Kernel	ノートPC、モバイルデバイス	バッテリー使用量とネットワークトラフィック削減	同期頻度低下により精度がやや低下
冗長NTP構成	標準構成 + 複数サーバ + Burst	高可用性が求められる環境	単一障害点の排除、より信頼性の高い時刻同期	設定が複雑化、ネットワーク負荷増加

NTPクライアント側での時刻同期モードについて解説しました。

stepモードやslewモードはよく使われれるものなので、重点的に理解しておきましょう。

特に構築するシステムの特性によりNTPに設定すべき項目は変わってきます。

DBサーバでは時刻のジャンプは許容できないため、slewモードのみでstepモードは使用しない設定にするなど考慮が必要です。

たかが、時刻同期ですが設計に失敗すると大障害に繋がることもあります。

しっかりと学習していきましょう。