ALBのTargetGroup付け替え時にエラーになるリクエストは発生しないのか確認した
確認したいこと
ALB(Application Load Balancer)のリスナーとして設定するTarget Groupは、随時変更することができます。変更したそのタイミングでアクセスがあった場合に、エラーになることはないのか、気になったので確認しました。
図で説明
この状態から
この状態に変える瞬間に
このようにエラーになってしまうリクエストが発生しないか
結論
大丈夫そうです。Target Group付け替え時にエラーになるリクエストは発生しないようです。
検証方法
httpingというpingのhttp版のコマンドを使って、ローカルからALBに対して断続的にリクエストし続けます。その途中でTarget Groupの付け替えを行なって、エラーになるリクエストが無いか調べました。
Target Groupには前述の図のように、それぞれ異なるEC2インスタンスが一台ずつ紐づいています。
httpingインストール方法
brewでインストールできます。v2.5がインストールされました。
1 | $ brew install httping |
使用したhttpingコマンド
1 | $ httping -s -i 0 -g http: // (ALBのDNS名) -Y -Z -c 500 --ts -G |
オプションの説明
- s : アウトプットにhttpステータスコードを追加します。
- i : 各リクエスト間のインターバル。0に設定しています。
今回、1リクエスト完了に約0.1秒かかりました。ですので秒間10リクエストくらいを発生させることができました。 - g : アクセス先のURLの指定です。
- Y : アウトプットで複数色使って見やすくする設定です。
- Z : プロキシにキャッシュさせなくする設定です。あまり意味はなかったと思いますが念のため設定。
- c : カウント。何回pingするか。
- ts : 各pingのタイムスタンプをアウトプットに追加する設定です。
- G : メソッドをGETに変更する(デフォルトはHEAD)
検証結果
上記はhttpingのアウトプット最下部のstatistics部分です。failedになった(=200以外のステータスコードになった)リクエストはありませんでした。
10回試してみましたが、10回ともfailリクエストは発生しませんでした。
まあ秒間約10リクエストだけなので、もっと大量にアクセス発生させていればエラーになる場合もあるかもしれません。(その検証は今回行なっておりません。)
Target Group付け替え後の挙動
- Target Groupを付け替える
- しばらくは元のTarget Group下のインスタンスにトラフィック流れ続ける
- 1から10〜15秒後、新Target Group下のインスタンスにALBヘルスチェックのリクエストが届く
- 3のヘルスチェック直後からトラフィックが新Target Group下のインスタンスに移行する
- 以下は新Target Group下のインスタンスのアクセスログです。ヘルスチェック1回実施後にトラフィックが流れ始めていることがわかります。(ヘルスチェックまではアクセスログを空状態にしていました)
-
Target Groupの設定項目に「正常のしきい値」という項目があるので、この回数以上ヘルスチェックに成功しないとリクエスト受けられないのかなと思っていましたが、この「正常のしきい値」は「非正常なインスタンスが正常であると見なすまでに必要なヘルスチェックの連続成功回数」のことを指すので、今回のようにリクエスト未受信(=登録直後)のインスタンスには関係のない項目でした。
- リクエスト未受信(=登録直後)のインスタンスがリクエストを受けるようになるために必要なヘルスチェック成功回数は1回だったわけですが、このことはドキュメントにも記述がありました。
ターゲットは、登録後に正常と見なされるためには、1 つのヘルスチェックに合格する必要があります。
※ ターゲットグループのヘルスチェック - ALB AWSドキュメント
まとめ
- Target Group 付け替え時にエラーになるリクエストが発生することはなさそう
- 付け替えには10〜15秒くらいかかる。それまでは付け替え前のTarget Groupがリクエストを受ける
- 付け替え先のTarget Groupは最初のヘルスチェックが終わってからリクエストを受け始める