分散システムの時刻同期(Clock Synchronization: NTP·PTP·TrueTime)

1. 概要

A. 定義

時刻同期(Clock Synchronization)とは、互いに独立して動作する複数のコンピュータ·ネットワーク機器の物理時計(wall-clock)を一つの基準時刻(例: UTC)に合わせるか、ノード間の時刻差(offset)を既知の限界内に抑制し、分散システムが時刻を信頼できる資源として利用できるようにするプロトコル·アルゴリズムの総称である。代表的な技術には、インターネット全般をミリ秒水準に合わせるNTP(Network Time Protocol)、LAN·産業網をマイクロ秒~ナノ秒水準に合わせるPTP(IEEE 1588)、そして時刻の不確実性を数値で露出しトランザクション順序に活用するGoogle SpannerのTrueTimeがある。

時刻同期は一見単純な「時計合わせ」のように見えるが、実際には分散ログの相関分析、セキュリティ証明書·OTP·Kerberosチケットの有効性、金融取引の約定順序、5G基地局の無線フレーム整列、電力網の位相測定までを支えるインフラの隠れた基盤である。ログのタイムスタンプがずれると障害の原因分析が不可能になり、証明書検証が誤動作し、取引順序が入れ替わって規制違反が発生する。

B. 登場背景と必要性

すべてのコンピュータは水晶発振器(quartz oscillator)を基盤とした内部時計を持つが、この発振器の周波数は温度·電圧·老化に応じて微細に変動する。その結果、時計は基準時刻より少しずつ速くなったり遅くなったりするが、この変化率をドリフト(drift)と呼び、一般的な商用水晶時計は一日に数秒、すなわち百万分の数十(数十ppm)水準でずれる。同期をまったく行わないと数日でノード間の時刻差が数秒に達し、時刻を基準とするすべての判定が揺らぐ。

問題が単純な「時計が狂う」にとどまらない理由は、分散システムにおいて時刻が正確性(correctness)とセキュリティの前提として使われるからである。TLS·コード署名証明書は有効期間を時刻で検証し、Kerberos·TOTPは時刻差が許容窓(通常±5分)を超えると認証を拒否し、分散データベースのLWW(Last-Write-Wins)はタイムスタンプの大小で勝者を決める。時計がずれると正常な証明書が拒否されたり期限切れのチケットが通過したりし、たった今書いたデータが過去の値に上書きされる更新喪失が発生する。したがって「ノード間の時刻をどれほど精密に、どれほど信頼できるように合わせるか」は、可用性·セキュリティ·データ整合性を同時に左右する設計問題となる。

具体的な被害事例も少なくない。2012年の閏秒(leap second)挿入時、多数のLinuxサーバがカーネルバグでCPUが暴走し、Reddit·LinkedInなど大型サービスが同時に障害を被り、2016年には公開NTPサーバの設定誤りで一部機器の時刻が過去に戻り、証明書が「まだ有効でない」と判定されて接続が切れる事故があった。このように時刻は平時には見えないが、ずれた瞬間に全面的·同時多発的な障害として現れる単一障害点(hidden SPOF)の性格を帯びる。

C. 核心的特徴

時刻同期技術の性質は三つに要約される。第一に、基準時刻への収束 — UTCを追跡するGNSS·原子時計·ラジオ信号のような一次基準(reference clock)に階層的に整列する。第二に、遅延の推定と補正 — ネットワーク往復遅延を測定して片道遅延を推定し、メッセージ往復に内在する非対称性を補正誤差として受け入れる。第三に、精度-コストのトレードオフ — ソフトウェアタイムスタンプのNTPは安価だがミリ秒級にとどまり、ハードウェアタイムスタンプ·専用機器のPTPはナノ秒級を達成する代わりにコストが大きい。特にTrueTimeは「時刻を一点ではなく不確実性区間 [earliest, latest]として露出する」という発想の転換により、誤差を隠さずアルゴリズムが明示的に扱えるようにする点が他の技術と決定的に異なる。

三つの性質を貫く共通課題は単調性(monotonicity)の保存である。同期補正で時刻を過去に戻すと「たった今押したタイムスタンプより小さい時刻」が現れ、ログ順序·期限判定·キャッシュTTLがねじれる。そのため実務では時刻を逆行させないようスルーだけで補正し、アプリケーションには決して戻らない単調時計(monotonic clock)を経過時間測定用に別途提供するのが定石である。結局、良い時刻同期は「正確な絶対時刻」と「決して逆行しない相対時刻」という二つの要求を同時に満たさなければならない。

2. 物理時計の誤差原理と同期モデル

時刻同期を理解する出発点は、物理時計の誤差を構成する三要素を区別することである。オフセット(offset)は特定瞬間の基準時刻との差、ドリフト(drift/skew)は時計がずれる速度(秒あたりの誤差)、ジッタ(jitter)は測定値が揺れる短期変動である。同期とは結局、オフセットを周期的に測定して戻し(step/slew)、ドリフトを推定して発振器周波数を補正(discipline)するフィードバック制御過程である。時刻を一度に跳躍させるステップ(step)方式は単調増加が崩れてタイムスタンプ逆転を引き起こすため、運用システムは通常、時計を徐々に早めたり遅らせたりするスルー(slew)を好む。

