More than 5 years have passed since last update.

パブリッククラウドのゾーン縮退を検証する - IaaS編

Posted at 2019-09-04

AWS上でALBとAutoscaling Groupで構成されたIaaSのシステムのゾーン縮退について検証してみました。

前回書いた記事(パブリッククラウドの大規模ゾーン障害について考える)で、ゾーン縮退をオプションとして用意しも良いのではないかと考えました。本記事はその検証です。

検証環境

ALBの下に、Autoscaling group経由でNginxを動作させているEC2をZone AとZone Cに1台づつぶら下げています。

検証結果と考察

今回の構成ではゾーン縮退自体は可能でした。
但し、以下課題が残ります。

どのゾーン(ゾーンID)が障害になったかオフィシャルには公開されなかった認識ですが、ゾーン縮退するために障害ゾーンの特定が必要
ゾーンの属性がないサービス(WAF等)は、手動によるゾーン縮退ができない

ゾーン障害でもゾーン縮退よりディザスタリカバリ(DR)をするほうが、良いかもしれません。
念の為DRできるように準備するのでは無く2,3年に1回DRが発生する位のつもりで準備しておけば万全だと思います。

以下、ゾーン縮退の検証の詳細です。

1. ALBの特性

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはトラフィックを受信しません。

アベイラビリティーゾーンを無効にすると、そのアベイラビリティーゾーン内のターゲットはロードバランサーに登録されたままですが、ロードバランサーはトラフィックをターゲットにルーティングしなくなります。

AWSのドキュメントからの引用です。
障害の発生したALBのゾーンを無効化すればそのゾーンにトラフィックが流れなくなります。一方ALBに最低2ゾーン登録しておく必要があります。
つまり2ゾーン登録されている状態で、ゾーンを無効化するためには、同時に別のゾーンを追加する必要があります。

2. ALBのゾーン縮退の検証

Zone AとZone Cで構成されているシステムで、実際にZone Aを縮退させてみました。

No	およその経過時間	Zone AのEC2へのトラフィック	Zone CのEC2へのトラフィック	ALBのヘルスチェック	ALBのネットワークインターフェースの状態	説明
1	-	Zone AとZone Cから流れる	Zone AとZone Cから流れる	Zone AとZone Cから流れる	Zone AとZone C	ALB変更前
2	0分	流れなくなる	↓	↓	↓	ALBに対しZone A無効化・Zone D追加を手動実行
3	2分半	↓	Zone CとZone Dから流れる	Zone AとZone CとZone Dから流れる	Zone AとZone CとZone D	ALBのZone Dのネットワークインターフェースが利用中になる
4	1時間	↓	↓	Zone CとZone Dから流れる	Zone CとZone D

ALBでZone Aを無効化した直後から、Zone AのNginxへのトラフィックは来なくなりました。
また(ヘルスチェックを除き)ALBのZone Dのネットワークインターフェースが利用中になった位から、ALBのZone AのインターフェースからZone CのNginxへのトラフィックも来なくなりました。

手元で確認した限りでは、うまくゾーン縮退できているようです。

ALBはマネージドサービスでノードが直接見える訳ではなく、ALBのネットワークインターフェースが見えているだけなので、上図のALBのノードはあくまで推測です。