• 2018-08-11
ウズマスター戦記
ウズマスター戦記 https://www.uzumax.org/2018/08/blog-post.html

サマータイムの想定作業

巷ではサマータイムが話題になってるな。
まあ、こんなのが決行されるなんて絶対ありえないから心配するだけ無意味だが、実際にやるとなったらどんな対応が必要か考えてみるか。



想定対応作業

1.切り替え手法

そもそもの問題として、「どうやって時間を変えるの?」がある。

と言うのも、サーバの中に時間があるんだったらコマンドで時間変更すれば良いだけだけど、実際のところ、多くのサーバではNTPサーバと言って、時間を管理する専門のサーバと連結して同期を取っている。

このNTPサーバってのがどう挙動するのか読めない。

NTPサーバが自分のところで動かしているなら、NTPサーバの時間を変更すれば一斉に切り替わる。
分からないのが、NTPサーバが外部の場合。外部のフリーのNTPサーバに繋げているシステムの場合、サマータイムに対応するのかしないのか分からない。

  • 外部のNTPサーバが海外にある場合、恐らくサマータイムが始まった所で時間基準はグリニッジ標準時から変わらないだろう。
  • 外部のNTPサーバが日本にある場合、もしかしたらサマータイム発動と同時に時間が切り替えられるのかも?

まあ、NTPサーバの性質を考えると、日本に置いてあっても時間はグリニッジ標準時から変わらないというのが本命の予想。

であれば、「NTPサーバで時間を取得し、更にそこから2時間前倒ししたものを自分のサーバに同期する」という挙動が必要になるわけだけど、Linuxってそんな設定出来るのか?

やったこと無いから全然分からんわ。

2.タイムゾーン

僕って実装する時、タイムゾーンを「asia/tokyo」にしちゃってるんだけど。

GoogleのWebAPIから時間を取得し、それを「asia/tokyo」で日本時間に直してから表示する、というロジックだから、サマータイムが始まったら更にそこから2時間減らす実装をしなきゃいけない。(´×ω×`)

つまり、自分のサーバの時間を拠り所としていないシステムの場合、サーバの時間を動かしても意味無いから実装対応が必要になってしまう。

3.ブログ

このブログみたいに、そもそも自分のサービスを使っていない場合、サマータイム対応がどうなされるのかがサッパリ分からん。

4.時間定期バッチ

サマータイムの切り替えをする場合、2時間サーバを止めて、切り替わったら再起動することで時間の連続性を保つ。

これで理論上、時間定期バッチは乗り切れるはず。
うるう秒対応をこれで乗り切ったシステムは多いはず。

だけど……、結局は「本当にそれで大丈夫なのか?」という検証を行うのにもの凄く時間を要するだろうな。
上述のとおり、システムの中に「時間変更で乗り切れる部分」と「そうでない部分」が混在しているから洗い出さなきゃいけない。

金融システムとかだとエラいこっちゃ。

また、年二回のサーバ停止が確定してしまうのもビジネス上のコストだな。

まとめ

思いつくのはこんなところだけど、やっぱ分かんねぇなぁ。
一番のリスクはここだろう。


ノウハウが無い。


「こういう風に作業すれば大丈夫です!!」と言える人って日本に存在するのか?

だからサマータイムが発動したら「どうすればいいの?」となってしまって、出来ることと言えば「根性で全域再テスト」くらいしか無いって人が多いだろう。

こりゃ途方も無いリスクだな。
やっぱサマータイムなんて実現するわけねぇな。

0 件のコメント:

コメントを投稿

お気軽にコメント下さい。