稼働中のEC2のコピーを作成してALB下で切り替えた話 WordPress Update Blue Green

稼働中のEC2を落とさないでALB下で切り替えた作業記録を書いてみます。
こちら↓の方が詳しく書いてあります..。今回書いた記事の特徴は以下となります。

• AutoScalingグループを使わない
• ALBの下で切り替える
• deploy手順をAWSの外に用意する

AWS CodeDeploy でEC2のBlue/Greenデプロイを作成する

AWS CodeDeploy を使ってBlue/Green デプロイの仕組みを構築する為の手順を紹介します。Blue/Greenデプロイとは？現在稼働している環境と別にもう1つ稼働環境を作成し、ロードバランサー等のルーティングを新環境に向けるデプロイ方法です。常にリクエストを受けている稼働中のサーバを置き換えるよりも安全にデプロイ可能なのがメリットになります。

現状と動機

WPCoreアプデとセキュリティパッチはマメに当てないといけないと痛感して、
仕方なくBlue Green的な方法を導入してみた。

• ALBの下にWebサーバ1台。Webサーバの下にDB用EC2が1台(非RDS)。
• アップデート対象はWebサーバのみ。
• Webサーバ内でWordPressが12個、SNIで動いてる。
• x.smallクラス。CloudWatchを見るとLoadAverageは常時30%くらい。
• 全てのサイトで、pluginでファイルとDBをS3にバックアップしている。
• localで開発/WPCore,plugin update/動作確認後、止めずにansibleでdeploy。
• deploy実行前に”メンテナンス中”に設定。deploy完了後に解除する。
• アップデート中は管理画面操作禁止を通達。

deploy、パッチ当てでコケると、S3から戻すまで止まる!
S3から戻らないと終わる。

やったこと

• deploy、アップデート時にのみ、WebサーバのEC2をコピーする。
• ALBのターゲットグループにコピーしたEC2を追加する。
• 元のEC2に対してansibleでdeployする。
• 元のEC2に対してパッチアップデートする。
• ALBの先を元のEC2に戻す。
• コピーしたEC2を削除する。

メディアライブラリにファイルをアップロードすると差分が発生するため、
元EC2と一時EC2のファイル達を同期させないといけないけれど、
メンテ中は、管理画面操作を禁止できるという状況であることと、
もともとEC2が1台なのでその仕組みを作っていないから、それは2台以上に増えたときに..。

AMI作成

まずAMIを作成。AMIとはAmazon Machine Imageの頭文字。

インスタンスと AMI

Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーであるインスタンスを起動します。以下の図に示すように、1 つの AMI の複数のインスタンスを起動することができます。

手順は以下。

1. ダッシュボードからコピーしたいインスタンスを選択
2. アクション->イメージ->イメージの作成を選択

デフォルトだと、AMI作成時にコピー元インスタンスが自動的に停止し、コピー後に自動的に再起動する。
“再起動しない”にチェックをいれることで、コピー元インスタンスの停止/再起動を抑止できる。
“再起動しない”にチェックをいれないでAMIを作成すると、コピー元が止まってしまうので注意!

イメージの作成を押下すると、作成処理が始まる。
EBSが30GiBだと、完了まで1時間程度要してしまった。
ダッシュボード -> AMI から AMIの作成状況を確認できる。
ステータスが available になれば完了。

インスタンスの起動

作成済みAMIからインスタンスを起動する。

1. ダッシュボード -> AMI を開く
2. 起動したいAMIを選択する
3. アクション -> 起動を押下

すると、インスタンスタイプを聞かれる。

進捗状況はEC2ダッシュボードで確認できる。

ALBのターゲットグループ変更

既にALBのターゲットグループに元EC2が属していて、
セキュリティグループが正しく設定済みで、ヘルスチェックが通っている前提。
現状、ALBの下は元EC2だけなので、AvailabilityZoneは1種類だけ。

ダッシュボード -> ターゲットグループ

そこに、新しく作成したインスタンスを追加する。
新しいインスタンスのセキュリティグループを旧インスタンスに合わせて
ALBからのInboundを受けられるようにすること。

新しいインスタンスのヘルスチェックが無事通って2台構成になった図。

元のEC2をターゲットグループから削除

元のEC2をターゲットグループから削除する。
EC2ダッシュボードのモニタリングタブをみて、CPU使用率などに変動があることを確認する。

元のEC2に対してゴニョゴニョする

ALBのターゲットグループから外れた元のEC2に対してdeployなりパッチ当てを実行する。
元のEC2にElasticIPを当てておけば、再起動してもIPアドレスは変わらない。
この手順においては、新規作成したEC2にElasticIPを当てる必要はない。

元のEC2のセキュリティグループを0.0.0.0/0:80からアクセスできるようにして、
hostsにElasticIPを書いてアクセスするなどの方法で、元のEC2にアクセスする。
このためだけにALBを作って置いておくとそのALBに対して課金されてしまう。

新規作成したEC2を無料枠でやったりしてスペックが低いとパフォーマンスが下がる。
非稼働のEC2に当てたElasticIPで課金される。

一時EC2をターゲットグループから外し、元のEC2を投入する

上の手順を逆から実施。つまり、一時EC2をターゲットグループから外し、元のEC2を投入する。