Help us understand the problem. What is going on with this article?

AWS東京リージョンの障害対応について

More than 1 year has passed since last update.

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

 ここから実際の対応記録

影響箇所の特定

まず始めに障害情報をウォッチしているSlackで異変を察知する
(この時、優雅にランチタイムでしたが、一瞬でヤバみを感じる)
スクリーンショット 2019-08-24 4.20.00.png

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

  • まずは、EC2上で動いている部分を触ってみる

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

    • 弊社では、定期的なバッチ処理が相当します。

ここで運の悪いことにバッチ処理をしているインスタンスが立っている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がゾンビインスタンスになってしまってたりと、対応が一筋縄にはいかなかったようで、うちの環境はただただ運が良かったなと...。

yahagin
継承と創造の精神
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした