うるう秒の来襲
さて、前回記事では、LinuxのNTP実装であるntpdについて、簡単ながら時刻同期の動作をまとめました。
前回述べている通り、これは直近に迫ったイベントに備えて書きだしたものです。
その直近に迫ったイベントというのが…2017年1月1日に予定されている「うるう秒」の挿入です。
とか、もったいぶってますが、すでにタイトルに書いてますね。
今度の「うるう秒」挿入は、最近唐突に決まったものではなく、2016年7月8日に既にアナウンスされていたものです。
これにより、IT関係者は元日の出勤や待機を強いられる方も多く、アナウンス後は怨嗟の声に満ちておりました。あっはっは。もちろん、私もその一人です。F*CK.
(けど、上手くすれば待機くらいで済む…かも?)
当記事についての注意点
今回の記事は、うるう秒とその対応について、私なりに調べたものであり、正確性については保証できません。
私の技術レベルは大したことが無いので、実際にシステム構築・運用を行う際には、当記事を鵜呑みにせず、より正確な情報源にてご確認ください。
当記事の信頼性は、たとえるなら甫庵信長記*1を下回り、どっかの英語学者が書き飛ばした日本史よりは少しマシなくらい。なお、このたとえはフィクションであり、怪しくはない。安心です。
うるう秒とは?
半端な理解で簡単に述べると、現行の協定世界時にて用いられている原子時計による「原子時」と、地球の自転に基づく世界時(UT1)とのズレを調整するために追加/削除される秒のことです。
うるう秒による調整は、1972年から前回実施の2015年7月1日まで、計26回行われており、いずれも1秒追加による調整でした。
27回目となる2017年1月1日のうるう秒調整は、今まで同様1秒追加による調整となります。
具体的な「調整」の内容は、午前8時59分59秒と午前9時00分00秒の間に「8時59分60秒」を追加することです。
詳細は、下記プレスリリースをご参照下さい。
プレスリリース | 「うるう秒」挿入のお知らせ | NICT-情報通信研究機構
うるう秒によるシステムへの影響
わずか1秒増えるだけとはいえ、ITシステムにとっては軽視出来ません。
2012年7月1日の実施時には、オーストラリアのカンタス航空で国内発着便に最大2時間以上の遅れが生じたり、SNSのミクシィで約4時間ほどサービスがつながりにくくなったりといったトラブルが起こりました。
幸い、その次の2015年7月1日実施時には、あまり大きなトラブルは聞かれませんでした。
2012年実施時の障害を受けて、各社・各システム*2の対応が進んだのでしょうね。
それでも、一部の古いルータが原因のネットワーク停止とかはあったようです。
個人的には、今回も問題は少ないのではないかと踏んでいます。
ちなみに、2015年実施の前に日本経済新聞の記事で、立命館大の上原哲太郎教授が
「うるう秒でトラブルが起きる可能性はゼロではないが、かなりレアケース。最大の被害はこの1秒のために多くのシステム担当者が準備に追われることだ」
と話しており、今回はまさにそれかもしれません。
うるう秒対応
さて、ことの経緯というか事情については以上です。
システム担当者は、うるう秒挿入に対して、なんらかの対応を取らねばなりません。
以下は、私なりに調べた対応策について述べます。
繰り返しますが正確性については保証できませんので、当記事を鵜呑みにせず、より正確な情報源にてご確認されることをお勧めします。
Windowsサーバの場合
特別な対応は不要なようです。
うるう秒指示子(Leap Indicator)を受け取っても何もしないし、そもそも「Windows Timeサービス」では、1秒とかの精度で時刻差異を発生させないよう保つことは出来ないとか書いてあります。
Windowsの時間管理がゆるいことも理由の一つのようですが、Windowsにしては珍しく、Linuxサーバよりも楽ですね(個人的見解)。
Linuxサーバの場合
さて、Linuxサーバです。
Windowsと違い、結構ガッツリ時間制御してますので、それなりの対応を取らねばなりません。
ntpd動作時
タイムサーバより、うるう秒指示子(Leap Indicator、LI)が立ったNTPパケットを受信し、ntpdおよびLinuxカーネルはそれをもとに「うるう秒対応」を行います。
ntpdがデフォルト設定(step動作になります)の場合、今どき使用されているLinuxカーネルであれば、カーネル内部のシステムクロックは正しくうるう秒を扱ってくれるはずです。
具体的には、うるう秒が挿入され、8時59分が1秒増えます。
(right/Asia/Tokyoというタイムゾーンを設定してると、プロセスからの問い合わせ時、まさに59分60秒といううるう秒時刻が取得されます。普通にAsia/Tokyoとかだと、59分59秒を2回繰り返して辻褄をあわせます*3。)
また、ntpdの起動オプションに「x」*4をつけている場合(slewモード)は、「59分60秒」を発生させず(うるう秒を無視して)1秒先に進みます。しかる後、徐々に正確な時間に補正していきます。
NTPを利用しない場合
tzdataパッケージに最新のうるう秒情報が含まれている場合は、NTPを利用してなくても「うるう秒対応」を行います。
具体的な挙動はntpdのstep動作時と同じです。
もし、tzdataに最新のうるう秒情報が含まれておらず、NTPも利用しない場合は、なにも起こりません。
世の中でうるう秒挿入が行われても、システムは何もしませんので、結果的には1秒早い状態となります。
大丈夫そう?
上記を見ると、大した問題は起こらないように思えますが、実際には古いカーネルで動いてて問題が生じうるサーバや、うるう秒動作(59秒の繰り返しや60秒の発生)に対する確認がとれていないアプリケーションがあったりします。
例えば、一部バージョンのLinuxカーネルでは、うるう秒の処理に不具合があり、2012年実施時に問題を引き起こしたことがあります。
いくつかの現象/原因があったのですが、取り敢えずRHEL6/CentOS6ならkernel-2.6.32-358.el6以上、Ubuntu12.04なら3.2.0-29.46以上であれば大丈夫(なはず)です*5。
また、ntpdのバージョンによっても問題が発生しました。
RHEL系ディストリの一部バージョンのntpdでslewモード動作にも関わらず、NTPクライアントがシステムコールを用いて時刻を1秒巻き戻す、という不具合が見られました。
いずれにしても、理想は、担当する全システムを事前調査して問題があれば然るべき対応を取ること…なのですが、そんなことができる組織はわずかだと思います。
なら、どうするか
対応策1
可能であれば、Linuxカーネルおよびntpdのアップデートを行い、ntpdサービスをxオプション付きで起動します。
カーネルのアップデートが難しいケースでも、最低限ntpdをアップデートおよびntpdサービスのxオプション付き起動を行います。
こうすることで、うるう秒を発生させず、正確な時刻に徐々に合わせる動作となります。
これなら、確認がとれていないアプリケーションがあっても、理屈としては問題ないはずです。
対応策2
他の手段としては、いっそのこと一時的にntpdを停止して、うるう秒が発生しないようにする、といった対策があります。
この場合、実際にうるう秒が挿入される24時間前からLeap IndicatorのセットされたNTPパケットが送られてくるので、その前にはntpdを停止しておく必要があります。
また、NTPを利用しなくても、tzdataに情報が含まれていると、うるう秒が発生するので、tzdataの更新は行わないことが前提になります。
この方法の難点は、時刻ズレが発生しやすい仮想サーバ等では、ntpd停止期間、派手に時刻ズレが生じる可能性があることです。
また、RFC上では、Leap Indicatorのセットは1ヶ月前からOKとなっております。今後、そのような対応が実施された場合は、当該手段は現実的ではありません。
もうひとつの対応策
上位NTPサーバでLeap Indicatorをカットする、という手段を提示されている方がいます。
上位NTPサーバでだけうるう秒補正を行い、下位サーバでは普通の時刻補正だけで済むようにしよう、というものですね。
詳細は下記サイトにて。
ちなみに、セイコーソリューションズ社のタイムサーバでも同じことができます。
めんどくせえ
以上、つたないながらも、うるう秒の対応についてまとめてみました。
私の担当しているシステムは、その多くがセイコーソリューションズ社製タイムサーバを参照しているため*6、こういった対応が必要なシステムは少ないです。
全てのサーバのNTP参照先を上記タイムサーバに向けられれば楽なのですが…。
あまりに面倒くさい「うるう秒」については廃止を望む声も多く、2015年11月のITU(国際電気通信連合)世界無線通信会議(WRC)でも検討されたのですが、結局2023年のWRCに持ち越しとなりました。
すでに15年にわたって議論が続けられておりますが、2015年の議論では、日本や米国、中国などが廃止を支持、英国やロシアなどは廃止に反対だったそうです。
まだまだ、どうなるかわかりません。
とっとと無くなってしまえ…というのは素人考えなのでしょうが、やっぱり辛いので、早めに廃止して欲しいところです。