コラム

自己紹介

こんにちは、BTCクラウドCoEの西村です。
弊社クラウド推進チーム（クラウドCoE）立ち上げメンバーの一人です。

現在、AWSに関する業務を手広くやっていますが、元々はアプリ屋です。
オンプレに触れる部分はその道のスペシャリストにお任せしつつ、クラウドネイティブなシステム構築や社内クラウド活用体制の整備、アカウント管理等を担当しています。

今回のBTC Tech Blogの内容は「AWS CloudFormationでBlueGreenデプロイを実現してみた」（第1回目）です。
本来は掲題の記事を執筆する前にInfastructure as CodeやCI/CDについてお話しするべきですが、それはまた別に機会に。。。
直近の支援プロジェクトでAWS CloudFormation（以下、CFnと略します。）テンプレートでインフラを定義しつつ、AWS CodeDeployやAWS Beanstalkの機能を使わずにBlueGreenデプロイを完全自動化するシステムを構築しましたので紹介させていただきます。

AWSでのデプロイ方法にはどのようなものがあるのか

まずは、BlueGreenデプロイとはどういうデプロイ方法なのか、ということを簡単に説明したいと思います。
主なデプロイ方法にはRollingやBlueGreen、Immutableなどがありますが、各デプロイ手法は以下のようなものです。

Rollingデプロイ

指定した割合でサーバをロードバランサから切り離し、切り離したサーバにデプロイします。
デプロイが完了したら更新したサーバをロードバランサに接続し、また指定した割合で次のサーバにデプロイ、という操作を繰り返す方法です。

通常は冗長化されているサーバを上書きする形でデプロイしますが、指定した割合で新規サーバを立ち上げ、こちらにデプロイをする「追加バッチ型」のRollingデプロイも存在します。

このデプロイ方法のメリットは、設定が簡単でデプロイに時間がかからないことです。
逆にデメリットは、一時的に新旧のサーバが混在してしまうことです。
また、デプロイ後の動作確認で不具合が見つかった場合、デプロイを再度実施する必要があります。

BlueGreenデプロイ

Blue環境（Live環境、旧環境）のコピー環境を用意し、Green環境（Pre環境、新環境）とします。
トラフィックはBlue環境に向けたまま、Green環境に資材をデプロイし、動作確認を行った上で問題がなければトラフィックの向き先をGreen環境に変更します。

このデプロイ方法のメリットは、動作確認済みの環境にトラフィックを向けるまでエンドユーザには影響がなく、ダウンタイムも発生しないことです。また、万が一切り替え後に不具合が発現した場合は、再度Blue環境に切り替えれば一瞬でデプロイ前の状態に戻すことができます。
逆にデメリットは、維持コストがかかることです。

ほとんどの場合は、BlueGreenデプロイと言えばELBとEC2のコピー環境への操作を指しますが、本記事ではELB、EC2、RDS、EFSをすべてBlueGreenデプロイの対象としています。
※アーキテクチャの紹介は後述します。

Immutableデプロイ

BlueGreenデプロイの発展形で、コピー環境を都度構築し、デプロイ後に旧環境を捨てるという方法です。
このデプロイ方法は、サーバの不変性（本番環境のサーバに手を加えない）を思想としており、サーバに変更を加える場合、既存のサーバには手を加えず、新規に作成し直して切り替えるという考え方に基づいています。

このデプロイ方法のメリットは、動作確認済みの環境にトラフィックを向けるまでエンドユーザには影響がなく、ダウンタイムも発生しないことです。また、万が一切り替え後に不具合が発現した場合は、再度Blue環境に切り替えれば一瞬でデプロイ前の状態に戻すことができます。
逆にデメリットは、新環境構築が毎回必要になるため一回のデプロイに時間がかかること、万が一切り替え後に不具合が発現した場合は、再度デプロイする必要があることです。

カナリアリリース

デプロイとは少し異なりますが、カナリアリリースという方法も存在します。
本番環境へのデプロイを一定の割合のトラフィックのみがアクセスする環境に実施し、その一部の環境でテスト・フィードバックを得てから残りの環境へもデプロイします。

カナリアリリースでは、新環境の構築方法は問われません。
何らかの方法でデプロイを実施した後に、段階的にリリースを行う方法です。

このリリース方法のメリットは、一部分のノードのみへのデプロイのため、不具合が発生しても対象のノードを切り離すだけでロールバックが可能であることです。
逆にデメリットは、一定の割合のトラフィックに制限できるとは言え、アクセス数そのものが大きい場合は不具合があれば多大な影響を及ぼす可能性があることです。

 
上記で説明したこれらのデプロイ／リリース方法はどれが良い悪いというものではなく、要件によって使い分けられるべきものです。
クライアントの要望にお応えできる、適したデプロイ方法を選択しましょう。

まだ自己紹介と内容の頭出し、デプロイ方法のご紹介しかできていませんが、すべてを書き切ったところでもの凄い文字数になってしまっていることに気が付きました。
この後、アーキテクチャや実際のデプロイフローをご紹介する予定でしたが、それは第2回の記事として投稿させていただきます。