Spinnaker で Blue-Green Deployment やってみた

NTT Engineer Festa #3 の発表資料です。一般公開のために一部編集してアップロードしてあります。

Transcript

1. Spinnaker で Blue-Green Deployment やってみた 北澤 祥太 (@kanatakita) 1 2019/09/18
2. 自己紹介 北澤 祥太 Twitter: かなた (@kanatakita) 所属: ICTインフラサービス部 クラウドサービス部門 (旧 NTTコミュニケーションズ クラウドサービス部) 自社クラウドサービスの SRE をするチームに配属された新卒1年目 現在 SRE のための基盤の検証/構築をやっています 趣味: ラーメン・スノボ・自宅鯖構築 学生の頃 ISUCON や ICTSC に参加してました 2
3. Contents 01 02 背景と取り組み これまでの ECL と SRE チームの取り組み 3 03 デプロイ戦略と その実現 Spinnaker を用いた Blue-Green Deployment さらなる改善 (WIP) デプロイフローの改善
4. 背景と取り組み 4
5. Enterprise Cloud (ECL) 　エンタープライズ向けのクラウドサービス基盤を10 拠点で提供中 5
6. ECL のアーキテクチャ 6 仮想サーバ 共通機能(契約管理・認証機能・課金など) ベアメタル サーバ ネットワーク モニタリング リソース・ コントローラ コンピューティング (仮想サーバ) ストレージ ネットワーク コンピューティング (ベアメタル) モニタリング (リソースなど) モニタリング (監査ログなど) ユーザから見た 機能･サービス 共通機能 コンポーネント化 されたソフトウェア群 リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ ... 各コンポーネントはAPIで連携 ➢ コンポーネント単位に別れたチームでの開発
7. • リリース効率に課題感 ◦ 一貫したリリース工程が存在しない ▪ リリースまでの品質を各チームが担保する必要性 ◦ プロセスの遷移に人の判断が介入 ▪ 人がボトルネック サービス開発の課題 7 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了
8. 課題へのアプローチ • SRE (Site Reliability Engineering) チームを結成 ◦ 品質を維持しつつ高速なリリースサイクルを実現 • 一部機能を共通化した基盤 (SRE基盤) を構築/運用 ◦ 最小限の設定でリリースプロセスを定義 ◦ 人の介入を最小限に 8 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 開発 単体試験 開発 共通化
9. SRE 基盤 • Google Cloud Platform を利用した基盤を構築 ◦ アプリケーションの動作環境に GKE を利用 ▪ アプリケーションの環境依存をコンテナに閉じ込める ◦ ステート管理 (例. Database) にマネージドサービスを利用 ▪ 運用コストの減少 ◦ 共通利用可能な CI/CD 基盤を提供 ▪ リリースまでの工程を自動化して品質を担保 • 本日の話: 上記の CI/CD 基盤 9
10. CI/CD 基盤の共通化 • 共通利用可能な CI/CD 基盤の提供 ◦ GitHub への Push をトリガーに CI/CD が動作 10 Cloud Source Repositories Cloud Build Container Registry Spinnaker Kubernetes Engine Jenkins Postman GitHub Code Push Sync Deploy/ Rollback Scenario Test Kick Test Return Result Call Test Return Result Developer Blue-Green Deployment によるソフトウェアのリリース
11. デプロイ戦略とその実現 11
12. デプロイ戦略の種類 • Rolling ◦ サービス断無しに Pod を徐々に新バージョンに上げていく ▪ Kubernetes の Deployment リソースの標準動作 • Blue-Green (Red-Black) ◦ 新バージョンの Pod を全て配置した後トラフィックを切り替える ◦ リリース前に本番環境でアプリケーション動作のテストが可能 • Canary ◦ n%のトラフィックだけ新バージョンに流す ◦ 実際のトラフィックを利用した新バージョンのテストが可能 12
13. Blue-Green Deployment の採用 • 採用理由 ◦ 環境固有のバグをリリース前に発見可能 ▪ 例. ある環境にのみ存在するといった差異に起因する問題 ◦ SLI (サービスレベル指標) の測定が出来ていないため ▪ Canary する場合エラーバジェットを事前に決める必要がある • 以下のソフトウェアで実現 ◦ Jenkins: CI ツール ◦ Postman: 正常性確認 (Jenkinsより実行) ◦ Spinnaker: CD ツール 13 Spinnaker Kubernetes Engine Jenkins Postman Deploy/ Rollback Scenario Test Kick Test Return Result Call Test Return Result
14. Spinnaker • Continuous Delivery を実現するソフトウェア ◦ ステージングへのリリース及び統合テストの自動化 • Netflix 製, 2015年に OSS 化 • マルチクラウド (provider) に対応 ◦ Kubernetes, DC/OS, Google Compute Engine, etc… • デプロイフローを Pipeline の各 Stage で定義 14 Stage Pipeline
15. Spinnaker: Kubernetes V2 provider • マニフェストファイルベースでKubernetesへのCDを実現 • SpinnakerにRSの世代管理機能 (Deployment相当) を委任 ◦ Pod.metadata.labels を動的に変更しトラフィックを切り替える ▪ Spinnaker の RS デプロイステージにて Service を指定 ➢ Rolling 以外のデプロイ戦略を取れる 15
16. デプロイフロー 全体図 16 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic switch call test return result GitHub manifest.yaml trigger refer
17. 17 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic switch 新規コンテナイメージの push をトリガーに動作 call test return result Configure Stage GitHub manifest.yaml trigger
18. 18 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine call test return result deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic switch テスト用に新規Podをデプロイ Deploy Stage GitHub manifest.yaml trigger refer
19. 19 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy User Cloud Load Balancing Active Pod Standby Pod user traffic switch call test return result Jenkins Job を Kick Test Stage test traffic テスト用 Pod へ Postman を用いた統合テスト GitHub manifest.yaml trigger refer
20. 20 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod user traffic switch call test return result Standby Pod テスト用 Pod を 本番用 Pod へ昇格 Enable Stage (test == True) テストが正常終了 GitHub manifest.yaml trigger refer
21. 21 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic call test return result Delete Stage (test == False) テスト用 Pod を削除 本番用 Pod は影響なし テストが異常終了 GitHub manifest.yaml trigger refer
22. デモ (発表時には動画が流れました) 22
23. デプロイフロー 全体図 23 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic switch call test return result GitHub manifest.yaml refer trigger
24. このデプロイフローを Spinnaker Pipeline 化 24
25. 25 RSは単体でのみ デプロイ (Spinnakerの制約) デプロイ初回と2回目以 降でフローが異なる RSを本番用に 公開 (初回のみ) Artifact (外部リソース) の設定 Spinnaker Pipeline (1/2) GSLBの設定反映まで待ち
26. 26 全削除 (初回のみ) Jenkinsによる 正常性確認 正常性確認後 RS を本番用に公開 旧 RS を削除 テスト用 Service リソースの削除 Spinnaker Pipeline (2/2)
27. 完成はしたが・・・ • Pipeline が長い場合の考慮点 ◦ 潜在的なバグを含みやすい ◦ 把握すべきことが過度に多い ◦ パイプライン実行時間が長い 27
28. Pipeline がバグる一例 1. 構文エラーのある RS マニフェストをArtifactとして参照 2. RS のデプロイに失敗 ◦ 本番環境 : 旧RSが動作 ◦ テスト環境 : 対象RSなし 3. 統合テストに失敗 4. Spinnaker が 「一番新しくデプロイしたRSを削除」する ⇒ 本番環境の旧 RS が削除される ◦ 削除の指定方法は Spinnaker の制約 • 他にも様々な要因で Pipeline が壊れうる 28
29. パイプラインの正常性担保 • Pipeline をテストする Pipeline を実装 ◦ 以下の9通りのテストケースを用意 ▪ Pipeline 終了時に本番用 Pod が意図したバージョンであるか assertion • 以下の都度に実行し Pipeline が正常動作することを担保 ◦ パイプライン変更時 ◦ Spinnaker バージョンアップ時 29 Deploy出来ないエラー Deploy出来るエラー 正常 ReplicaSet 構文エラー PodがCrashLoopBackOff - Service 構文エラー namespaceを間違える -
30. ここまでのまとめ • SRE: 品質を維持しつつ高速なリリースサイクルを実現 • 本番環境での正常性確認からリリースまでを自動化 ◦ Spinnaker を用いた Blue-Green Deployment • リリース用 Pipeline の正常性を担保 ◦ Pipeline をテストする Pipeline を実装 30
31. さらなる改善 (Work In Progress) 31
32. でもパイプライン長い辛い 32
33. 完成はしたが・・・ • Pipeline が長い場合の考慮点 ◦ 潜在的なバグを含みやすい ▪ テストで正常性を担保 ◦ 把握すべきことが過度に多い ◦ パイプライン実行時間が長い やっぱり長いのやめたい 33
35. Argo Rollouts • Rollouts カスタムリソースを提供 ◦ 以下のデプロイ戦略を定義可能 ▪ Blue-Green ▪ Canary ◦ デプロイ戦略以外は Deployment リソースのように扱える 35 apiVersion: argoproj.io/v1alpha1 kind: Rollout … spec: strategy: blueGreen: … manifest.yaml
36. Argo Rollouts (Blue-Green) 36 • Argo Rolloutコントローラが以下を管理してトラフィックを切り替える ◦ Pod.metadata.labels ◦ Service.spec.selector • Rollout リソースを更新すると、旧 RS と新 RS がクラスタ上に存在 ◦ spec.paused: false によりトラフィック切替と旧リソース削除が走る ▪ kubectl patch コマンドを one-shot すれば良い ◦ 新旧 RS が存在したまま再度 Rollout リソースを更新すると 新 RS が置き換わる形でデプロイされる
37. 新 デプロイフロー 全体図 37 Container Registry Postman (Newman) Spinnaker Jenkins Kubernetes Engine deploy test traffic User Cloud Load Balancing Active Pod Standby Pod user traffic switch バージョン管理を委任 Rollout リソースを 適用するだけ call test return result trigger GitHub manifest.yaml refer
38. 38 新 Spinnaker Pipeline Artifact (外部リソース) の設定 全リソースのデプロイ GSLBの設定反映まで待ち Jenkinsによる 正常性確認 トラフィック切り替え用の K8s Job をデプロイ
39. 新 Spinnaker Pipeline 利点 • ステージ数: 33 → 9 ◦ 可読性の向上 • 実行時間: 10 min → 8 min (内 Wait 5 min, Test 1 min) ◦ リリース効率の向上 39
40. 新 Spinnaker Pipeline 課題点 • patch job 用にそこそこ強い権限が必要 ◦ Rollout への ["list", "patch"] • リソースを余分に使用する ◦ テストに失敗しても新バージョンのPodが残り続けるため • Rollout に対する HPA の動作未検証 40
41. まとめ • SRE: 品質を維持しつつ高速なリリースサイクルを実現 • 本番環境での正常性確認からリリースまでを自動化 ◦ Spinnaker を用いた Blue-Green Deployment • リリース用 Pipeline の正常性を担保 ◦ Pipeline をテストする Pipeline を実装 • Argo Rollouts を使うと Pipeline をいい感じにできそうなので検証中！ 41
42. Thank you ! 42