重い腰を上げてECS BlueGreenデプロイに挑戦

Transcript

1. 株式会社ビッグツリーテクノロジー＆コンサルティング 札幌オフィス 〒060-0004 北海道札幌市中央区北4条西6-1 毎日札幌会館9F ベトナムオフィス 7th Floor, Mercury Building, No.444 Hoang Hoa Tham Street, Thuy Khue ward, Tay Ho District, Hanoi city 西日本オフィス 〒530-0001 大阪府大阪市北区梅田2-2-2 ヒルトンプラザウエストオフィスタワー19F シリコンバレーインキュベーションセンター 3350 Scott Blvd. #29 Santa Clara, CA 95054 東京オフィス(本社) 〒108-0073 東京都港区三田3-13-16 三田43MTビル12F 重い腰を上げてECS BlueGreenデプロイに挑戦 ～「どうして私の腰が重かったのか」～ BTC クラウドCoE 熊谷 有輝子 2022年06月27日 2022/6/27(月) AWS好きエンジニア LT会 vol.2 ~コンテナ編~
2. 2 Copyright © 2022 BTC Corporation All Rights Reserved. 自己紹介 熊谷 有輝子 名前 株式会社ビッグツリーテクノロジー＆コンサルティング （2016年2月～） 所属 • Cloud CoE（2021年1月～） 登山、ハロプロ（今年は8回現場入り） 趣味 業務 • AWSを使ったインフラ基盤構築 • 複数のお客様内でCloud CoE設立、PMO業務
3. 3 Copyright © 2022 BTC Corporation All Rights Reserved. LTのサマリ どうして私の腰が重かったのか でもやり方は何となくは知っているので、きっと勉強 する時間が出来ればすぐ実装できるだろう！ 後からデプロイ基盤を変更することは容易だろう。 • Blue/Greenデプロイメントとローリングアップ デートのインフラ構成における違いをなんとなく わかっていたが、試したことがなかった 腰重ポイント デプロイ基盤を俊敏に作って、まずは開発チームに環 境を渡すことが最優先。 • ローリングアップデートはCloudFormationで簡 単に作成できる • 案件を複数掛け持ちするなかで、新しい技術を キャッチアップする時間がなかった（スーパー言 い訳） 腰重ポイント 腰重ポイント まずは開発チームにデプロイ基盤を渡すことが最優先 私の方針 1. 基盤を迅速に作る Blue / Green デプロイメントの勉強をしてから、デ プロイ基盤を変更しよう 2. 後から変更する 結果、どうしたか Blue / Green デプロイメントの勉強はしたが、本番導入は行わなかった。
4. 4 Copyright © 2022 BTC Corporation All Rights Reserved. 2つのデプロイ手法の違い ローリングアップデート target group v1⇒v2 ターゲットグループ配下のコンテナに対して デプロイ メリット AutoScaling配下でもデフォルトで利用可能 デメリット ロールバックができない 前のバージョンに戻したい場合は再デプロイ 2つのターゲットグループ メリット デプロイ失敗時、迅速に切り戻しが出来る リリース時のダウンタイムが小さい デメリット AutoScalingはサポートされていない (デプロイ前にスケーリングプロセスを停止し、デプロイ後 にスケーリングプロセスを再開) Blue/Greenデプロイ target group 旧本番環境 v1 v2 target group 新本番環境 切り替え
5. 5 Copyright © 2022 BTC Corporation All Rights Reserved. ローリングアップデート⇒Blue/Greenデプロイに変更するためのポイント A) 既存のインフラ基盤の変更 ① デプロイタイプがCODE_DEPLOYのFargateサービスを新規で作成 ② ALBのターゲットグループを2環境分作成 B) 既存のデプロイ基盤の修正 ① Blue/Green Deployment用のIAMポリシーをアタッチしたCodeDeploy用のRoleを作成 ② Blue/Green DeploymentのCodeDeployを手動 or AWS CLIで構築 ③ 新しく作成したCodeDeployをPipelineのデプロイアクションに設定 ④ appspec.ymlの新規作成 ⑤ buildspec.ymlのイメージ定義ファイルの変更 ⑥ taskdef.jsonの追加 ※今回はプレースホルダ版でチャレンジ ※他にもCodeDeploy::BlueGreen フック版というやり方もある
6. 6 Copyright © 2022 BTC Corporation All Rights Reserved. DeploymentControllerというコンポーネントをECSからCODE_DEPLOYに変更 Aの① デプロイタイプがCODE_DEPLOYのFargateサービスを新規で作成 <変更部分> <画面(Fargate側)の見え方> ローリングアップデート Blue/Greenデプロイメント ただし、CloudFormationを修正しても既 存のStackを更新することはできません。 サ ー ビ ス を 一 度 削 除 し て 、 修 正 し た CloudFormationテンプレートで新規作成 する必要があります。
7. 7 Copyright © 2022 BTC Corporation All Rights Reserved. アプリケーションとデプロイメントグループを作成し、Pipelineのアクションに指定 Bの②・③ Blue/Green DeploymentのCodeDeployを手動 or AWS CLIで構築
8. 8 Copyright © 2022 BTC Corporation All Rights Reserved. Bの④ appspec.ymlの新規作成 ローリングアップデート Blue/Greenデプロイメント • CodePipelineステージのアクションプロバイダーが 「Amazon ECS」 • CodePipelineステージのアクションプロバイダーが 「Amazon ECS(ブルー/グリーン)」 • CodeDeployを使わない ⇒appspec.ymlも必要ない • CodeDeployのアプリケーション・デプロイメントグ ループを作成する ⇒appspec.ymlが必要
9. 9 Copyright © 2022 BTC Corporation All Rights Reserved. Bの⑤ buildspec.ymlのイメージ定義ファイルを変更 ローリングアップデート Blue/Greenデプロイメント • イメージ定義ファイルの名称は任意 • イメージ定義ファイルはimageDetail.json 参照：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/file-reference.html ※デフォルトのファイル名はimagedefinitions.json、 パイプラインデプロイステージを作成するときにそのファイル 名を指定する必要がある • 必ずartifactで成果物としてS3に格納
10. 10 Copyright © 2022 BTC Corporation All Rights Reserved. 結論（なぜ本番導入しなかったか）と今後やりたいこと • 変更点はシンプル、修正も難しくなかったが、サービスの再作成が必要でアプリ開発の手を止 めることになる⇒アプリチームの開発過渡期に実行するのは難しい • アジリティの高い（適切なものを素早く選択して速やかに行動することができる）組織である ために、どちらのデプロイ手法も迅速に（アプリ開発前に）取り入れることができるよう、ク ラウドCoEとして準備を進めたい