PipeCDを導入してGitOps & Progressive Deliveryをしている話

WRITER: Seiya Muramatsu
このエントリーをはてなブックマークに追加

メディア統括本部 Developer Productivity室の村松です。Developer Productivity室の中では、Bucketeerという社内基盤のフィーチャーフラグ・A/Bテストシステムの開発チームに所属しています。

この記事は、以前の社内勉強会での発表に加筆・修正して書き起こしたものです。内容は、Developer Productivity室が主体となって開発しているPipeCDを、Bucketeerチームに導入してGitOps & Progressive Deliveryをしている話です。PipeCDのアップデートを踏まえた補足説明や、今後対応しようと考えていることなどを加筆しています。

社内勉強会の発表資料: PipeCDを使用したBucketeerのGitOps-style CI/CD

また、記事の最後にPipeCDチームから社外へ向けたメッセージがあります。

目次

  • 用語の説明
  • Bucketeerのアーキテクチャの概要
  • BucketeerのCI/CDの概要
  • PipeCDを使用したGitOps & Progressive Delivery
  • 今後対応しようと考えていること
  • PipeCDについての所感
  • まとめ
  • PipeCDチームより

用語の説明

まずは、この記事で登場する用語について簡単に説明します。

  • PipeCD: Developer Productivity室が中心となって開発している、様々なインフラに対応しているOSSのCDツール。GitOpsやProgressive Deliveryの機能を提供。
  • GitOps: Gitを使用して、全てのアプリケーションとインフラの望ましい状態を宣伝的に記述し、管理する手法。
  • Progressive Delivery: 新しいバージョンのロールアウト時に分析を行い、主要なメトリクスが設定した閾値を満たしていない場合に、自動でロールバックするようなデプロイ手法。

詳しい説明は以下の資料を参照してください。

Bucketeerのアーキテクチャの概要

BucketeerではGCPを使用しており、アプリケーションはGKE上でホストしています。GCPプロジェクトは、開発環境用のサービスプロジェクト、特定のサービス専用のサービスプロジェクト、複数サービス共用のサービスプロジェクトがあります。また、それらを統一的にモニタリングしたり、CIを行うためのホストプロジェクトがあります。このようにマルチプロジェクト/マルチテナントをサポートするシステムです。

全体像は以下の図のようになっています。

GCP project structure

BucketeerのCI/CDの概要

ソースコードに関しては、GitHubのbucketeerリポジトリで全てのマイクロサービスのコードを管理しており、モノレポ構成になっています。各マイクロサービスのConfigはbucketeer-configリポジトリで管理しています。また、Kubernetesのマニフェスト管理にはHelmを使用しています。

CIツールはArgo EventsとArgo Workflowsを組み合わせて構築しており、CDツールはPipeCDを使用しています。注意点として、CyberAgent社内では、Developer Productivity室で運用しているPipeCDのControl Plane (PipeCD SaaS) を使用できるため、そちらを使用しています。

全体像は以下の図のようになっています。

CI/CD for microservices

PipeCDを使用したGitOps & Progressive Delivery

ここからはBucketeerでのPipeCDの活用事例について説明します。

PipeCDの設定

まずPipeCDを導入する際に、インストールや設定を行う必要があります。

  • Control Planeをインストール。 (サイバーエージェント社内ではSaaSとして提供されているので不要です。)
  • WebUIのProject画面で認証・認可周りの設定。
  • WebUIでEnvironmentの作成, Pipedの登録, API Keyの作成。 (BucketeerではGKEクラスタ単位でそれぞれ作成しています。)
  • Piped用の設定ファイルを作成し、各GKEクラスタにPipedをインストール。
  • bucketeer-cofnfigリポジトリに、各アプリケーションのデプロイ設定ファイル (.pipe.yaml) を作成し、PipeCDに登録。 (Bucketeerには全Environment合わせて100以上のアプリケーションがあるので、PipeCDのCLIを使って一括登録しています。)

また、bucketeer-configリポジトリのディレクトリ構成は以下のようになっています。

├── .pipe
│ └── analysis-template.yaml # 後述するAutomated deployment analysis用
├── charts
│ ├── account # account microservice
│ │ ├── .helmignore
│ │ ├── Chart.yaml
│ │ ├── templates
│ │ └── values.yaml
# ...
├── config
│ ├── account # account microservice
│ │ ├── abematv
│ │ │ ├── .pipe.yaml
│ │ │ ├── image_tag.yaml
│ │ │ └── values.yaml
│ │ ├── dev
│ │ │ ├── .pipe.yaml
│ │ │ ├── image_tag.yaml
│ │ │ └── values.yaml
│ │ ├── media
│ │ │ ├── .pipe.yaml
│ │ │ ├── image_tag.yaml
│ │ │ └── values.yaml
# ...

