AWS ECSでブルーグリーンデプロイメント！～デプロイメントタイプ別の動作比較～

カテゴリ一 AWS ブログ 開発 構築 クラウド
2024-04-03

こんにちは！エンジニアの岩間です。

今回は、AWS ECSのブルーグリーンデプロイメントの、デプロイメントタイプ別の動作の違いについてご紹介します。

前回は、AllAtOnceデプロイメントタイプを使用してLaravelのセッション切れを起こさないための対策についての記事を書きましたが、
今回はデプロイメントタイプ別（AllAtOnce、Canary、Liner）の動きに焦点を当てて解説していきたいと思います。

 

この記事でわかること

  • ECSのブルーグリーンデプロイメントの仕組み
  • ECSのブルーグリーンデプロイメントの各デプロイメントタイプの動作について
  • 実際の設定を通じて動作を確認する方法

※スティッキーセッションの設定については紹介しません。もしご興味がある方は前回の記事で紹介しているので、ぜひチェックしてみてください！

 

前提条件

前提条件は前回のブログと同様です。

 

  • AWS ECS on EC2（※1）上にLaravel10アプリケーションを構築

  • LaravelアプリはAppコンテナとWebコンテナの2コンテナで構成

  • CodePipeline + CodeDeployでブルーグリーンデプロイ（※2）パイプラインを構築済み

  • CodeDeployのデプロイタイプはCodeDeployDefault.ECSAllAtOnce

  • 本番リスナーは443、テストリスナーは8443（※3）

  • Laravelのセッション保存先はデータベース（RDS）
    →.envファイルでSESSION_DRIVER=databaseに変更、RDSでsessionsテーブルを作成済み

 

以下の画像は構成図です。

（※1 ）AWS ECSのインフラはFargate（サーバレス）とEC2インスタンスが選択できます。今回はEC2インスタンスタイプを選択しました。

（※2）ブルーグリーンデプロイメントは、アプリケーションやサービスの新しいバージョンをリリースする際に使用されるデプロイメント戦略の一種です。
従来の「ブルー」の環境と新しい「グリーン」の環境の2つの異なる環境を用意し、トラフィックをブルー環境からグリーン環境に漸進的に切り替えることで、ダウンタイム0でシームレスなトランジションを実現できます。
また、ブルー環境を破棄する前にしばらく並行して実行させておくことでロールバックを容易にし、問題が発生した場合に素早く以前の状態に戻すことができるというメリットがあります。
詳しくはこちら

（※3）ブルーグリーンデプロイメントでは、新しいバージョンのアプリケーションに対するトラフィックを制御するために、テストリスナーとプロダクションリスナーを使用します。

  • テストリスナー: 新しいバージョンのアプリケーションに対するトラフィックを一部のユーザーやテスト環境に向けるためのリスナーです。テストリスナーを使用することで、新しい機能や変更の影響を限定的なユーザーに制限し、本番環境への影響を最小限に抑えることができます。
  • プロダクションリスナー: 新しいバージョンのアプリケーションに対するトラフィックを本番環境に向けるためのリスナーです。テストリスナーでのテストが完了し、新しいバージョンが本番環境で正常に動作することが確認された後、プロダクションリスナーを介してトラフィックを新しいバージョンに切り替えます。

 

ブルーグリーンデプロイメントタイプについて

ECSブルーグリーンデプロイを行う場合、CodeDeployのデプロイ設定より、更新された Amazon ECS タスクセットにトラフィックを移行する方法を指定ができます。

以下のようにcanary、リニア、または一度にすべてのデプロイ設定を使用してトラフィックをシフトできます。

 

項目 内容
CodeDeployDefault.ECSLiner10PercentEvery1Minutes すべてのトラフィックが移行されるまで、毎分トラフィックの 10 パーセントを移行します。
CodeDeployDefault.ECSLiner10PercentEvery3Minutes すべてのトラフィックが移行されるまで、3 分ごとにトラフィックの 10 パーセントを移行します。
CodeDeployDefault.ECSCanary10Percent5Minutes 最初の増分でトラフィックの 10 パーセントを移行します。残りの 90 パーセントは 5 分後にデプロイされます。
CodeDeployDefault.ECSCanary10Percent15Minutes 最初の増分でトラフィックの 10 パーセントを移行します。残りの 90 パーセントは 15 分後にデプロイされます。
CodeDeployDefault.ECSAllAtOnce すべてのトラフィックを同時に更新済み Amazon ECS コンテナに移行します。

 

上記の他にも、AWSコンソール上でCodeDeploy→デプロイグループの編集→デプロイ設定の作成で独自のカスタムルールを作成することもできます。

 

デプロイメントタイプ別の動作の違い

ここからは、AWS ECSのブルーグリーンデプロイメントの、デプロイメントタイプ別の動作の違いについて解説していきます。

CodeDeployDefault.ECSAllAtOnce選択時

