ELB+AutoScaling環境でALBに移行してみる

菊池修治

2017.01.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

昨年発表された Application Load Balancer （ALB）ですが、すでに既存のClassic Load Balancer（元々のELB：標準ロードバランサー）から移行しているユーザも多いと思います。

今回、AutoScalingで使用しているケースにおける、CLBからALBに移行する手順を調べてみました。単純な移行と比較して、いくつか注意点もありました。

手順サマリ

ALB/Target Groupを作成（ここではインスタンスの追加不要）
Auto Scaling Groupを編集
1. 一部プロセスを停止
2. Target Groupを追加
Health Checkが正常となることを確認
Auto Scaling Groupを編集
1. CLBを削除
2. 停止していたプロセスを再開
DNSレコードを切り替え、アクセス先をCLBからALBに変更

1、6についてはこれまでの記事でも紹介しておりますので、そちらも合わせてご確認ください。

やってみる

1. ALB/Target Groupの作成

まずはALB/Target Groupを作成します。以下にコンソールからの手順を記載しますが、同設定での移行であればelastic-load-balancing-tools を使うのも確実で良いかもしれません。

基本はこれまでのCLBと同様です。

Application Load Balancerを選択します。

基本的な設定、リスナー、セキュリティグループ等はこれまでと変わりませんので、移行元のCLBと同様に作成しましょう。

Target Groupは新規で作成します。インスタンスへのプロトコルとヘルスチェックを設定します。

作成できたら次の手順に進みます。

Auto Scaling Groupを編集

既存のAuto Scaling Group を編集し、先ほど作成したTarget Groupを設定に追加します。

対象のAuto Scaling Groupを選択し、編集を選択。

「ターゲットグループ」に先ほど作成したTarget Groupを追加します。

「停止したプロセス」にReplaceUnhealthyを追加します。（理由は後述）

上記変更を保存します。

3. Health Checkが正常となることを確認

上記の手順により、AutoScalingで起動してたEC2インスタンスが自動的にTarget Groupの配下に登録されます。Health Checkの設定に問題がなければ、healthyのステータスになっていることが確認できます。

もしunhealthyが継続する場合には、ヘルスチェックパスやセキュリティグループ設定に問題がないか確認しましょう。

そして、先ほどの手順でAutoScalingのReplaceUnhealthyを停止した理由ですが、これを無効化しないと、追加したALBの設定に問題がある場合にEC2インスタンスがTerminateされます。CLBとALBの両方のヘルスチェックに合格しない場合、AutoScalingの監視プロセスによってインスタンスが削除・再作成される動きになります。

ReplaceUnhealthyのプロセスを停止しておくことでTerminateが抑止されますので、新しく作成したALB側の設定に問題が合っても、CLB側ヘルスチェックに問題がなければ、サービスに影響なく安全に作業が可能です。（ただし、運悪くCLB側で障害が発生してしまった場合にもインスタンスの削除・再作成が発生しませんのでご注意ください。）

また、この状態でALB/CLBそれぞれからサービスにアクセスし、正常性を確認しましょう。