LASSIC Media らしくメディア

システム開発を発注する担当者やプロジェクトマネージャーが見積書や設計書を読んでいても、「サーバーの時刻を合わせる」という項目はあまり目にとまりません。ところが障害調査の場面になると、複数のサーバーのログを突き合わせても発生順序が食い違い、原因の切り分けに時間がかかりがちです。その背景には、各サーバーの時計が少しずつずれていく、という地味だが根の深い問題が潜んでいます。とくに複数のベンダーが関わる開発体制や、オンプレミスとクラウドが混在する構成では、どの機器がどの基準時刻を参照しているかを誰も把握しないまま稼働に至ってしまう例も見受けられるでしょう。

この時刻のずれを放置しないための取り決めがNTP（Network Time Protocol）です。実装そのものはインフラ担当者やクラウド事業者に任せる場面が大半ですが、「時刻同期がどこまで設計に組み込まれているか」を発注側が把握しておかないと、稼働後に思わぬ形で不具合の原因になり得ます。この記事では、NTPの基本的な仕組みと、時刻がずれるとどんな不具合につながるか、そして発注・レビューの場面で何を確認すればよいかを、実装の細部ではなく判断材料として整理します。

NTPとは

NTP（Network Time Protocol）とは、ネットワークを通じて複数のコンピュータの時刻を、基準となる正確な時刻へ合わせ続けるための通信の取り決めです。似たテーマに「タイムゾーンとUTC」がありますが、あちらは時刻の表し方（何時何分と表示するか）を扱う内容です。本記事は、複数の機器が持つ時刻そのものを合わせ続ける仕組みを取り上げます。

サーバーやネットワーク機器は、内部に水晶発振子を使った時計を持ちます。この時計は温度や個体差の影響を受け、時間の経過とともに少しずつずれていくのが一般的です。1台だけを見ているとずれに気づきにくいものですが、複数台が連携するシステムでは、ずれの向きや大きさが機器ごとに異なるため、時刻を突き合わせる場面で不整合として表に出てきます。

NTPは、このずれの蓄積を放置しないための通信の取り決めであり、基準となるサーバー（時刻源）へ定期的に問い合わせ、自分の時計との差分を測ったうえで補正し続けます。発注担当者やプロジェクトマネージャーにとっては、実装の細部より先に、システム全体でどの機器がどの基準へ時刻を合わせているかを把握しておくことが要点になるでしょう。時刻同期の設定自体は珍しいものではなく、OSやネットワーク機器の初期設定にすでに組み込まれている場合もあります。ただし、その既定の設定が自社のシステム構成に合っているかどうかは、別途確認しておく必要があるでしょう。

やり取りそのものは単純で、問い合わせる側（クライアント）が参照先のサーバーへ時刻を尋ね、サーバーが自身の時刻を添えて答える、という往復を繰り返します。オフィスのPCから業務サーバー、クラウド上の仮想マシンまで、ネットワークにつながる機器であれば同じ仕組みで時刻を合わせられる点が、NTPが広く使われている理由の一つといえるでしょう。厳密な精度を求めない用途向けに、やり取りを簡略化したSNTP（Simple NTP）という派生の仕様も存在しますが、いずれも基準時刻へ寄せていくという考え方は共通しています。

複数の会社が開発した機器やサービスが連携するB2Bのシステムでは、それぞれの担当ベンダーが個別に時刻の設定を決めてしまいがちです。発注側があらかじめ「どの基準時刻へ、どの経路で合わせるか」を横断的に取り決めておくと、後から複数のベンダーの設定を突き合わせて手直しする事態を避けやすくなります。

時刻がずれると何が起きるか

たとえば、注文受付サーバーと在庫管理サーバーの時刻が数分ずれているとします。両者のログを突き合わせて注文処理の遅延原因を調べようとしても、どちらの処理が先に走ったのかを時刻だけでは判断がつかないのです。時刻のずれは、単体の機器では気づきにくい一方、システムが連携する場面でまとまった不具合として表面化します。発注・レビューの段階で押さえておきたい代表的な影響は、次の四つです。

