デプロイメント手法を選択する/Decide the way of deployment

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. デプロイ戦略
   Progressive Delivery
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. Flagger vs Argo Rollouts
    

    View Slide

13. 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
    

    View Slide

14. 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
    

    View Slide

15. 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
    

    View Slide

16. 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
    

    View Slide

17. 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
    

    View Slide

18. Cases
    

    View Slide

19. 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
    

    View Slide

20. 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
    

    View Slide

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

    View Slide

22. 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
    

    View Slide

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

    View Slide

24. Demonstration !!
    

    View Slide

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

    View Slide

26. Tips
    

    View Slide

27. 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がそんなに安定しているものがあればという部分があります。
    

    View Slide

28. Thank you for listening !!
    

    View Slide