EC2 インスタンスの障害調査依頼を受けた時に確認していること

障害対応

#初心者向け

#Amazon EC2

#AWS

ttaka

2020.03.08

この記事は公開されてから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 使用率の急上昇に起因する何かがホストダウンの原因ではないか？というあたりをつけます。

参考

メトリクスはたくさん取ってるけどデータをどう読み取ったらいいの？という人は下記書籍の第６章「ステータスモニタリング」を読むのがいいのかなと思います。

書籍： Webエンジニアが知っておきたいインフラの基本

3. CloudTrail を確認

CloudTrail には AWS マネジメントコンソール、AWS Command Line Interface、および AWS SDK と API で実行されたアクションが含まれます。極稀にあるのですが、障害ではなく EC2 インスタンスへの停止もしくは再起動のアクションが実行されていたことが原因の場合もありますので、そのようなアクションが実行されていなかったか？を確認するようにしています。