たかが「1秒」、されど「1秒」
こんにちは！「リナックス先生」です。
今日のテーマは、サーバー構築において最も地味で、しかし最も手を抜いてはいけない設定の一つ、「NTP（Network Time Protocol）」による時刻同期です。
先生、時刻設定ですか？
スマホもPCも勝手に時間が合う時代だし、サーバーだって放っておけば合うんじゃないんですか？
1分くらいズレてても、Webサイトが見れなくなるわけじゃないし…。
コウ君、その認識だと現場で「戦犯」扱いされるわよ。
サーバーの世界では、時刻がズレると「ログの犯人探しが不可能」になり、「二段階認証が通らなく」なり、最悪の場合「データベースが破損」するの。
今日は、現代Linuxの標準である「Chrony（クロニー）」を使って、絶対にズレないサーバーを作るわよ。
1. なぜサーバーの時間はズレるのか？
そもそも、なぜコンピュータの時間は放っておくとズレるのでしょうか。
それは、コンピュータ内部にある時計（ハードウェアクロック）が、安価な水晶発振子（クオーツ）で動いているからです。
これは品質にもよりますが、ネットワークに繋がずに放置すると、1日で数秒〜数十秒平気でズレます。1ヶ月放置すれば数分のズレになります。
特に仮想サーバー（VPSやクラウド）は、物理サーバーのCPU時間を分け合って動いているため、さらに時間が不安定になりがちです。
時刻ズレが引き起こす3大悲劇
- ログ解析不能： WebサーバーとDBサーバーの時間がズレていると、「エラーが起きた瞬間にDBで何が起きていたか」を突き合わせることができません。
- 認証エラー： Google Authenticatorなどの「ワンタイムパスワード（TOTP）」や、Windowsの「Kerberos認証」は、時刻が正確であることを前提にしています。数分のズレでログインできなくなります。
- makeの暴走： プログラムのビルドツール（make）はファイルの更新時刻を見てコンパイルするか判断します。未来の日付のファイルがあると正常に動作しません。
2. NTPの仕組みと「Stratum」階層
正確な時刻を得るために使われるプロトコルが **NTP (Network Time Protocol)** です。
NTPは、世界中の時計を階層構造（Stratum）で管理しています。
- Stratum 0： 原子時計やGPSなどの「究極に正確な時計」。直接ネットワークには繋がりません。
- Stratum 1： Stratum 0に直結されたサーバー。非常に高負荷。
- Stratum 2： Stratum 1から時刻を教えてもらうサーバー。私たち一般のサーバーは、主にここやStratum 3を参照します。
「Stratum 1を使えば一番正確だ！」と思いがちですが、Stratum 1のサーバーには世界中からアクセスが集中します。
負荷分散のため、通常の用途ではプロバイダやクラウド事業者が提供するStratum 2以下のサーバーを使うのがマナーです。
3. 現代の標準「Chrony」とは？
昔のLinux（CentOS 6など）では ntpd というソフトが使われていました。
しかし、RHEL 7 / CentOS 7以降、そしてUbuntu 18.04以降では、より高性能な Chrony（クロニー） が標準採用されています。
ntpd に対する Chrony のメリット
| 特徴 | Chrony | 旧来の ntpd |
| 同期速度 | 爆速（起動後すぐに合う） | 遅い（合うまで数十分かかることも） |
| ネットワーク断 | 断続的な回線に強い | 常時接続が前提 |
| 精度 | マイクロ秒単位 | ミリ秒単位 |
今からLinuxを学ぶなら、ntpd ではなく chronyd の使い方を覚えるのが正解です。
4. Chronyのインストールと基本操作
それでは、実際に設定していきましょう。
多くのディストリビューションで最初から入っていますが、確認を含めて手順を解説します。
インストール
AlmaLinux / RHEL系:
# インストール確認 rpm -q chrony # 入っていなければインストール dnf install chrony
Ubuntu / Debian系:
apt update apt install chrony
サービスの起動と自動起動
systemctl enable --now chronyd systemctl status chronyd
5. 設定ファイル (chrony.conf) の完全解説
Chronyの心臓部は /etc/chrony.conf です。
デフォルトでも動作しますが、日本のサーバーを使うように最適化しましょう。
vi /etc/chrony.conf
① 参照先NTPサーバーの設定 (pool / server)
デフォルトでは pool 2.alma.pool.ntp.org iburst のようになっています。
日本国内で運用するなら、より近くて信頼できるサーバー（NICTやMFEED、Googleなど）に変更することを推奨します。
推奨設定例（日本国内）:
# 日本標準時を提供するNICT（情報通信研究機構） server ntp.nict.jp iburst # インターネットマルチフィード (MFEED) server ntp.jst.mfeed.ad.jp iburst # Google Public NTP (分散していて信頼性が高い) server time.google.com iburst
先生のメモ：「iburst」って何？
これは「Initial Burst」の略よ。
サーバー起動直後、通常よりも短い間隔でパケットを連打して、一瞬で時刻を合わせるオプション。
サーバー再起動後のログズレを防ぐために、必ずつけておくべきおまじないよ。
② 段階的な時刻修正 (makestep)
もしサーバーの時間が1時間ズレていたとします。
NTPがいきなり「1時間進める」と、定期実行タスク（cron）がスキップされたり、DBの整合性が壊れたりします。
それを防ぐため、通常は「時計の進むスピードを少し速めて、じわじわ合わせる（Slewモード）」動作をします。
しかし、起動直後だけは「ガツン」と合わせて欲しいですよね。
その設定が makestep です。
# 最初の3回以内の更新で、1.0秒以上のズレがあれば、一気に合わせる makestep 1.0 3
③ ログファイルの場所
# 記録場所 logdir /var/log/chrony
設定の反映
書き換えたら再起動を忘れずに。
systemctl restart chronyd
6. 同期状態の確認（プロのコマンド術）
設定して終わりではありません。「本当に合っているか？」を確認するコマンドを覚えましょう。date コマンドだけでは、NTPが正常に動いているか分かりません。
chronyc sources -v （ソースの確認）
現在参照しているNTPサーバーの一覧と状態を表示します。
chronyc sources -v
出力例の見方：
.-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / '?' = not reachable, 'x' = time may be in error, '~' = time too variable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* ntp.nict.jp 1 6 377 25 -123us[ -125us] +/- 4ms ^+ ntp.jst.mfeed.ad.jp 2 6 377 20 +450us[ +450us] +/- 8ms
ここだけは見て！最重要ポイント：
- 左端の記号 (M/S):
*(アスタリスク): 現在メインで同期しているサーバー。「神」と崇めている相手です。+(プラス): 候補として良好なサーバー。「予備」です。?(ハテナ): 通信できていません。Firewall設定などを疑ってください。
- Reach: 通信成功履歴（8進数）。ずっと通信できていれば 377 になります。これが 0 の場合は全滅です。
chronyc tracking （詳細精度の確認）
現在の自分のサーバーのズレ具合を確認します。
chronyc tracking
- System time: 0.000123 seconds slow of NTP time
→ 実際にどれくらいズレているか。ここが数秒以上ある場合は異常です。 - Leap status: Normal
→ 「うるう秒」の予告があるかどうかが分かります。
7. タイムゾーンの設定 (timedatectl)
NTPで正確な時刻（UTC）を取得しても、表示設定（タイムゾーン）が間違っていると、ログの時間がズレて見えます。
日本時間 (JST) に設定しましょう。
現在の設定確認
timedatectl status
日本時間への変更
# タイムゾーン一覧から Asia/Tokyo を探す timedatectl list-timezones | grep Tokyo # 設定変更 timedatectl set-timezone Asia/Tokyo # 確認 date # -> 末尾が JST になっていればOK
8. 高度な設定：内部NTPサーバーの構築
もし、社内LANの中に100台のサーバーがあったとします。
100台すべてがインターネット上のNICTへ時刻を取りに行くと、ルーターに負荷がかかりますし、マナー違反でもあります。
そこで、1台を「親（NTPサーバー）」にし、残りの99台を「子（クライアント）」にする構成をとります。
親サーバー側の設定 (/etc/chrony.conf)
「特定のネットワークからのアクセスを許可する」設定を追加します。
# 192.168.1.0/24 からの時刻問い合わせを受け付ける allow 192.168.1.0/24
そして、Firewallで UDP 123番ポート を開放します。
firewall-cmd --add-service=ntp --permanent firewall-cmd --reload
子サーバー側の設定
親サーバーのIPを指定します。
server 192.168.1.10 iburst
まとめ：時間はインフラの品質そのもの
たかが時刻設定、されど時刻設定。
NTPの設定が美しいサーバーは、ログも追いやすく、トラブル時の復旧もスムーズです。
【本日のまとめ】
- ntpdは古い。 今は Chrony を使うべし。
- iburst は必須。 起動直後の高速同期に役立つ。
- Stratum 1 への集中を避ける。 通常はプロバイダ等のStratum 2を利用する。
- 確認は date ではなく chronyc sources。
*マークがついているか必ずチェックする。 - タイムゾーンも忘れずに。
timedatectlでJSTにする。
なるほど…。
「なんか時間が合わないなー」と思って手動で date コマンドで直してたのが、いかに危険な行為だったか分かりました。
これからはちゃんとChronyにお任せします！
ええ、それがいいわ。
インフラエンジニアの仕事は「当たり前を維持すること」。
時間が正確であること、それはサーバーが健康であることの基本中の基本よ。
しっかり設定して、信頼されるサーバーを作りなさい！
▼時刻が正確で安定したVPS
ハードウェアクロックの精度が高く、国内の高速回線でNTP同期も安定している、Linux学習や本番運用に最適なVPSはこちらです。
コメント