Hiroki Matsumoto デプロイメント手法を選択する ~ Flagger/Argo Rollouts~

Title Name 松本 宏紀 ( まつもと ひろき ) ● Application Engineer ● 2020年3月 楽天株式会社入社。 Platformとなるサービス群の開発・運用を担当。 ● 2020年12月 Passenger Go ExporterをOSSとして公開。 ● 前職は、自動車業界における業務システムの開発・運用を担当。 ● GKE + Java → Ruby + PHP + golang + Kubernetes ( Azure, 社内クラスタ) Twitter：@hirokimatsumo13 自己紹介

Title Name CNCF × 楽天 https://www.cncf.io/about/members/

Title Name お話すること どうやってデプロイすればいいんだろう？ 品質保証の観点や、政治的な色々なあれこれでリリースプロセスをなかなか変えれない。けれどもエンジニアからはコストがかかる リリースプロセスで不満の声が聞こえてくる。 そんなことを悩んでいるあなたに、今どんなやり方でデプロイが可能なのか？というのをお話します。 今デプロイが手動で行われている人、もっと改善したいけど出来るかどうかよくわかっていないという人のお力になれればと思ってい ます。

Title Name 1.デプロイ戦略　Progressive Delivery 2.デプロイ戦術 3.Flagger vs Argo Rollouts 4.ケース 5.Tips 目次

デプロイ戦略 Progressive Delivery

Title Name Progressive Delivery デプロイメント戦略の方法論 CD(Continuous Delivery)の次のステップ。 新しいバージョンをデプロイする際、一部のユーザーにロールアウトを行い、性能、正確性等の観点から評価を 行い、問題があればロールバックします。 Progressive Deliveryには、下記のデプロイメント手法が含まれています。 ● Canary Release ● A/B/ Testing ● Blue/Green 負荷がいきなり急上昇し、システム全体が停止してしまうリスクを防ぎます。 Development Feature Tests Release Stress Test

Title Name トラフィック 制御 How to achieve it ? 観測 手順

Title Name How to achieve it ? Istio Linkerd Nginx Ingress Prometheus トラフィック 制御 観測 手順 Flagger Argo Rollouts

Title Name Deployment Strategies ある程度は自動化できるけれども、 完全には自動化できない現実。

Title Name Deployment Strategies a) 通常リリース。Hot Fix ( Bug, Security ) 頻度： 数回/月 Canaryしたい。すごい楽したい。その都度監視したくない。 b) エラーバジェット使い果たした悲しいとき 頻度：恐らく無い 開発者でテストを行った後、 Blue/Green or Canary したい。 c) 破壊的変更が発生したメジャーリリース 頻度： 1回/数年 開発者は新バージョン、ユーザーはメンテナンス画面となるようにしたい。 ( Blue/Green, A/B Testing ) 一般的にエラーバジェットが無い (≒管理していない)場合、確実なテストによる品質保証が求められ ることが多いと思います。 他にもシステム間連携がある場合においても e2eテストが難しい場合があります。

Flagger vs Argo Rollouts

Title Name Flagger with Istio Flagger Canary app Service app-canary Service Mesh or Ingress Deployment app-canary Deployment app Service app-primary Deployment app-primary Istio reference, replicas=0 mange gateway Virtual Service app Metric Provider control change weight check metrics

Title Name Argo Rollouts with Istio Argo Rollouts Rollouts app Service app-canary Service Mesh or Ingress ReplicaSet app-canary Service app-primary ReplicaSet app-primary Istio mange gateway Virtual Service app Metric Provider control change weight change selector

Title Name Canary Workflow: Flagger with Istio Virtual Service app weightによるtrafficのコントロール Rolling Upgrade Deployment app Primary: 100 Canary: 0 Primary: v1 Canary: none Primary: 50 Canary: 50 Primary: v1 Canary: v2 Primary: 100 - (max weight ) Canary: max weight Primary: v1 → v2 Canary: v2 Primary:100 Canary: 0 Primary: v2 Canary: none 1 2 3 4 5 6

Title Name Argo Rollouts Workflow with Istio Service app-primary selectorによる切り替え Primary: hash=v1 Canary: hash=v1 Primary: hash=v1 Canary: hash=v2 Primary: hash=v2 Canary: hash=v2 Virtual Service app weightによるtrafficのコントロール Primary: 100 Canary: 0 Primary: 50 Canary: 50 Primary: 100 Canary: 2 4 1 3

Title Name 簡易比較 ( Delivery ) どこまで制御できるか？は、利用している Service Mesh,Ingressに依存します。 よくドキュメントを確認しておく必要があります。 https://github.com/fluxcd/flagger#features https://argoproj.github.io/argo-rollouts/features/traffic-management/ Flagger Argo Rollouts Note Deployment: Canary ✔ ✔ Deployment: Blue/Green ✔ ✔ Deployment: A/B Testing ✔ ✔ Manual Abort ✔ ✔ Manual Approval ✔ ✔ UI ( CLI ) ✔ Notification ✔ argoproj/argo-rollouts/issues#369

Cases

Title Name Canary with Flagger Canaryしたい。すごい楽したい。その都度監視したくない。 pre-rollout,rollout部分で独自のテストを実行することが可能です。 Argo Rolloutsであれば、適宜pauseをかけて自由にテストはできます。 https://docs.flagger.app/usage/webhooks Primary:100 Canary: 0 Webhook: confirm-rollout pre-rollout Primary:-weight Canary: +weight Webhook: rollout (* N ) Primary:0 Canary: 100 Webhook: confirm-promotion Primary:100 Canary: 0 Webhook: post-rollout

Title Name Release After Manual Test with Flagger 開発者でテストを行った後、 Blue/Green or Canary したい。 User Primary : v1 Canary : v2 Developer Canary前にテストを実施することは Flagggerの機能としては提供されていません。 アプリケーション側の対応 ( CanaryへのトラフィックはHTTPヘッダで制御など)が必要となります。 Webhook: confirm-promotion Canary : v2 Waiting for approval User Developer Custom HTTP Header

Title Name Maintenance Window with Flagger 開発者は新バージョン、ユーザーはメンテナンス画面となるようにしたい。 今までのリリース方法の組み合わせで実現できます。 1. メンテナンス画面をBlue/Greenでリリースします。 ( 全ユーザーがメンテナンス画面 ) 2. Blue/Green ( A/B Testing)で新バージョンをリリースします。

Title Name Manual Rollback with Flagger メトリクスだけでは判断できない部分があるのでロールバックも行えるようにしておきたい。 User Primary : v1 Canary : v2 Developer Webhook: rollback confirm-promotion Canary : v2 Waiting for approval User Developer Custom HTTP Header

Title Name Traffic Mirroring with Flagger 新しいバージョンに対して裏側でユーザートラフィックを流して挙動を確認したい。 ※ DB移行時など。 Primary:v1 Canary:v2 Virtual Service app XX % Mirroring

Demonstration !!

Title Name Demonstration https://github.com/h-r-k-matsumoto/progressive-delivery.git

Tips

Title Name Flaggerのloadtesterで全て事足りる？ おそらく運用は難しいです。 /gate/機能も、open/close状態を保持するため、リリースする度にリセットさせなくてはならない。CD側の仕組みで事前にPOST するなどの考慮は必要です。 Tips 安定してる？ バージョンアップで動かなくなることはある。でも修正できると思います。 ● https://github.com/fluxcd/flagger/pull/781 ● https://github.com/fluxcd/flagger/pull/777 Progressive Deliveryをするべき？ 安定しているシステムなら、導入しない方がコストパフォーマンスは良いかもしれないです。 ただ、利用しているライブラリ、言語、Frameworkがそんなに安定しているものがあればという部分があります。

Thank you for listening !!