みなさん、こんにちは。今日は前回の続きとして、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を実施したにも関わらずデプロイ中に障害を起こした経験があります……)。

まとめ

ECSによるBlue-Green Deploymentは、サービスのインフラ全体を含めたデプロイメント戦略を考える上でデプロイ時におけるダウンタイムの少なさや、障害時の迅速なロールバックによる復旧を担保する上で非常に重要な要素となります。

ECSが登場してから日も経ち、開発・運用に関して少ないコストで信頼のおける構成をとることが可能となって来ました。

釈迦に説法ですが障害の起きないシステムは存在しないので、システム更新時における障害対応フローを見直して適切な運用体制になるよう取り組むことは非常に有意な取り組みだと思っております。

SunnyCloudでは、AWSが5%お得に利用できるAWSリセール(請求代行)サービスを提供しています!

▼「無料相談」受付中です。
https://www.sunnycloud.jp/contact-us/