詳しい設定手順はPipeCDのドキュメントを参照してください。

PipeCDを使用したGitOps

BucketeerのCIでは、変更があったマイクロサービスのDockerイメージをGCRにpushした後、bucketeer-configリポジトリで管理しているイメージのバージョン (image_tag.yamlに記載) を更新するPRを、自動で作成するようにしています。

開発環境用のイメージ更新のPRについては、CIで自動マージするように設定しています。マージされるとPipeCDが変更を検知してデプロイが行われます。

本番環境については、CIで開発環境に対してのE2Eテストが成功した後、イメージ更新のPRが自動で作成されます。その後Slackに通知が行われるので、エンジニアが手動でPRをマージすると、PipeCDが変更を検知してデプロイが行われます。

また、手動でのロールバックなどの何らかのオペレーションが必要な場合も、GitHubのPRを介してオペレーションを行うようにしています。

備考

現在では、PipeCDにEvent Watcherという機能が追加されているので、CIで行っている開発環境用のPR作成・マージ処理を置き換えることができると考えています。

PipeCDのAutomated deployment analysis機能を使用したProgressive Delivery

PipeCDにはAutomated deplyment analysisという、メトリクスツールと連携して、メトリクスが設定した閾値を満たしていない場合に自動でロールバックする機能があります。これはまさにProgressive Deliveryのための機能です。

Bucketeerでは、Analysis用のテンプレートファイル (analysis-template.yaml) にリクエストのエラーレートが1%以上だと失敗となるような設定を書いています。このテンプレートをデプロイ設定ファイル (.pipe.yaml) から参照して、デプロイパイプラインに分析ステージを設定しています。

デプロイパイプラインは、カナリアPodのロールアウト、カナリアPodへのリクエストの分析、全てのPodのロールアウトという流れになっています。

ADA success

分析ステージで失敗した場合は、以下のように自動ロールバックとSlack通知が行われるようになっています。

ADA failure

Slack通知の例:

ADA failure slack notification

今後対応しようと考えていること

Bucketeerではインフラ管理にTerraformを使用しており、GitHub ActionsでTerraformのCI/CDを行っています。

一方で、PipeCDもTerraformのApply機能を提供しており、また、TerraformのPlanのPreview機能も今後提供される予定です。これらを利用すれば、TerraformについてもPipeCDでGitOps形式のデリバリーを実現できます。CDツールを統一していくという観点で、将来的にこの部分もPipeCDの使用を考えています。

参考: PipeCDのPlan Preview機能のRFC

PipeCDについての所感

PipeCDを導入してみて、以下のような点で良さを感じました。

  • 色々なツールを組み合わせなくても、PipeCD単体で、GitOpsやProgressive DeviliveryなどのCDで必要になることを実現できる。
  • 以前にArgo CD + Argo Rolloutsを使っていた頃は、KubernetesのDeploymentをRolloutに置き換える必要があり不便だったが、PipeCDではDeploymentをそのまま使うことができる。
  • 様々なインフラ (Kubernetes, Terraform, CloudRun, Lambda, ECSなど) を統一的に扱うことができる。
  • 英語でのやりとりだけでなく、SlackやTwitter上で日本語でやりとりすることもできる。

また、社内勉強会での発表時点では不安定さを感じる部分もありましたが、アップデートを重ねるにつれ、だいぶ安定したと感じます。

一方で、利用者数やコミュニティの活発さは他のCDツールに比べてまだまだだと思うので、みんなで盛り上げていきたいと考えています。

まとめ

BucketeerチームにPipeCDを導入してGitOps & Progressive Deliveryをしている話について紹介しました。

サイバーエージェントでは、Bucketeerチームだけでなく、他にもいくつかのチームで実際にPipeCDを本番利用しています。非常に便利に利用できているので、みなさんもぜひ試してみてください。

PipeCDチームより

PipeCDコミュニティ

情報発信はTwitter、Webサイト、CNCF Slackの#pipecd（英語）・#pipecd-jp（日本語）チャンネルで行っています。登壇予定のイベントなどもありますので、ぜひTwitterのフォローお願いします。

また、ユーザーからのフィードバックを積極的に募集していますので、導入や運用でうまくいかないことがありましたら些細なことでも連絡ください。

We are hiring!

現在PipeCDチームではバックエンドとフロントエンドエンジニアを一人ずつを募集しています。詳しくはコチラを参照ください。PipeCDの開発や組織のデリバリーパフォーマンスの改善に興味のある方のご応募をお待ちしております！

MongoDBの勉強会を実施しました
次の記事
Amebaアプリのアクセシビリティに関する取り組み
前の記事