• ログの時系列が突き合わせられない：複数サーバーのログを時刻順に並べて障害原因を追う調査で、サーバー間の時刻がずれていると発生順序を取り違え、原因の特定に時間がかかります。障害対応の初動が遅れれば、影響範囲の見極めそのものも後ろ倒しになりかねません。
• 認証トークンや証明書の有効期限判定が乱れる：サーバーの時刻がずれると、本来有効なトークンや証明書を期限切れと誤って扱ったり、逆に期限切れのものを通してしまったりすることがあります。連携先のシステムとの間で認証エラーが断続的に起き、原因が時刻のずれだと気づくまでに時間を要するケースも見られます。
• 分散処理での順序が混乱する：複数のサーバーがタイムスタンプをもとに処理順序を決める仕組みでは、時刻のずれが前後関係を狂わせ、意図しない上書きや処理の重複につながります。在庫・予約のように早い者勝ちの判定を伴う処理では、影響がそのまま業務上の不整合として表面化します。
• 課金・監査記録の整合性が崩れる：課金の起算・終了時刻や監査ログの証跡は、時刻の正確さが前提です。ずれが生じると記録の説明が難しくなり、監査対応や顧客への説明に支障が出ます。

認証やログのように、複数の仕組みが時刻を前提に組み立てられているシステムほど、ずれの影響は一箇所にとどまりません。ある処理で生じたわずかなずれが、別の処理での判定ミスを誘発し、原因の切り分けをいっそう難しくすることもあります。設計の早い段階で時刻同期の方針を決めておくことが、後工程での手戻りを避ける近道といえるでしょう。

NTPの仕組み — stratum階層と補正

NTPは、基準となる時刻から段階的に時刻を配る階層構造と、通信の遅れを見込んで少しずつ時刻を寄せる補正のしくみで成り立っています。細かな計算式を覚える必要はありませんが、この二つの柱を押さえておくと、製品選定時のカタログや設定資料に出てくる用語の意味がつかみやすくなるはずです。順に見ていきましょう。

階層は「stratum（ストラータム）」と呼ばれ、原子時計やGPS受信機など時刻そのものを生成する基準時刻源をstratum 0とします。stratum 0に直接つながるサーバーがstratum 1、そこから時刻を受け取るサーバーがstratum 2というように、基準からの距離に応じて番号が一つずつ増えていく仕組みです。

番号が大きくなるほど基準時刻源からの経由が増えるため、時計の精度は段階的に下がっていきます。社内のサーバー群を設計する際は、外部の基準（stratum 1相当のNTPサーバー）を何段で受け止め、どこまでの階層で運用するかを決めることになります。

この階層には、時刻の流れを一方向にそろえ、循環参照を避けるという役割もあります。下位のサーバーは自分より番号の大きいサーバーを参照先に選ばない、という決まりに沿って動くため、社内のサーバー同士が互いを参照し合って時刻が定まらなくなる、といった事態を防げる設計になっているのです。

もう一つの柱が補正の方法です。NTPは、問い合わせを送った時刻・相手が受け取った時刻・相手が返した時刻・自分が受け取った時刻という四つの記録から、通信にかかった往復の遅れ（ディレイ）を割り出し、そのうえで自分の時計が基準時刻とどれだけずれているか（オフセット）を求めます。片道の通信時間が行きと帰りでほぼ等しいと見なせることを利用した、シンプルな計算です。

求めたオフセットは、一度に反映するのではなく、時計の針を少しずつ進めたり遅らせたりして近づける「slew（スルー）」という方法で解消するのが基本です。時刻を一気に巻き戻す「step（ステップ）」補正も存在しますが、こちらはログの記録順序が入れ替わったり、ファイルの更新日時が前後したりする不具合を招きやすいため、ずれが大きいときの初期補正など限られた場面で使われます。両者の違いを整理すると、次のようになります。

