ALBを3AZにしてもあの障害は乗り切れないんじゃない？
昔起きた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を落とさないためにはスティッキーセッションを無効にした方が効果的じゃない？ ということを伝えたかったのです。
3AZ のいいところ
3AZ のメリットは1つのAZが使えなくなった場合に切り離すことができるという点です。ALB は2つ以上のAZを設定しなければいけないという制約がありますので、3AZ にしないと利用できないAZを切り離せないわけです。そのため 2AZ 構成においてはまったく使えないAZがあったとしても切り離せないので、ALBの障害回避ができなくなります（2つ以上のAZが落ちた場合はどちらも回避不可ですが、まあそういったことは極めて少ないと思います）。
そういった点では 3AZ にする利点があるので、そのもしもを回避したい場合においては 3AZ は有効的なアプローチとなります。
まとめ
この障害で影響を受けた人も受けない人もいるわけなので、スティッキーセッションを無効にしたら大丈夫だったよってわけではないのですが、今回のAWSの障害報告を見て「AZを増やせばいい」という人は、着目する箇所がちょっと違うんじゃないかなと思った次第です。
個人的に、AWSのベストプラクティスに「ALBで3つ以上のAZを指定すると、障害を回避できます」と明記されるまでは、3AZ 対策の効果を信じられないですね（ALBに対する）。
過去の事例から学ぶことは多いです。これからもこういった事例は考察していきたいです。
おわり
Discussion