【IT業界】2017年1月1日 「うるう秒」追加で何が起こり、どう対応すればいいのか?

1: 海江田三郎 ★ 2016/12/22(木) 14:50:11.89 ID:CAP_USER

 

 

他サイトでIT関連の時事ネタを扱うコラムを連載中の筆者は、12月のテーマとして来る元旦に行われる予定の「うるう秒」をテーマにその概要を書いた。

今回のうるう秒は、世界で一斉に行われる。

日本時間では「2017年1月1日午前8時59分60秒」という「1秒」が挿入される予定である。

 

 

(中略)

 

筆者は文系であまりプログラムやシステムについて詳しくないが、そもそも不定期に出現する61秒の「1分」に、ITシステムが対応できるの?という疑問がある。

元SEであるダンナに聞いてみたところ、「自動で対応できるわけないじゃん」。
彼いわく、そのあり得ない「8時59分60秒」ちょうどに何か処理が行われたら、コンピュータがあり得ない時刻を書き込もうとしたり、探しに行ったりして、処理が戻ってこなくなる恐れがある、という。

「戻ってこない」というのはコンピュータにとっては一大事。

人間なら途中で諦めたりもするが、機械は諦めることを知らず、ずっと処理を続けてしまうこともある。

 

結果としてシステムが停止したり、ハードウエアが壊れたり、様々な不具合が起こってもおかしくない。

たくさんのサービスや機器、ユーザーを巻き込んで大事になってしまうかもしれない。
 

調べてみたら、前々回(2012年)のうるう秒には、FirefoxのMozillaやSNSサービスのLinkedIn、Foursquare、日本ではau(KDDI)、mixiなど、世界中の様々なサービスで不具合が起こったという。

一方、前回(2015年)は、エンジニアが対策したため、大きなトラブルは発生しなかったらしい。
 

ちなみに、大きなトラブルが起こらなかった前回のうるう秒は、7月1日という平日であった。
そのためエンジニアが勤務時間に普通に対処できた。

 

ところが今回は休日、しかも元旦で、人員が手薄になるので特に注意が必要と、警戒を促す声も多い。
 

スマートフォンなどのモバイル機器がますます普及して、サービスの多くをクラウドに頼っている今、SNSやメッセージ、ゲームサーバー、ビデオや音楽のストリーム、クラウドストレージなどなど、不眠不休で動き続けるクラウドシステムは数知れない。

そんな現状で何かが起こったら、たくさんの人が不便を強いられる可能性もある、と筆者は思っていた。

Googleのユニークな「うるう秒対策」

 

 

(続きはサイトで)

http://itpro.nikkeibp.co.jp/atcl/column/16/042700098/122000018/

 

引用元: http://potato.2ch.net/test/read.cgi/bizplus/1482385811/

 
4: 名刺は切らしておりまして 2016/12/22(木) 15:06:36.66 ID:lvHOliDE
うるう秒追加が毎年あると、毎年やばいことになる。

 

6: 名刺は切らしておりまして 2016/12/22(木) 15:11:57.57 ID:+ytEQxTq
うるう秒一つ事前に対策できないんだからな
IT技術者のレベルの低さときたら

 

10: 名刺は切らしておりまして 2016/12/22(木) 15:23:05.56 ID:+UI+iOvF
>>6
対策なんかいらないと告知してるのに
問い合わせがバンバンきて困ってるわw

 

 

9: 名刺は切らしておりまして 2016/12/22(木) 15:22:30.01 ID:L/nvQvg+

今はNTPのSlewモードという便利な機能があってだな。

 

 
17: 名刺は切らしておりまして 2016/12/22(木) 15:50:31.22 ID:cpjz7jXr

>「2017年1月1日午前8時59分60秒」という「1秒」が挿入される予定である。

こんな中途半端な時間にするからだろ
みんなが寝てる明け方とかにすれば良いだけ

 

18: 名刺は切らしておりまして 2016/12/22(木) 15:52:50.26 ID:1QtFm0QH
>>17
ひんとUTC

 

 
21: 名刺は切らしておりまして 2016/12/22(木) 16:08:57.26 ID:ElNy4SPi

 想定外の時間を書き込む操作をするのだから、困るわな。
 59秒+1秒=0秒であって、60秒じゃないもの。

 システムやライブラリにうるう秒関数でもあれば良いんだが。  

 

 

 

【2chまとめ】人生成功を加速させるニュースまとめ 管理人サッスーの補足
管理人サッスーのコメント

今回もやってきた「閏秒問題」(うるう秒問題)。
 
 

何が起こるか分からない

 
うるう秒対応時に時刻のカウントは、
 
57秒、58秒、59秒、0秒といかずに、
57秒、58秒、59秒、60秒、0秒とカウントする。
 
 

