HDE One サービスの DevOps チームに所属する松浦です。
弊社では4年ほど前から、HDE One を動かすプラットフォームとして Amazon Web Service (以下、AWS) を利用しています。
現在私が所属するチームが管理・運用しているインスタンスは900台を超え、近い将来には1000台の大台を突破する見込みになっています。
今回は、そんな比較的管理台数が多い AWS ユーザーが直面する（であろう）、ホストの状態に起因してインスタンスが稼働しない問題とその対処法について話をしたいと思います。
impaired instance
AWS のインスタンスはホストマシンのハイパーバイザー上で稼働していますが、そのためホストマシンで何らかの問題*1が発生すると、インスタンスが正常に稼働しない状態になることがあります。
これを一般的には、インスタンススターテスが impaired である、または該当のインスタンスを impaired instance と呼ぶようです。
インスタンスが impaired 状態になると、該当インスタンス上で稼働しているサービスの停止はもちろんのこと、ssh ログインさえできない状態になり、運用に支障を来すことなります。
インスタンスが impaired になってしまったら
もしあなたが管理するインスタンスが impaired になり正常に稼働しなくなった場合、AWS のガイドラインにもあるように、大きく分けて以下の2つの対処法があります。
- 該当のインスタンスを破棄し、新規インスタンスを launch する
- 該当のインスタンスを停止・起動*2して、ホスト移動する
前者の対応方法は非常に明快です。impaired になったインスタンスはさっさと破棄し、代わりのインスタンスに乗り換えればよいのです。
こちらの対処方法は、Instance store-backed の場合、つまり、worker 等の利用用途でローカルにデータが保存されない（または無視できる）ケースに適用が可能です。
一方で、データベースサーバ用途等で EBS をアタッチしデータを格納しているインスタンス（EBS-backed）の場合は手順が異なります。
該当インスタンスを停止・起動して稼働ホストを移動することで、インスタンスを正常な状態に戻すことができます。
インスタンス停止しません問題
この2つの対処法さえ知っていれば「impaired instance 恐るるに足らず!!」と言いたいところですが、そうは問屋がおろしません。
EBS-backed で利用している場合は、インスタンスを停止・起動すればよいと書いてありますが、impaired 状態になったインスタンスは停止をしようとしても、ほぼ100%の確率で停止しません*3。
かのマスターヨーダは言いました。"may the force be with you" そう、私たちには force stop というフォースオプションが残されているではありませんか!!
・・・しかしながら残念なことに、force stop をしても、基本的には impaired instance は停止しません（私がダークサイドに落ちてしまっているからではありません）。
そうなると残された道は、AWS サポートにリクエストを上げて強制停止を座して待つしかありません。
ただし、契約サポートプランにもよりますが、AWS サポートが対応してくれるまでに数時間かかることも多々あり、このままではサービス正常復旧までに時間がかかりすぎてしまうことになります。
impaired instance の復旧方法
そこで苦肉の策で考えだされたのが、「AMI から復旧させちまおうぜ!!」です。
最初は EBS をデタッチして、別インスタンスにアタッチして稼働させればよいと考えたのですが、
- 過去インスタンスが正常稼働していない状態で EBS がデタッチできないケース
- アプリケーションの仕様で一時ファイルが EBS に書き出されていないケース
があり、断念をいたしました。
なお、この復旧方法の背景には、長年 AWS を運用してきた経験から導きだされたダーティーノウハウがあります。
インスタンスが impaired 状態でも基本的には AMI が取得可能
幸いなことに、インスタンスが impaired になっても、基本的には該当インスタンスの AMI を取得することが可能です。そのため、取得した AMI からコピーインスタンスを launch することができるのです。
AMI 作成に時間がかかりすぎる!!
しかしながら、この方法にも落とし穴がありました。それは、AMI 作成に時間がかかりすぎるという問題です。
AMI は インスタンスの環境情報と EBS のスナップショットで構成されていますので、EBS が大きくなればなるほど、AMI の取得にかかる時間も長くなるというからくりがあります。
上記は、1TB の EBS をアタッチしたインスタンスの AMI を作成する時間が表示されています。弊社では、TB 以上の EBS をアタッチして稼働しているインスタンスが少なくありませんのでこれでは困ります。
AMI は差分ベース
そこで、AMI に関するノウハウなのですが、AMI（スナップショット） は差分ベースで生成されます。
こちらは先ほどの AMI 作成の後に、再度 AMI の作成をした場合の時間が表示されています。2000s かかっていた AMI 作成が 130s で完了しています。
ワークアラウンド
さて、ここまでお話しした内容を含め、以下のような方法で impaired instance からの復旧が可能となります。
- インスタンスの AMI を定期的に作成
- 同時に、インスタンスのステータスを監視
- ステータスが impaired になったインスタンスを発見したら、Slack/メール/電話でメンバーに通知
- 該当インスタンスの AMI を作成し、環境情報を引き継いでコピーインスタンスを launch するジョブを実行
このワークアラウンドのおかげで impaired instance に直面しても短時間で復旧が可能となり、Opsメンバーは少しばかり心の平穏を抱くことができました（と同時に、電話音に敏感になったという話は内緒です）。
最後に
2015年初めに、AWS から Auto Recovery 機能が発表されました。
Auto Recovery 機能は、CloudWatch で impaired instance を発見した際に自動的にインスタンスを復旧してくれるというものです。US Eastリージョン*4、インスタンスタイプがC3/M3/R3/T2であること、また インスタンスが VPC で稼働している等いくつか条件がありますが、長らく待たれた機能です。
インスタンス不良は現時点では避けられない（むしろ想定範囲内）事象となりますので、利用が可能であれば事前に Auto Recovery 機能を設定しておくことも1つの手であると思います。
