この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
記事を書こうと思ったきっかけ
サポートへの問い合わせで一番多いのが "EC2 インスタンスの障害調査依頼" だから
「サーバはペットではなく畜牛のように扱え」というフレーズがあるように、クラウドではインフラがいつも変化するという前提でシステムを設計するのがよいとされています。そのため、EC2 インスタンスが障害でホストダウンしてもサービスが継続できるように設計されていればいいのですが、アプリケーションの要件や環境によっては単体の EC2 インスタンスで運用されることもあるようです。
そのため、EC2 インスタンスの障害調査依頼をいただく際は緊急度が高い場合が多くあります。テクニカルサポートとして、私が障害調査依頼があった際に実施している内容を公開することで、迅速な障害の切り分けや復旧につながればと思い書きました。
前提
- EC2（Linux）を想定して書いています
- AWS マネジメントコンソールから確認できる範囲でという前提で書いています
確認すること
1. インスタンスのステータスチェック
Amazon CloudWatch ステータスチェックメトリクスを確認します。
ステータスチェックには、システムステータスチェックとインスタンスステータスチェックの 2 種類があり、どちらが失敗していてもアプリケーションの実行が妨げられるような問題が検出されたことになるのですが、どちらが失敗しているかによって障害の切り分けと復旧方法が異なってきます。
確認する項目
- CloudWatch メトリクス
- システムステータス（StatusCheckFailed_System）
- インスタンスステータス（StatusCheckFailed_Instance）
確認すること
- システムステータスチェックが失敗している場合は EC2 インスタンスをホストしているハードウェア側の障害が考えられます
- インスタンスステータスチェックが失敗している場合は EC2 インスタンスの OS やネットワーク設定起因による障害が考えられます
参考
実際にステータスチェックが失敗してたんだけど、どうしたらいいの？という場合は公式ドキュメントに対応方法の記載があるので公式ドキュメントを確認するのがよいかと思います。
AWS ドキュメント： インスタンスのステータスチェック
2. メトリクス確認
Amazon CloudWatch メトリクスを確認します。 ステータスチェックもメトリクスには変わらないのですが、対応時には意識的にステップを別けて考えているので項目を別けました。
確認する項目
- CloudWatch メトリクス
- CPU 使用率（CPUUtilization）
- CPU クレジット（CPUCreditBalance）
- ネットワーク流量（NetworkIn / NetworkOut）
- ディスク IO 数 (DiskReadOps / DiskWriteOps)
- CloudWatch カスタムメトリクス
- 使用可能メモリ量（mem_free）
- ディスク空き容量（disk_free）
- 特定プロセスの起動数（pid_count）
確認すること
ケース・バイ・ケースであるため一概に書くのは難しいという前提のもと、敢えて書くとするとスパイク（急上昇、急下降）がないかを確認しています。
わかりやすい例としては CPU 使用率の急上昇がホストダウン付近で発生していた場合は、CPU 使用率の急上昇に起因する何かがホストダウンの原因ではないか？というあたりをつけます。
参考
メトリクスはたくさん取ってるけどデータをどう読み取ったらいいの？という人は下記書籍の第６章「ステータスモニタリング」を読むのがいいのかなと思います。
3. CloudTrail を確認
CloudTrail には AWS マネジメントコンソール、AWS Command Line Interface、および AWS SDK と API で実行されたアクションが含まれます。極稀にあるのですが、障害ではなく EC2 インスタンスへの停止もしくは再起動のアクションが実行されていたことが原因の場合もありますので、そのようなアクションが実行されていなかったか？を確認するようにしています。
4. ログファイルを確認
CloudWatch Logs の設定がされていれば、になりますが障害発生時間帯付近のログを確認することもあります。ログを確認することで原因がわかることもありますが、わからない場合もあります。そのため、これまでのステップで原因が掴めない場合のみ確認するようにしています。
感想
書いてみたらむちゃくちゃ難しかった です。
障害調査依頼といっても状況は１つ１つ違うので、なるべく一般化して書こうと意識して書いてみたものの、情報が足りないんじゃないか？もっと想定されるパターンがあるんじゃないか？など、情報を公開するだけの価値があるのだろうか、ということをずっと悩んでました（泣）
ただ、障害対応の考え方は専有するよりは公開して広く知れ渡ることで、みんなが幸せになると私は考えているので、誰かのお役に立てればと勇気をだして公開してみました！！もっとこうした方がいいなど、情報があればコメントいただければと思います。
3
