2019年8月23日
AWSの東京リージョンで大規模な障害がありました。
その際に、自社のサービスの維持のために自分がどんな対応をしたのか記録しておきます。

　ここから実際の対応記録

影響箇所の特定

まず始めに障害情報をウォッチしているSlackで異変を察知する
(この時、優雅にランチタイムでしたが、一瞬でヤバみを感じる)

弊社サービスは一部GCPに遺産を残しつつも、メイン系統を動かしているインスタンス群は、AWSの東京リージョンのものを使用しています。

まずは、EC2上で動いている部分を触ってみる
- ここでは特に問題は見当たらないので、リージョン全体ではないので、単一AZでの障害であることを察知する (AWSからの障害情報の中でも、単一AZでの障害であったことが明記されています。)
次に、複数台で同時実行されたくないので、あえて単一インスタンスで動かしている部分の動作状況を確認
- 弊社では、定期的なバッチ処理が相当します。

ここで運の悪いことにバッチ処理をしているインスタンスが立っているAZで障害が発生していることが判明
バッチ処理自体は、死んでても、サービスの提供に多大な影響を及ぼすものではなかったので、ここは運が良かったなと思います。

この時点でもまだ、正常に終了しない処理がありました。

ここで、インスタンス自体は障害の発生していないAZに立てたはずなので、バッチサーバーが依存している別のサービスにも障害が内部的に波及してそうであると疑います。

障害自体は、EC2とRDSについてアナウンスがあったので、DBを疑うところですが、DBは
弊社サービスは一部GCPに遺産を残しつつも
の遺産の一部にあたるため、選択肢から外れます。

実際、DBとしかやりとりをしていない処理は、この時点で正常に動き始めました。

バッチ処理自体は、Rubyで書かれており、スケジューラーとして一部Sidekiqが使われています。
Sidekiqは、実行スケジュールの管理にRedisを使用していて、そのRedisはAWSのマネージドなサービスであるElastiCacheを使用していました。

障害のアナウンス自体は、EC2とRDSについてのみでしたが、実はここもなんじゃないかなと疑います。
TwitterでRedisって検索して直近の状況を確認してみるとビンゴ！
こういうときに便利ですね！ Twitter
どこよりも情報が早い！

そして、コンソールからRedisが立っているAZを確認すると...
お察し

幸いにも、そこまでヘビーにElastiCacheを使い込んでた訳ではないので、バッチサーバーのインスタンス内部にRedisを構築して、そこを参照させるという回避策を取り、事なきを得ました。

潰せる単一障害点はつぶしておく、どうしても単一障害点になってしまう部分は、すぐに別の環境に引越しておける用意をしておく
要求的に、そうでなくなってしまう箇所は、AWSと心中するしかないので諦める

の分岐点がわかりやすい良問みたいな障害だったなぁって思いました。

諸事象でとっとと直したいのに、ロードバランサーが建つAZをコントロール出来ない構成になってしまっているので、ロードバランサーのAZ配置ガチャに負けてたら、阿鼻叫喚してただろうなと。。。

良問みたいな障害だなと思っていましたが、人によっては、EC2がゾンビインスタンスになってしまってたりと、対応が一筋縄にはいかなかったようで、うちの環境はただただ運が良かったなと...。