AWS Wavelength zone内のサブネット上に、chronyを使ったNTPサーバーを立ててみました。

AWS Wavelengthとは

AWS Wavelengthとは、簡潔に表現すると、EC2を利用したコンピューティング環境をモバイルキャリア網（日本ではKDDI）に直結する形で構築することができるサービスとなります。

ヒント
WavelengthゾーンにEC2のインスタンスを立てる場合ですが、インスタンス・タイプなど、いろいろな限定がありますので、東京リージョンとすべて同じというわけではありません。

下の図で説明しますと、AWS Wavelength Zoneは、キャリアネットワーク（日本ではKDDI）の雲の一部に設置されるようなイメージになります。実際のAWS Wavelength Zone（東京）の物理的な場所は、KDDIのネットワークセンター内になりますので、ちょうど、キャリアネットワークの中にAWSの出張所がある感じですね！

Wavelengthゾーンにサーバーを立てるとどうなるか？

WavelengthゾーンにWindows Serverを立てて、そのWindows Serverへリモートデスクトップで接続してみますと、そのデスクトップ上でブラウザを使ってGoogle、Yahooなどの通常のWebサービスにアクセスすることができます。

ただし、その逆については制限があり、例えば、PCからWavelengthゾーン上のWebサーバーへアクセスしようとするケースでは、そのPCがauまたはUQのSIMを使って通信を行っている場合のみ可能となります。（au/UQのスマホによるテザリング、または、au/UQのSIMを使っているモバイルルーターなど。もちろん、au/UQのSIMを使っているスマホのブラウザでアクセスすることも可能です。）

また、次に出てきますが、Wavelengthゾーン上のサーバーとインターネット上のサーバーがUDPを使って通信をする場合、仕様上、Carrier Gateway（AWS WavelengthとKDDIモバイル網の接続ポイントにあるルーター）がパケットを通さないので、通信できません。

問題点

AWS Wavelength zone内に普通にEC2インスタンスを立ててchronyをインストールしても、WavelengthはUDPを通さないので、外部のNTPサーバーにアクセスして時間情報を取得することができません。

補足
下記のAWSのマニュアルにある通り、Wavelength上のEC2インスタンスとKDDIのモバイルネットワークを利用している端末はUDPで通信できるのですが、外部のNTPサーバーがauで通信しているわけがない（当然固定回線ですね！）ので、結局、このケースでは「通信できない」となります。

下記は、AWS Wavelengthのマニュアルからの抜粋です。

解決策

仕方がないので、下記の2つの方法を試してみることとしました。

1. 同じVPC内の東京リージョン側に同様のNTPサーバーを立てて、それを参照する
2. Amazon Time Sync Serviceを利用する

それでは、下記の構成図のような形で設定していきます。

東京リージョン（Public Subnet）のinstanceへchronyをインストール

Ctrl+Alt+Tでターミナルを開いて、コマンドでchronyをインストールします。

sudo apt install chrony

次に、/etc/chrony/chrony.confをエディターで開いて、chronyのコンフィグファイルを編集します。

sudo nano /etc/chrony/chrony.conf

そうすると下記のような画面が開きますので、デフォルトで入っているサーバーを消して、下記の画面のような感じで、サーバーを追加しましょう。

ちなみに、169.254.169.123は、Amazon Time Sync Serviceのアドレス、ntp.nict.jpは情報通信研究機構が運営する時刻サーバーのドメインとなります。（それ以外は適当に選びました。）

また、最後の行にWavelength上のサーバー(10.50.50.234)で稼働しているchronyから参照できるように、下記のような設定を1行追加します。

allow 10.50.50.234

もし、複数のサーバーからのアクセスを許可したい場合は、複数の行にして、それぞれ記入するか、または、CIDRフォーマット（例えば、10.50.50.0/24）で記述します。

allow 10.50.50.0/24

ここで一度、chronyサービスをリスタートしましょう。

sudo systemctl restart chrony.service

chronyを有効にするためのサーバーの設定変更

さらに、上記のallow 10.50.50.234の設定はあくまでもchronyの話なので、サーバーのセキュリティグループも同時に設定変更する必要があります。

Wavelength側のchrony(10.50.50.234) => 東京リージョン側のchrony(10.50.10.252)という形のアクセスになりますので、東京リージョン側のEC2インスタンスにおけるセキュリティグループのインバウンドルールの設定において、すべてのトラフィック（all traffic, all protocol）について10.50.50.234を許可しましょう。

