Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 / SRE NEXT 2020

Transcript

1. SRE NEXT [D5] Blue-Green デプロイメントを採用したデプロイ の仕組みを実装して共通基盤として導入した話 NTT Ltd. Group 森垣 航太
2. 自己紹介 森垣航太 所属: NTT Ltd. Group 2018年入社(2年目) 業務: Cloudn･Enterprise Cloud 2.0 サービス開発･運用 Enterprise Cloud 2.0 SRE チーム 2
3. Contents 01 02 背景 これまでの ECL2.0 開発 における問題点 03 SRE チームの結成と 問題への取り組み KUJIRA プロジェクト の発足 デプロイ戦略と その実現 Spinnaker & Argo Rollouts を用いた Blue-Green Deployment 3
4. Enterprise Cloud (ECL) 2.0 概要 エンタープライズ向けクラウドサービス 世界12拠点で提供中! 4
5. ECL2.0 のアーキテクチャ マイクロサービスアーキテクチャを採用 5 仮想サーバ 共通機能(契約管理・認証機能・課金など) ベアメタル サーバ ネットワーク モニタリング リソース・ コントローラ コンピューティング (仮想サーバ) ストレージ ネットワーク コンピューティング (ベアメタル) モニタリング (リソースなど) モニタリング (監査ログなど) ユーザから見た 機能･サービス 共通機能 コンポーネント化 されたソフトウェア群 リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ ... 各コンポーネントは API で連携
6. ECL2.0 開発における問題点 ① Dev チームの所掌範囲が広い Dev チームが VM, OS/ミドルウェアレイヤまで構築･運用 自由度は高いが維持コストが重く、アプリケーション開発に集中できない 6 VM OS/ミドルウェア アプリケーション ハードウェア ネットワーク 理想 Dev Team Infra Team VM OS/ミドルウェア アプリケーション ハードウェア ネットワーク 現実 Dev Team Infra Team
7. ECL2.0 開発における問題点 ② リリースプロセスの乱立 統一的なリリースプロセスが存在しない Dev チーム毎にリリースプロセスを確立･維持する必要がある 7 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 リリースプロセス
8. 重厚長大な会議体によるリリース頻度の低下 品質担保のため、商用作業には複数の会議で承認が必要 アプリのデプロイから物理機器のアップデートまですべて同じ会議に付議 ECL2.0 開発における問題点 ③ 8 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 会議 ① 会議 ② 試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 会議 ③ 会議①（開発部門による承認） 会議②（運用部門による承認） 会議③（構築部門による承認）
9. 課題へのアプローチ SRE チーム結成 & KUJIRA プロジェクト発足 品質を維持しつつ高速なリリースサイクルを実現する 9
10. 課題へのアプローチ SRE チーム結成 & KUJIRA プロジェクト発足 品質を維持しつつ高速なリリースサイクルを実現する 具体的には? 10
11. 課題へのアプローチ SRE チーム結成 & KUJIRA プロジェクト発足 品質を維持しつつ高速なリリースサイクルを実現する 具体的には? ① アプリケーション基盤の構築･運用 11
12. 課題へのアプローチ SRE チーム結成 & KUJIRA プロジェクト発足 品質を維持しつつ高速なリリースサイクルを実現する 具体的には? ① アプリケーション基盤の構築･運用 ② リリースプロセス(CI/CD パイプライン)の整備 12
13. ① アプリケーション基盤 Google Cloud Platform を利用したアプリケーション基盤 動作環境に Google Kubernetes Engine を採用 => Dev チームの所掌範囲を VM => コンテナ へ => 様々な変更に対して共通のデプロイ方法を取れるように 各種マネージドサービスを組み合わせて利用 => SRE チームの運用コストを最小限に 13
14. ② リリースプロセス ( CI/CD パイプライン ) 共通化したリリースプロセスを Dev チームに提供 デプロイ〜リリース or ロールバックまでのプロセスを自動化 プロセスの遷移に人を介入させないことで => リリース効率の向上 => ヒューマンエラーを排除 14 単体試験 デプロイ 正常性確認 ロールバック 開発 リリース 単体試験 開発 単体試験 開発 共通化
15. ② リリースプロセス ( CI/CD パイプライン ) GCP + Spinnaker を組み合わせて実現 GitHub への Push をトリガーに CI/CD が動作 コードの Push からリリースまでを完全に自動化可能に 15 Cloud Source Repositories Cloud Build Container Registry Spinnaker Kubernetes Engine Postman GitHub Code Push Sync Deploy/ Rollback Scenario Test Developer Create Container Image Application Call Test / Return Result Job Resource
16. ② リリースプロセス ( CI/CD パイプライン ) Spinnaker とは Continuous Delivery を実現するソフトウェア マルチクラウド (provider) に対応 => Kubernetes, DC/OS, Google Compute Engine, etc… デプロイフローをパイプラインの各ステージで定義 16
17. ② リリースプロセス ( CI/CD パイプライン ) GCP + Spinnaker を組み合わせて実現 GitHub への Push をトリガーに CI/CD が動作 コードの Push からリリースまでを完全に自動化可能に 17 Cloud Source Repositories Cloud Build Container Registry Spinnaker Kubernetes Engine Postman GitHub Code Push Sync Deploy/ Rollback Scenario Test Developer Create Container Image Application Call Test / Return Result Job Resource
18. アプリケーションのデプロイ戦略 Blue-Green Deployment の採用 ユーザトラフィックを流す前にアプリケーションの動作を確認 => 環境固有のバグをリリース前に発見できる 動作確認して問題がなければユーザトラフィックを Green へ切替 18 User Green Pod Blue Pod Test Traffic User Traffic Dev Team Production
19. Blue-Green Deployment の実現 Spinnaker 単体で実現してみた場合 Spinnaker のバージョン管理機能で実現できた! が、パイプラインが複雑すぎて一連の流れを理解するのが難しい 19
20. Blue-Green Deployment の実現 Argo Rollouts を導入 Kubernetes に Rollouts Custom Resource を提供してくれる 以下のデプロイ戦略が定義可能に! • Blue-Green Deployment • Canary Release デプロイ戦略以外は Deployment リソースのように記述できる 20
21. Argo Rollouts での Blue-Green Deployment デプロイフロー 21 Spinnaker Kubernetes Engine Cloud Load Balancing Postman User Preview Pod Active Pod Deploy Test Traffic User Traffic バージョン管理 & トラフィック切替制御 Switch
22. Argo Rollouts での Blue-Green Deployment Spinnaker + Argo Rollouts にすることで ステージ数が 34 → 10 になり可読性が向上 パイプライン自体のバグが発生しにくい状態に 22
23. パイプラインはできたが･･･ パイプラインの作成が負担に アプリケーション × 環境の数だけパイプラインが必要 GUI で作成･変更するため設定ミスが頻発 & 時間がかかる 環境毎に細かい差分が存在するためコピペも不可能 • 各ステージの定義 • manifest ファイルのパスの指定 • デプロイ先 K8s クラスタの指定 • 通知先の設定 23
24. パイプラインのコード化 & GitOps 化 Spinnaker の sponnet + spin を活用 Json 形式の変数ファイルの作成 & GitHub へ Push => Cloud Build でパイプラインを自動作成 24 { "Application": "sample", "Notification": "sample-channel", "Repo": "github" etc... } Sponnet: Jsonnet で書かれた Spinnaker パイプラインのテンプレート (https://github.com/spinnaker/spinnaker/tree/master/sponnet) spin: Spinnaker パイプライン等の作成を可能とする CLI (https://github.com/spinnaker/spin) Cloud Build Spinnaker GitHub Push Developer Create Pipeline value.json
25. まとめ SRE チームの結成 & KUJIRA プロジェクト発足 品質を維持しつつ高速なリリースサイクルの実現を目指す ① アプリケーション基盤の構築･運用 ② リリースプロセス(CI/CD パイプライン)の整備 25
26. まとめ 開発におけるこれまでの課題に対して • Dev チームの所掌範囲が広い ◦ コンテナを採用し所掌範囲を VM -> コンテナへ • リリースプロセスの乱立による Dev チームの負担増 ◦ 共通的なリリースプロセスの提供 • 重厚長大な会議体によるリリース頻度の低下 ◦ 会議ではなくソフトウェアで品質を担保する <- 取組中! ◦ 会議体の詳細については ｢アプリケーションのリリースに必要な会議を倒したい話｣ で検索 (https://qiita.com/kanatakita/items/a68c6e7758524422ecb0) 26
27. 今後の取り組み SLI / SLO の策定と計測 • アプリケーションに対して ◦ まずは信頼性の計測と可視化 ◦ 将来的にはエラーバジェットの仕組みの導入 社内での啓蒙活動 • SRE やエラーバジェットという考え方について広め、浸透させる 27