AWS EC2サービスにおける時刻同期の信頼性を高める取り組み(事例紹介)

システムを構築する上で、信頼性を高める方法には、主に2つのアプローチがあります。

①Fault Avoidance
②Fault Tolerance

①は単一のシステムそのもので信頼性を高める方法で、障害をなるべく起こさないようにすることから名付けられた方式で、実現するためには高コストになりがちです。

一方、②は障害が発生することを前提としたもので、複数のシステムを利用して片方のシステムが障害に遭遇しても、もう一方でリカバリーすることで信頼性を確保する方式です。

②はクラウドサービスと相性が良く、コスト面からしても低コストで実現できるのがメリットです。但し、アプリケーションレイヤとの連携や管理策を的確に規定して、いざというときに役に立つ仕組み造りが重要です。②を実現しているだけで安心してはいけません。

ここからは②の活用事例について説明します。

セキュリティ監査が義務付けられている組織にとっては、証跡を提示する必要があるため、イベント発生時刻のタイムスタンプには高い精度が求められます。
AWSが提供する時刻設定の標準的なサービス「Amazon Time Sync Service」では、「各 AWS リージョンで衛星接続された原子基準クロックを使用して、NTP(Network Time Protocol)を通じて世界標準時 (UTC) の正確な現在時刻」が提供されています。
また、OS停止中はこの時刻設定のサービスを利用できないので、Amazon EC2(Elastic Compute Cloud)サービス等では「通常のコンピュータと同様にハードウェアクロック(OS停止時もクロックを進める仕組み)を通じて、OS起動時に世界標準時 (UTC) の正確な現在時刻」が提供されています。
OS起動中は「Amazon Time Sync Service」からNTP通信を通じて現在時刻を取得し、OS停止時は時刻情報が失われ、OS起動時に「ハードウェアクロック」から現在時刻を取得します。
この状況により互いを補う関係があるので、「②Fault Tolerance」な設計になっていると考えられます。

WindowsのEC2インスタンス(初期設定状態)では、タイムゾーンの設定は協定世界時(UTC)が推奨となっています。
ここで、もし日本標準時刻JST(UTC+9:00)に設定して、OS再起動を実施すると、どのような動きをするか考えてみます。(なお、現行世代のAMI(Amazon Machine Image)では本件はすでに対応済み)
今回は、オンプレミス環境でWindows Serverを初期インストールしたものをAWS EC2に持ち込む場合を想定します。

まず、OS再起動によりOSの時刻が9時間前にずれるので、その仕組みを説明します。

Windows Serverの時刻設定の仕様において、OS起動すると、ハードウェアクロックを参照する仕組みがあります。
AWS EC2ではハードウェアクロックはUTCの時刻が提供されているのですがWindows Serverの仕様(設定変更可能)として、さらに、UTC時刻をそのままローカルタイム(JST)の時刻として認識するようになっています。

例えば、JST 9:00にOS再起動したとします。OS再起動した時刻は、UTCではJSTの9時間前なので UTC 0:00となります。
この状態の時に、Windows Serverはハードウェアクロックを参照するため、UTC 0:00と認識し、ローカルタイムの時刻として設定するので、【JST】の 0:00となります。これにより、本来は、JST 9:00であるべきなのですが、JST 0:00と設定されるため、時刻が9時間前にずれてしまいます。

OSのNTP設定が正しければ、しばらく経過するとNTP時刻同期が自然回復して、9時間の時刻ずれも解消します。

Note:

AWS EC2インスタンスはハイパーバイザ(物理マシン)の上で動いています。AWS EC2のハイパーバイザには古くから提供されている「Xen」と、比較的新しい「Nitro(ナイトロ) System別ウィンドウで開きます」があります。上記で説明したものはXenで動作するT2、M4、R4等のインスタンスタイプで発生する事象です。Nitro Systemで動作するT3インスタンスタイプで試したところ、OS時刻情報をOS起動後も継続・維持できたので9時間前に時刻がずる現象は発生しませんでした。但し、インスタンスの停止・起動では9時間前に時刻がずれる現象はいずれのタイプでも発生しました。

既にこの挙動はWindows Serverに基づく仕様であることと、設定変更が可能であることを説明しましたので、修正方法を説明します。
修正方法は、Windows Serverのレジストリを修正することになります。
これにより、OSがUTC時刻をローカルタイム(JST)として設定されたものを、UTC時刻として解釈させ正しい日本標準時刻(JST)に変換して設定させられるようになります。

Window Serverのコマンドプロンプトを実行して、RealTimeIsUniversal レジストリキーを設定することで対応できます。

reg add "HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Control¥TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

つぎに、正しく登録されていることを確認するには、以下のコマンドを実行します

reg query "HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Control¥TimeZoneInformation" /s

応答の結果に、「RealTimeIsUniversal REG_DWORD 0x1」と表示されれば登録ができています。

これにより、OSの再起動が発生しても9時間のずれ問題を防止でき、ハードウェアクロックがリカバリーするので正しい時刻が維持されるようになります。但し、OS起動後は基本的にハードウェアクロックを参照しないので、速やかにNTP時刻同期を有効化すべきと考えます。

表1に、構築パターン1「Windows Server OSの初期設定のままEC2インスタンスとして構築した場合」、構築パターン2「構築パターン1の対策としてWindowsのレジストリにRealTimeIsUniversalを追加した場合」、構築パターン3「オンプレミスの物理サーバにOS初期設定のまま構築した場合」のそれぞれについて、時刻ずれの有無をまとめましたので、改めて違いを認識して頂ければと思います。

表1.構築パターンの違いによるWindows OS起動時の時刻ずれの有無

構築パターン OSリブート/
停止時
OSリブート/
起動時
時刻ずれ
1 Windows Server OSの初期設定のまま、EC2インスタンスを構築した場合 ハードウェアクロックにOSの現時刻(JST)を反映できない ハードウェアクロックのUTCの時刻をそのままJST時刻としてOSの時刻に設定する(9時間前にずれる) 時刻ずれあり
2 1に対して対策を実施した場合(レジストリにRealTimeIsUniversalを追加) ハードウェアクロックにOSの現時刻(JST)を反映できない ハードウェアクロックのUTCの時刻をJST時刻に変換してOSの時刻に設定する 時刻ずれなし
3 オンプレミスの物理サーバにOS初期設定のまま構築した場合 ハードウェアクロックにOSの現時刻(JST)を反映する 前回ハードウェアクロックに書き込んだJST時刻に、それからの経過時間を反映した時刻をOS時刻に設定する 時刻ずれなし

T2 R4 M4インスタンス等のXenハイバーバイザで動作する仮想サーバの場合

AWSが提供する時刻設定の標準的なサービスである「Amazon Time Sync Service」 がFault Toleranceな仕組みになっていることを実感して頂ければと思います。AWS AMIでは今回説明させて頂いた事象等を解消するためにOSの初期設定について配慮されています。参考資料に「Amazon Time Sync Service」の詳細や、「Windows版のAMIで設定されている設定値」の詳細が掲載されていますので、興味のある方はご覧頂ければと思います。また、「Amazon Time Sync Service」の時刻は非常に正確ですが、万能ではないことを注意しておきます。マルチクラウド構成やオンプレミス側にドメインコントローラがあるような場合は、要件に振り返り適切なNTPサーバを検討すべきと考えます。

参考資料:

Amazon EC2/ Windowsインスタンス用ユーザガイドの「Windows インスタンスの時刻を設定する別ウィンドウで開きます

Amazon Web Services(AWS)、Microsoft Azureの
導入支援サービスのご相談、お問い合わせをお待ちしております。

ページ上部へ戻る