EC2インスタンスのステータスチェックが1/2の場合でもAutoRecoveryしたい！

2019.10.27

この記事を書いたメンバー：

那須隆

最近の趣味は懸垂です、那須です。
CloudWatch alarmでひっかかったのをトリガーにEventBridgeのルールでアクションを起こすことができるようになりました！

クラウドを使うのにデータセンターでやっていた手作業の運用をそのままにしておくのはもったいないです。自分たちでサーバを運用していた時は障害が発生したら現地に行って復旧作業にあたったりしていましたが、クラウドだとある程度復旧作業まで自動化できますよね。
一番よくあるのは、AutoRecoveryだと思います。詳細は↓このリンクを見てください。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html

AutorecoveryはEC2インスタンスのステータスチェックが0/2になった時にEC2インスタンスを停止して起動してくれます。そうすることで異常があったホストから正常なホストへEC2インスタンスが移動されるので、ホスト障害時はほぼ何もしなくてもインフラレベルでは自動復旧が可能です。（アプリケーションの動作確認は必要です）
問題はEC2インスタンスのステータスチェックが1/2の場合です。ネットワーク異常やOS内部の異常が原因なので、そもそもEC2インスタンスにSSHやRDP接続できない場合がほとんどです。
この場合でもEC2インスタンスの停止＆起動で復旧できる場合もありますが、それはAWSネットワーク障害の場合のみです。OS内部が原因の場合はそれでも復旧できません。ルートボリュームをデタッチして復旧用EC2インスタンスにアタッチして復旧してからもとに戻す、みたいなアクションが必要ですが、正直障害発生している時にそんな複雑な手順を落ち着いてできる人って少ないと思うんですよね。本当は自動化できるならしたいです。
最初にご紹介した新機能情報を使えば、ある程度はステータスチェック1/2の場合でも復旧作業を自動化できる可能性が出てきました！
今回はその内容をご紹介します。

事前に確認しておく情報

EC2インスタンスのステータスチェック1/2の時に実行する復旧手順ですが、実はSystems ManagerのAutomationドキュメントに存在します。それがAWSSupport-ExecuteEC2Rescueです。今回はこれを使いましょう。
詳細は↓このAWSドキュメントを読んでみてください。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/automation-ec2rescue.html

構成

こんな構成で仕組みを作っていきます。

設定してみましょう

CloudWatch alarm設定

まずはCloudWatch alarmを設定します。設定方法もいくつかありますが、EC2コンソールから設定した方が対象インスタンスを間違えずに済みそうですね。ステータスチェックアラームの作成アイコンを押しましょう。ここでは指定したいアクションが選べないので、通知、アクションのチェックを外します。
ステータスチェックに失敗(インスタンス)を選択し、アラーム名を指定しましょう。
アラームの作成ボタンを押してアラーム設定します。

CloudWatchコンソールでアラームを見ると、先ほど設定したアラームが↓このように表示されていると思います。
CloudWatch alarm設定はこれで完了です。

EventBridgeのルール設定

次にアラーム発生したらどんなアクションを起こすのかの設定をしましょう。
EventBridgeに統合されているCloudWatch eventですが、今回設定したい内容はまだEventBridgeコンソールで設定できないので、CloudWatchコンソールで設定していきます。
CloudWatchのイベントでルールの作成を押します。まずソースですが、事前定義はされていないのでカスタムイベントパターンの構築を選択し、JSONでトリガーを設定します。下の例は、アラーム名awsec2-i-0b730xxxxxxxxxxxx-instance-status-checkがアラーム状態になったら、トリガー発生します。

{    "source": [
        "aws.cloudwatch"
    ],
    "detail": {
        "alarmName": [
            "awsec2-i-0b730xxxxxxxxxxxx-instance-status-check"
        ],
        "state": {
            "value": [
                "ALARM"
            ]
        }
    }
}

ターゲットはSystems ManagerのAutomationを使いますので、SSM Automationを選択してください。ドキュメントはAWSSupport-ExecuteEC2Rescueを選択しましょう。
パラメータですが、対象のEC2インスタンスが1台だけであれば定数を選択して、必要な情報を入力すればOKです。対象が複数台ある場合は、インプットトランスフォーマーを選択してパラメータが自動で設定されるようにしましょう。
インプットトランスフォーマーの内容ですが、1つ目のボックスは変数定義で、2つ目のボックスは定義された変数を使ったJSONでのパラメータ定義になります。
1つ目のボックスの例です。instance-idという名前の変数を定義しています。

{    "instance-id": "$.detail.configuration.metrics[0].metricStat.metric.dimensions.InstanceId"
}

2つ目のボックスの例です。この内容でAutomationを実行するようにパラメータ定義しています。

{    "UnreachableInstanceId": [
        <instance-id>
    ],
    "EC2RescueInstanceType": [
        "t2.small"
    ],
    "SubnetId": [
        "SelectedInstanceSubnet"
    ]
}

ターゲットの一番下にCloudWatchがターゲットを実行するためのIAMロールを指定するところがあるので、必要なポリシーが付与されたIAMロールを指定するか新規作成しましょう。
設定すると↓こんな感じの設定になっていると思います。あとは次に進んで、ルールの名前を決めて保存してください。
これで設定はすべて完了です。

テスト手順

実際にテストをしないと不安だと思いますので、ここでテストしてアラーム発生したらAutomationが実行されるかどうか確認してみましょう。
実際にEC2インスタンスに障害発生させることが難しいので、ステータスチェックの数値をAWS CLIで変更してテストすることにします。
AWS CLIで実行するコマンドは下記ドキュメントが参考になります。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/US_AlarmAtThresholdEC2.html

https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html

では実際にやってみましょう。

$ aws cloudwatch set-alarm-state --alarm-name awsec2-i-0b730xxxxxxxxxxxx-instance-status-check --state-reason "test" --state-value ALARM --profile nasu-test

アラーム状態になりましたね。ではターゲットが実行されているかどうか確認してみましょう。
Systems Manager Automationコンソールに移動すると…

1つのドキュメントが進行中になっていました。

10分ちょっとでステータスが成功になりました。動作としては問題なさそうですね。

自動復旧できるならやってみよう

EC2ステータスチェックが1/2の場合の自動復旧についてご紹介しました。もちろんこれですべてが解決するわけではないのですが、この障害が発生したら夜間休日に必ず誰かが対応しないといけない、という運用パターンは少しでも減らせるのではないでしょうか？
Webサーバ等であればAutoScalingで復旧できるようにできますが、SAPのようなシステムだとそれもできない場合が多いので、今回のような仕組みはいろんな運用の場面で役に立つのではないかなと思います。
EC2インスタンスの数が多ければ多いほどこのような仕組みが重要になってきます。皆さんの環境でもし使えそうならやってみてくださいね。

カテゴリー