システム障害なしにうるう秒を乗り切る技術の発達について

数年に一度、1日が1秒だけ長くなることがある。そのたびにどこかでシステム障害が起こるのだが、何回もうるう秒を経験するごとに次第にベストプラクティスも確立されつつある。ここではうるう秒問題と人々がそれにどう対応してきたかについて説明しよう。

うるう秒というのは地球の自転速度のわずかな揺らぎに対して時計を調整するために数年に一回調整される1秒のことだ。うるう秒で1秒短くなる日は23:59:59からの1秒がスキップされる。うるう秒で1秒長くなる日は、23:59:59の次が23:59:60になり、その1秒後に次の日の00:00:00になる。

というわけで公式には秒というのは数年に一度60秒目というのがありえるのだが、ほとんどのOSはうるう秒にきちんと対応していない。Linuxなどでは通常「時計を1秒戻す」という驚くほど単純な方法でうるう秒を扱っている。つまりうるう秒がある日には23:59:59.999の1ミリ秒後に23:59:59.000に戻ってしまう。時間が戻ることはないということを前提にしているプログラムではこれはトラブルの原因になりえる。

実際、2012年にうるう秒が追加されたときは、RedditやMozillaなどのサイトに障害が発生したり、カンタス航空でチェックインシステムが止まったりした。カンタス航空では数十分間、手動でチェックインをするはめになったそうだ。Linuxではバグにより突然カーネルのCPU使用率が跳ね上がっていろんなサイトが影響を受けた。

プログラマとして考えてみると、こういう問題は簡単に起こりそうだな、ということが容易に想像がつく。サーバでは時計を正確な時間ソースに対して常に同期させているので、基本的に時間が巻き戻ってしまうことはない。したがって、現在時刻と過去の時刻の差がマイナスになることは普段は絶対に起こらない。起動時からの経過秒といった形で巻き戻ることのないタイマも提供されているので、相対的な時間だけが重要な場合はそういうものを使えばよいのだけど、うっかり本物の時計に同期したタイマを使ってしまっても、普段は問題なく動く。つまり気づかないうちに、数年後にタイマじかけで炸裂する地雷みたいなバグを作ってしまいがちなのである。

そこで、うるう秒を扱うもっと安全な方法として2010年代から一般的になってきたのは、実質的にうるう秒をなくしてしまう方法だ。うるう秒が追加される日の00:00:00からサーバの時計の進みを0.001%ほど遅くして、ちょうどうるう秒の瞬間に時計が1秒遅れている状態にすれば、24時間かけてうるう秒を消化してしまうことができる。この手法はleap smearと呼ばれている。

細かいタイミングなどは異なるものの、AWSやGCPではこのような方法でうるう秒が扱われている。クラウドを使っている場合すでにいつのまにかleap smearを導入しているのだ。

うるう秒は数年に一度しか追加されないので、leap smearのようなテクニックの導入もすごくスローペースだ。他の会社のシステムでleap smearを導入しているのを見て、次は自社もそうしようと思っても、次というのは何年も先のことだったりするのである。とはいえだんだんleap smearはIT企業の中でのベストプラクティスとして広まりつつあるようだ。