ELB 配下の EC2 インスタンスを Active Standby 構成にする.md

ALB 配下の EC2 インスタンスを Active Standby 構成(自動切り替え)にする

ALB配下の EC2インスタンスを 2台に冗長化するときに 1台をコールドスタンバイにして障害時に自動切り替えする構成を考える場面がありました (1,2)

ALB配下に EC2インスタンスが 2台以上同時稼働する構成にバックエンド側が対応できない
2台分の料金を支払いたくない

ALB のロードバランシングアルゴリズム

ALBのリクエスト振り分け方式 ( ロードバランシングアルゴリズム ) は以下の２つのいずれかになります

ラウンドロビン → すべてのターゲット( EC2インスタンス ) を対象にして順繰りにリクエストを送信
最小の未処理のリクエスト → 未処理のリクエスト数が最も少ないターゲット( EC2インスタンス ) にリクエストを送信

下の図のように 1台の EC2インスタンスをコールドスタンバイにして自動切り替えする事はできません
※ 例えば「Availability Zone A に起動している EC2インスタンスが ALBからのヘルスチェックで Unhealthy になったら Availability Zone B に自動で新しく起動」ということは出来ません

※ 自動切り替えは不可なものの手動では出来ます (コールドスタンバイのインスタンスをターゲットグループから外しておき障害発生時に手動でターゲットグループに入れることで実現可能です)

Auto Scaling グループを使ってActive Standby 構成(自動切り替え)を実現する

Auto Scaling グループを使ってActive Standby 構成(自動切り替え)を実現できます
実際に以下のように切り替わるようにします (ap-northeast-1 リージョンでの例です)

運用中の EC2インスタンスが ALB からのヘルスチェックに失敗
ALB からのヘルスチェックに失敗した EC2インスタンスを削除
新しく EC2 インスタンスを 1台起動 ( ap-northeast-1a または ap-northeast-1c )

具体的な設定は以下のようにします

アベイラビリティーゾーン：ap-northeast-1a, ap-northeast-1c
ヘルスチェックのタイプ：ELB
ターゲットグループ：ELBのターゲットグループ
希望するキャパシティ：1
最小キャパシティ：1
最大キャパシティ：2
終了ポリシー：default

※削除中に新しいインスタンスを起動できるように「最大キャパシティ」を2に設定しています

作成した構成を図示します

Availability Zone (AZ) 障害対策となるか？

Availability Zone (AZ) 障害対策となるか？という観点でドキュメントに以下のような記述がありました

1 つのアベイラビリティーゾーンが異常ありまたは使用不可になると、Amazon EC2 Auto Scaling は、影響を受けていないアベイラビリティーゾーンで新しいインスタンスを起動します。異常のあるアベイラビリティーゾーンが正常な状態に戻ると、Amazon EC2 Auto Scaling は Auto Scaling グループのアベイラビリティーゾーンにわたって均等にインスタンスを自動的に再分散します。Amazon EC2 Auto Scaling は、インスタンス数が最も少ないアベイラビリティーゾーンで新しいインスタンスの起動を試みることで、これを実行します。この試みが失敗すると、Amazon EC2 Auto Scaling は成功するまで他のアベイラビリティーゾーンでの起動を試みます。