Feature 環境の自動生成と Blue Green Deployment で効率的かつ安全なリリースプロセスを構築

CloudNative Days Tokyo 2022 プレイベントの登壇資料です。

Transcript

1. Feature 環境の⾃動⽣成と Blue Green Deployment で効率的かつ 安全なリリースプロセスを構築 2022/11/01 CloudNative Days Tokyo 2022 プレイベント
2. ⾃⼰紹介 猪熊 朔也 ( いのくま さくや ) / @sinocloudon - 株式会社 Red Frasco - インフラエンジニア u経歴 ⾦融系SIer -> リクルート -> ⾦融系スタートアップ -> Red Frasco uその他コメント - うどんが好きです - ラーメン⼆郎が好きです - うどん脳 をプロフィールアイコンにすることが多いです - 最初4年くらいは Java エンジニア - ここ5年くらいはインフラ・クラウド⼀⾊ 2
3. はじめに • AWS 上にデプロイしたコンテナの CI/CD に関するお話です • ALB / ECS / Fargate / CloudFormation / AWS CLI あたりが主に登場します • 各サービスに関する詳細な説明は割愛しますのでご了承ください • CI/CD ツールには CircleCI を採⽤しています • ただし、CircleCI の特定の機能に依存した仕組みではありません • 他ツールを使⽤されている場合は、適宜読み替えながらご参考いただ ければと思います 3
4. ⽬次 1. はじめに 2. Blue Green Deployment 編 3. Feature 環境⾃動⽣成 編 4. まとめ
5. 5 1. はじめに
6. とある不動産ポータルサイトのAWS移⾏を進めています 6 【物件情報がポータルサイトに掲載されるまでの流れ】 不動産会社 担当者 物件情報⼊⼒ 物件情報変換 物件情報表⽰ 物件管理 システム データ 連動 物件データ 画像データ 他システム 物件データ 画像データ ⼿⼊⼒ コンバータ 各種ポータルサイト データ 連動 デ ー タ 連 動 ⾃社ポータル 総合ポータル S 総合ポータル H 総合ポータル A データ 連動 データ 連動 データ 連動 カスタマー 物件探し ⼿⼊⼒またはシステム連携によって 物件情報を管理システムに登録する 登録された物件情報を各種ポータルサイトの 仕様に沿ったデータ形式に変換する 物件情報がポータルサイトに掲載される AWS に移⾏中 • とあるクライアント様の⾃社ポータルサイトを AWS に移⾏しています
7. 現⾏サイト 新サイト とある不動産ポータルサイトのAWS移⾏を進めています 7 オンプレミス AWS 仮想サーバー コンテナ (ECS on Fargate) Java Node.js (Apollo) Java(JSP) Next.js プラットフォーム 実⾏環境 バックエンド フロントエンド • TypeScript ベースの構成に再構築
8. AWS アカウント全体構成 8 ここの話
9. ポータルサイトのインフラ構成 9 本番環境 開発・ステージング環境
10. ポータルサイトのインフラ構成 10 • 3つの ECS Service で成り⽴つ • 各 ECS Service の前段に ALB をはさむ • インフラコストは増えるが、Connection Draining など ALB の機能が使えるメリットを優先 Public subnet Private subnet ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server)
11. 私たちの開発スタイル・リリースプロセス • JIRA 起票 -> PRレビュー -> ステージング反映 -> 本番反映 の流れ • 環境とブランチは 1:1 対応 • feature︓チケットごとに作成。各⾃機能開発を⾏う • stg1 〜 5︓ステージング環境⽤ブランチ(数字つきstg) • 利⽤者調整なくステージング環境を利⽤できるようにするために存在 • 本番環境とのかい離はある程度あっても許容 • stg︓ステージング環境⽤ブランチ(無印stg) • リリース前の動作確認に使⽤ • リリース案件がない限り、原則 main (本番環境) と同期 • main︓本番環境⽤ブランチ 11
12. 現⾏デプロイ基盤が抱えていた課題 • オンプレミス上でも⾃動リリースは導⼊済 • リリースのたびに、数10秒程度のダウンタイムが発⽣ • 2021年実績だと、約700チケット / 年くらいリリース実施 • 700 チケット × 10 秒 = 7,000秒 = 116.7 分 のダウンタイムが発⽣する計算 • リリースすればするほどダウンタイムが増える構造をなんとかしたい 12 Blue / Green Deployment 導⼊を決意
13. こうして、新しいデプロイパイプラインが⽣まれました 13 feature/xxx feature/yyy feature/zzz Developer Developer Developer JIRA xxx JIRA yyy JIRA zzz create create create ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 stg merge ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) Front Service (Next.js) ALB API Service (Apollo Server) リリース main merge ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) Front Service (Next.js) ALB API Service (Apollo Server) リリース ステージング環境 本番環境 ブランチが削除されたら 環境をすべて削除 Blue / Green Deployment
14. 14 2. Blue Green Deployment 編
15. 実際のデプロイパイプライン • CircleCI でワークフローを定義 • CloudFormation + AWS CLI のみで必要な処理を実装 15 ALB 更新 • アプリケーションビルド • Unit Test 実⾏ • ECS Cluster 更新 • ECS Task Definition 更新 ECS Service 更新 • 疎通確認 • 環境切り替え 後処理(キャッシュパージ) • Slack通知 • E2Eテスト
16. ECSのデプロイ⽅式 • 待機系をすべて更新し、疎通確認OKであればALBの向き先を切り替える 16 Public subnet Private subnet ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) CloudFormation ①待機系の更新 Main Listener Test Listener ②疎通確認 ③切り替え
17. 17 2.1. 構築フェーズの振り返り
18. まずはとりうる構成パターンを整理 • 既存CI(CircleCI)との連携、マネージドの活⽤を念頭に構成を検討 18 No. 構成パターン 考えたこと 1 CodeDeploy(その他Codeシリーズ含む) • Codeシリーズを活⽤したマネージド構成 • https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userg uide/deployment-type-bluegreen.html • 役割分担次第ではあるが、⾒かけ上CI/CD 基 盤が重複するので、Codeシリーズがっつり 使ってしまって良いか悩んだ • マネージドであることは強⼒だが、逆に細 やかなカスタマイズがしづらい副作⽤はな いだろうか︖ 2 CloudFormation • CloudFormation から CodeDeploy の Blue / Green Deployment を実⾏ • https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/lat est/UserGuide/blue-green.html • 考慮事項が多く、時期尚早な印象を受けた • ネストスタック未サポート • Outputs の Import / Export 未サポート • Feature環境⾃動⽣成への流⽤を考えると、 スタック分割できないと環境のカスタマイ ズが必要になった際にしんどいかも 3 CircleCI(⾃前で頑張る) • CI 上に Blue / Green Deployment パイプラインを実装する • アプリケーションの CI/CD との連携が柔軟 • ⾃前実装なのでマネージドに⽐べると⼤変 • 要件に応じたカスタマイズがしやすい
19. 当初案: CircleCI + CloudFormation + CodeDeploy による B/G Deployment • CircleCI でデプロイパイプラインを構築 • 必要な AWS リソースは CloudFormation 経由でデプロイ • ECS の Blue / Green Deployment 部分のみ、CodeDeploy に任せる 19 ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) Front Service (Next.js) API Service (Apollo Server) CloudFormation ①リソースの初期構築は CloudFormation で実施 CodeDeploy CodeDeploy CodeDeploy ②CodeDeployで 切り替え ②CodeDeployで 切り替え ②CodeDeployで 切り替え
20. 実際にパイプラインを回して気づいた課題 • CodeDeploy でしかデプロイできない • ECS の仕様によるもの(デプロイタイプ=CodeDeploy) • 取り急ぎコンソールから設定を変えるといったことができない • 複数 ECS Service 間の整合性を本当に保つことができるか︖ • CodeDeploy によるデプロイ単位はあくまで ALB - ECS 1セットのみ • 複数サービスをデプロイしている場合、各サービス間の順序性や依存 性を考慮し、整合性を維持しながらデプロイする必要がある • 途中でデプロイ失敗したときはどうなる︖ 20
21. 開発も佳境に差し掛かっていたところでしたが… 21 パイプライン書き直し︕
22. 実際のデプロイパイプライン(再掲) 22 ALB 更新 • アプリケーションビルド • Unit Test 実⾏ • ECS Cluster 更新 • ECS Task Definition 更新 ECS Service 更新 • 疎通確認 • 環境切り替え 後処理(キャッシュクリア) • Slack通知 • E2Eテスト
23. ポイントその１︓依存関係のないジョブはなるべく並列で • 当たり前ですが、CI ツールの利点をなるべく活かす • ALB の更新や、ECS Cluster、ECS Task Definition の更新は並列 • ECS Service は、ALB、ECS Task Definition 更新完了後でなければ実⾏でき ないので、後続ステップとして定義 23
24. ポイントその２︓切り替え前に切り替え OK/NG 確認を⾏う • Webサービスとして正常に起動していない状 態でリリースされないように、環境を切り替 える前に最終確認を⾏う • テスト⽤のリスナー経由で以下を実施 • 確認⽤URL にアクセスする • 200 OK かつ レスポンス 1s 以下なら OK • 200 OK 以外 または レスポンス 10s以上なら NG • OK が 3回でジョブ成功 • NG が 3回でジョブ失敗(リリースされない) 24
25. ポイントその3︓毎回デプロイターゲットを確認する • ALB, ECS 更新ステップでは毎回デプ ロイ対象(Blue または Green)を確認 する • ジョブが途中で失敗した場合でも失 敗時点からリトライできるようにす る 25
26. 26 2.2. 運⽤フェーズの振り返り
27. 1 年間運⽤した実績︓よかったところ • 切り替え時のダウンタイムなし • Next.js のバージョンアップもダウンタイムなくリリースできた • Next.js 13もこの調⼦でアップデートするぞ︕ • Node.js のアップデート(Runtime, Library両⽅)も難なくできた • 切り戻しも⼀瞬でできる • ALB の向き先を変更するだけでOK • 1年間、本番リリース事故なし 27 リリースに対する⼼理的負荷がかなり減った
28. 1 年間運⽤した実績︓今後の課題 • インフラコスト • 常に 2 ⾯保持するため、当然 1⾯ よりコストはかかってしまう • ビルド時間が⻑い( CI コスト) • 15分 〜 18分くらいを推移 • 継続的に速度改善をしていきたい • CloudFormation のデプロイ完了前に CircleCI のジョブがタイムア ウトすることがある 28
29. (余談) Datadog のダッシュボード 29
30. 30 3. Feature 環境⾃動⽣成 編
31. Branch ⽣成をトリガーにテスト環境を⾃動構築 • Blue / Green Deployment で作成した CloudFormation を流⽤ • パラメータだけ変えれば動くようにしている 31 Public subnet Private subnet ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) CloudFormation
32. Feature 環境⾃動⽣成パイプライン • Blue / Green Deployment ワークフローとほぼ同じ • CDN のキャッシュパージ処理は不要のため、削除している 32
33. テスト環境は社内コンソールからアクセス • 社内⽤コンソールを⽤意 • 稼働確認⽤URL • Datadog ログ • ECS Exec コマンド • GraphQL コンソール • ALB DNS名 33
34. ブランチが削除されたら、テスト環境も削除する • ブランチ削除トリガーで構 築したテスト環境を削除 • GitHub Actions で実施 • 以下のリソースを削除 • ECS Service • ECS Task Definition • ECS Cluster • ECR • CloudWatch Logs • ALB 34
35. 35 3.1. 構築フェーズの振り返り
36. Prefix を⽣成して AWS リソースの⽂字数制限を回避 • ALB の名前は最⼤32⽂字まで • ブランチ名やコミットハッシュを素直に⼊れられない • Prefix ⽣成処理を追加して⽂字数制限を回避 36 f [JIRA チケットNo.] - [ブランチ名のハッシュ先頭4⽂字] feature の「f」
37. CloudFormation は Condition で環境差分をコントロール • Feature 環境⽤の設定は CloudFormation の Condition で制御 • テンプレートを分けることもできるが、どの環境もなるべく同じテンプ レートから⽣成できることを優先 37
38. 38 3.2. 運⽤フェーズの振り返り
39. Dependabot 対応をあとから実施 • Dependabot が⽣成するブランチを考慮できていなかった • あとで Dependabot 対応を実施 • Dependabot や renovate などが⽣成するブランチについても、最初から⾒越 して Prefix ⽣成処理を実装しておいた⽅がよかった 39 dep - [ブランチ名のハッシュ先頭4⽂字] dependabot の「dep」
40. VPC の CIDR が枯渇 • ALB をはさむ構成にしたため、CIDR 消費が激しい • ALB 1つにつき 8 IP を消費 • 1 環境構築すると、ALB × 3、ECS Service × 3 = 27 IP 消費 • 当初 /23 (IP数:512) で VPC を構築してしまったため、IP 枯渇が頻発 • 結局 VPC ごと再構築し、/20 (IP数: 4,096) に拡張 • VPC 再構築と同時に ALB 上限数も 50 から 200 に拡張 40
41. コストの問題 41 予算作成時 いま
42. ⽌まらない円安
43. コスト削減策その１︓Feature は⽚⾯構成かつ最低スペックに • 最初は、Feature 環境も Blue / Green 両⾯構成 • コスト削減、リソース消費の抑制のため最⼩構成に変更 43 Public subnet Private subnet ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) CloudFormation
44. コスト削減策その２︓週末お掃除ジョブ追加 • 毎週⼟曜⽇に、すべての Feature 環境を削除するジョブを追加 • リソース削除には aws-nuke (https://github.com/rebuy-de/aws-nuke) を使⽤ • CircleCI のジョブをリランすることで、環境を復元 44
45. 45 まとめ
46. Blue / Green Deployment , Feature 環境⾃動⽣成パイプラインを紹介 46 feature/xxx feature/yyy feature/zzz Developer Developer Developer JIRA xxx JIRA yyy JIRA zzz create create create ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) 環境構築 stg merge ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) Front Service (Next.js) ALB API Service (Apollo Server) リリース main merge ALB Proxy Service (Nginx) ALB Front Service (Next.js) ALB API Service (Apollo Server) Proxy Service (Nginx) Front Service (Next.js) ALB API Service (Apollo Server) リリース ステージング環境 本番環境 ブランチが削除されたら 環境をすべて削除 Blue / Green Deployment Feature 環境⾃動⽣成 Blue / Green Deployment
47. 本セッション全体をとおしてのポイント • シンプルな切り替え⽅式 • 待機系の環境をすべて更新してから、先頭のALBの向き先だけ変える • 技術的な取り⼊れやすさ • 今回は、CircleCI + CloudFormation + AWS CLI で実装 • 何らかのCI ツール + 何らかの IaC ツール + CLI があれば基本導⼊できるはず • ⾃前実装なので労⼒はそれなりにかかったが、それに⾒合う恩恵を受けている • ただし、コスト抑制やビルド速度抑制を継続的に⾏わないと従量課⾦が… 47
48. ⼤切な基盤は⾃分たちで管理・運⽤する覚悟をもって愚直にやる • スピーディかつ安定したリリース基盤 = 成果に結びつく基盤 • 成果 =安定的にたくさんリリースすることで事業の成⻑をもたらす • CI/CD基盤はそういう意味合いで⾮常に⼤切な基盤だと考えています • 難しいことをしているわけではないですが、たくさんのマネージドサービ スがある中で、あえて⾃前実装を選択しました 48 ⾃分たちで正解を探しながら 今後も運⽤していきます︕
49. END OF PRESENTATION ご清聴ありがとうございました