AWS障害の対応振り返り

本番稼働しているサービスいくつかのうち、動かなくなるものがあったので対応した振り返り。

一人で運用している程度の比較的規模が小さいものなのであくまで自分のメモ程度に。

構成

• ECS, RDS, ALB, ElastiCache, S3, SQS, CloudFormation
• RDSだけSingleAZになっていた
  • 昔は t2.micro をMultiAZにできなかったのかそれか無料枠を使うためにSingleAZにしてた気もする。

影響

• 13:30頃に外形監視のアラートから電話がかかって調査開始
• ECSのコンテナが起動していない
• ログを見ると13:10頃から2つのコンテナのうちコンテナが1つ落ちてその後起動しなくなっていた
• もう1つのコンテナはギリギリ13:30過ぎまで生きていたが13:10からすでにだいぶ不安定でユーザーはまともに利用できていなかった可能性が高い
• 顧客からの問い合わせもこのくらいから入り始める

調査対応

• コンテナが起動しない原因調査としてログを見るとRailsでMigrationが他のコンテナで行われているよ〜みたいなログが出ていた
• RDSに入ってshow processlistをするとおかしなプロセスはなさそう
• もう一回show processlistしたら帰ってこない
• とりあえず再起動
• 再起動が全然終わらないのでこれはディスクが死んだかと思ってSnapshotから復元を試みる（最新のSnapshotが12:50までだった）
• Snapshotの復元待ちの間Twitterを除くとAWSがトレンドになっていて全体の障害だと気づく
• DBの復元完了を待ちつつAWSの障害じゃしょうがないよなぁと思ってゆっくり待つ
• しばらくまったがDBの復元が完了しないので諦めるか…と思ったもののAZの障害なら復元先のAZを変えなきゃだめじゃんと気づく
• 違うAZに復元したら進んだ
• 12:50からのアクセスログからGET以外のものを抜き出してこのままスナップショットからサービス継続した場合の影響範囲を調査
• 責任者に復旧を待つかスナップショットから復元したDBを向けるかで判断を仰ぐ
• スナップショットから復元したものでいくことに決定
• DBの向き先を変えたものをDeployして復旧（CircleCIが動いていたのでいつもどおりのフローでデプロイ）
• 障害のタイミングで行ったRDSの再起動が終わったのは夜の時間帯

振り返り

• 12:50〜13:10のデータが失われてしまった
• 復旧は14:40にはできたので障害時間は2時間弱
• RDSの復旧を待っていたら10時間かかっていたので比較的影響は小さく抑えられた
• MultiAZじゃなくても良いという判断をするレベルのサービスなので20分程度のデータ損失はぎりぎり許容範囲だったと思う
• 今後はMultiAZにします…