(一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います)。前提2019-08-23、AWSで大規模な障害が起こりました。障害の一般的な内容は以下のとおりです。https://www.publickey1.jp/blog/19/aws23.html私は、AWSの障害については仕方のないものだと思っています。このブログ記事はAWSの障害や対応について論じたり、補償などを求めるものではありません。誤解なきようお願いします。AWSからこの記事での報告と一致する説明が追記されましたwww.publickey1.jptech.nikkeibp.co.jp以前のレポートではALBについての説明などありませんでしたが、8月29日時点で追記が確認されました。ALBでも一部の構成の場合エラーが発生していたと説明されています。その構成の場合はMultiAZ構成でも障害の影響を受けていたということです。ALB(ELB)がたまに500を返すようになる23日午後6時30分ごろから、ロードバランサーが500を返すようになりました。障害が主に発生していたのは午後1時か、2時ごろだったので、後になってからALBが500を返すようになったという状態です。特定の別サーバーからアクセスするとたまに500になる昼過ぎのころもインスタンスが勝手に死んだりしていましたが、分散した構成でしたので大規模な問題にはなりませんでした。「特定のAvailabilityZoneで障害なんだな、MultiAZにしていて良かった」と僕はそのときは思っていました。そのあとロードバランサーが突然500を返すようになります。最初はアプリの問題かと色々調べたのですが、結局アプリサーバーは正常に稼働しており、ロードバランサー自体が500を返していると特定できました。後になっての知識ですが、同時刻に冷却システムの復旧とインスタンスの復旧、一部のインスタンスで(ハードウェアの限界による)リタイアがあったようなので、その当たりが関係しているのかもしれません。ALBのデプロイをするAZで、特定のAZを使わなくすると解決ALBを利用させているAZから、特定のAZを消すと問題なく動作するようになりました。ALBの設定で配置する対象のサブネットを変更しました(VPCのサブネットはAvailabilityZoneに紐付いています)。「特定のAZで障害があった」とは私も認識していましたが、ALBの設定(ALBをデプロイするAZの設定)まで変えようとは思っていませんでした。事態の収束を告げるグラフこれはALB自体のモニタリングのグラフです。ロードバランサー自体が返している5xxエラーの数です。ロードバランサーは通常、正常に稼働しているインスタンスが1つもない場合などに5xx系のエラーを返しますが、このときはALB以下には正常なインスタンスが紐付いていました。自動で治る雰囲気が無かったのでALBのAZの設定を変えると、グラフ右端のように問題は解決しました。大きな問題でなく「静かに少し死ぬ」、そして影響範囲は大きいというのは大変でした。検知やトレーサビリティーの大切さを思い知りました。今回の問題について今回の障害について、「MultiAZ構成だったから大丈夫だった」というような声をSNSなどでも見聞きしましたが、今回発生したすべての問題をそれだけで解決できるとは思いません(障害を起こしたサービスに対して安易な批判をするのは控えたほうが良いでしょう)。(このALBの問題もそうですし、RDSの応答がなくなる問題や、コンソール画面を操作できなくなる問題、AMIがビルドできない問題もあったと話に聞いています)。AWSのマネージドサービス全体に関わる問題ですし、システム構成、アプリケーションの作り、時の運に影響して問題は発生し得る状況でした。障害がどう影響したかなどは詳しくは分かりません。アプリサーバー側が古いコネクションを持っており問題を抱えたALBにアクセスしていたのか?なども考えられますが、ALBの設定を変更すればすぐに治ったので決定的にそれが原因だとも言えない状態です。安易に「コレをしていたから大丈夫」、「コレをしないのが悪いんだ」と思わずに、今一度問題が起こっていないか、今後何をできるかを考えたほうが良いでしょう。自動でキレイに元通りにならないと対応は簡単ではなくなります。検知の重要性インフラを信じる、お金を使うということは大事ですが、今回のようにクラウドサービス自体が予期しない動作になることもあると勉強になりました。「MultiAZだから大丈夫」というのも、そもそもクラウドサービス自体がすべて正常に動作しているから言えることです。予期しない状況ですべてのシステム、アプリがうまく動作するとも限りません。足がかりにしている地盤そのものに問題が発生する場合どう検知して対応したら良いでしょうか?インフラ環境を信じすぎず、自分のアプリも信じすぎず、問題が発生する前提でちゃんと監視、検知、トレースすることは重要だと勉強になりました。「大した成果をあげら...2019-01-20aiohttp.ClientSessionのリクエストをaioresponsesでモックする。アクセスをテスト時にモックした...2018-11-02作りたいWebアプリのアイディアを迷走せずに作る方法。月別アーカイブPyQという製品を作っていますスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。