ゾーンシフトも出現したしクロスゾーン負荷分散を再考察する


先日まで開催されていたAWSの一大イベント Re:Invent の期間中に、 単一AZ障害時の自動対処をおこなうための機能がリリースされていました。

それが自動ゾーンシフトです。 https://docs.aws.amazon.com/ja_jp/r53recovery/latest/dg/arc-zonal-autoshift.html

ゾーンシフトは、Route 53 Application Recovery Controller(ARC)に付随する機能で、 これまで手動でのみ特定のAZを切り離すことができましたが、 今回のアップデートで自動で障害を検知して切り離してくれるようになりました。

ただ、ゾーンシフトの大前提として「ELBのクロスゾーン負荷分散を無効化しておくこと」というのがあり、 チームメンバともこれ無効化するの微妙だよねという話を手動ゾーンシフトが出たときもしていました。 そして今回の自動ゾーンシフトの発表ということで、あらためてクロスゾーン負荷分散の無効化の是非について考えてみようと思います。

クロスゾーン負荷分散って?

そもそもクロスゾーン負荷分散についておさらいしておきたいと思います。 クロスゾーン負荷分散はその名のとおり、AZをクロスして負荷分散するELBの設定です。 ELBは作成するときは1リソースでも、実際には設定した各AZにそれぞれインスタンスが配置されます。 クロスゾーン負荷分散が無効の場合は自身と同じAZのターゲットグループにだけ転送しますが、有効にするとゾーンをまたいだものにも転送されるというわけです。

クロスゾーン負荷分散の有効/無効で下記の表のように違いがありました。

考慮事項クロスゾーン負荷分散 有効クロスゾーン負荷分散 無効
スティッキーセッションサポートされるサポートされない
バックエンドの偏りの負荷影響全インスタンス均一に負荷分散されるインスタンス数が少ないゾーンでは負荷が上がる
AZのインスタンス全損時の挙動ELBのエンドポイントはそのまま。分散先が変わるELBのエンドポイント自体が削除される
性能面の考慮事項AZまたぎの通信になるので多少レイテンシが上がる-
コスト面の考慮事項AZまたぎの通信になるので多少コストが上がる-

コスト・性能の問題はあれど、そのレベルを気にするならそもそもパブクラを選ぶか?ということもあり、 クロスゾーン負荷分散は基本的に有効にするものだと思ってきて育ってきたわけですから、 今回のゾーンシフト機能でクロスゾーン負荷分散をわざわざ無効化することという前提があったのはとても驚きでした。

どんなワークロードなら無効化してもよいのか

正直、今のところわざわざクロスゾーン負荷分散を無効化してまでゾーンシフトを利用したほうがよいケースが思いうかびません。

強いて言うなら、EKSがバックエンドであれば、もともとKubernetesはコンピュートノード間で仮想ネットワークを張って、 そちらでクロスゾーンで通信がおこなわれるのでELBのレイヤでもクロスゾーンに分散する必要はないのかもと思っていますが、どうなんでしょうか?

AZのインスタンスが全損したときの復旧が、クロスゾーン負荷分散が無効のほうが仕組み上わずかに時間がかかる(503エラーになる確率が上がる)ので、それを気にするよりも大規模AZ障害がおきたときにも、手を加えずにビジネス継続したいという考えに持っていければ使えるのかもしれないですね。 どうしても目先の切替時間の秒数に目が行きがちですが。

なぜゾーンシフトという機能がでてきたか

ここからは完全にエスパーですが、そもそもなぜクロスゾーン負荷分散を無効化してまでゾーンシフトという機能がでてきたのでしょうか。

私は最近AWSがさかんに言うようになった「静的安定性」の考え方にもとづくものと考えています。 今年のAWS Summit Tokyoでもセッションがありましたが、静的安定性は一言で言えば、 「障害が発生しても、何も設定変更をしなくても良い状態」を指すようです。

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-43_AWS-Summit-2023_Resilience.pdf

クロスゾーン負荷分散は、自身のAZの中でしか分散されないので、 AZ単体で想定される負荷をさばく、十分なキャパシティが求められます。 これはまさに静的安定性の考え方と一致しています。

当然通常運用時は余剰キャパシティが多く、正直無駄なコストにも見えてしまいますが、 そのコストを払ってでもビジネス継続性が求められる超重要なシステムに対して信頼性を提供する機能としてゾーンシフトが出てきたのではないでしょうか。

なので、やはりあらゆるシステムでとりあえず入れておこうというものではなく、 費用と費用対効果と十分そろばんを弾いて、導入する機能なのかなと思います。


See also

comments powered by Disqus