DMMでの「うるう秒」対策
本日 「うるう秒」の挿入が行なわれましたが、みなさま無事だったでしょうか？
参考) 閏秒 – Wikipedia
DMMで行なった「うるう秒」対策は以下の6点です。
- うるう秒による影響調査
- ネットワーク機器の対策
- ゆっくり時刻を合わせるNTPサーバの構築
- 大量のサーバのNTPの設定変更
- パブリックNTPサーバとの通信遮断
- 当日待機
うるう秒による影響調査
ベンダーからのアナウンス情報、3年前の事例、NTPのプロトコル調査、等を行なって以下の問題があることを事前に洗い出して、チーム内周知を行ないました。
- うるう秒で問題が発生する要因は大きく2つ。
- NTPプロトコルでうるう秒対策に使われる、リープインジケータ(以下LI)をうまく処理できないLinuxサーバが存在する。
- うるう秒挿入をうまく処理できないアプリケーションがある。
- 60秒の挿入、時間の巻き戻り、にうまく対応できないソフトウェアがある。
- 3年前には、MySQL、Java、で高負荷になる事例があった。
- LIを受信しなければ、LIに起因する問題発生は回避できる。
- LIを受けるタイミング(うるう秒挿入の24時間前からうるう秒挿入までの時間)でNTPサーバを停止すれば問題は回避可能。
- LIを送信しないNTPサーバを使うことでも回避可能。
- NTPをslewモードで動作させれば、ゆっくり時間を合わせるので時間の巻き戻りをある程度回避できる。
- ただし、NTPの古いバージョンではうるう秒の時のslewモードにバグがある。
- ネットワーク機器についての情報は各ベンダが情報を出してくれている。
- 問題があるものはファームウェアを上げることで対処可能。
- ファームウェアを上げられない場合は、NTPサービスを停止することで問題回避は可能。
ネットワーク機器の対策
機材によって以下の2つ対策を使いわけました。
- ファームウェアのアップデート
- 前日からのNTPサービスの停止
ゆっくり時刻を合わせるNTPサーバの構築
LIを流さずに、ゆっくり時刻を合わせるNTPサーバがあれば、うるう秒による問題は回避できます。
そんな製品がありました。
このアプライアンスサーバを最上位(stratum 1)のNTPサーバとして、複数のNTPサーバを用意しました。
大量のサーバのNTPの設定変更
DMMには大量のサーバがありますが、そのサーバのNTPの設定を確認してみたところ、いろいろなNTPサーバを参照していました。
なんてこったい。
Ansibleを使って、一気にNTPサーバの設定変更を行ない、NTPサーバの再起動を行ないました。
設定の標準化できて一石二鳥。
パブリックNTPサーバへの通信遮断
DMMには本当に沢山の機材があって、上記の対応をしても、更新漏れの機材がある可能性があります。
万が一に備えて、前日から24時間、参照している可能性があるパブリックNTPサーバへの通信を遮断しました。
ルータのルーティングテーブル上で、/32の経路をdropする、という乱暴なことをしています。
当日待機
念のため当日待機もしましたが、残念なことに、幸いなことに、何もありませんでした。
めでたしめでたし。