🤔

ALBを3AZにしてもあの障害は乗り切れないんじゃない?

2 min read

昔起きたALBの障害

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

以前、このような障害が発生しました。

今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。

AZの一部に障害が発生し、

予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。

ALBに障害が発生した事例が多くあったようです。

もしも僕たちのALBが、3AZだったら

そんなこんなで 3AZ だったら大丈夫だったんじゃね?という話が出てきました。

AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」

こちらの記事で 3AZ だったら!という話が出ています。ですが、障害時のALBは 2AZ 状態だったようです。この記事がきっかけか 3AZ の記事を見かけるようになりました。

ただ私には納得のいく回避策ではありませんでした。

スティッキーセッションじゃないの?

上述している障害報告の文章では、「AWS Web Application Firewall やスティッキーセッションとの組み合わせ」と記載があります。

「じゃあ 3AZ にしてもスティッキーセッション使ってたら意味なくね?」

これが率直な感想でした。私と同じような考えの記事もありました。

スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと

AZって3つも必要?

AWSのベストプラクティスにおいて、マルチAZはよく聞く単語です。これは当たり前ですが可用性を高めるために必要なことになります。しかしALBを落とさない対策として、3つも必要でしょうか?

よくある不安として、2つ以上のAZに障害が起こったらどうする?といったものがありますが、地理的に離れたAZが2つ以上同時に障害が起こってしまうほどの災害は、リージョン全体を破壊するほどの大地震とかになるでしょう(偶然、同じ時間帯に同時に障害が起こる可能性はありますが)。

またAZは、以下の引用文の通りに作られておりますので、単一のAZ障害がリージョンサービスを落とすことになるのは可能性が低いでしょう。

それぞれの AZ での障害や不具合は他の AZ に影響しないように構成されつつ、レイテンシなど複数拠点利用する際の考慮事項は最低限に抑えられている

Well-Architected for Startups -信頼性の柱- 導入編

話を少し戻すと、そもそもこの障害はスティッキーセッションなどが原因で障害が発生しているAZから別のAZに切り替えれなかったのが原因なので、3AZ にするだけで障害は回避できないと思います。

3AZ 環境がだめだと言っているわけではなく、ALBを落とさないためにはスティッキーセッションを無効にした方が効果的じゃない? ということを伝えたかったのです。

まとめ

この障害で影響を受けた人も受けない人もいるわけなので、スティッキーセッションを無効にしたら大丈夫だったよってわけではないのですが、AWSの障害報告を見て「AZを増やせばいい」という人は、着目する箇所がちょっと違うんじゃないかなと思った次第です。

個人的に、AWSのベストプラクティスに「ALBで3つ以上のAZを指定すると、障害を回避できます」と明記されるまでは、3AZ 対策の効果を信じられないですね(ALBに対する)。

過去の事例から学ぶことは多いです。これからもこういった事例は考察していきたいです。

おわり

GitHubで編集を提案

Discussion

ログインするとコメントできます