## 定義 クロック同期と信頼性は、分散システムを構成する各ノードが持つ物理クロックを、どの程度・どのような手段で一致させられるか、そしてその不確実性をどう扱うかという問題領域を指す。現代のコンピュータは**時刻日クロック(time-of-day clock)**と**単調クロック(monotonic clock)**の 2 種類を持つ。前者(`clock_gettime(CLOCK_REALTIME)` 等)は暦上の日時を返し NTP で同期されるが、NTP サーバとの乖離が大きいと強制的に巻き戻る・跳ぶことがあり、経過時間の計測には不向きである。後者(`clock_gettime(CLOCK_MONOTONIC)` 等)は常に前進することが保証され所要時間の計測に適するが、絶対値に意味はなくマシン間の比較はできない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Monotonic Versus Time-of-Day Clocks") ## クロックが不正確になる要因 水晶発振器のドリフト(Google は最大 200ppm を想定——30 秒ごとの再同期で 6ms、1 日ごとの再同期で 17 秒のドリフトに相当)、NTP サーバとの乖離時の強制リセット、NTP ファイアウォールによる同期断、ネットワーク遅延によるNTP精度限界(インターネット経由では最良でも 35ms 程度、輻輳時は 1 秒に達することも)、誤設定 NTP サーバ、リープ秒、VM のクロック仮想化、ユーザーが意図的に不正確な時刻を設定する端末など、多くの経路でクロックは不正確になりうる。クロックの誤りは CPU やネットワークの故障と異なり静かに進行するため、気づかれにくい。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Clock Synchronization and Accuracy") ## クロック信頼区間という考え方 クロック読み取りを単一の点でなく、`[earliest, latest]` という**信頼区間**として扱う考え方が、不正確なクロックを安全に活用する鍵になる。区間が重ならない 2 つの事象であれば、確実に前後関係を判定できる。TrueTime(Spanner)はこの考え方を GPS/原子時計で ε を数ミリ秒に抑えて実装している([[TrueTime]] 参照)。一方、ハイブリッド論理クロック(HLC)は物理時刻に Lamport 論理時刻を組み合わせることで、専用ハードウェアなしに同種の因果順序保証を得ようとする([[ハイブリッド論理クロック]] 参照)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Clock readings with a confidence interval") ## 横断的知見 - **本概念は [[TrueTime]] と [[ハイブリッド論理クロック]] の上位にある一般問題を扱う**: 両ページはそれぞれ Spanner・CockroachDB という具体的な実装のクロック同期戦略を詳述するが、本概念はその前提となる「なぜクロック同期は本質的に不正確なのか」「不確実性をどう形式化するか」という問題設定そのものを扱う。DDIA 第9章は TrueTime を「不確実性区間という考え方の具体例」として位置づけており、GPS/原子時計は区間を小さく保つ手段にすぎず本質ではないと明言する——これは [[TrueTime]] ページの実装詳細(タイムマスターマシン・Marzullo のアルゴリズム)と、より一般的な信頼区間の設計原則を切り分ける視点を与える。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Synchronized clocks for global snapshots") - **不確実性区間を「積極的に待機する」という設計判断は、教科書間で独立に同じ表現に到達する**: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.5 は TrueTime を「不確実性の境界を明らかにする機能を持ち、ローカル操作が意図的に減速を行って不確実性の境界が過ぎるまで待機することを可能にする」と表現する。これは本ページが記録する「区間が重ならない2つの事象であれば確実に前後関係を判定できる」という一般原則を、Spanner の commit wait という具体的な運用(意図的な減速)に翻訳した独立の言い回しであり、DDIA第9章の抽象的な信頼区間論と Spanner の実装論の間を橋渡しする第3の教科書的表現として位置づけられる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.5, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Synchronized clocks for global snapshots") ## 未解決の問い - クロックの信頼区間を明示的に公開する API(TrueTime、Amazon ClockBound)は今のところ少数の実装に限られる。`clock_gettime` のような標準 API が信頼区間を返さないのはなぜか。標準化の障壁は技術的か、それとも実務上の需要不足か。 - HLC の `max_offset` 設定とクロックドリフトへの耐性のトレードオフ([[ハイブリッド論理クロック]] の未解決の問いを参照)は、本概念が扱う NTP 精度の限界(インターネット経由で 35ms〜1秒)とどう定量的に関係するか。 - パブリッククラウドでの高精度クロック同期サービス(AWS Time Sync Service 等)は、TrueTime のような専用ハードウェアなしにどこまで信頼区間を小さくできるか。 - 詳説 データベース13章は「意図的な減速」という表現で commit wait を説明するが、この減速がクライアント側のレイテンシ体感にどう伝播するか(コミット完了通知のタイミングなのか、それ以前の何らかの処理もブロックするのか)には触れていない。原論文レベルでの精査が必要か。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] - 概念: [[TrueTime]] / [[ハイブリッド論理クロック]] / [[分散システム障害]] ## 出典 - Martin Kleppmann and Chris Riccomini, *Designing Data-Intensive Applications*, 2nd Edition, O'Reilly Media, 2026, Chapter 9, "Unreliable Clocks", "Monotonic Versus Time-of-Day Clocks", "Clock Synchronization and Accuracy", "Relying on Synchronized Clocks". - [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]](§13.5 TrueTime の不確実性境界と commit wait の独立した要約)