同僚の Mingxue Zhao がゲストポストを投稿してくれました。これは今後発生する重要な時刻調整についての説明です。
注:このブログは最初2015年5月18日にポストされましたが、その後5月25日に追記・修正版としてポストされたものです(訳注:翻訳版も25日の内容に合わせて更新しています)
— Jeff;
IERS(The International Earth Rotation and Reference Systems)は、標準時刻に対し2015年6月30日に追加の1秒を挿入するとアナウンスしました。これは、6月30日の最後の1分には61秒目が存在するということです。もし時刻を標準時と同期している場合、この追加の秒が23:59:60として、23:59:59と00:00:00の間に表示されることになります。この追加の1秒をうるう秒と呼びます。このような「うるう秒の挿入」は1972年から25回実施され、最近では2012年6月30日に実施されています。(※補足:これはUTC時間ですので、日本時間では7月1日午前9時になります)
全てのITシステムのクロックがこの標準時にそのまま追従するわけではなく、色々な方法で対応を行います。例えば以下のような例があります:
- いくつかのLinuxカーネルのインプリメンテーションは、":60"の秒を追加する代わりに、1秒戻る動作を行います。つまり59秒目を繰りかえすようになっています。(詳細はこちらの資料をご覧ください(英文) Resolve Leap Second Issues in Red Hat Enterprise Linux )
- Windows 時刻サーバ(Windows time server)はうるう秒のシグナルを無視し、うるう秒挿入後に正しい時刻に同期します。(詳細はこちらの資料をご覧ください(英文) How the Windows Time Service Treats a Leap Second )
- AWSを含むいくつかの組織では、1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法で対応することを計画しています
- もしクロックが時刻同期システムに接続していない場合、そのまま動作し、うるう秒が挿入されることはありません。もしくは別途調整されます
もしご自身のアプリケーションやシステムが適切にうるう秒をハンドリングできるかどうかを知りたい場合は、それを提供している提供元にまずコンタクトをしてください。そしてもし、時刻に非常に厳密に動くワークロードがあり、そのためにAWSのクロックの挙動について知りたい場合は、このドキュメントを注意深くお読みください。大きく分けて3つのパートに影響がありえます:
- AWSマネジメントコンソールと、バックエンドシステム
- Amazon EC2 インスタンス
- その他のAWSリソース
AWSクロックと、UTCとの比較についての詳細は、以下のAWS調整時刻(AWS Adjusted Time)のセクションで説明しています。
AWSマネジメントコンソールと、バックエンドシステム
AWSマネジメントコンソールとバックエンドシステムは、うるう秒をハンドリングするようには実装されていません。代わりに、24時間という期間に渡って、各1秒1秒をごくわずかだけ遅くすることで、うるう秒の挿入された標準時(UTC)とのズレが無くなるように調整されます。このためAWSクロックは最大で、標準時から0.5秒遅れ、もしくは0.5秒先行します。(詳しくは以下のAWS調整時刻(AWS Adjusted Time)を読んでください)
この調整の結果、コンソールにおける値(リソースを作成したタイムスタンプ等)の他、CloudFront や CloudTrail のログに":60" といった記録は残りません。同様にビリング(支払い)画面においても、この調整済み時刻で利用料金が計上されます。
Amazon EC2 インスタンス
EC2インスタンスにおける挙動は、それぞれの設定によりますが、AWS 側でインスタンス内部の時刻同期を管理することはありません。上述したような挙動になると考えられますので、ご利用OSの供給元に問い合わせていただき、想定される挙動について確認をしてください。
Amazon Linux AMIをお使いの場合は、EC2インスタンスは1秒戻す挙動が実施されます。つまり23:59:59を2回表示することになります。以下に詳細な情報があります。
- フォーラムへのポスト: Amazon Linux AMI and the 2015-06-30 leap second.
EC2インスタンスの時刻を調整する必要がある場合には、以下の資料を参照してください。
- Amazon Linux AMIの場合: Linux インスタンスの時刻の設定
- Amazonが提供するWindows AMIの場合: Windowsインスタンスの時刻を設定する
- その他のAMIを利用したインスタンス: AMIの提供元にお問い合わせください
その他のAWSリソース
他のAWSリソースは、それぞれのクロックを持っています。EC2とは異なり、AWS側で対応されるため、ユーザ側で対応する必要はありません。(注:お客様管理下でEC2のインスタンスを起動するサービスを除きます)。
以下のリソースでは1秒戻すように実装されており、23:59:59が2回表示されます。
- Amazon CloudSearch クラスター
- Amazon EC2 Container Service インスタンス
- Amazon EMR クラスター
- Amazon RDS インスタンス
- Amazon Redshift インスタンス
EMRクラスターで時刻同期を実施するには、VPC環境からNTPへアクセスできる必要があります。ご利用のEMRクラスターがインターネットへアクセスでき、セキュリティグループやネットワークACLがUDPポート123への通信を許可しているかを確認してください。
AWS調整時刻(AWS Adjusted Time)
このセクションでは、AWSマネジメントコンソールやバックエンドシステムで、どのようにクロックが動作するかの詳細を説明します。
2015年6月30日 12:00:00PM(お昼の12時)から、AWSクロックが毎秒あたり1/86400秒だけ遅くなります。つまりAWSクロックでの1秒の経過が、実際の時刻では1+1/86400秒の経過になります。この処理が2015年7月1日の12:00:00PM(お昼の12時)までの24時間にわたって続くことによって、ちょうど1秒分実際の時刻より遅れた状態になります。この調整期間の最中である2015年6月30日の終わりに標準時(UTC)にはうるう秒が挿入され、こちらも1秒だけ時刻が遅くなります。結果として2015年7月1日の12:00:00PM(お昼の12時)には、AWSクロックとUTCは完全に同じ時刻を指すようになります。以下の表でこの変化を説明しましょう。
UTC | AWS調整時刻 |
AWS vs. UTC | 注記 |
11:59:59 AM 2015/06/30 |
11:59:59 AM 2015/06/30 |
+0 | AWSクロックはUTCと同期しています。 |
12:00:00 PM | 12:00:00 PM | +0 | |
12:00:01 | AWSクロックの各1秒が1/86400だけ長くなり、UTCから遅れ始めます。少しづつ差が開いていき、最大で1/2秒の差になります。 | ||
12:00:01 | +1/86400 | ||
12:00:02 | |||
12:00:02 | +2/86400 | ||
… | … | … | |
23:59:59 | |||
23:59:59 | +43199/86400 | ||
23:59:60 | UTCにうるう秒が挿入されます。 | ||
00:00:00 AM 2015/07/01 |
-1/2 | UTCが1秒遅れた結果として、AWSクロックはUTCより1/2秒進んでいる状態になります。 | |
00:00:00 AM 2015/07/01 |
AWSクロックは依然速度を落としたままのため、少しづつUTCとのギャップが縮まっていきます。 | ||
00:00:01 | -43199/86400 | ||
00:00:01 | |||
00:00:02 | -43198/86400 | ||
… | … | … | |
11:59:59 AM | -1/86400 | ||
11:59:59 AM | |||
12:00:00 PM 2015/07/01 |
12:00:00 PM 2015/07/01 |
+0 | ギャップがゼロになりました。この時点でAWSとUTCは同期され、この後は同じ時刻を指すようになります。 |
12:00:01 | 12:00:01 | +0 | |
… | … | … |
この現象についてご質問がある場合はAWSサポートにご連絡いただくか、EC2フォーラムで質問をしてください。
— Mingxue Zhao, シニアプロダクトマネージャー(翻訳:下佐粉 昭)