閏秒挿入でなぜ多くのシステムがダウンするのか

Question

今年の元旦、8時59分60秒が挿入されたことで、多くのエンジニアの年末年始が仕事に追われる日々だったのではないかと思われます。そこで閏秒を挿入することで同期がおかしくなるということなのでしょうが(そもそもこの認識が間違っているのならご指摘下さい)この”おかしくなる”の詳細がわからず調べていたのですが、詳しく踏み込んだ説明はあまり見当たりません。CPU使用率が100％になりサーバーがダウンするということがあるというのも見つけたのですが、先の認識とCPU使用率の増加がいまいち繋がりません。どなたかご教授いただけないでしょうか。

Answer 1

大きなポイントとして３つ有るかと思います。
１つはタイムアウト判定などの時刻間計算のロジックが閏秒の挿入により狂う（8時59分59秒と9時00分00秒の差は閏秒により正しくは2秒であるが、1秒と算出してしまう)ことによる計算結果矛盾の発生。これをアプリがエラーとして検出するケース。
１つは時刻のバリデーションチェックで59秒以上（60秒という数値）を弾いてしまい、エラーとして検出してしまうケース。
１つは閏秒のわずか1秒間でもコンピュータは何万命令も実行するため、運悪く閏秒のタイミングにエラー検出してしまい大量のエラーメッセージを出力してしまい運用対応が混乱してしまうケース。
特にDataBaseシステムが閏秒をエラーとして検出すると、自分自身の振る舞いに異常を検出したと判断してDataBase自体が動作を止めてしまうケースが考えられ、こうなると被害は甚大です。

ですが、閏秒については実施の事前に情報が公開されるのでDataBaseシステムのパッチやアプリケーション改修などによってベンダー対応が入ることが一般的です。それでも先に書いたように閏秒の1秒間でもシステムは何万もの命令を実行するため、テストだけでは再現しきれないコンディションも存在します。そんなコンディションのタイミングで初めて露見するバグ（障害）に当たり、運用対応が必要になるケースも有るかも知れません。

エンジニアとしては必要なパッチを全て当てて、事前に閏秒のコンディションを作って検証して不具合を出し切り、当日は警戒感をもって待機するしかないかと思います。私の2000年対応もそのような感じでした。閏秒については机上確認で影響は有り得ない（DataBaseは使用していないなど、システムの性質として発生確立は非常に低い）と判断してゆるめな対応になりました。

Answer 2

先の認識とCPU使用率の増加がいまいち繋がりません。

おそらく linux kernel でのトラブルの話をされているのかと思います。
それを前提にものすごくざっくり説明します。
この時の bug では、うるう秒挿入時に CLOCK_REALTIME を1秒巻き戻したのに、
clock_was_set() を呼び忘れたことです。
この状況では、高精度カーネルタイマ(hrtimer) の処理時に1秒ずれが生じた状態になります。

このため、hrtimer でタイマーを設定すると1秒早くタイマーが終了してしまう状況になります。

ここで問題なのは1秒未満のタイマーを設定した場合で、1秒未満のタイマーを設定した際に
即座にタイマーが終了してしまいます。
タイマーが切れたため、プログラムはタイマー切れの処理を行います。
タイマー切れの場合に必要な処理を行い、再度タイマーを設定するプログラムであった場合、
この一連の処理はループします。

これらのプログラムが複数呼び出された場合は、システム全体の負荷が高くなります。
1秒ずれた状態は clock_was_set() を呼びだすまで解消されないため、
うるう秒処理後から1秒未満のタイマーを設定する様なプログラムで
高負荷の状況を生み出す事になります。

この問題の解消は clock_was_set() を呼びだして1秒のずれを解消する事です。
date コマンドで解消する記事が多くあると思いますが、それは内部で clock_was_set() を
呼びだしているからです。

ソース: https://lkml.org/lkml/2012/7/1/203