うるう秒対応

http://www.jst.mfeed.ad.jp/others/04.html
 
 
インターネットマルチフィード
時刻情報提供サービス for Public
ws000018
 
 
通常のプログラムなんて59秒、60秒、0秒の流れなんて意識していない。
1台だけで処理をしているなら何の問題もないが、大規模なシステムになると、DBサーバ10台、Webサーバ20台、アプリサーバ5台なんていう複雑なものもある。
 
しかもお客さんからお金をいただくシステムだと、どうなるのか分からない(笑)
 
たとえば、チケット購入とかで、単純に毎月1日9時にお客さんに課金しますというシステムだと、
1月1日08時00分59秒 → まだ課金しない、9時じゃないから。
1月1日08時00分60秒 → 課金するかしないか微妙。プログラムによっては、09時00分00秒と判断して課金するかもしれない。
1月1日09時00分00秒 → 課金処理実施。確実に課金される。
 
ということは、2重課金される人がでるかもしれない。
 
単なる二重課金なら、お客さんがお金を取られるだけなので、まだ被害は少ない(と言ってもそれが原因でいろんな影響が出るかしれないけど(笑))
 
命にかかわる問題も出るかもしれない。
それが一番恐ろしい。。
 
システムで自動的に薬の投入をしているとか。
2重に薬投入→患者死亡とか。
プログラムが対応できなくて、システムが停止して病院全体で患者が被害に遭うとか、絶対に止まってはいけないところで、いきなりシステムが止まってしまうとか。
 
あけおめメールがエラーになるとか、二重に送信されてしまうとかなら、笑い話ですむけど、何気にとんでもなく重要なシステムが止まってしまうことがあるかもしれない。
 
2015年にいろいろ問題が発生したうるう秒問題であるが、現在、企業のサーバでLinuxを使用しているケースが多い。
しかもLinuxのカーネルのバグで、この「08時00分60秒」に対応できなくて、CPUが100%になってしまうバグがあった。
ちなみに、こういうバグは事前に分かって対処できることもあれば、実際にその状況になって(被害が発生して)初めて分かるケースもあるので、予測できないのである。
だから、何か発生するかもしれないと思って対策を練らなければならない。
 
そのため、7月1日ならまだしも、1月1日はエンジニアが現場で待機するという企業は多くなる思う。
しかも毎年のようにうるう秒で大騒ぎしているので、本当、エンジニアは大変だ(笑)
 
正月も休めない。。
 
 
だから、うるう秒は怖いと言える。
 
 

エンジニアはどうやって「うるう秒」対策をするのか

こんな所だろうか。
 
①8時59分60秒を入れさせず、手動で時刻を1秒進める
②8時59分60秒をいれさせず、slewモードでゆっくりともどす
③何もせず8時59分60秒を入れる
 
 
1つ1つ検討してみる。
 
 

①8時59分60秒を入れさせず、手動で時刻を1秒進める

1月1日8時59分60秒を入れさせない。
具体的には、それ以前にNTPサーバ(ntpd)を停止する。
 
そして、9時00分00秒を迎える。
当然、時刻は1秒進んでいる状態だ。
 
その後、手動でNTPサーバ(ntpd)を起動する。
 
CentOS7の場合
$ sudo systemctl start ntpd
 
CentOS6の場合
$ sudo /etc/rc.d/init.d/ntpd start
 
NTPサーバ(ntpd)を起動すると最初に ntpdate コマンドが実行され、正しい時刻に設定される。
→この時に1秒進んでいる状態が、正しい時刻に戻される。
 
 
 

②8時59分60秒を入れさせず、slewモードでゆっくりともどす

NTPサービスには、slewモードいうものがある。
slewモードとは、時刻のずれを少しずつ戻すやり方のことである。
 
具体的には、1秒あたり最大で 0.0005 秒づつ徐々に時間を合わせる。
だから1秒のずれが発生した場合、瞬間的に時刻を同期させるのではなく、2000秒かけて少しずつ修正していくのである。
2000秒→約33分
 
 

③何もせず8時59分60秒を入れる

何の対処もしないやり方だ。

これはこれで「あり」だと思う。

その場合は、9時59分60秒が入る。

その結果どうなるかはやってみなければわからないが、現地にエンジニアが待機をしていて、何か不具合が発生したらすぐに対応するやり方である。

→このようにあえて、何かが起こってから対応するやり方の方が、意外とコスト減になることもある。

 

 

 

以上がうるう秒対応時のエンジニアの対応になると思う。
ただ、いずれにせよ「何が起こるかは実際にやってみないと分からない」ため、正月出勤が増えると思う。。
 
 
 

コメントを残す

メールアドレスが公開されることはありません。