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

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

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

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

![IaaS_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/57aacfd0-13e2-09ce-1cc9-5c83332edd4e.png)

# 検証結果と考察

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

1. どのゾーン(ゾーンID)が障害になったかオフィシャルには公開されなかった認識ですが、ゾーン縮退するために障害ゾーンの特定が必要
2. ゾーンの属性がないサービス(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-seni.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/361449be-790d-68e1-233a-60a339003e93.png)

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

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

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

#### ALBに対しZone A無効化・Zone D追加を設定

<img width="707" alt="alb_ac_to_cd.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/53834ac8-e11d-a2f4-1b0a-e61728b3f3e6.png">

## 3. Autoscaling group配下のEC2インスタンスのゾーン縮退

ALBをゾーン縮退させれば障害ゾーンにあるEC2インスタンスにトラフィックは流れなくなりますが
障害ゾーンにあるEC2が無駄になります。

以下手順でAutoscaling group配下のEC2インスタンスに対しゾーン縮退させることが出来ます。

### A. インスタンス台数が可変の場合

1. Autoscaling groupから障害ゾーンに属するサブネットを削除
2. 残ったサブネットにインスタンスが作成される
3. 障害ゾーンに属するサブネットにあるインスタンスが削除される

#### 1. Autoscaling groupから障害ゾーンに属するサブネットを削除

削除前
<img width="539" alt="ac_2_1_before.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/9b89fdbe-5fb1-a584-c72b-de352a111725.png">

削除後
<img width="488" alt="ac_2_2_after.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/d47955a3-8f57-414b-b832-ea05c2b41d55.png">

#### 2. 残ったサブネットにインスタンスが作成される

<img width="1495" alt="ac_2_3_3dai.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/6ec479fc-1d40-56b9-1f5a-374db91a9277.png">

#### 3. 障害ゾーンに属するサブネットにあるインスタンスが削除される

<img width="1500" alt="ac_2_4_2dai.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/99ec0799-3159-8667-cd5d-d3341286eeb2.png">

### B. インスタンス台数固定の場合

1. 障害ゾーン以外のインスタンスに対し、Instance protectionを設定
2. Autoscaling gropuのインスタンス数を変更
3. 障害ゾーンのインスタンスが削除される

#### 1. 障害ゾーン以外のインスタンスに対し、Instance protectionを設定
<img width="1503" alt="ac_1_1_2dai.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/31e6157f-dcf3-737b-e16b-9004c88e9eeb.png">

#### 2. Autoscaling gropuのインスタンス数を変更
<img width="536" alt="ac_1_2_2_to_1.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/af323715-a6c2-07b0-c5f1-a5df55b0bf38.png">

#### 3. 障害ゾーンのインスタンスが削除される
<img width="1500" alt="ac_1_3_1dai.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/192584/d373e3c1-1032-b098-6cc3-3276c4b1730a.png">