この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
現在開催中の re:Invent 2017 で、Time Sync Service という時刻同期サービスが公開されました。
【試してみた】Windows2016でAmazon Time Sync Serviceに同期してみた #reinvent
既に速報記事（Amazon Linuxでの有効化方法）と Windows での設定方法は記事があがっているのですが、個人的に気になったことを確認するため、旧来の ntpd を使っての設定を行ってみました。
OS は Ubuntu16.04 を使用しています。
ntpd の導入
このあたりは目新しいものではないので、さくっと終わらせます。
$ dpkg -l | grep -i ntp
$ sudo apt-get update > /dev/null
$ sudo apt-get install ntp
:
The following NEW packages will be installed:
libopts25 ntp
0 upgraded, 2 newly installed, 0 to remove and 13 not upgraded.
:
$当然ながら、いまはデフォルトの *.ubuntu.pool.ntp.org を向いています。
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.000
:時刻同期先を Amazon Time Sync Server へ
下記のドキュメントに従って /etc/ntp.conf を修正します。
Amazon Time Sync Service で時間を維持する | Amazon Web Services ブログ
- 全ての
pool行をコメントアウト - 下記の1行を追加する
server 169.254.169.123 prefer iburst修正が終わったら ntpd を再起動します。
$ sudo service ntp restart再起動前と同様、ntpq コマンドで確認してみましょう。
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*169.254.169.123 10.66.1.94 3 u 4 64 1 0.331 -1.713 1.234問題なく時刻が取得できているようです。
気になったこと
「st」と書いてある列をみてみると、169.254.169.123 が参照している NTP サーバは階層 (Stratum) が「 3 」だそうです。
上述のドキュメントには「各地域で冗長化している衛星接続の原子時計を使って高精度な時刻参照を提供」とあったので、もっと階層が少ないかと思ったのですが、意外と大きいですね？
これはおそらく、各拠点内で広域に、かつ様々な使われ方をするため、通常必要とする以上の非常に高精度な時刻情報が必要な用途で負荷があがらないようにするなどの工夫がされているためではないかと想像します。
とはいえ、例えば情報通信機構（NICT）が公開している NTP サーバは Stratum 1 になります。
通常は Stratum が小さい方が良いとされますが、AWS データセンタ内の Stratum 3 と外の Stratum 1 ではどちらが理想的でしょうか。
試しに ntp.conf を修正して、両方のサーバを時刻情報源に設定してみましょう。「このサーバを優先的に同期先にする」という指定の prefer オプションも、試験のために外しました。
server 169.254.169.123 iburst
pool ntp.nict.jp$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*169.254.169.123 10.66.1.94 3 u 43 64 17 0.277 -9.534 5.157
ntp.nict.jp .POOL. 16 p - 64 0 0.000 0.000 0.000
+133.243.238.243 .NICT. 1 u 48 64 17 2.441 -9.162 4.753
133.243.238.244 .NICT. 1 u 38 64 17 2.492 -9.630 5.022
+133.243.238.163 .NICT. 1 u 44 64 17 2.829 -9.389 4.861
133.243.238.164 .NICT. 1 u 38 64 17 2.822 -9.669 5.003リスタート後しばらく待ったところ、上記のようになりました。
さすがというか当然というか、Amazon Time Sync Service は delay の小ささが文字通りケタ違いです。ntpd も Time Sync Service のほうを時刻同期先に選んだようです。
もちろん1回試しただけなので断言は出来ないのですが、結果にも納得感がありますし、ここまで有意差があれば大きなずれはないのではないでしょうか。
また、時刻同期先の選定には品質だけではなく様々な要因があります。
Amazon Time Sync Service は外部と通信しないという最大のメリットがありますから、品質はその足かせ（デメリット）にならない、むしろプラス、と見るべきかと個人的には思います。
まとめ
いくら Stratum が 3 とはいえ、AWS のサービスを使う以上は時刻同期先としては Time Sync Service を使うべき、ということが分かりました。安心して prefer 付きで指定できますね。
0