運用で確認すべきこと

NTPを使いこなすうえで、日々の運用で確認しておきたい点は主に三つあります。設定して終わりにできる項目ではない、という前提で見ていきましょう。

参照するNTPサーバーの選び方

参照先には、インターネット上で無償公開されている公開NTPサーバーと、社内に構える社内NTPサーバーの二種類があります。国内では情報通信研究機構（NICT）が日本標準時に直結したNTPサーバー（ntp.nict.jp）を公開しており、stratum 1として利用できます。公開NTPサーバーには、想定を超えるアクセスへの利用制限が設けられている場合があるため、社内に多数の機器がある環境では、各機器が直接問い合わせるのではなく、社内に中継用のNTPサーバーを一台以上置き、そこから配る構成が一般的です。

参照先は1台に絞らず、複数のNTPサーバーを並行して参照する構成も広く採られています。複数の参照先から得た値を突き合わせ、他と大きくかけ離れた応答を除外する仕組みがNTPには備わっているため、参照先を複数持たせるほど、単一のサーバーの不調や経路上の異常に振り回されにくくなります。社内の中継サーバー自体も、電源系統やネットワーク経路を分けて複数台構成にしておくと、片方が停止しても社内全体の時刻同期を保ちやすくなるでしょう。

うるう秒の扱い

NTPには、うるう秒（閏秒。地球の自転のずれを補正するために時刻へ1秒を足し引きする調整）の挿入・削除を通知する仕組みが用意されています。通知を受けた側の対応方法は実装に委ねられており、うるう秒の瞬間に1秒を差し込む方式のほか、前後の時間帯にかけて1秒を薄く引き延ばす「leap smearing」という方式を採る事業者も見られるでしょう。どちらの方式で運用するかによって、瞬間的な時刻の重複や飛びが起きるかどうかが変わるため、時刻に敏感な処理を持つシステムでは事前の確認が要ります。うるう秒の挿入は頻繁に起こるものではありませんが、発生する年には各所のシステムが同じタイミングで影響を受けます。対応方針を決めていないまま当日を迎えると、原因の切り分けに時間を取られやすい点にも注意が必要です。

監視でずれを検知する

参照先のサーバーが応答しなくなったり、ネットワーク経路の変化で遅延が広がったりすると、時刻のずれは気づかないうちに広がっていきます。オフセット（基準時刻との差分）を定期的に取得し、あらかじめ決めたしきい値を超えたら通知する監視を組み込んでおくと、ずれの拡大を早い段階で捉えられるでしょう。代表的なNTPクライアントであるchronyやntpdは、参照先との差分やジッター（ゆらぎ）を照会するコマンドを備えています。これらの値を監視基盤に取り込み、ダッシュボードやアラートへ反映しておくと、日々の運用にかかる手間が減るはずです。たとえば、参照先のネットワーク機器がファームウェア更新で一時的に応答しなくなった場合、監視の仕組みがなければ、時刻がじわじわとずれ続けていることに誰も気づかないまま、しばらく経ってからログの不整合という形で問題が発覚します。オフセットの監視は、こうした静かな不調を早めに拾い上げるための備えといえるでしょう。

表に挙げた不具合は、いずれも発生してから時刻のずれが原因だと判明するまでに時間がかかりやすいという共通点があります。日頃から時刻同期の状態を可視化しておくことが、こうした不具合の切り分けを早める土台になるでしょう。

発注・レビューで押さえる点

システム開発を発注・レビューする立場では、実装の細部より先に、時刻同期が設計に組み込まれているかどうかを確認する視点が要ります。

時刻同期の設計が含まれているか

