こんにちは！
BFT名古屋支店の佐野です。
今回はAWSの仮想マシンであるEC2のリタイアについてのお話です。
滅多に起こることではないのですが、現在進めている案件の最中で発生しました。
折角なので、その件を実例として、どういう通知が行われ、どういう処置がユーザー側で必要なのかを解説していきます。
はじめに：インスタンスのリタイアとは
EC2は、AWS上で構築可能な仮想マシンです。
簡単に言えばユーザーはAWSのコンピューティングリソースを間借りして仮想マシンを作れるのですが、根にあるのはやはり物理的なハードウェアであるため、そのハードウェアに障害が発生した場合は、仮想マシンであるEC2インスタンスにも影響が及ぶことになります。
そしてハードウェアで起こった障害が回復不可能なものである場合、恐らくAWSの内側では交換などの対処が行われると思いますが、その上に載っているEC2インスタンスは当然に削除されることになります。
このような理由によってインスタンスが停止・削除されることを、AWS上ではリタイアといいます。
しかしこのリタイアは唐突に行なわれるわけではなく、事前にAWSからリタイアの対象となるインスタンスとリタイア実施日のスケジュールがメールにて通知されます。
そのためメールを受けたユーザーは、リタイアが実施される前にリタイアするインスタンスに対して必要な処置を行なうことができるのです。
実際に送られてきたメールの例
以下は実際に送られてきたメールになります。
（アカウントID、インスタンスID、日付については非実在のものに差し替えております）
Hello,
EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: i-xxxxxxxxxxxxxxxxx) associated with your AWS account (AWS Account ID: xxxxxxxxxxxx) in the ap-northeast-1 region. Due to this degradation your instance could already be unreachable. We will stop your instance after 20xx-01-01 00:00:00 UTC. Please take appropriate action before this time.
The affected instances are listed below:
i-xxxxxxxxxxxxxxxxx
You can find more information about retirement events scheduled for your EC2 instances in the AWS Management Console https://console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Events
You can also customize your event notification to include tags associated with your EC2 instances. For more information about customizing your event notifications see the EC2 user guide https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html#customizing_scheduled_event_notifications
例によって全文英語となりますが、要約すると以下のことが書かれていました。
- 対象のインスタンスが載っているハードウェアが劣化していて、既に接続不能になっている可能性がある
- 記載日時に対象のインスタンスはAWSによって自動的に停止される
- リタイア実施前に対象のインスタンスの停止・起動を行ない、別のハードウェアに載せ換えることを推奨する
- ローカルインスタンスストアボリュームのデータは保持されないことに注意すること
訳してみると、概ね対応方法が見えてきました。
対処方法：EBSを使用しているインスタンスの場合
通常、インスタンスを作成する際には記憶領域となるEBSも同時に作成し、紐づけることになります。
そういったタイプのインスタンスを使用している場合、たとえインスタンスが載っているハードウェアが壊れてしまったとしても、メールにある通りインスタンスの停止・起動を行なえば、そのまま復旧が可能となります。
なお停止せず、再起動するだけではハードウェアが変わらないため、必ず一度「停止」して、その後「起動」する必要があります。
とはいえ、開発・検証用のものであればおおよそ問題なくとも、本番運用中のインスタンスはメールが来てからすぐ停止・起動を行なうことは難しいでしょう。
その場合でも、AWSの公式ドキュメントでは一番運用に影響が少ないタイミングを見極めて、リタイア予定日までに起動・停止を行なうことを推奨しています。
また、基盤劣化によって既に対象インスタンスに到達できなくなっている可能性も考えられます。
メールを受け取った場合は、対象インスタンスに接続可能かどうかを確認しましょう。
もし到達できないようなら、すぐに停止・起動を行なう必要が出てきます。
詳しくは以下の公式ドキュメントにも記載があります。
対処方法：インスタンスストアを使用しているインスタンスの場合
インスタンスストアは「エフェメラルディスク」とも言われる、EC2インスタンス内蔵のローカルストレージです。
こちらはEBSと違って、あくまで一時的なデータを保持するためのもので、EC2が停止するとデータがクリアされます。
当然、リタイアへの対応時における停止・起動についても例外ではありません。
もしリタイア対象のインスタンスのインスタンスストアに残したいデータを入れていた場合は、まずインスタンスへの接続を確認します。
ここでもし接続できないようであれば、残念ながらインスタンスストア内のデータについては絶望的となります。
幸いにも接続が可能だったら、インスタンスストア内にあるデータをEBSのボリュームへ移し替えましょう。
ちなみにLinuxの場合、インスタンスタイプによってはインスタンスストアをルートデバイスボリュームとして使用するインスタンスを作成できます。
そのインスタンスがリタイア対象になってしまった場合、移す先のEBSが存在しないため、AMIを作成して別のインスタンスを起動することが必要になります。
詳しくは以下の公式ドキュメントにも記載があります。
さいごに
リタイアの告知メールは、本当に何の前触れもなく急に、かつ一方的に配信されます。
当然と言えば当然なのですが、初めてリタイアの告知が来ると慌ててしまうもので、本当に「停止」と「起動」だけでよいのかなども調査することとなりました。
インスタンスストアを使用していない場合は、この通り問題なく対処できる事象ですので、もしリタイアが発生した時は落ち着いて対応スケジュールを立てましょう。
というわけで、今回はここまで。
また別の記事でお会いしましょう！
