AWS ECSでのデプロイをBlue/Greenデプロイに変更しよう～Blue-Green Deployment 戦略、ローリングアップデートとの違いとは（第2回）

みなさん、こんにちは。今日は前回の続きとして、ECSのサービスでBlue-Green Deploymentをやってみましょう。

実際にECSのサービスでBlue-Green Deploymentを行ってみる

それでは、ECSのWebコンソールを利用してBlue-Green Deploymentを試してみましょう。

※記事ボリュームの都合上、各種の準備や操作を省略しています。

まず、何らかのECSクラスターを作成してタスクを定義した後、サービスの作成／変更画面から「デプロイメントタイプ」を「Blue/Green デプロイメント」として作成します。
サービス作成のダイアログを進める中で、適宜必要なリソースの作成（Application Load Balancer等のAWSリソースの作成）が求められます。

ダイアログに従って進めてサービスの作成が完了すると、自動的にCodeDeployのアプリケーションが作成されます。

ECSのBlue-Green Deploymentの実際のデプロイ操作はCodeDeployで行われるため、CodeDeployのコンソールに移動します。

作成されたCodeDeployのデプロイメント画面に移動するため「デプロイ→デプロイメント」を左メニューより選択し、上図のように更新したいタスク定義に該当するようにAppSpecを書きます（今回はシンプルなNginxのイメージをタスクとして定義していますが、タスクによってAppSpecは書き換える必要があるため少しだけ勉強する必要があります）。

下部の「デプロイの作成」ボタンを押すことでデプロイが開始され、サービスに紐付いたタスクがBlue-Green Deployment方式でデプロイされます。

CodeDeployのフローは5つのステップに分かれており、先程説明したフローのように「新しい環境を作成し（必要に応じてテストトラフィックへのルーティングを作成し）、トラフィックを切り替えた後一定期間のロールバックの猶予をもって、旧環境をリタイアさせてデプロイが完了する」ような流れになります。

新しい環境の作成が完了し、ロールバックの猶予となっている状態が上図となりますが、ここで「デプロイを停止してロールバック」ボタンを押すと、即座に古い環境へとルーティングが戻り、作成中の新しい環境は破棄されます。

この紹介ではWebコンソールを用いたCodeDeployの操作を行いましたが、AWS CodePipelineを用いることで新しいイメージのpushをトリガーとしてCodeDeployでのデプロイ実施までを自動化できるので、実際の流れとしては人が操作できるような、とてもシンプルな操作に抽象化されていることがわかります。

Blue-Green Deploymentを運用する上での注意

ローリングアップデートと同様の問題ではありますが、本番運用として厳格に管理する上ではECSが管理しきれないアプリケーションのレイヤに関して障害の可能性について検証する必要があります。

以下に例を挙げてみます。

・アプリケーション上でKafkaやRedis、Memcached等のミドルウェアを利用してジョブやキューの管理をしていて、BlueとGreenで同時に実行されることで予期せぬ動作をする（Greenで作成したデータをBlueが処理する可能性がある）

・ロードバランサーが突然ルーティングを切り替えるため、ユーザーが操作をしている途中で予期せぬ処理を行う可能性がある

・ローリングアップデートと違い2つの環境が同時に存在する期間が存在し、MySQL等ミドルウェアのコネクションが耐えきれなくなって大規模な障害を起こす可能性がある

ECSのBlue-Green Deploymentで管理できるのは、標準ではデプロイメントに関するヘルスチェック程度になるため、それより高いレイヤにある「実際にアプリケーションはデプロイ時に不都合が起きないか」という課題に関しては開発しているサービスに関して包括的に挙動を検証し、場合によっては実運用上のリスクとして考える必要があります。

アプリケーションや関連するミドルウェアの挙動に関しては、いわゆるステージング環境のような本番環境を模した構成を用いて、実際にBlue-Green Deploymentを実施している最中にトラフィックを流しながら検証する必要があります（詳細は省きますが、筆者もBlue-Green Deploymentを実施したにも関わらずデプロイ中に障害を起こした経験があります……）。