AWS の障害をどう検知させ、どう通知するか？

AWS を運用する中で Amazon EC2 等のサービスの障害は発生し得ることです。
障害が発生しないことがもちろん望ましいのですが、障害が発生した際にいち早く検知し、気づけるように通知し、早急に復旧できる仕組みづくりが重要になります。

どのように AWS から通知させるのか？
AWS からどこに通知させるのか？
どうやって障害を検知させるのか？
どんな障害を検知できるのか？

実はこのようなお悩みをお持ちの方必見の障害を検知するサービス、通知するサービスが AWS にあります。今回は EC2 でWebサーバを構築している場合を例に、障害の検知方法、気づくための通知方法についてご紹介します。

AWS の障害検知　Amazon SNS で通知の仕組みを設定する

AWS には Amazon SNS という通知のサービスがあり、これによりユーザーやアプリケーションにメッセージを送信することができます。障害の検知は CloudWatch にて行えるため、「CloudWatch にて障害を検知し、それをトリガーにして SNS にて通知を行う」という連携設定を行うのが一般的な AWS の運用方法です。

ここではメールに通知させる手順についてご紹介します。

　SNS の「トピックの作成」からタイプを「スタンダード」、名前を任意で設定します。

　1 で作成したトピックを選択し、「サブスクリプションの作成」からプロトコルを「Eメール」、エンドポイントを通知先メールアドレスに設定します。

　登録されたサブスクリプションを確認すると、ステータスが「保留中」となっています。

　サブスクリプションに登録したメールアドレス宛に、AWS からメールが届いているので、本文内の「Confirm subscription」をクリックします。

　3 と同様にサブスクリプションを確認すると、ステータスが「確認済み」になっています。これで SNS での通知設定は完了です。

なお、SNS にてメール通知させる設定をしてもメールが届くのみです。メールが届いたことに気づくためには、着信通知音を設定する・定期受信する・携帯電話のキャリアメールに転送する等の設定が別途必要ですのでご注意ください。

また PagerDuty というスマホアプリを使用することで、通知＋インシデントの一元管理を行うことができます。

PagerDuty へ SNS 通知させる場合もメール通知と同様の考え方です。PagerDuty 内で設定を行うと https のURLが生成されますので、SNS での通知プロトコルは「HTTPS」となります。

SNS が対応しているプロトコルは下記となります

Amazon Kinesis Data Firehose
Amazon SQS
AWS Lambda
Eメール
HTTP
HTTPS
JSON形式のメール
SMS
プラットフォームアプリケーションのエンドポイント

今回ご紹介したEメール以外にも対応プロトコルは様々です。AWS のサービスとも連携できるので、実際の AWS 運用に合ったプロトコルを利用したいですね。

AWS の障害検知　EC2 のOS障害を検知する

EC2 のOS障害は CloudWatch のメトリクス「StatusCheckFailed」にて検知することができます。

具体的には稼働するホストから EC2 へ疎通が取れなくなった際に検知します。疎通が取れないということは、OS内で何らかの問題（OSフリーズ等）が発生した可能性が高く、原因はOS内で確認する必要があります。

Webサイトを AWS で運用している場合、以下をチェックするとよいでしょう。

AWS のシステムログ
OS内のシステムログ

AWS の障害検知　EC2 のハードウェア障害を検知し、自動復旧する

EC2 のハードウェア障害は CloudWatch のメトリクス「StatusCheckFailed_System」にて検知することができます。

具体的には稼働するハードウェアホスト（筐体）にて AWS の問題による障害が発生した際に検知します。OS側の問題ではなく AWS 側の問題であり、事前に予測することができません。（AWS も個々のハードウェア障害に関しては原因を原則公表しておりません）

従いまして ALB 等のロードバランサーを使用して冗長化しておくことで、障害が発生してもサービス停止せずに影響を最小限に抑えることが可能です。

また、Cloudwatch での障害検知時に、合わせて自動復旧（オートリカバリ）を行う設定をすることにより、障害発生時に自動でインスタンスを停止→起動することで、正常なハードウェアホストにてOSを再稼働させるこが可能です。ハードウェア障害時に自動復旧（オートリカバリ）を合わせて行うのは AWS 運用において一般的なのでぜひ設定しておくことを推奨します。

AWS 運用において大切なことは、たとえ障害が発生したとしても AWS のサービスを使ってダウンタイムゼロやそれに近い状態にできる仕組みを確立させることです。障害を絶対起こさないようにすることはできませんが、影響範囲を最小限に抑えることは十分に可能です。

AWS の障害検知　Webサイト障害を検知する

Webサイトの障害は Amazon Route 53 のヘルスチェック機能（URL監視）により検知することができます。

Route 53 でヘルスチェックを設定すると、CloudWatch のメトリクス「ヘルスチェックステータス (HealthCheckStatus)」が同時に設定されます。Route 53 のヘルスチェック機能は、常時URL監視を行っており、サイトに繋がらないときだけでなく、レスポンスが悪い場合でも検知できるため、Webサイトを AWS で運用する際はぜひ設定しておくことを推奨します。

なお、ヘルスチェックの際にはURLを指定しますが、例えばトップページURLを指定したもののページ表示に時間を要してヘルスチェック（URL監視）に引っかかってしまうような場合は、静的コンテンツ（css や専用の軽い html ページ等）をヘルスチェック対象にするのも1つの方法です。
ただし、その場合は事実上の死活監視のみとなります。レスポンスも含めて監視する場合はこの方法は取れませんのでご注意ください。