AllAtOnceを選択した場合、ブルーグリーンデプロイメント時、プロダクションリスナー443の向き先がブルー環境からグリーン環境に一度で同時に切り替わるため、即座に新しい環境をデプロイできます。

 

この時、スティッキーセッションを利用している場合、セッション中のユーザーはグリーン環境に切り替わりますが、セッションは継続された状態で利用することができます。

AllAtOnceを選択することで、即時に新しい環境にデプロイすることができ、スムーズなユーザー体験を確保することができます。

 

CodeDeployDefault.ECSAllAtOnce以外選択時

canaryやリニアタイプを選択した場合、ブルーグリーンデプロイメント時、プロダクションリスナー443の向き先がブルー環境からグリーン環境に一括ではなく段階的に切り替わります。

 

この際、ブルー環境でセッション中のユーザーは引き続きブルー環境にルーティングされます。
そのため、デプロイ中はスティッキーセッションを使用していなくても、ユーザーはセッションが継続した状態で引き続き既存の環境を使用することができます。

AllAtOnceデプロイメントでは即座にグリーン環境に切り替えられますが、セッション中のユーザーのルーティングをグリーン環境に切り替えたくない場合は、CanaryやLinerデプロイメントが適しているといえます。

 

一方、デプロイ中に新しくセッションを開始したユーザーは、グリーン環境にルーティングされるためデプロイが進行中でも新しいバージョンの機能や更新内容を利用することができます。

 

AWSコンソールのCodeDeploy→デプロイの画面をみてみると、デプロイ中のトラフィック移行の進行状況が表示されます。

オリジナルはブルー環境、置換はグリーン環境を指しており、デプロイの進行状況をリアルタイムで把握することができます。

 

やがて設定の時間が経過すると、プロダクションリスナー443の向き先が、グリーン環境に100%のトラフィックがルーティングされるようになります。

例えば、毎分トラフィックの10パーセントを移行するCodeDeployDefault.ECSLiner10PercentEvery1Minutesを選択した場合、デプロイ開始から10分後にはすべてのトラフィックがグリーン環境に切り替わります。

 

スティッキーセッションを利用していない場合、すべてのトラフィックがグリーン環境に切り替わると、これまでブルー環境でセッション中だったユーザーはセッションが切れになります。
そのため、ユースケースや要件に応じて適切なデプロイメントタイプとスティッキーセッションの利用を検討する必要があります。

 

 

CodeDeployのデプロイの画面では、トラフィックが置き換えタスクセットに100%移行していることが確認できます。

 

デプロイ完了後

プロダクションリスナー443の向き先が、グリーン環境に完全に切り替わった後は、ブルー環境は削除されます。

ブルー環境が削除されると、これまでブルー環境に紐づいていたTarget Group1はどこにも紐づかない状態となります。
この動作は、どのデプロイメントタイプでも共通しています。

このとき、ブルー環境が削除されるまでの時間は指定することができます。
CodeDeploy→デプロイグループの編集→デプロイ設定の画面で「元のリビジョンの終了」という設定項目で設定が可能です。

 

動作確認

ここまでデプロイメントタイプ別の動作の違いの説明でした。

ここからは、ブルーグリーンデプロイの前後でリスナーとターゲットグループの設定がそのように変化するか、実際に確認してみましょう。

デプロイ前

ブルーグリーンデプロイ前のリスナーとターゲットグループのコンソールを確認します。

リスナー

ブルーグリーンデプロイ前のALBのリスナールールをみてみると、443リスナーと8443リスナーが同じターゲットグループ（TEST-1）に向いていることが確認できます。

 

ターゲットグループ

ブルーグリーンデプロイ前のターゲットグループをみてみると、TEST-1のターゲットグループのみロードバランサーと関連付けされていることが確認できます。TEST-2のターゲットグループは「関連付けなし」と表示されています。

 

ブルーグリーンデプロイ前は、以下の画像のような構成になっていることを確認できました。

 

デプロイ後

ブルーグリーンデプロイ後のリスナーとターゲットグループのコンソールを確認します。

リスナー

ブルーグリーンデプロイ後のALBのリスナールールをみてみると、443リスナーと8443リスナーが同じターゲットグループ（TEST-2）に向いていることが確認できました。（デプロイ前はTEST-1に向いていました）

 

ターゲットグループ

ブルーグリーンデプロイ後のターゲットグループをみてみると、TEST-2のターゲットグループのみロードバランサーと関連付けされています。（デプロイ前はTEST-1のターゲットグループのみロードバランサーと関連付けされていました）

 

上記より、ブルーグリーンデプロイが正常に行われ、リスナーとターゲットグループの設定が期待通り以下の画像の構成に変更されたことがわかります。

 

まとめ

以上、「AWS ECSでブルーグリーンデプロイメント！～デプロイメントタイプ別の動作比較～」でした。

ここまでお読みいただきありがとうございました。

この記事が気に入ったら
いいね ! しよう

シェアする
ツイートする
Twitter で

【採用情報】一緒に働く仲間を募集しています

採用情報
2024-04-03

関連投稿

ページトップへ