イベント対策とよくある質問
では、メンテナンスがスケジュールされた場合どのような対応が必要なのでしょうか。このセクションでは実際にAWSサポートでよくお問い合わせ頂くご質問と合わせて、イベントへの対応方法をご紹介していきたいと思います。
Q：利用しているEC2インスタンスについてイベントの通知が来たのですが、どのように対応すればよいですか。
まず、スケジュールされているイベントと対象のEC2インスタンスを確認してください。確認ポイントとしては次のような点があります。
イベントの種別と発生日時
はじめに確認していただきたいのは、イベントコード（イベントの種別）です。予定されているイベントがリタイア（Retirement）の場合、通知された日時を待たずできるだけ早いタイミングで事前回避の対応をご検討ください。
リタイアイベントは、EC2インスタンスが稼働している仮想サーバーホストで障害が検出されていることを示しています。
場合によってはEC2インスタンスの稼働状態が不安定になったり、通信に問題が起きることもあります。このため、リタイアについては早い段階で対応を行って障害の影響を最小化していただくことをおすすめします。
その他のイベントについては必ずしも急いで対応をする必要はありませんが、イベントのスケジュールされた日時が問題ないか確認を行って下さい。メンテナンスの日時がそのままで問題ない場合には、イベントへ対応のための作業などは必要ありませんので、そのままイベントが完了するのをお待ち下さい。AWSによって自動的にイベントが実施され、対応完了の状態となります。
日時とメンテナンス内容が許容できない場合は次の質問「Q：事前に対応を行うことでメンテナンスを回避することはできないでしょうか」でご紹介する手順で、ご都合の良いタイミングでの事前対応を検討下さい。
なお、Eメールで通知されるイベント時刻は必ずしも日本標準時（JST）ではないことにご注意下さい。協定世界時（UTC）や太平洋標準時（PST）で記載されていることもあるため、必要に応じて日本標準時に変換して確認しましょう。
また、イベントに表示されている時刻はイベントが実施される可能性のある最も早い時間となりますが、この時刻を経過してもすぐに実行されるわけではない点もご注意下さい。特に「System maintenance」では実際の影響時間の情報が通知メールに記載されていることがありますので、通知メールもしっかり確認するようにしましょう。
対象EC2インスタンスのルートデバイスボリューム
もう一点注意していただきたいのが、対象のEC2インスタンスのルートデバイスボリュームの種類です。
EC2インスタンスで利用可能なルートデバイスボリュームはEBSボリュームもしくはインスタンスストアボリュームの2種類があり、前者を利用している場合はEBS Backedインスタンス、後者を利用している場合はInstance Store Backedインスタンスと呼ばれます。両者の違いはおおまかに言うとインスタンスの停止可否です。
Instance Store Backedインスタンスは停止状態にすることができませんが、EBS Backedインスタンスであればインスタンスを停止することができます。
メンテナンス発生時の挙動という観点では、EBS Backedインスタンスではリタイアイベント時にインスタンスが停止状態に移行するのに対し、Instance Store Backedインスタンスではインスタンスそのものが削除されてしまいます。このため、Instance Store Backedインスタンス上のデータを保管したい場合には、事前にEBSやS3などにデータを移動させておくなどの作業が必要となります。
各インスタンスのルートデバイスタイプはマネジメントコンソールやAWS CLIのdescribe-instancesコマンドで確認できます。
Q：メンテナンスを回避することはできないでしょうか
残念ながらイベントによってメンテナンスがスケジュールされると、それを回避することはできません。
しかしながら、利用者側で以下の操作をすることで、スケジュールよりも早くイベントを対応済みのステータスにすることができます。
EC2インスタンスを停止し、起動する
EBS Backedインスタンスに限られる対応とはなりますが、一般に、EC2インスタンスを停止し、起動すると稼働する仮想サーバホストが再度選択されます。
この性質を利用してインスタンスを停止・起動することにより、EC2インスタンスをイベント対象外の仮想サーバホストに移動させることができます。
実施後、イベントのステータスは必ずしもすぐにはアップデートされず、1時間程度かかる場合がありますのでご注意下さい。
なお、EC2インスタンスに付与されるパブリックIPアドレスはインスタンスの停止・起動時に変更が行われます。停止・起動時のパブリックIPアドレス変更を回避したい場合は、Elastic IPアドレスを利用することで常に同一のIPアドレスが利用可能です。
また、EBSボリュームをルートボリュームとするインスタンスであってもデータボリュームとしてインスタンスストアが利用可能なインスタンスタイプもありますが、インスタンスストア上に保管されているデータは停止時に削除されます。
もしインスタンスストアにデータを保管している場合には、停止を行う前にEBSボリュームやS3などに移動を行って下さい。
AMIから代替EC2インスタンスを作成する
インスタンスを停止する代わりに、Amazon Machine Image（AMI）を使って代替EC2インスタンスを起動することもできます。
新しいインスタンスを起動し、DNSエントリの変更やEIPの付け替えを行ったり、あらかじめELBを利用する構成にしておくことで、インスタンスの停止・起動処理よりも短い期間での対応も可能になります。
AMIはイベントの対象となっているEC2インスタンスからも取得することができます。取得時のオプション設定によってEC2インスタンスを稼働させたままの取得も可能ですが、この場合ファイルシステムの整合性は保証されないため注意が必要です。
代替EC2インスタンス起動後は、サービスを新しいインスタンスに切り替え、イベントの対象となっているインスタンスは適宜停止・削除を実施してください。
Q：イベントが対応済みであることはどのように確認できますか。
イベントが実施されたりお客様での対応が完了すると、イベントの説明（Description）の先頭に［Completed］と追記されるか、イベントのエントリそのものが表示されなくなります。これらの状態を確認された場合には、対応が完了しているものとお考え下さい。
なお、イベントのステータスの更新には最大で1時間ほどかかる場合がありますので、対応後すぐに確認できるわけではない点にご注意下さい。
中締め
以上イベントに関連してお問い合わせ頂く内容について見てきました。改めてポイントをまとめると以下のようになります。
- メンテナンス通知を受け取ったら、まずはきちんと内容を確認する。
- 通知された時刻での対象イベントの実施が問題ないか確認する。
- 通知された時刻での実施が難しい場合、インスタンスの停止・起動を実施する。または代替EC2インスタンスを起動し、古いインスタンスを停止する。
次回は、イベントを楽にするための運用上のアイデアについてご紹介します。
さて、アマゾン ウェブ サービス ジャパン株式会社ではクラウドサポートエンジニアを絶賛募集中です。誰よりもAWSの仕組みを深く知り、また実際のAWSのユースケースを幅広く知ることができるとても刺激的な仕事です。
AWSサポートに興味を持ってくださった方はWebサイトからオープンハウス参加の登録をお願いいたします。
AWSサポートはダブリンにも日本語サポートのエンジニアが勤務するオフィスがあり、シアトルや日本オフィスと連携して業務を行っています。ダブリンの様子はこちらでもご紹介していますので、よろしければご一読ください。