EC2 > セキュリティグループの設定 > 該当するセキュリティグループにおいて、インバウンドルールを編集します。

ルールを1行追加して、typeでall trafficを選択、Sourceは10.50.50.234を入力

Wavelength Subnet上のinstanceへchronyをインストール

Wavelength上のインスタンスに接続するためには、通常は、踏み台サーバー（Jump Box）を立てて、それを経由してアクセスします。Jump Boxを使った接続方法については、Public Subnet上にあるJump BoxからPrivate Subnet上にあるサーバーにアクセスする方法と全く同じですので、その部分については省略させていただきます。

ちなみに、auの携帯を持っている方であれば、Jump Boxなしで、au携帯のテザリングで直接接続することもできます。
その場合、Internet Gatewayは通らず、Wavelength側のCarrier Gatewayを通ってサーバーにアクセスする形となりますが、Wavelength上のサーバーのセキュリティグループを編集して、RDPでauが使っているIPアドレスレンジを受け付ける設定を入れましょう。

サーバーに接続できたら、先ほどと同様に、chronyをインストールしましょう。

sudo apt install chrony

次に、/etc/chrony/chrony.confをエディターで開いて、chronyのコンフィグファイルを編集します。

sudo nano /etc/chrony/chrony.conf

そうすると、また下記のような画面が開きますので、デフォルトで入っているサーバーを消して、こちらも下記の画面のような感じで、サーバーを追加しましょう。

169.254.169.123はAmazon Time Sync ServiceのIPアドレス、10.50.10.252は、東京リージョン側のchronyが稼働しているサーバーのアドレスとなります。

この10.50.10.252を入れることで、chronyが自動的に東京リージョン側のchrony（NTPサーバー）へアクセスするようになります！

設定が終わりましたので、一度、chronyサービスをリスタートしましょう。

sudo systemctl restart chrony.service

chronyが稼働しているかどうか、サービスのステータスを見てみましょう。

sudo systemctl status chrony

東京リージョン側のchrony(NTP Server)の稼働状況を確認

chronyc sourcesコマンドによって、情報ソース毎の状況を確認できます。-vをつけると、説明が付きます。

上から6番目の星印が付いているサーバーが現在同期しているサーバーであり、調整されたオフセットが百万分の98秒であると表示しています。

Stratumは、時間ソースサーバーを階層化していて、Startum 0が原子時計に直結している時間サーバー、Stratum 1はStratum 0の時間サーバーに同期していて、Stratum 0の次に正確な時間を供給するサーバーとなります。

chronyc sources -v

chronyc sourcestatsは、chronyc sourcesによって表示されない詳細な統計情報を表示するコマンドです。

chronyc sourcestats -v

また、chronyc trackingコマンドによって、現時点でのトラッキング情報（選択している時間サーバーをベースとした時間情報の追跡状況）を表示します。

こちらで表示している内容では、システムタイムがNTPタイムに対して百万分の6.77秒遅れていると言っています。

chronyc tracking

さらに、chronyc clientsコマンドによって、このサーバー（東京リージョン側のchrony）へアクセスしているクライアントの情報が得られます。
ip-10-50-50-234.ap-north...は、Wavelength側のサーバー（10.50.50.234）のDNSネームになりますので、このサーバー（10.50.10.252）へアクセスしていることがわかります！

chronyc clients

Wavelength側のchronyの稼働状況を確認

利用するコマンドは同じですが、下記のようなステータスが確認できます。
時間ソースがAmazon Time Sync Serviceと東京リージョンに建てたNTPサーバー（chrony）の2つとなります。
いずれの調整後のオフセット値も1ミリ秒以下の数値（百万分の884など）となっており、悪くないのでは？！と思っていますが、いかがでしょうか。。

chronyc sources -v

chronyc sourcestats -v

トラッキング情報を見ると、System timeのところで、NTPタイムと比較して百万分の154秒（1万分の1.54秒）早いとのこと。

chronyc tracking

Amazon Time Sync Serviceについて

こうしてみると、Linux系、FreeBSD系、MacOSであれば、すべてchronyをインストールできるので、AWSの内部では、片っ端からchronyを入れて、単に、configファイルに、下記のサーバーの記述を入れてしまえば、まあまあの精度が得られるということでしょうか。
※　ただし、この記事では、Amazon Time Sync Serviceに固定されてしまっては面白くないので、下記のサーバーの記述からpreferは外しています。

server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

参考情報