要件定義や基本設計の資料に、どのサーバーがどのNTPサーバーを参照するか、社内に中継サーバーを置くかどうかが明記されているかを確認します。クラウド環境を使う場合も、提供元が用意する内部向けの時刻同期サービスを使うのか、独自に構成するのかを切り分けておく必要があります。記載が見当たらない場合は、既定の設定に任せきりになっている可能性があるため、確認を求めるとよいでしょう。とくに複数の開発会社が別々の工程を担当する体制では、それぞれが個別のNTP設定を持ち込んでしまい、後になって参照先の不一致が見つかることもあります。設計レビューの早い段階で、時刻同期の方針を一枚の資料として横断的に確認しておくと、こうした食い違いを未然に防ぎやすくなります。

ログのタイムゾーンとあわせて確認する

時刻同期が整っていても、サーバーごとにログの記録がUTCとJSTで混在していると、突き合わせの際に読み替えの手間が生じます。設計段階で、ログに記録するタイムゾーンの統一方針を時刻同期の方針とセットで確認しておくと、障害調査で時刻の読み替えに時間を取られずに済むでしょう。あわせて、ログの出力形式にタイムゾーンの表記（UTC・+09:00など）そのものを含めておくよう指定しておくと、後から見返す際の取り違えを防ぎやすくなります。

運用体制・保守契約でおさえる点

時刻同期の設定は、構築時だけでなく運用フェーズでも見直しが要る項目です。参照先サーバーの変更、うるう秒対応方式の切り替え、監視のしきい値調整といった作業が、保守契約のどの範囲に含まれるのかを事前に確認しておくとよいでしょう。含まれていない場合、障害発生後にあらためて追加の依頼が必要になり、対応が後手に回りかねません。災害対策やデータセンターの切り替えを想定した設計を組む際も、切り替え先の環境で参照するNTPサーバーが変わらないか、切り替え直後に大きな時刻のずれが生じないかをあわせて確認しておくと、いざというときの動作をイメージしやすくなります。

社内だけでこの設計を詰める場合、stratum構成の設計・監視のしきい値設定・クラウド基盤側の時刻同期仕様という三つの領域を把握した担当者が要ります。稼働中のシステムに後から手を入れる場合は、既存の時刻設定を機器ごとに洗い出す工数も見込んでおく必要があるでしょう。自社に前例がない場合、参照構成の妥当性や監視のしきい値を一から検討することになり、初期の構築に時間がかかりがちです。設計段階から開発パートナーに加わってもらえば、階層設計や監視方針を含めて相談しながら進められます。内製で完結させる場合と、外部のパートナーに設計段階から加わってもらう場合とでは、検討にかける時間の配分が変わってくる点も見積もりの際に考慮しておきたいところです。

まとめ

本稿では、NTPの基本的な仕組みと、発注・レビューで確認したい点を整理しました。要点を三つに集約すると、次の通りです。第一に、NTPは複数の機器の時刻を基準へ合わせ続けるための通信の取り決めであり、時刻のずれはログ突き合わせや認証判定、分散処理の順序に影響します。第二に、仕組みの中心は、stratumと呼ばれる階層構造と、往復の遅延を見込んだ段階的な補正の二本柱です。第三に、運用では参照先サーバーの選び方・うるう秒の扱い・監視という三点を継続的に確認する姿勢が欠かせません。

開発を依頼する際は、これらが設計に組み込まれているかを早い段階で確認しておくと、後工程での手戻りを避けやすくなります。見積もりや提案の場でNTPの構成が話題に上らない場合は、こちらから「参照先はどこにするか」「監視はどう組み込むか」を尋ねてみるとよいでしょう。時刻同期は完成後に見た目で分かる機能ではないぶん、要件定義や設計レビューの場でこちらから話題に挙げなければ、確認の機会を逃してしまう項目でもあります。発注担当者やプロジェクトマネージャーが要点を押さえておくことが、稼働後のトラブルを未然に防ぐ手立てになるはずです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• 情報通信研究機構（NICT）「公開NTPサービス」
• 情報通信研究機構（NICT）「NTP：よくあるご質問（FAQ）」
• IETF RFC 5905「Network Time Protocol Version 4: Protocol and Algorithms Specification」
• Wikipedia日本語版「Network Time Protocol」

Tweet