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

Bd2d523ac5cbdd39f78990e8663f16e3?s=47 Kota Morigaki
January 25, 2020
2.9k

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

Bd2d523ac5cbdd39f78990e8663f16e3?s=128

Kota Morigaki

January 25, 2020
Tweet

Transcript

  1. 2.

    自己紹介 森垣航太 所属: NTT Ltd. Group 2018年入社(2年目) 業務: Cloudn・Enterprise Cloud

    2.0 サービス開発・運用 Enterprise Cloud 2.0 SRE チーム 2
  2. 3.

    Contents 01 02 背景 これまでの ECL2.0 開発 における問題点 03 SRE

    チームの結成と 問題への取り組み KUJIRA プロジェクト の発足 デプロイ戦略と その実現 Spinnaker & Argo Rollouts を用いた Blue-Green Deployment 3
  3. 5.

    ECL2.0 のアーキテクチャ マイクロサービスアーキテクチャを採用 5 仮想サーバ 共通機能(契約管理・認証機能・課金など) ベアメタル サーバ ネットワーク モニタリング

    リソース・ コントローラ コンピューティング (仮想サーバ) ストレージ ネットワーク コンピューティング (ベアメタル) モニタリング (リソースなど) モニタリング (監査ログなど) ユーザから見た 機能・サービス 共通機能 コンポーネント化 されたソフトウェア群 リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ リソース・ コントローラ ... 各コンポーネントは API で連携
  4. 6.

    ECL2.0 開発における問題点 ① Dev チームの所掌範囲が広い Dev チームが VM, OS/ミドルウェアレイヤまで構築・運用 自由度は高いが維持コストが重く、アプリケーション開発に集中できない

    6 VM OS/ミドルウェア アプリケーション ハードウェア ネットワーク 理想 Dev Team Infra Team VM OS/ミドルウェア アプリケーション ハードウェア ネットワーク 現実 Dev Team Infra Team
  5. 7.

    ECL2.0 開発における問題点 ② リリースプロセスの乱立 統一的なリリースプロセスが存在しない Dev チーム毎にリリースプロセスを確立・維持する必要がある 7 単体試験 デプロイ

    デプロイ後 正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 リリースプロセス
  6. 8.

    重厚長大な会議体によるリリース頻度の低下 品質担保のため、商用作業には複数の会議で承認が必要 アプリのデプロイから物理機器のアップデートまですべて同じ会議に付議 ECL2.0 開発における問題点 ③ 8 単体試験 デプロイ デプロイ後

    正常性確認 ロールバック 開発 リリース完了 単体試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 会議 ① 会議 ② 試験 デプロイ デプロイ後 正常性確認 ロールバック 開発 リリース完了 会議 ③ 会議①(開発部門による承認) 会議②(運用部門による承認) 会議③(構築部門による承認)
  7. 13.

    ① アプリケーション基盤 Google Cloud Platform を利用したアプリケーション基盤 動作環境に Google Kubernetes Engine

    を採用 => Dev チームの所掌範囲を VM => コンテナ へ => 様々な変更に対して共通のデプロイ方法を取れるように 各種マネージドサービスを組み合わせて利用 => SRE チームの運用コストを最小限に 13
  8. 14.

    ② リリースプロセス ( CI/CD パイプライン ) 共通化したリリースプロセスを Dev チームに提供 デプロイ〜リリース

    or ロールバックまでのプロセスを自動化 プロセスの遷移に人を介入させないことで => リリース効率の向上 => ヒューマンエラーを排除 14 単体試験 デプロイ 正常性確認 ロールバック 開発 リリース 単体試験 開発 単体試験 開発 共通化
  9. 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
  10. 16.

    ② リリースプロセス ( CI/CD パイプライン ) Spinnaker とは Continuous Delivery

    を実現するソフトウェア マルチクラウド (provider) に対応 => Kubernetes, DC/OS, Google Compute Engine, etc… デプロイフローをパイプラインの各ステージで定義 16
  11. 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
  12. 20.

    Blue-Green Deployment の実現 Argo Rollouts を導入 Kubernetes に Rollouts Custom

    Resource を提供してくれる 以下のデプロイ戦略が定義可能に! • Blue-Green Deployment • Canary Release デプロイ戦略以外は Deployment リソースのように記述できる 20
  13. 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
  14. 22.

    Argo Rollouts での Blue-Green Deployment Spinnaker + Argo Rollouts にすることで

    ステージ数が 34 → 10 になり可読性が向上 パイプライン自体のバグが発生しにくい状態に 22
  15. 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
  16. 26.

    まとめ 開発におけるこれまでの課題に対して • Dev チームの所掌範囲が広い ◦ コンテナを採用し所掌範囲を VM -> コンテナへ

    • リリースプロセスの乱立による Dev チームの負担増 ◦ 共通的なリリースプロセスの提供 • 重厚長大な会議体によるリリース頻度の低下 ◦ 会議ではなくソフトウェアで品質を担保する <- 取組中! ◦ 会議体の詳細については 「アプリケーションのリリースに必要な会議を倒したい話」 で検索 (https://qiita.com/kanatakita/items/a68c6e7758524422ecb0) 26
  17. 27.

    今後の取り組み SLI / SLO の策定と計測 • アプリケーションに対して ◦ まずは信頼性の計測と可視化 ◦

    将来的にはエラーバジェットの仕組みの導入 社内での啓蒙活動 • SRE やエラーバジェットという考え方について広め、浸透させる 27