AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい

前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ

[everybodyelse]

Multi-AZ構成にしてても特定のAZに引っ張られて死ぬの、対処しようがねえ感ある。まだまだマルチクラウドの夢は遠そうだし、どうしたもんかという気持ち。

[jiro68]

オンプレミスの時代から冗長構成を取ると大抵死に損ないのプロセスとかに邪魔されて上手くフェールオーバーできないというのはあるあるだよね。だから死にかけのプロセスがあったらをOS毎ぶち殺す watchdog なんかがある

[circled]

オンプレだろうがクラウドだろうが微妙な死に損ないは対応に苦慮する。tomcatとかもサービスは死んでないのにcatalina.outにはout of memoryエラー吐いてたりだし、中途半端が一番困る。そして都度対策を増やし成長して行く。

[hatest]

AZ障害は、(A)AWSが(Z)ゾンビになるかもしれない障害

[sasasin_net]

「サービスは綺麗に死ぬとは限らない」これは完全同意で難しくて、「自動で切り替える仕組み」が発動しない場合も考えるしかないのですが、考えるの面倒くせえなあと

[leiqunni]

インフラ落ちるの気にしないためのクラウドなんだけど、もちろん末端のサーバは壊れたりしてる。僕はデータセンタの空調が壊れて、「氷と扇風機」でなんとかしようとしてるのを見た。よろしくお願いしまーす！

[manFromTomorrow]

“死ぬときは綺麗に死んでくれないってのは物理時代もスイッチやNICでよくあった”　ほんとこれ。FCとかも良く泣かされた。

[kagerou_ts]

最後のその瞬間まで生きていようとするんだ。それが命だ。それが命の輝きってやつなん（ﾊﾞﾁｰﾝ

[studio_graph]

Among Us で学ぶAWS障害対応 (EC2インスタンスの中にImposterが混じっている)

[napsucks]

ELBが半死にになるの去年もあったような。あいつSPoFなんだから勘弁してほしいところだね。route53でELBごとバッサリ切り替えろってことなのかな。

[iekusup]

ほー。

[houyhnhm]

結局障害は障害なんだよなあという感想。いくら頑健にしようとしても案外難しい。

[masa_iwasaki]

ほんとそれな "サービスは綺麗に死ぬとは限らない"

[rryu]

高可用性を求めるところは手動で特定のAZを切り離す訓練とかをしているのだろうか。東証のarrowheadですら同じような問題で大規模な障害になっていることを考えると…

[degage122]

“というのはAZ障害の場合は当然綺麗に自動切り離しが行われる前提で設計をしていたので、今回みたいに自動的に切り離しができないことを想定していなかった…切り離し方がサービスによってかなり違うので”

[teppeis]

本質情報だ「サービスは綺麗に死ぬとは限らない」

[raimon49]

マルチAZ構成でも検知できなきゃ死んでいる方に行ってしまう話。

[ryuichi1208]

“サービスは綺麗に死ぬとは限らない”これ難しい。一瞬だけ起動するも死ぬみたいな挙動だとクラスタ管理ツールが常に起動させてアラートすらならないみたいなのあったな。

[katzchang]

“サービスは綺麗に死ぬとは限らない” unknownな現象ってやつだ。

[taruhachi]

AZ「(咳はあるし、昨日晩熱出てたけど)大丈夫です！仕事できます！」ALB「ヨシ！通れ」

[suginoy]

音楽が梶浦由記なので。 “プリンセス・プリンシパル Crown Handler 超良作だから観てね”

[hdampty7]

これはプラットフォーム側で対処すべき問題も含んでると思う。multi-azで割増料金払ってるんだから。経験あるけど非常時にサービス特性にあった対応処理やるのって頭がもげそうになるほどツライ。

[hitoyasu]

AZ障害。

[chimerast]

オンプレのころからのあるあるなんだよね。まともに対応しようとすると、さらに冗長な構成が必要になって、サーバ費用や運用人件費が倍々になる。ビジネスインパクト見てどっかで妥協が必要。

[yodelx]

"今回AZ障害だからMultiAZだから影響がないっていうのは間違いで、中途半端に死んだ結果切り離しがうまく行かず、MultiAZ構成を取っていても影響が出てしまうというトラブルだった"

[stella_nf]

“中途半端に死んだ結果切り離しがうまく行かず、MultiAZ構成を取っていても影響が出てしまうというトラブルだった”

[NOV1975]

この手の話はたいていマルチAZにしとけって話なんだけど今回についてはそれだと厳しいってのがな

[hoppie]

自分が作ってる構成が耐えられるか全然自信ないんだけど、最近はAWSの人に構成レビューなり相談するしかないんじゃかなとか思ってる

[dekasasaki]

EC2とか使ってると、どんどんインスタンス増えていくものねえ。こりゃ大変だわ。分割損を覚悟して他社クラウドでメインのクラウドを監視するとか、そういう構成も真面目に考えないといけないのかな。

[azumi_s]

死ねば助かるのに(中途半端に生きてるもんだから助からない)

[tsucchi1022]

オチ(?)も含めてわかりみがすごいある

[tanimiyan]

一昨年の障害もそうだったけどELBとかのマネージドサービス（基盤はEC2）が綺麗に落ちずに機能不全になってしまうのが一番厄介だよなあ

[daiksy]

そうそう。マルチAZにしてても、綺麗に落ちたりしないから「確率的に不安定に」とかにどうしてもなるよね。

[camellow]

AWS特有のノウハウは知らんけど普通のサービス/死活監視ってPING、サービスの応答（内側から、外側から）、プロセス数、ロードアベレージとか監視するから切り分けできないってのは監視設計が悪いと思う。

[netcraft3]

マルチAZ構成だから安全という神話は捨て去るべき

[hiroomi]

”ゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。”

[thekoruku]

クラウドも物理から解き放たれる訳ではないのよな。ただまあ、システムとしてAWS使うことが決まってるなら、障害の説明はめっちゃ楽だからいいな

[nagabow]

メモ

[northlight]

手動切り離し