8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話

このブログ記事で「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです（当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。

MultiAZにしておくことは基本 です。その上でも、 安心しきらずに監視は必要 という話をしています。

MultiAZ構成にしておきましょう
そのうえで監視、検知、トレーサビリティを大切にしましょう

MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。

前提

2019-08-23、AWSで大規模な障害が起こりました。障害の一般的な内容は以下のとおりです。

まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801
AWSからのレポート https://www.publickey1.jp/blog/19/aws23.html

私は、AWSの障害については仕方のないものだと思っています。このブログ記事はAWSの障害や対応について論じたり、補償などを求めるものではありません。誤解なきようお願いします。

8月29日追記: AWSからこの記事での報告と一致する説明が追記されました

www.publickey1.jp

tech.nikkeibp.co.jp

以前のレポートではALBについての説明などありませんでしたが、8月29日時点で追記が確認されました。やはり、他のマネージドサービスでも影響があり、 ALBでも一部の構成の場合エラーが発生していたと説明されています 。その構成の場合はMultiAZ構成でも障害の影響を受けていたということです。

ALB（ELB）がたまに500を返すようになる

23日午後6時30分ごろから、ロードバランサーが500を返すようになりました。障害が主に発生していたのは午後1時か、2時ごろだったので、後になってからALBが500を返すようになったという状態です。

ALB自体が500を返す（バックエンドからの500ではない）
バックエンドのサーバーは異常なし
ブラウザーでアクセスしても問題ないが、 特定の別サーバーからアクセスするとたまに500になる

昼過ぎのころもインスタンスが勝手に死んだりしていましたが、分散した構成でしたので大規模な問題にはなりませんでした。「特定のAvailabilityZoneで障害なんだな、MultiAZにしていて良かった」と僕はそのときは思っていました。

が、そのあとロードバランサーが突然500を返すようになります。最初はアプリの問題かと色々調べたのですが、結局アプリサーバーは正常に稼働しており、ロードバランサー自体が500を返していると特定できました。

後になっての知識ですが、同時刻に冷却システムの復旧とインスタンスの復旧、一部のインスタンスで（ハードウェアの限界による）リタイアがあったようなので、その当たりが関係しているのかもしれません。

ALBのデプロイをするAZで、特定のAZを使わなくすると解決

ALBを利用させているAZから、特定のAZを消すと問題なく動作するようになりました。 ALBの設定で配置する対象のサブネットを変更しました（VPCのサブネットはAvailabilityZoneに紐付いています）。

もちろん「特定のAZで障害があった」とは私も認識していましたが、ALBの設定（ALBをデプロイするAZの設定）まで変えようとは思っていませんでした。

f:id:hirokiky:20190823200044p:plain — 事態の収束を告げるグラフ

これはALB自体のモニタリングのグラフです。ロードバランサー自体が返している5xxエラーの数です。ロードバランサーは通常、正常に稼働しているインスタンスが1つもない場合などに5xx系のエラーを返しますが、このときはALB以下には正常なインスタンスが紐付いていました。自動で治る雰囲気が無かったのでALBのAZの設定を変えると、グラフ右端のように問題は解決しました。

f:id:hirokiky:20190826134101p:plain — 全体像（時刻はUTC）

今回はすぐに検知して、調査、対応できましたが、 大きな問題でなく「静かに少し死ぬ」、そして影響範囲は大きいというのは大変でした。検知やトレーサビリティーの大切さを思い知りました 。

今回の問題について

今回の障害について、「MultiAZ構成だったから大丈夫だった」というような声をSNSなどでも見聞きしましたが、今回発生したすべての問題をそれだけで解決できるとは思いません（障害を起こしたサービスに対して安易な批判をするのは控えたほうが良いでしょう）。 MultiAZは当たり前として、監視や復旧のための準備が必要 です（このALBの問題もそうですし、RDSの応答がなくなる問題や、コンソール画面を操作できなくなる問題、AMIがビルドできない問題もあったと話に聞いています）。 AWSのマネージドサービス全体に関わる問題ですし、システム構成、アプリケーションの作り、時の運に影響して問題は発生し得る状況でした。

障害がどう影響したかなどは詳しくは分かりません。もちろんアプリサーバー側が古いコネクションを持っており問題を抱えたALBにアクセスしていたのか？なども考えられますが、ALBの設定を変更すればすぐに治ったので決定的にそれが原因だとも言えない状態です。

ともかく安易に「コレをしていたから大丈夫」、「コレをしないのが悪いんだ」と思わずに、今一度問題が起こっていないか、今後何をできるかを考えたほうが良いでしょう。特定のAZでインスタンスが落ちちゃうくらいならMultiAZで対応できますが、ロードバランサーで問題が発生する & 自動でキレイに元通りにならないと対応は簡単ではなくなります。