大規 模障害 から見るAWSのバックエンド 2019/09/25 #awswakaran _tokyo 株式会社ドリコム インフラストラクチャー部 中 村 昴 ( @varu3)

自 己紹介 ばるさん twitter: varu _3 github: varusan Blog: https://varu3.hatenablog.com/ インフラストラクチャー部 弊 社で 運 用しているサービスのインフラを 管理している部 署 です AWS, GCP, 国内パブリッククラウド, Kubernetesなどなど

2019年8月23日....

止 まるインスタンス... 鳴 り 止 まないアラート... 流 速 が 増 すTwitterのTL... 加 熱 する報 道... 祈 りの 声 ... 悲鳴…

AWSの大規 模障害 日本時間 2019年8月23日 12:36 より、東 京 リージョン (AP-NORTHEAST-1) の 単 一のアベ イラビリティゾーンで、オーバーヒートにより一定の 割合の EC2 サーバの 停止 が発生し ました。 いわゆるAZ 障害 、ゾーン 障害

アベイラビリティゾーンのちょっとした話 a p - n o r t h e a s t - 1 a が示すゾーンはアカウントごとに 異 なる アカウントごとでは Z o n e I d が 識 別子となる 確認 の 仕 方 $ a w s e c 2 d e s c r i b e - a v a i l a b i l i t y - z o n e s { " A v a i l a b i l i t y Z o n e s " : [ { " S t a t e " : " a v a i l a b l e " , " Z o n e N a m e " : " a p - n o r t h e a s t - 1 a " , " M e s s a g e s " : [ ] , " Z o n e I d " : " a p n e 1 - a z 4 " , " R e g i o n N a m e " : " a p - n o r t h e a s t - 1 " } ] }

弊 社で 起 きた事

その １ EC2インスタンスのステータスチェックに 失敗する

発生 直後 稼働 中のインスタンスのAWS上でのステータスチェックが 失敗し、 疎 通ができなくなっ た。 止 まるインスタンスは 3 AZのうちの 1 つのAZのみ 大 半 のインスタンスは 強制停止 → 起動 で 復旧 たが、一部 立ち上がらないインスタ ンスもあった 立ち上がらなかったインスタンスを、AMIイメージを取 得 してそのAMIから 立ち上げ ようとするも 失敗 EBSスナップショットも取れない 状態

EC2インスタンスの 強制 停止 ？ $ a w s e c 2 s t o p - i n s t a n c e s - - i n s t a n c e - i d s < インスタンスI D > - - f o r c e インスタンス 停止 コマンドで - - f o r c e をつけると 強制 停止 となる それでも 停止 できない場合は、 心を 強く 持 って連 打 もしくはAWS上でstopping 中にさらに 停止 すると、 強制 停止 になる

対 応 策 止 まったら 困 るインスタンス（ 絶賛 開発中のサーバとか）は日 次スナップショットを取 っておく EBSのスナップショットはS3に 保 存 される S3は最 低3つのAZに 冗 長 化されて 保 存 される そのため、他のAZでも 起 動できる（はず） 障害 時にはバックアップからインスタンスを 起 動する 本番 環境 MultiAZ 構成 オートスケールしなくても 台 数を 固 定してオートスケーリンググループで 管理する 問 題 が 起 きたインスタンスを 削除して他AZで 立ち上げる

その ２ Elasticache(Memcached)でのパフォーマンスが 低 下する

NewRelicのメトリクス 障害 が発生した時間 帯 からMemcachedの 負荷 が 微増 している 状態 Memcached クラスタには 接続 はできている

CloudWatchメトリクスが正 常 に取 得 できていない 一見、 a v a i l a b l e となっているため問 題 ないように見えるがこれは 罠 。

なぜMemcachedでも 影 響 が？ EC2とEBSを 基 盤 として動作しているため その他にもRDS、 Redshift、 ElastiCache および Workspace なども。 当初、 障害 が 起 きているとアナウンスされたのは、AWSではEC2, EBSのみだった 該 当サービスがなくてよかった、と 安心してはいけない。 むしろEC2の 障害 だと大きく 影 響範囲 が広がる可能性を 考慮 する。

その3. ALBで5xxエラーが発生

障害 発生時からALBで5xxエラーが 増 加。 ALBログを 確認 したところ " a c t i o n s _ e x e c u t e d " : " w a f - f a i l e d " と出ていた このALBはWAFと 紐 づけていた

どういうことか 本 来の 挙 動 1. ALBのリクエストはAWS WAFへ 転送される 2. AWS WAF はリクエストのブロックもしくは 許 可する 3. 許 可されたリクエストは本 来のリクエスト先へ 障害 発生時 障害 が発生したAZへルーティングされたWAF上で問 題 が発生した 本 来の 挙 動でいうと2.の部分

※ クラスメソッドさんの記事より: https://dev.classmethod.jp/cloud/aws/apne1-az4-down-0823-devio/

対 応 WAFを無 効にする ALBのサブネットから問 題 が 起 きたリージョンを外す ALBは最 低 2 AZが 必 要なため、3 AZ目のサブネットの設定をしておく

障害 時の情報 源 AWS Personal Health Dashboard 各 アカウントごとにAWSコンソールから 参照できる 公式の（おそらく）一番 確 かで 早 い情報 報 告されない事 象 もある（EC2がバックエンドだったものなど） AWS Service Health Dashboard https://status.aws.amazon.com/ 探 しやすい、一覧性がある ただし情報は 即座 には 反映 されない（体 感、ラグがある） Twitter 情報の 精 度としては 玉 石混 合 みんなが大変そうなのはわかる。

まとめ 単 一インスタンスは定 期的にスナップショットを取ることが 必 要だよ 本番 環境 では、オートスケーリンググループでインスタンスを 管理して、 柔軟にインス タンス数やAZを変更できることが大事だよ EC2の 障害 はEC2以外にも、他のEC2がバックエンドで使われているフルマネージドサー ビスにも 影 響 を 及 ぼすよ 障害 を 辿るとAWSのバックエンドがチョットワカルようになるよ 情報を 逐 一 確認 しながら、自分たちのアカウントではどのように 影 響 が出ているかを 確 認 することが大事だよ

最後に 弊 社ではこのような事 例があったものの 幸 いなことに、本番 環境 への 影 響 は最 低限 に 止 めることができました。 AWSの中の人やサービス対 応におわれた方 々、本当にお 疲 れ様でした！！