課題とスコープ
複数のサーバーが比較可能なイベント発生時刻を記録する必要があり、同時に一部のサービスはデッドラインやレイテンシも計測しなければなりません。NTP、PTP、およびプロセスローカルなモノトニッククロックが何を解決するのかを説明し、その上でデプロイ構成、同期喪失時の動作、および検証方法を提案してください。ネットワーク遅延の変動、ノードの再起動が存在し、時刻同期を因果一貫性として扱うことはできないものと仮定します。
面接官が見ているポイント
重要な評価ポイントは、比較可能なウォールクロック時刻、ローカルな経過時間、そしてイベントの因果関係を明確に区別できているかです。優れた回答では、まず精度の許容範囲（精度バジェット）とネットワーク境界を確認し、その上で一般的な同期や広域ネットワークにはNTPを、ハードウェアタイムスタンプを備えた制御されたLANにはPTPを、タイムアウト計測にはモノトニッククロックを適用します。PTPがあらゆる場所で自動的により高精度になると主張することはありません。
回答前に確認すべき前提事項
- 許容される最大オフセットはどれくらいですか？ミリ秒単位の監査タイムスタンプには通常NTPが適しており、マイクロ秒単位の制御が必要な場合にPTPとハードウェアタイムスタンプの評価が妥当となります。
- ネットワークは制御可能ですか？スイッチはIEEE 1588をサポートしており、バウンダリクロックやトランスペアレントクロックを利用できますか？これらがない場合、PTPの前提が成り立たない可能性があります。
- 時刻は順序付け、デッドライン、署名、コンプライアンス証跡のいずれに使用されますか？デッドラインにはモノトニック時刻を使用します。ノード間の順序付けには依然としてシーケンス番号、バージョン、または論理クロックが必要です。
- 上流の時刻ソースが利用できなくなった場合、どのような挙動を取るべきですか（書き込み停止、縮退運転、継続のいずれか）？この回答によって、ホールドオーバー、アラートのしきい値、およびデータラベルが決まります。
推奨設計と導出
階層構造を構築します。GPS、原子時計、または信頼できる少数の上流ソースからリージョナルNTPサーバーに時刻を供給し、一般的なホストはNTPを用いて自身のウォールクロックを調整します。NTPの通信では往復遅延とパスの非対称性を考慮する必要があるため、単にサービスが稼働しているかだけでなく、オフセット、周波数誤差、往復遅延、stratum、および最終同期からの経過時間を監視します。
PTPはグランドマスタークロックの時刻をスイッチ経由で伝播させ、ハードウェアタイムスタンプを利用してOSのスケジューリングやNICのキューイングに起因する誤差を低減できます。バウンダリクロックまたはトランスペアレントクロックを備え、エンドポイントがハードウェアに対応した制御されたLAN内では、NTPよりも厳しい誤差バジェットを満たすことが可能です。パブリックインターネットや経路が変動するクラウド環境では、その精度を保証する前に実際のデバイスおよびネットワークのサポート状況を検証してください。
wall_now = CLOCK_REALTIME # calendar, logs, cross-node timestamps
elapsed = CLOCK_MONOTONIC # deadlines, retries, latency measurement
deadline = monotonic_start + timeoutモノトニッククロックは、NTPがウォール時刻を調整しても逆戻りしないため、経過時間の計算に適しています。LinuxではCLOCK_REALTIMEとCLOCK_MONOTONICに異なるセマンティクスが規定されています。適切に同期されたウォールクロックであっても、時刻補正によってステップ調整（急激な変更）やスルー調整（緩やかな変更）が発生する可能性があるため、30秒のタイムアウト計測に使用するのは安全ではありません。
代替案とトレードオフ
NTPは導入が容易で、ルーティングされたネットワーク全体で動作し、成熟した運用ツールを備えています。その誤差はネットワーク経路とホストのタイムスタンプ処理に依存します。PTPは制御されたドメイン内でより小さなオフセットとジッターを提供できますが、NIC、スイッチ、ドライバ、およびクロックソースに依存するため、障害ドメインと設定の複雑さが増大します。イベントの順序付けにおいては、物理時刻の精度を追求するよりも論理クロックやデータベースのシーケンスを用いる方が直接的な解決策となることがよくあります。単一ホスト内での所要時間計測には、どちらの環境であってもモノトニック時刻が適切なツールです。
障害モード、境界条件、反面教師
- オフセット、stratum、ソースの変更を無視して、「NTPが同期されている」ことだけをビジネス用タイムスタンプが正確である証拠として扱うこと。
- デッドラインの管理に
CLOCK_REALTIMEを使用すること。手動変更や時計の補正によってタイムアウトが早まったり遅れたりする原因になります。 - ハードウェアタイムスタンプのないクラウドホストでPTPによるマイクロ秒精度の達成を保証すること。ネットワーク機能が前提条件となります。
- ウォールタイムスタンプからノード間の因果関係を推論すること。ネットワーク遅延によって順序が同一になったり逆転した観測結果が生じたりするため、シーケンス、バージョン、または論理クロックデータを使用する必要があります。
- 同期喪失後も一見正確に見える署名や監査ログの発行を継続すること。タイムソース、同期経過時間、不確実性を記録し、しきい値を超えた場合は高リスクな操作にラベルを付与するか拒絶してください。
テストと検証のチェックリスト
3つのレイヤーで検証します。各ノードでリアルタイムおよびモノトニックのセマンティクスをテストし、NTP/PTPのオフセット、ジッター、周波数誤差、同期経過時間を収集した上で、遅延、パケットロス、上流ソースの変更、再起動を注入します。合格基準は「指定されたネットワークおよびハードウェアの下で、観測ウィンドウの99.9%がオフセットX未満を維持すること」と定義し、ホールドオーバーと復旧は個別にテストします。単一のdateの比較だけでは検証として不十分です。
フォローアップ質問
ノード間のイベントはどのように順序付けるべきですか？
表示や監査フィールドには物理時刻を使用しますが、因果関係の担保にはモノトニックバージョン、メッセージシーケンス番号、データベースのコミット順序、または論理クロックを利用します。人間向けのタイムラインが必要な場合は、不確実性区間を明示し、重複する区間内では安定したタイブレーカー（順序決定ルール）を適用します。
PTPはNTPを完全に置き換えることができますか？
完全な代替にはなりません。PTPは明確な精度バジェットを持つ制御されたドメインに適しています。一方、NTPは依然として管理ネットワーク、広域リンク、およびPTP対応ハードウェアを持たないホストをカバーします。一般的な設計では、クリティカルなドメインにPTPを使用し、そのドメイン内のサービスから他のホストに対してNTPを提供します。
タイムソースが利用できなくなった場合、サービスを停止すべきですか？
ビジネス上のリスクに応じて判断します。通常のキャッシュやメトリクス収集は、限定されたホールドオーバー期間内であれば継続できます。署名、証明書発行、金融マッチングなどは、不確実性がしきい値を超えた時点でリクエストを拒否するかエスカレーションすべきです。縮退運転を行う場合は必ずアラートを発報し、データにラベルを付与し、復旧後にキャリブレーション記録を残す必要があります。