AWS で障害が発生したときにチェックしているページをまとめてみた。
はじめに
先週は AWS の東京リージョンで大規模な障害が発生した。
AWS に関わるようになって初めて体験した AWS の大規模な障害だったのだが、オンプレミスのシステムが障害を起こしたときと同じように AWS というかクラウドで障害が発生したときも情報収集が非常に重要になる。
たとえば、障害が発生した AZ のリソースを止めて別の AZ にリソースを立ててトラフィックを新しく立てたリソースに回して業務継続する……などの対応は障害の原因と影響範囲が分からないとできないし、クラウド上で動いているシステムがお客様のもので自分たちがその運用会社であるなら、状況をお客様へ報告をするためにも障害の原因と影響範囲は分かっていなければならない。
AWS で障害が発生したときにチェックしているページ
前フリが長くなったが先週 AWS の障害が発生したときにチェックしていたページをまとめておく。
- AWS Personal Health Dashboard
- AWS Service Health Dashboard
- AWS Service Health Dashboard の RSS フィードを Slack に追加
AWS Personal Health Dashboard
AWS Personal Health Dashboard は情報が見やすいし探しやすいのがよい。
ただ、先週 AWS の東京リージョンで発生した障害では AWS コンソールを表示できなくなることがしばしばあったので、AWS Personal Health Dashboard 以外のページもチェックしておくほうがよさそうだった。
AWS Service Health Dashboard
AWS Service Health Dashboard は AWS の全サービスのステータスを見ることができる。
自分が関係しそうなリージョンは東京リージョンくらいなので Asia Pacific のタブだけを見ていたが、Asia Pacific という名前のとおり東京リージョン以外にも香港リージョンとかソウルリージョンなどのサービスステータスが一緒に掲載されている。東京リージョンにしか関心がない自分にはやや冗長さは感じたがページの性格上仕方なさそう。
AWS 公式以外からの情報収集手段としては Twitter をチェックしていた。
自分がチェックしているすべての情報収集手段のなかでも一番早く異常が検出できることが多い。外形監視として非常に優秀。
先週の東京リージョンの障害は AWS 公式の発表は「単一の AZ で発生」ということだったが「単一の AZ ってどこなの？」というのが分からなかったのだが、Twitter で「AZ ID が apne1-az4 の AZ で障害が発生してる (らしい)」という情報を得られたので「あ、自分のところも影響ありそう」ということが分かったのは大きかった。
あと、インフラ業務を担当している人との謎の連帯感を感じられるので Twitter はチェックしておいたほうがいいと思う。
AWS Service Health Dashboard] の RSS フィードを Slack に追加
AWS Service Health Dashboard の RSS フィードを Slack に追加すると AWS のステータスが更新されたときに Slack のチャンネルに post してくれるようになる。
AWS Service Health Dashboard をチェックするのは pull 型の情報収集手段だがこの方法は push 型の情報収集手段になる。 障害発生中といえどダッシュボードに張り付くわけにもいかないことが多いと思うので push 型の情報収集手段はかなり便利。
さいごに
障害は起きないに越したことはないがそんなことはありえないし、最低限これくらいはチェックしておいたほうがよさそうなページをまとめてみた。