同期は基準の有無によって外部同期(external synchronization)と内部同期(internal synchronization)に分かれる。前者はUTCのような絶対基準に合わせるものでNTP·PTPがここに属し、後者は外部基準なしにノード同士で平均を合わせて相互間の差だけを縮める方式で、バークレーアルゴリズム(Berkeley algorithm)が代表的である。また遅延補正方式として、クリスティアンアルゴリズム(Cristian's algorithm)は往復時間RTTの半分を片道遅延と仮定してサーバ時刻に加えるが、この「往復の半分 = 片道」という仮定が経路非対称(上·下行遅延が異なる)の前で崩れることが、すべてのネットワークベース同期の根本的な誤差源である。

flowchart TB
    subgraph Ref["基準時刻の階層"]
      UTC["協定世界時 UTC"] --> ATOMIC["原子時計·GNSS(GPS)"]
      ATOMIC --> PRIM["一次基準時計(Stratum 0)"]
    end
    subgraph Err["物理時計の誤差要素"]
      OSC["水晶発振器"] --> DR["ドリフト(温度·電圧·老化)"]
      DR --> OFF["オフセット(基準との差)"]
      OSC --> JIT["ジッタ(短期変動)"]
    end
    subgraph Sync["同期方式"]
      EXT["外部同期(UTC基準): NTP·PTP"]
      INT["内部同期(相互平均): Berkeley"]
      EST["遅延推定: Cristian(RTT/2仮定)"]
    end
    PRIM --> EXT
    OFF --> EXT
    OFF --> INT
    EXT --> ASY["経路非対称 → 補正誤差"]
    EST --> ASY

バークレーアルゴリズムとクリスティアンアルゴリズムは、このモデルが歴史的にどう実装されたかを示す二つの軸である。クリスティアン方式は信頼できる時刻サーバ一つに問い合わせ、その時刻をRTTの半分だけ補正して受け取るクライアント-サーバモデルで、今日のNTPの直接の祖先である。一方バークレー方式は基準サーバがない環境で調整者(master)がすべてのノードの時刻を収集して平均を取り、異常値を除外した後、各ノードに「どれだけ早めるか遅らせるか」という補正量を返す能動的な内部同期方式である。前者は絶対時刻が必要な場合に、後者は外部基準なしにノード間の相対的一貫性だけが必要な閉域網に適する。

この図が示すように、すべての同期技術の品質は結局ネットワーク経路の遅延をどれほど正確に·対称的に測定するかで決まる。NTP·PTP·TrueTimeの違いは、まさにこの測定をどこで(ソフトウェアvsハードウェア)、どんな仮定で(平均vs実測)、どんな基準(一点vs区間)で行うかの違いに還元される。

3. NTP(Network Time Protocol) — インターネット標準同期

NTPは1985年にDavid Millsが設計し、RFC 5905(NTPv4)として標準化された、インターネットで最も広く使われる時刻同期プロトコルである。NTPは時刻サーバをストラタム(stratum)という階層に組織する。Stratum 0は原子時計·GPSのような基準装置そのもの、Stratum 1はそれに直接接続されたサーバ、Stratum 2以下は上位サーバを参照するサーバで、階層が下るほど誤差が累積する。クライアントは複数の上位サーバの応答を相互検証して偽ティッカー(falseticker)を除外し、最も信頼できる組み合わせを選択する。

NTPの核心は四つのタイムスタンプからオフセットと遅延を計算することである。クライアントがT1に要求を送り、サーバがT2に受信·T3に応答、クライアントがT4に受信したなら、往復遅延 δ = (T4−T1)−(T3−T2)、オフセット θ = ((T2−T1)+(T3−T4))/2と推定する。この式は上·下行の片道遅延が等しいという対称仮定の上に立っており、非対称経路ではその差の半分だけ誤差が残る。これが公衆網NTPが通常数ミリ秒~数十ミリ秒にとどまる理由である。

sequenceDiagram
    participant C as クライアント
    participant S as NTPサーバ(Stratum 2)
    Note over C,S: 四つのタイムスタンプからオフセット·遅延を算出
    C->>S: 要求送信(T1記録)
    Note right of S: T2に受信
    Note right of S: T3に応答生成
    S-->>C: 応答(T1,T2,T3含む)
    Note over C: T4に受信
    Note over C: 遅延 δ = (T4-T1)-(T3-T2)
    Note over C: オフセット θ = ((T2-T1)+(T3-T4))/2
    Note over C: θだけ時計を徐々に補正(slew)

NTPがミリ秒級にとどまるより根本的な理由は、タイムスタンプを押す位置にある。要求·応答時刻(T1~T4)がアプリケーション·オペレーティングシステムのソフトウェア層で記録されるため、パケットがカーネルキューに留まったり割り込み処理が遅延したりする時間がすべて測定誤差として混ざり込む。このソフトウェアスタック遅延は数百マイクロ秒から数ミリ秒まで可変で上·下行が非対称なので、どれほど頻繁に測定してもミリ秒の壁を越えがたい。それでもNTPは専用ハードウェアなしに既存ネットワーク上で広域に動作し、数十年間検証されたアルゴリズムで偽ソースを除外するため、インターネット時刻の事実上の標準として残っている。

NTPの長年の弱点はセキュリティであった。平文UDPベースなので中間者が時刻を操作すると証明書失効·Kerberos認証を攪乱でき、過去にはmonlist機能が大規模反射·増幅DDoSに悪用された。これを解消するため2020年にRFC 8915でNTS(Network Time Security)が標準化され、TLSで鍵を交換しNTPパケットに認証タグを付けて時刻の完全性·出所を検証する。公共·金融領域ではNTS適用とNTPサーバの多重化が事実上必須のセキュリティ統制として定着している。運用面でも公共のpool.ntp.orgだけに依存するより、国家標準時機関(韓国はKRISS)や自前のStratum 1サーバを一次に置き、複数上位を相互参照するよう構成することが信頼性·セキュリティの両面で推奨される。

4. PTP(IEEE 1588) — 精密時刻プロトコル

ミリ秒では足りない産業·通信·金融領域のために登場したのがPTP(Precision Time Protocol, IEEE 1588)である。PTPはNTPと同じメッセージ交換原理を使うが、二つの決定的な違いでマイクロ秒~ナノ秒精度を達成する。第一に、タイムスタンプをOSソフトウェアではなくNIC·スイッチのハードウェアがパケットが物理層を離れる瞬間に押す(hardware timestamping)。ソフトウェアスタックのキューイング·割り込み遅延という最大の誤差源を除去するのである。第二に、経路上のスイッチが透過クロック(Transparent Clock)として動作し、自身がパケットを留め置いた滞留時間(residence time)を補正フィールドに加えることで、ネットワーク輻輳による可変遅延を除去する。

PTPを支援するネットワーク機器は二つの役割で遅延を扱う。透過クロックはスイッチ内部の滞留時間を測定して補正フィールドに累積することで輻輳による可変遅延を相殺し、境界クロックは自身がある区間のスレーブであり次の区間のマスターとなって誤差累積を区間単位で断ち切る。この二つの装置がない一般スイッチを経ると、キューイング遅延がそのまま誤差として残り、PTPのナノ秒精度は経路上すべての機器がPTPを支援するときにのみ完全に実現される。

PTPはBMCA(Best Master Clock Algorithm)でドメイン内の最良の基準であるグランドマスター(Grandmaster)を自動選出し、境界クロック(Boundary Clock)がこれを下位区間に中継する。Sync·Follow_Up·Delay_Req·Delay_Respメッセージでマスター-スレーブ間のオフセットと経路遅延を分離測定するが、ハードウェアタイムスタンプのおかげでLAN内で数十ナノ秒の精度も可能である。その代償としてPTPは経路上すべてのスイッチがPTPを支援してこそ最高性能が出るため、専用ハードウェア投資とネットワーク設計の制約が伴う。

数値で見ると二つのプロトコルの隔たりは明白である。公衆インターネットのNTPは通常1~~50ms、よく管理されたLANでも数百μs~~1msにとどまる一方、ハードウェアタイムスタンプと透過クロックを備えたPTPは同じLANで数十~数百nsを達成する。約1万倍のこの差はアルゴリズムではなくタイムスタンプを押す地点と経路機器の支援有無から生まれる。すなわちPTPの精度はプロトコル設計だけでなく、NIC·スイッチというハードウェア生態系全体への投資の産物である。

実際の適用事例が技術の価値を明確に示す。5G移動通信は基地局間のTDDフレームを整列するため±1.5μs以内の同期が要求されPTP(ITU-T G.8275プロファイル)を使い、証券取引所は欧州MiFID II規制が高頻度取引(HFT)に100μs以内のUTC追跡とタイムスタンプ記録を義務化したことでPTPを導入した。電力網ではPMU(位相測定装置)が60Hz交流の位相を数マイクロ秒精度で測定するためPTP·GPS同期を活用する。

5. TrueTimeと分散データベースの時刻

Google SpannerのTrueTimeは時刻同期をデータベース整合性と結合した独創的なアプローチである。伝統的な同期が「時刻を一点として知らせるが誤差は隠す」なら、TrueTimeは各データセンターにGPS受信機と原子時計を共に配置し、APIが時刻をTT.now() = [earliest, latest]という不確実性区間として返す。すなわち「今の本当の時刻はこの区間のどこかにある」と誤差εを数値で露出するのである。GPSと原子時計を共に使う理由は、GPSはアンテナ障害·電波妨害に弱く原子時計は長期ドリフトがあり、互いの弱点を相互補完するためである。運用環境でεは通常1~7msの範囲である。

ここでεの大きさが性能に直結する点が重要である。εが大きいと後述のコミット待機時間が長くなり書き込み遅延が増え、εが小さいとその分スループットが高まる。そのためGoogleは各データセンターにGPS·原子時計を綿密に配置し短い周期で同期してεを数ミリ秒に抑制することに大きく投資した。これは「精密時刻インフラへの資本投資が即ち分散DBの性能」という、ハードウェアとアルゴリズムがかみ合った設計哲学を示す。

この不確実性を活用する装置がコミット待機(commit-wait)である。トランザクションにタイムスタンプsを付与した後、SpannerはTT.now().earliest > sになるまで、すなわち不確実性区間がsを完全に過ぎるまで(最大2ε)コミットをわざと待つ。すると後から始まるどのトランザクションも必ずより大きいタイムスタンプを受け取ることになり、物理的に分散した環境でも外部一貫性(external consistency, 線形化可能性の強い形)を保証する。結局TrueTimeは時計誤差をなくそうとする代わりに誤差を測定可能にしてその分だけ待つことで整合性を買う戦略であり、精密時刻インフラへの投資(εを減らすほど待機が短くなる)が即ち性能につながる点で、物理時計と分散アルゴリズムをつなぐ橋の役割を果たす。

このアプローチは後にオープンソース陣営にも影響を与えた。CockroachDB·YugabyteDBは専用原子時計なしにNTPベースの最大誤差限界(max offset)を設定値として置き、その範囲を超える不確実区間では読み取りを再試行(read restart)する方式でTrueTimeの発想を商用ハードウェア上で近似する。これは「精密時刻投資」と「アルゴリズム的補正」の間のトレードオフを示す良い対比事例であり、時刻インフラが貧弱なほどアルゴリズムがより多くの再試行·待機コストを負うことを明確に表す。

6. 比較 — NTP·PTP·TrueTime

三つの技術は「何をどこまで保証するか」が根本的に異なる。NTPは低コスト·広域を、PTPは高精度·近距離を、TrueTimeは誤差の明示的活用を志向する。下の表は補助的な整理であり、選択の本質は精度要求値とそれにかかるインフラコストの均衡にある。

区分	NTP (RFC 5905)	PTP (IEEE 1588)	TrueTime (Spanner)
典型的精度	数ms ~ 数十ms	数十ns ~ 数μs	ε 数ms(区間露出)
タイムスタンプ	ソフトウェア	ハードウェア(NIC·スイッチ)	GPS+原子時計
適用範囲	インターネット·WAN	LAN·産業網·通信網	グローバル分散DB
核心仮定/装置	RTT対称, ストラタム	透過クロック·BMCA	不確実性区間·commit-wait
コスト	低い	高い(専用HW)	非常に高い(専用時刻インフラ)
セキュリティ	NTS(RFC 8915)	プロファイル別認証	内部統制

三つの技術は競争関係というより階層的に共存する点も重要である。グローバル分散DBがTrueTimeを使っても、その基準となるGPS·原子時計は物理時刻であり、データセンター内部のサーバは依然としてPTPでマイクロ秒同期を、オフィス·開発環境はNTPでミリ秒同期を維持する。実務アーキテクチャは最上位にGNSS·原子時計基準を置き、コア網·データセンターはPTP、その外側はNTPへと下る精度ピラミッドとして設計されるのが一般的である。したがって「何を選ぶか」より「各層にどの精度の時刻を供給し、どう復元力を確保するか」がより正確な設計の問いである。

違いが生じる理由は誤差源をどこで除去するかにある。NTPの最大の誤差源はOSソフトウェアスタックの可変遅延だが、PTPはこれをハードウェアタイムスタンプで取り除く。TrueTimeはネットワーク測定誤差自体を減らす代わりにGPS·原子時計で基準自体を各データセンターに直接置いてネットワーク経路依存を断つ。したがって「ミリ秒で十分なログ·認証」はNTP、「マイクロ秒が生死を分ける通信·金融·電力」はPTP、「グローバル強一貫性DB」はTrueTime式投資に帰結する。

7. 深化 — 最新動向とPNT復元力

最近の時刻同期分野の最大の話題はGNSS(衛星航法)依存の危険とその代案である。金融·通信·電力がGPS時刻に広範に依存するようになり、電波妨害(jamming)·偽装信号(spoofing)で時刻が汚染されると広域障害に広がりうるという懸念が高まった。これに対し米国はPNT(Positioning, Navigation, Timing)復元力の大統領令を通じてGPS非依存バックアップ(地上波eLoran等)と異常検知を要求し、EUも重要インフラの時刻復元力を規制で扱い始めた。設計の観点ではGPS·NTP·PTP·原子時計を多重化し、時刻ソース間の相互検証で偽ソースを隔離するholdover(基準喪失時の自己維持)設計が標準になりつつある。

GNSS偽装信号の危険は仮説ではなく現実である。船舶·航空でGPS位置·時刻が操作される事例が紛争地域を中心に着実に報告されており、通信·金融が同じGPS時刻を共有する以上、広域の時刻攪乱が二次被害に広がりうる。このため重要インフラは異なる衛星群(GPS·Galileo·BeiDou)と地上基準を併用し、ソース間の時刻が急激に開けば当該ソースを自動隔離するよう設計する。

プロトコルの次元ではセキュリティ強化と超精密化が同時に進む。NTPはNTS(RFC 8915)で完全性を確保し、データセンター内部ではFacebook(Meta)が公開したPTPベースの大規模運用事例のようにマイクロ秒以下の同期を商用データセンターに普及させようとする動きが活発である。素粒子物理研究網から出発したWhite Rabbit(PTP拡張)はサブナノ秒同期を実現し次世代PTP高精度プロファイルに反映され、5G-Advanced·6Gはネットワーク全般の時刻をサービスとして提供するTaaS(Time as a Service)概念を議論している。予想される出題方向としては「NTPとPTPの精度差が生じる原理と各適用分野」「TrueTimeのcommit-waitが外部一貫性を保証するメカニズム」「GNSS依存リスクと時刻インフラ復元力設計」が論述形で扱われる可能性が高い。

8. 考慮事項および示唆点

精度要求値をまず定義し、それに合わせて投資せよ。 すべてのシステムがナノ秒を必要とするわけではない。ログ相関分析·認証はミリ秒級NTPで十分であり、通信·金融·電力のリアルタイム制御のみがPTP·専用ハードウェアを正当化する。要求値なしに高精度インフラを導入すればコストだけが増え、逆に過少投資すれば規制違反·障害につながるため、業務影響度ベースの精度等級設計が先行しなければならない。
時刻をセキュリティ統制の対象として扱え。 時刻操作は証明書検証·Kerberos·OTP·ログ完全性を一度に崩す高リスクの攻撃面である。NTPにはNTSを適用し、外部時刻ソースを多重化·相互検証し、時刻の急変を異常の兆候として監視しなければならない。特に時刻を信頼境界の外から受け取る区間は署名·認証で出所を検証することが必須である。
単一基準(GNSS)依存を断ち復元力を設計せよ。 GPS一つに依存すると電波妨害·衛星障害が即座に広域の時刻障害に広がる。異なる原理のソース(GNSS·原子時計·地上波)を組み合わせ、基準喪失時に自己維持(holdover)可能な原子時計をホールドオーバーソースとして置き可用性を確保しなければならない。これは重要インフラの事業継続性(BCP)要件に直結する。
同期誤差を隠さず明示的に扱え。 TrueTimeの教訓は「誤差を0と仮定するアルゴリズムが最も危険だ」ということである。分散DB·イベント整列で物理時刻だけで順序を決めず、不確実性区間·論理時計([[logical-clock]])·合意アルゴリズムと結合し、時刻誤差が整合性を崩さないよう防御的に設計しなければならない。
運用·可観測性を設計段階に含めよ。 時刻同期は設定後に放置されやすいが、上位サーバ障害·ネットワーク非対称の変化·発振器老化で静かにずれる。ノード別のオフセット·ジッタ·ストラタム·ソース状態を常時収集し閾値超過時に警報し、時刻の急変をログと相互検証する可観測性体系が長期の信頼性を左右する。

参考資料

D. Mills et al., "Network Time Protocol Version 4 (NTPv4)", RFC 5905, 2010. https://www.rfc-editor.org/rfc/rfc5905
"Network Time Security for NTP", RFC 8915, 2020. https://www.rfc-editor.org/rfc/rfc8915
IEEE 1588-2019, "Precision Clock Synchronization Protocol (PTP)". https://standards.ieee.org/ieee/1588/6825/
Corbett et al., "Spanner: Google's Globally-Distributed Database", OSDI 2012. https://research.google/pubs/pub39966/

一言まとめ: 時刻同期は独立して流れる複数ノードの物理時計を基準時刻に合わせるか誤差を既知の限界に抑制する技術であり、ソフトウェアタイムスタンプの低コスト·広域NTP、ハードウェアタイムスタンプでナノ秒級を達成するPTP、誤差を不確実性区間として露出しcommit-waitで外部一貫性を買うTrueTimeに分かれ、精度-コストの均衡とGNSS依存復元力·時刻セキュリティが核心的な設計課題である。