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

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

Transcript

1. Feature 環境の⾃動⽣成と
   Blue Green Deployment で効率的かつ
   安全なリリースプロセスを構築
   2022/11/01 CloudNative Days Tokyo 2022 プレイベント
   

   View Slide

2. ⾃⼰紹介
   猪熊 朔也 ( いのくま さくや ) / @sinocloudon
   - 株式会社 Red Frasco
   - インフラエンジニア
   u経歴
   ⾦融系SIer -> リクルート -> ⾦融系スタートアップ -> Red Frasco
   uその他コメント
   - うどんが好きです
   - ラーメン⼆郎が好きです
   - うどん脳 をプロフィールアイコンにすることが多いです
   - 最初4年くらいは Java エンジニア
   - ここ5年くらいはインフラ・クラウド⼀⾊
   2
   

   View Slide

3. はじめに
   • AWS 上にデプロイしたコンテナの CI/CD に関するお話です
   • ALB / ECS / Fargate / CloudFormation / AWS CLI あたりが主に登場します
   • 各サービスに関する詳細な説明は割愛しますのでご了承ください
   • CI/CD ツールには CircleCI を採⽤しています
   • ただし、CircleCI の特定の機能に依存した仕組みではありません
   • 他ツールを使⽤されている場合は、適宜読み替えながらご参考いただ
   ければと思います
   3
   

   View Slide

4. ⽬次
   1. はじめに
   2. Blue Green Deployment 編
   3. Feature 環境⾃動⽣成 編
   4. まとめ
   

   View Slide

5. 5
   1. はじめに
   

   View Slide

6. とある不動産ポータルサイトのAWS移⾏を進めています
   6
   【物件情報がポータルサイトに掲載されるまでの流れ】
   不動産会社
   担当者
   物件情報⼊⼒ 物件情報変換 物件情報表⽰
   物件管理
   システム
   データ
   連動
   物件データ
   画像データ
   他システム 物件データ
   画像データ
   ⼿⼊⼒
   コンバータ
   各種ポータルサイト
   データ
   連動
   デ
   ー
   タ
   連
   動
   ⾃社ポータル
   総合ポータル S
   総合ポータル H
   総合ポータル A
   データ
   連動
   データ
   連動
   データ
   連動
   カスタマー
   物件探し
   ⼿⼊⼒またはシステム連携によって
   物件情報を管理システムに登録する
   登録された物件情報を各種ポータルサイトの
   仕様に沿ったデータ形式に変換する
   物件情報がポータルサイトに掲載される
   AWS に移⾏中
   • とあるクライアント様の⾃社ポータルサイトを AWS に移⾏しています
   

   View Slide

7. 現⾏サイト 新サイト
   とある不動産ポータルサイトのAWS移⾏を進めています
   7
   オンプレミス AWS
   仮想サーバー コンテナ (ECS on Fargate)
   Java Node.js (Apollo)
   Java(JSP) Next.js
   プラットフォーム
   実⾏環境
   バックエンド
   フロントエンド
   • TypeScript ベースの構成に再構築
   

   View Slide

8. AWS アカウント全体構成
   8
   ここの話
   

   View Slide

9. ポータルサイトのインフラ構成
   9
   本番環境 開発・ステージング環境
   

   View Slide

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)
    

    View Slide

11. 私たちの開発スタイル・リリースプロセス
    • JIRA 起票 -> PRレビュー -> ステージング反映 -> 本番反映 の流れ
    • 環境とブランチは 1:1 対応
    • feature︓チケットごとに作成。各⾃機能開発を⾏う
    • stg1 〜 5︓ステージング環境⽤ブランチ(数字つきstg)
    • 利⽤者調整なくステージング環境を利⽤できるようにするために存在
    • 本番環境とのかい離はある程度あっても許容
    • stg︓ステージング環境⽤ブランチ(無印stg)
    • リリース前の動作確認に使⽤
    • リリース案件がない限り、原則 main (本番環境) と同期
    • main︓本番環境⽤ブランチ
    11
    

    View Slide

12. 現⾏デプロイ基盤が抱えていた課題
    • オンプレミス上でも⾃動リリースは導⼊済
    • リリースのたびに、数10秒程度のダウンタイムが発⽣
    • 2021年実績だと、約700チケット / 年くらいリリース実施
    • 700 チケット × 10 秒 = 7,000秒 = 116.7 分 のダウンタイムが発⽣する計算
    • リリースすればするほどダウンタイムが増える構造をなんとかしたい
    12
    Blue / Green Deployment 導⼊を決意
    

    View Slide

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
    

    View Slide

14. 14
    2. Blue Green Deployment 編
    

    View Slide

15. 実際のデプロイパイプライン
    • CircleCI でワークフローを定義
    • CloudFormation + AWS CLI のみで必要な処理を実装
    15
    ALB 更新
    • アプリケーションビルド
    • Unit Test 実⾏
    • ECS Cluster 更新
    • ECS Task Definition 更新
    ECS Service 更新
    • 疎通確認
    • 環境切り替え
    後処理(キャッシュパージ)
    • Slack通知
    • E2Eテスト
    

    View Slide

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
    ②疎通確認
    ③切り替え
    

    View Slide

17. 17
    2.1. 構築フェーズの振り返り
    

    View Slide

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 との連携が柔軟
    • ⾃前実装なのでマネージドに⽐べると⼤変
    • 要件に応じたカスタマイズがしやすい
    

    View Slide

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で
    切り替え
    

    View Slide

20. 実際にパイプラインを回して気づいた課題
    • CodeDeploy でしかデプロイできない
    • ECS の仕様によるもの(デプロイタイプ=CodeDeploy)
    • 取り急ぎコンソールから設定を変えるといったことができない
    • 複数 ECS Service 間の整合性を本当に保つことができるか︖
    • CodeDeploy によるデプロイ単位はあくまで ALB - ECS 1セットのみ
    • 複数サービスをデプロイしている場合、各サービス間の順序性や依存
    性を考慮し、整合性を維持しながらデプロイする必要がある
    • 途中でデプロイ失敗したときはどうなる︖
    20
    

    View Slide

21. 開発も佳境に差し掛かっていたところでしたが…
    21
    パイプライン書き直し︕
    

    View Slide

22. 実際のデプロイパイプライン(再掲)
    22
    ALB 更新
    • アプリケーションビルド
    • Unit Test 実⾏
    • ECS Cluster 更新
    • ECS Task Definition 更新
    ECS Service 更新
    • 疎通確認
    • 環境切り替え
    後処理(キャッシュクリア)
    • Slack通知
    • E2Eテスト
    

    View Slide

23. ポイントその１︓依存関係のないジョブはなるべく並列で
    • 当たり前ですが、CI ツールの利点をなるべく活かす
    • ALB の更新や、ECS Cluster、ECS Task Definition の更新は並列
    • ECS Service は、ALB、ECS Task Definition 更新完了後でなければ実⾏でき
    ないので、後続ステップとして定義
    23
    

    View Slide

24. ポイントその２︓切り替え前に切り替え OK/NG 確認を⾏う
    • Webサービスとして正常に起動していない状
    態でリリースされないように、環境を切り替
    える前に最終確認を⾏う
    • テスト⽤のリスナー経由で以下を実施
    • 確認⽤URL にアクセスする
    • 200 OK かつ レスポンス 1s 以下なら OK
    • 200 OK 以外 または レスポンス 10s以上なら NG
    • OK が 3回でジョブ成功
    • NG が 3回でジョブ失敗(リリースされない)
    24
    

    View Slide

25. ポイントその3︓毎回デプロイターゲットを確認する
    • ALB, ECS 更新ステップでは毎回デプ
    ロイ対象(Blue または Green)を確認
    する
    • ジョブが途中で失敗した場合でも失
    敗時点からリトライできるようにす
    る
    25
    

    View Slide

26. 26
    2.2. 運⽤フェーズの振り返り
    

    View Slide

27. 1 年間運⽤した実績︓よかったところ
    • 切り替え時のダウンタイムなし
    • Next.js のバージョンアップもダウンタイムなくリリースできた
    • Next.js 13もこの調⼦でアップデートするぞ︕
    • Node.js のアップデート(Runtime, Library両⽅)も難なくできた
    • 切り戻しも⼀瞬でできる
    • ALB の向き先を変更するだけでOK
    • 1年間、本番リリース事故なし
    27
    リリースに対する⼼理的負荷がかなり減った
    

    View Slide

28. 1 年間運⽤した実績︓今後の課題
    • インフラコスト
    • 常に 2 ⾯保持するため、当然 1⾯ よりコストはかかってしまう
    • ビルド時間が⻑い( CI コスト)
    • 15分 〜 18分くらいを推移
    • 継続的に速度改善をしていきたい
    • CloudFormation のデプロイ完了前に CircleCI のジョブがタイムア
    ウトすることがある
    28
    

    View Slide

29. (余談) Datadog のダッシュボード
    29
    

    View Slide

30. 30
    3. Feature 環境⾃動⽣成 編
    

    View Slide

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
    

    View Slide

32. Feature 環境⾃動⽣成パイプライン
    • Blue / Green Deployment ワークフローとほぼ同じ
    • CDN のキャッシュパージ処理は不要のため、削除している
    32
    

    View Slide

33. テスト環境は社内コンソールからアクセス
    • 社内⽤コンソールを⽤意
    • 稼働確認⽤URL
    • Datadog ログ
    • ECS Exec コマンド
    • GraphQL コンソール
    • ALB DNS名
    33
    

    View Slide

34. ブランチが削除されたら、テスト環境も削除する
    • ブランチ削除トリガーで構
    築したテスト環境を削除
    • GitHub Actions で実施
    • 以下のリソースを削除
    • ECS Service
    • ECS Task Definition
    • ECS Cluster
    • ECR
    • CloudWatch Logs
    • ALB
    34
    

    View Slide

35. 35
    3.1. 構築フェーズの振り返り
    

    View Slide

36. Prefix を⽣成して AWS リソースの⽂字数制限を回避
    • ALB の名前は最⼤32⽂字まで
    • ブランチ名やコミットハッシュを素直に⼊れられない
    • Prefix ⽣成処理を追加して⽂字数制限を回避
    36
    f [JIRA チケットNo.] - [ブランチ名のハッシュ先頭4⽂字]
    feature の「f」
    

    View Slide

37. CloudFormation は Condition で環境差分をコントロール
    • Feature 環境⽤の設定は CloudFormation の Condition で制御
    • テンプレートを分けることもできるが、どの環境もなるべく同じテンプ
    レートから⽣成できることを優先
    37
    

    View Slide

38. 38
    3.2. 運⽤フェーズの振り返り
    

    View Slide

39. Dependabot 対応をあとから実施
    • Dependabot が⽣成するブランチを考慮できていなかった
    • あとで Dependabot 対応を実施
    • Dependabot や renovate などが⽣成するブランチについても、最初から⾒越
    して Prefix ⽣成処理を実装しておいた⽅がよかった
    39
    dep - [ブランチ名のハッシュ先頭4⽂字]
    dependabot の「dep」
    

    View Slide

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
    

    View Slide

41. コストの問題
    41
    予算作成時
    いま
    

    View Slide

42. ⽌まらない円安
    

    View Slide

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
    

    View Slide

44. コスト削減策その２︓週末お掃除ジョブ追加
    • 毎週⼟曜⽇に、すべての Feature 環境を削除するジョブを追加
    • リソース削除には aws-nuke (https://github.com/rebuy-de/aws-nuke) を使⽤
    • CircleCI のジョブをリランすることで、環境を復元
    44
    

    View Slide

45. 45
    まとめ
    

    View Slide

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
    

    View Slide

47. 本セッション全体をとおしてのポイント
    • シンプルな切り替え⽅式
    • 待機系の環境をすべて更新してから、先頭のALBの向き先だけ変える
    • 技術的な取り⼊れやすさ
    • 今回は、CircleCI + CloudFormation + AWS CLI で実装
    • 何らかのCI ツール + 何らかの IaC ツール + CLI があれば基本導⼊できるはず
    • ⾃前実装なので労⼒はそれなりにかかったが、それに⾒合う恩恵を受けている
    • ただし、コスト抑制やビルド速度抑制を継続的に⾏わないと従量課⾦が…
    47
    

    View Slide

48. ⼤切な基盤は⾃分たちで管理・運⽤する覚悟をもって愚直にやる
    • スピーディかつ安定したリリース基盤 = 成果に結びつく基盤
    • 成果 =安定的にたくさんリリースすることで事業の成⻑をもたらす
    • CI/CD基盤はそういう意味合いで⾮常に⼤切な基盤だと考えています
    • 難しいことをしているわけではないですが、たくさんのマネージドサービ
    スがある中で、あえて⾃前実装を選択しました
    48
    ⾃分たちで正解を探しながら
    今後も運⽤していきます︕
    

    View Slide

49. END OF
    PRESENTATION
    ご清聴ありがとうございました
    

    View Slide