COLUMN

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

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

①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の時刻が９時間前にずれるので、その仕組みを説明します。

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と設定されるため、時刻が９時間前にずれてしまいます。

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

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

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

表１．構築パターンの違いによるWindows 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サーバを検討すべきと考えます。