Blue/Greenデプロイメントで利用するターゲットグループに別途リスナーを紐付けても問題ないか調査してみた
こんにちは！AWS事業本部コンサルティング部のたかくに（@takakuni_）です。
今回は、タイトルの通りBlue/Greenデプロイメントで利用するターゲットグループに別ポートのリスナーを紐付けても大丈夫かどうかを検証してみようと思います。
図にすると次のようなイメージです。
このような状況で、Blue/Greenデプロイメントを行う場合、Blue/Greenデプロイメント用に作成したリスナーはターゲットグループが上手く切り替えれるのか検証してみようと思います。
今回は次のブログを参考にBlue/Greenデプロイメントの環境をサクッと作ってみました。
動作確認（リスナー追加前）
一旦、Blue/Greenデプロイメントがリスナーの追加前に正しく挙動しているか確認してみます。
Blue/Greenデプロイメント実行を参考にindex.htmlを更新し、GitHubのmainブランチにpushします。
テストトラフィックルーティングが開始されると、テストポート用リスナー（8080ポート）が置き換え後のタスクに向いていることがわかります。
ポート比較
また、本番用ポート（80ポート）へトラフィックの再ルーティングを行うと、本番用ポートも置き換え後のタスク（v2）へ向いていることがわかります。
ポート比較
動作確認（リスナー追加前ロールバック）
続いて、ロールバックも正常に行われるか確認してみます。
Blue/Greenデプロイメント実行を参考にindex.htmlを更新し、GitHubのmainブランチにpushします。
<!DOCTYPE html> <head> <meta charset="utf-8" /> <title>testページ</title> </head> <body> <h1>Blue/Green Deployment Demo v3</h1> </body> </html>
先ほど確認したように、テストトラフィックルーティングが開始されると、テストポート用リスナー（8080ポート）が置き換え後のタスクに向いていることがわかります。
ポート比較
ロールバックを実行してみます。「デプロイを停止してロールバック」をクリックすると、本番用/テスト用ポートが置き換え前のターゲットグループに戻ります。
ターゲットグループ
動作確認（リスナー追加後）
別ポートリスナーが更新前のタスク配置先ターゲットグループを参照している場合
さて、本題に入ります。再掲になりますが、以下の状態でブルーグリーンデプロイメントを行うとどのような挙動になるのか検証してみます。
ALBリスナー追加
まずはリスナーの追加を行います。図に記載されている18080番ポートを追加します。
セキュリティグループルールの追加
18080番ポートのアクセスを許可するためセキュリティグループのルールを追加します。
ポート確認
ポートを確認すると全てのリスナーが同じターゲットを参照していることがわかります。
準備が整いました。図をもう少し詳しくすると現在の状態でブルーグリーンデプロイを開始します。
index.htmlを更新して、mainブランチにプッシュします。
<!DOCTYPE html> <head> <meta charset="utf-8" /> <title>testページ</title> </head> <body> <h1>Blue/Green Deployment Demo v4</h1> </body> </html>
テストトラフィックが問題なく開始されていることがわかります。
各ポートを確認すると、テスト用リスナー（8080ポート）のみが正しく置き換え後のタスクに向いていることがわかります。
ターゲットグループからも、テスト用リスナー（8080ポート）のみ置き換え後のタスクが配置されたターゲットグループに転送先が切り替わっていることが確認できます。
本番用リスナーにもトラフィックを再ルーティングします。
本番用リスナーも置き換え後のタスクにターゲットが向いていることがわかります。
また、ターゲットグループを確認すると本番用/テスト用リスナーが「system-dev-blgr-tg-blue」に向いて、18080ポートリスナーは「system-dev-blgr-tg-green」のままになっています。
少し時間が経つとターゲットグループ「system-dev-blgr-tg-green」のタスクが削除されるため、503エラーが返されます。
図にすると現在、以下の状態に変化しています。
別ポートリスナーが更新後のタスク配置先ターゲットグループを参照している場合
続いて、別ポートリスナーが更新後のタスク配置先ターゲットグループを参照している場合でも、上手くブルーグリーンデプロイされるか検証してみます。
index.htmlを次のように更新しmainブランチへプッシュします。
<!DOCTYPE html> <head> <meta charset="utf-8" /> <title>testページ</title> </head> <body> <h1>Blue/Green Deployment Demo v5</h1> </body> </html>
置き換え後タスクのルーティングも問題なく切り替わっていました。
ポートを確認すると、テスト用リスナー（8080番ポート）と18080ポートで置き換え後のタスクが参照されていることがわかります。
ターゲットグループを確認すると、同じくテスト用リスナー（8080番ポート）と18080ポートリスナーで同じターゲットグループが参照されています。
本番用リスナーへトラフィックの再ルーティングも問題なく行われました。
動作確認（リスナー追加後ロールバック）
現在の状況を再度確認します。
動作確認（リスナー追加後）で2回ブルーグリーンデプロイを行なっているため、次の状況になっています。
この状態で、「system-dev-blgr-tg-blue」にv6コンテナをデプロイし正常にロールバックされるか確認してみます。
テストルーティング中にロールバック
テストルーティング（ステップ3）中にロールバックして問題なくロールバックが行われるか確認します。
「デプロイを停止してロールバック」からロールバックを行います。
ロールバックは正常に終了したことが確認できます。
また、ロールバック後のターゲットグループも元に戻った状態でした。
本番ルーティング中にロールバック
本番用ルーティングの置き換え後（ステップ5）に問題なくロールバックが行われるか確認します。
こちらも問題なくロールバックは正常に終了したことが確認できます。
同じく、ロールバック後のターゲットグループも元に戻った状態でした。
尚、18080ポートリスナーが参照しているターゲットグループの差異で挙動に変化はありませんでした。
まとめ
以上、「Blue/Greenデプロイメントで利用するターゲットグループに別ポートのリスナーを紐付けても大丈夫かどうか」でした。
ECS Serviceに対して複数のターゲットグループを登録する場合、ローリングアップデートのみ対応だったため、リスナーとターゲットグループ間の相関関係も気になり調べてみました。
この記事がどなたかの参考になれば幸いです。
以上、AWS事業本部コンサルティング部のたかくに（@takakuni_）でした！
![[小ネタ] ECS Anywhere で Amazon Linux 2023 を登録すると GPG エラーになるときの対処法](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-df53a651de243220f098c0db1a1ee07b/fe901239ff0a03da5a89375c192e924a/amazon-ecs-anywhere)
