コンピュータが対応するように設計されていなかった「うるう秒」
現代の時刻管理の基盤である原子時計は、揺るぎない精度で時を刻みます。しかし、地球の自転は決して一定ではなく、予測不能に速度を上げたり下げたりしています。この不一致を調整するため、歴史的に「うるう秒（leap seconds）」が協定世界時（UTC）に挿入され、地球の天体リズムとの誤差を0.9秒以内に収めてきました。
1972年の導入以来、27回の正のうるう秒が追加されてきました。この稀な機会には、時計は23:59:59から前例のない23:59:60へと進み、その後ようやく深夜0時へと切り替わります。この1秒の追加は、コンピュータシステムにとって特有の課題となります。
基本的な尺度である「Unix time」は、すべての1日が正確に86,400秒であると前提しており、23:59:60を表現するネイティブな仕組みを持っていません。Linuxのようなオペレーティングシステムは、伝統的にこの問題を解決するために1秒を繰り返す手法をとっており、実質的に時計を巻き戻して23:59:59を2回実行させています。
この「非単調（non-monotonic）」な時刻調整、つまり壁時計の時刻が一瞬逆行するように見える現象は、無数のソフトウェアアプリケーションにおける核心的な前提を侵害します。こうした混乱は、2012年の悪名高いRedditの障害を含め、重大な障害を繰り返し引き起こしてきました。これは、コンピュータが対応するように設計されていなかった1秒の上に構築されたシステムの、本質的な脆弱性を浮き彫りにしています。
繰り返された1秒が、いかにしてRedditを機能不全に陥らせたか
この連鎖反応の典型的な例が、2012年6月30日に発生しました。その日、うるう秒の挿入がLinuxカーネルの重大なバグを引き起こしました。カーネルのhrtimerコードがfutexタイマーと相互作用する際、適切に調整されるどころか、プロセスが繰り返し即座に起動する事態となりました。これによりCPU使用率が100%に達し、システムが事実上のデッドロック状態に陥りました。
主要なオンラインプラットフォームであるRedditは、この微細な時刻調整の影響をまともに受けました。サービスは約30〜40分間にわたって利用不能となり、たった1秒の繰り返しが本番環境のインフラに波及し、広く利用されているアプリケーションを機能不全に追い込めることを証明しました。
このインシデントや同様の事例は、エンジニアリングにおける基本的な教訓を浮き彫りにしました。それは、「壁時計（wall-clock time）」は常に単調増加するわけではないということです。時間は前方に飛んだり、後方に巻き戻ったり、繰り返されたりすることがあり、時間は常に直線的に進むという多くのソフトウェアにおける暗黙の前提を覆すのです。
堅牢なシステムを構築するために、開発者はtime.Now()に盲目的に依存しない経過時間やイベント順序のロジックを設計する必要があります。代わりに、潜在的な不連続性を考慮しなければなりません。これには、期間の測定に「単調時計（monotonic clocks）」を使用し、時間が逆行するように見える可能性のあるイベントシーケンスを慎重に管理することが含まれます。
Cloudflareの負の時間のパニックと、その回避策としてのスミアリング
2017年の元日に発生した別のうるう秒は、CloudflareのDNSを麻痺させました。彼らのGoコードは、終了タイムスタンプから開始タイムスタンプを引くことでDNSルックアップの期間を計算していました。時計が巻き戻った際、この計算結果が「負の期間（negative duration）」となり、非負の引数を期待していた関数がこれを受け取ったことで、致命的なパニック（fatal panic）が発生しました。
このインシデントは根本的な欠陥を浮き彫りにしました。多くのソフトウェアシステムは「時間は常に前に進む」という前提で動作していますが、標準的なうるう秒の調整はこの前提を覆すものです。Cloudflareが説明したように、「認識される解決時間が負になる」ことで、予期せぬクラッシュが発生しました。詳細については、How and why the leap second affected Cloudflare DNSを参照してください。
このような急激な時間の飛躍を回避するため、GoogleやMetaといった大手事業者は「leap smearing（うるう秒の塗りつぶし）」という手法を採用しています。1秒を一度に追加するのではなく、数時間かけてシステムクロックをわずかに遅らせることで、余分な1秒を段階的に分散させます。これにより、内部システムに対して時間が逆行しているように見えることを防いでいます。
Smearingはソフトウェアの破損を招く急激な不連続性を回避しますが、新たな課題も生じます。組織によって異なるsmearingスケジュールを採用している場合、システム間でクロックの読み取り値が一時的に乖離する可能性があります。これを防ぐには、分散インフラ全体で一貫性を維持するために、タイムソースの慎重な調整が必要です。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
うるう秒は廃止へ—それでも時間管理には注意が必要
国際的な計量機関は、2035年まで（あるいはそれ以前）にうるう秒を廃止することを決定しました。この歴史的な転換により、Coordinated Universal Time (UTC) と地球の自転に基づく時間との乖離が許容されるようになり、半世紀にわたる混乱を招く調整に終止符が打たれます。この決定は、うるう秒のメリットよりもリスクの方が大きいという認識が強まっていることを反映しています。
この変更の重要な要因は、近年の地球の自転のわずかな加速です。これにより、UTCから1秒を「削除」しなければならない負のうるう秒という前例のない事態が懸念されるようになりました。これまで実施されたことのないこのような調整は、歴史的に「1秒の追加」にも苦慮してきたソフトウェアにとって、さらに大きな課題となるでしょう。
開発者にとって、これはうるう秒の直接的な脅威がいずれ消滅することを意味しますが、堅牢な時間管理の基本原則は変わりません。期間やタイムアウトの計測には、時間が常に前に進むことを保証するmonotonic clocks（単調増加クロック）を必ず使用してください。UTCに関連付けられることが多いカレンダー上のタイムスタンプと、経過時間の計測は明確に区別しましょう。
最後に、クロックの挙動に関するあらゆる前提を厳密にテストしてください。うるう秒がなくても、システムは依然として以下のような問題に直面する可能性があります：
- 時刻同期の失敗
- ネットワーク遅延
- 手動によるクロック調整
信頼性の高い分散システムを構築するには、慎重な設計と検証が不可欠です。
よくある質問
うるう秒とは何ですか？
うるう秒とは、地球の不規則な自転とUTCを概ね一致させるために、必要に応じて追加される1秒のことです。
なぜうるう秒でソフトウェアが破損するのですか？
一部のシステムではクロックの1秒が繰り返されたり調整されたりするため、「時間は常に前に進む」あるいは「1日は必ず86,400秒である」という前提で動作するソフトウェアに支障をきたします。
Cloudflareの2017年のDNS問題の原因は何ですか？
クロックの逆行調整により、非負の値を期待していたコード内で負の期間が生成され、乱数生成関数でパニックが発生しました。
開発者は今後もmonotonic clocksを使うべきですか？
はい。経過時間の計測にはmonotonic clocksを使用してください。ウォールクロック（壁時計）は調整される可能性があるため、タイムスタンプやカレンダー上の時間に適しています。