マルチAZ構成で単一AZの障害の影響を受けるのは何故か？

昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。

前提としてのELBの実装（の予想）

マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。

blog.takuros.net

旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが、それほど間違っていないのではないかと思っています。

マルチAZ構成で単一AZ障害の影響を受けるケース

上記のアーキテクチャの予想が正しいと仮定すると、単一AZ障害がマルチAZ構造に影響を及ぼす可能性が見えてきます。2つのAZを利用したELBを利用したマルチAZ構成の例で考えて見ましょう。AZ内には、それぞれ1台づつインスタンスがあるものとします。

ELBのファクターを考慮しないケース

まずELBのファクターが無い状態で片方のAZで障害が発生したとしたら、取りうる値は次のとおりです。ELBのヘルスチェック機能で障害AZの方に振り分けなければサービスが継続できますね。これが通常のマルチAZの考え方です。事前にテストする場合、片方のインスタンスを落とすか通信できなくしてテストすると思います。その場合も、ヘルスチェックのおかげで正常なサーバに振り分けられます。

正常AZ　インスタンス　○
障害AZ　インスタンス　☓

※今回はAZが全滅した訳ではないので、障害AZ内に生きているインスタンスがある可能性はありますが、単純化のために無視

ELBのファクターを考慮するケース

次にELBのファクターを入れて考えてみましょう。先程の組み合わせは、次のように変わります。今回は便宜上、障害AZ内に生きてるインスタンスと死んでいるインスタンスがあるという前提にしています。次のような組み合わせになります。

正常AZ　ELB　○　インスタンス　○
障害AZ　ELB　○　インスタンス　☓
障害AZ　ELB　☓　インスタンス　○
障害AZ　ELB　☓　インスタンス　☓

マルチAZで問題が発生するケースは、ELBが☓の場合だったのではないかと推測しています。もっと言うと、ELBが中途半端に壊れかけの場合だった可能性が高いです。そうなるとDNSにより障害が発生しているELBに振り分けられ、問題になると思います。

この問題の難しいところ

仮定を置きまくっていますが、シングルAZの障害がマルチAZ構成に影響を与える理由としては上記と推測しています。そして、この問題の難しいところとしては、この事象を正確に検知する方法がないということです。CloudWatchで ELB 5XXsのメトリクスを見ていると、ELB全体として何か問題が起こっていることは解りますが、個別のELBインスタンス（仮称）の問題を検知することができません。これが対応を難しくしています。

どういう構成にしておけば良いのか？

　それではどういう構成にしておけば良いのでしょうか？ちまたでは、マルチリージョンやマルチクラウドなど勇ましい話を聞きますが、殆どのケースで費用対効果に合わないと思います。比較的簡単にコストもほぼ変わらないで実現する方法としては、2AZではなく3AZ構成にすれば良いと考えています。そして、障害を起こしたAZを切り離します。
　今回の分析（妄想）で、AZ内のELBインスタンス（仮称）が問題を起こしており、ユーザー側の操作でそれをどうにかすることは出来ません。であれば、ユーザー側が対処できる方法として、3AZ構成にして問題があったら1つのAZを切り離すという方法が現実的です。実際にそのような対応をされて問題が収束したというケースがあったようです。

でも、その前に

　じゃぁ3AZ構成が有効として、障害が発生した時にすぐに対応すべきなのでしょうか？これも現実的にはNoです。もし上記のような対応をするのであれば、設計段階で3AZから2AZへの縮退稼働を織り込んでおく必要があります。そして、切り替え手順（スクリプト含む）・訓練を含めて事前に共有しておく必要があります。また、切り離しの判断基準や2AZから3AZへの復帰手順も必要ですね。
　それなしにぶっつけ本番で試すのは無謀です。2次被害の可能性も出てくるので、それであればAWSを信じて待つというのも正しい選択肢です。

まとめ

　今回の障害で、私自身もいろいろ知見を得られました。2018年に東京リージョンに事実上の3AZ目が使えるようになったので3AZ設計についても考えようかと思いつつも、具体的な設計に落とし込んでおりませんでした。今回のケースを考えると、もう少しアーキテクチャについて考えていかなければと反省点しています。ただピンチはチャンスです。Twitterのタイムラインを見ていても、皆さん色々な考察や対処法を考え出しているので、日本のAWSを使ったシステムももう一弾進化しそうな気配を感じています。みんなで頑張って、より良いシステムを作っていきましょう！！

　ちなみに今回のケースも、マルチAZ構成にしておけば影響が小さくなったのは間違いないと思います。また言及していませんが、RDSやCloudFrontなど他の要因もあったと思います。