3月24日、サイバーエージェントのエンジニア・クリエイターによる技術カンファレンス「CyberAgent Developer Conference2022」を開催しました。本記事では「A consistent delivery process with GitOps style for any application on any platform」の様子をお届けします。

サイバーエージェントには100を超える連結子会社が存在し、多数のプロダクト開発が行われています。プロダクトごとに技術を選ぶ自由度は大切ですが、組織から見るとデリバリープロセスの一貫性・標準化も大切です。本講演では、これまで生じていたデリバリープロセスの課題と、社内で構築したCDシステム「PipeCD」によって、どのように課題を解決し、単一なデリバリープロセスを実現することができたかについてご紹介しました。

■CDの状態と課題
 ■CDプラットフォームとして「PipeCD」をどのように使うか
 ●全ては一貫したプロセス
 ●関係者全員にとって簡単であること
 ●すばやく有益なフィードバックの提供
 ●PipeCDはアプリケーションを管理・監視する
 ●PipeCDの安全性
 ■サイバーエージェントにおける「PipeCD」の利用状況
 ■まとめ

■CDの状態と課題

まず、一般的なCIとCDのプロセスや、サイバーエージェントにおける「PipeCD」導入以前のCDの状態と課題について説明します。

●CI/CD

ソフトウェア開発をする際には、CI（Continuous Integration）とCD（Continuous Delivery）がよく使われます。その目的は、ソフトウェアのデリバリープロセスをより高速、より安全・安心にすることです。CIとCDは一括りに話されることが多いですが、ここではCDにフォーカスして説明します。

1つのソフトウェアサービスは、CDの視点からは基本的に「実行できるアーティファクト」「コンフィギュレーション」「ホスト環境」という3つのコンポーネントから構成されています。実行できるアーティファクトはコンテナイメージの場合もあり、バイナリの場合もあります。コンフィギュレーションは環境に特化した設定など、環境ごとにアーティファクトをどう実行するかというものです。ホスト環境はアーティファクトを置いているところで、Kubernetesクラスタの場合も、クラウド、iOS、Androidの端末などの場合もあります。

これら3つのいずれかに変更があれば、アプリケーションやサービスのコード変更が生じる可能性があります。そこで、これら3つのコンポーネントの変更を管理してレビュー、ベリファイすることが必要になってきます。

●「PipeCD」導入以前のCDにおける2つの課題

サイバーエージェントには多くの連結子会社が存在し、多数のプロダクト開発が行われています。その多くでCIとCDが強く結合しており、これが課題の1つでした。

2つめの課題は、CD専用チームやCDプラットフォームが存在しなかったことです。各プロダクトチームがCDシステムの選択、構築、運用に自由度を持てる反面、リソースが足りずにきちんとCDを採用できない、メンバーの異動ごとにオンボーディングのコストがかかる、プロダクトやチームが増えるとツールの数も増える、などの問題が発生していました。

これは運用コストが増えるだけでなく、組織として一貫性、システムコンシステンシーがなくなっていることが問題でした。マイクロサービスやマルチクラウドを採用しているプロダクトでは、またクラウドごとにツールが異なるため、エンジニアのコンテキストスイッチコストも発生していました。

そこで、開発者の生産性を向上させることで、サービス開発を支える「Developer Productivity室」が設立されました。CDについては上記の問題点を改善するため、CIとCDの分離と、全社のCDプラットフォーム提供を目指すことになりました。

●CIとCDの分離

もともとCIとCDは別々の役割を持っています。これらを分離することで、CIとCDそれぞれに合うツールを選ぶことができます。またCIとCDの結合による大きなパイプラインの増加を防ぐことができますし、セキュリティリスクを減らすこともできます。

CIは「開発」プロセスに含まれ、下記の2つを担当します。

開発コードベースに全ての変更リクエストに対してテストを実行し、早い段階で問題　点を検知し開発者にフィードバックとして上げる。
コードベースにマージされるたびにホスト環境にインストールするアーティファクトをビルドして保存する。

CDは「デプロイメント」プロセスに含まれ、下記の2つを担当します。

CIで生成されたアーティファクトをホスト環境にインストールし展開する。
各デプロイメントの影響を分析して、開発者にフィードバックを上げる。

CIとCDの役割は以下の図のとおりです。図の上の部分はCIのフローと担当の領域で、下の部分はCDのフローと担当の領域です。CIはソースコードのリポジトリを見てテストとビルドをします。一方、CDではコンフィグのリポジトリをプルで見て、そしてホスト環境にリコンサイルして、Gitで定義されている状態を同期するという役割を持っています。

●セキュリティリスクの削減

CIとCDの分離により、セキュリティリスクを減らすことができます。まず、クラスタなどのホスト環境へのアクセススコープを制限できるようになります。また、CDがホスト環境の中で動くことにより、CIなどではクラスタへアクセスキーやクレデンシャルが不要になり、ロールの管理もシンプルになります。つまり、分離することでCI経由で攻撃される危険性が小さくなります。

■CDプラットフォームとして「PipeCD」をどのように使うか

全社のCDプラットフォームとして「PipeCD」を採用するにあたり、私たちは以下の5つが重要だと考えました。

- - 全ては一貫したプロセス
  - 全員にとって簡単であること
  - 役に立つフィードバックを早めに提供すること
  - アプリケーションやサービスのデプロイだけでなく、管理もチームで権限が持てること
  - 安全性
●全ては一貫したプロセス

「全ては一貫したプロセス」とは、全ての環境・オペレーション・アプリケーション・ホスト環境で、同じプロセス、同じデプロイの手法を実現するということです。

そもそもなぜ同じプロセス、同じやり方が重要なのかというと、繰り返し可能で信頼性があるデリバリープロセスを実現するために不可欠だからです。全ての環境で同じプロセスを行うと、プロセスが毎日全ての人からテストされることになります。同じプロセスが開発環境で毎日百回、千回も実行されていれば、本番環境で同じことを実行する際に、失敗するリスクが限りなく低くなります。さらにプロセスの一貫性により、ヒューマンエラーも減らすことができると考えています。

プロセスの一貫性を実現するためには、以下の図のようにコンフィグのリポジトリにプルリクエストを出して、そしてプルリクエストの内容をレビュー、マージして、その後は全部「PipeCD」に任せるというシンプルな流れになります。

●関係者全員にとって簡単であること

使いやすさが必要な理由は、関係者全員がKubernetesやkubectlのエキスパートではないでしょうし、セキュリティの面で全員が直接クラスタやホスト環境へアクセスしてトラブルシューティングすることはできないからです。一方でデプロイプロセスには関係者全員が関与すべきだと考えます。だからこそ「PipeCD」は全てのことを同じプロセスで行え、Gitさえあれば使えるようになっています。

さらに「PipeCD」は可視化も大事にしており、トラブルシューティングのためにデプロイメントの状態ログなどを確認することができます。kubectlなどを不要にする目的でアプリケーションのリソースをリアルタイムにレンダリングしたり、Web UIでコンフィギュレーションドリフトを確認することもできるようになっています。

また人手によるオペレーションを減らすために、自動化も最大化しています。例えば新しいアプリケーションを追加するには、Gitのリポジトリにファイルを追加するだけで、「PipeCD」が新しいアプリケーションを自動検知します。デプロイ中に人間がメトリックスチェックしたり、ログで確認することも要らなくなり全て自動です。

「PipeCD」は運用がしやすい
「PipeCD」は運用のしやすさにもこだわっています。「PipeCD」は、Control PlaneとPipedエージェントという2つのコンポーネントから構成されています。1つのControl Planeに複数のPipedエージェントを対応させる形で各プロダクトチームのホスト環境にPipedエージェントをインストールします。

チームの構成によって適切な運用モデルが異なりますが、基本的には以下の2つのモデルがあり、どちらでも構いませんが、サイバーエージェントでは1つめのモデルを採用しています。
- - - 1つめのモデルでは、プラットフォームチームが1つのControl Planeを運用し、各プロダクトチームが自分のPipedエージェントを運用
    - 2つめのモデルでは、プラットフォームチームがControl PlaneもPipedエージェントも運用します。
Pipedエージェントは1つのステートレスなバイナリなので、どこにでもインストールでき、運用しやすくなっています。

エージェントの数を増やしたい場合は、Pipedエージェントをインストールするだけです。新しいバージョンに上げるときも、追加コンポーネントのインストールなどは不要で、Pipedエージェントのバージョンを上げるのは、Control PlaneのWebコンソールツールから簡単に行えます。

Control Planeは運用が簡単
Control Planeの運用は、基本的にはプラットフォームチームの担当になります。1つのControl Planeで複数のPipedエージェントが使えます。Control Planeの設計はシンプルで、基本的にサーバー、キャッシュ、Opsという3つのコンポーネントから構成されます。そしてDB、データまわりは全部マネージドのサービスを使うことができます。

Control Planeをスケーリングしたい場合は、サーバーの数を増やすだけで大丈夫です。また、モニタリングのコンポーネントも含まれており、オン／オフすることができます。

●すばやく有益なフィードバックの提供

エンジニアには、できるだけ早くフィードバックを提供する必要があります。しかし、早期検知できるものもあれば、エンドユーザーまで届けないとフィードバックが返されないものもあるので、デリバリープロセスの様々な段階でフィードバックを提供することが必要です。

「PipeCD」では、デプロイ前とデプロイ中に開発者にフィードバックを上げることが可能です。デプロイ前はコンフィグリポジトリへプルリクエストを出す際に、変更の内容をデプロイするとどんなリスクがあるかをプルリクエストにコメントとして提供します（後述するプランプレビュー）。それによって、プルリクエストのレビューの正確度を向上でき、レビューのコストも下げることができます。プルリクエストがマージされた後、デプロイ中にメトリックスやログを分析してフィードバックを提供することもできます。

PipeCDのプランプレビュー
ここでプランプレビューについて説明します。プルリクエストを出すとき、Git diffから得られる情報は十分ではありません。たとえば、このプルリクエストをマージすると何のアプリケーションがデプロイされるのか、ということがわかりません。また、プルリクエストでHelmチャートのバージョンを変更する場合、それによってたくさんのリソースが変更されても、Git diffではバージョン番号しかわかりません。Terraformのソースコードを変更するとどのリソースが追加・削除・変更されるかや、変更によってデプロイメントのポリシーに違反があるかどうかも、わかりません。「PipeCD」では、それらをすべて検知して、プルリクエストのコメントに以下の図の右側のように開発者に示してくれます。

PipeCDのプログレッシブデリバリー
プログレッシブデリバリーは、デリバリーの1つの安全対策です。「PipeCD」はカナリアリリース、ブルーグリーンリリースの戦略をサポートし、メトリックスやログに基づいてデプロイメントの分析を行うことができます。デプロイメントが悪い影響を与える場合、開発者に通知をしたり、自動ロールバックすることができます。

●PipeCDはアプリケーションを管理・監視する

「PipeCD」はアプリケーションの管理機能も提供しています。アプリケーションやサービスが増えれば増えるほど管理コストが増え、特に大きなプロダクトで複数のチームがある場合は、自分がどのアプリケーションを担当しているか、どのアプリケーションのオーナーシップを持っているかが分かりづらくなります。「PipeCD」では、アプリケーションリストの画面、アプリケーション管理フィルタ、グルーピングをUIで確認することができます。そして、アプリケーションのリソースの状態をリアルタイムで表示したり、以下の図の右側のようにアプリケーションのコンフィギュレーションドリフト、現在のGitの状態とクラスタの状態にずれがないかを検知して表示します。また、チームのリーダーや管理者が各チームのデリバリーパフォーマンスなどを確認したい場合は、デプロイの頻度などをInsightsの機能で確認することもできます。

●PipeCDの安全性

「PipeCD」の安全性を守るには、下記4つがあります。
セキュリティマルチてナンシー
キーレスデプロイメント
シングルサインオン
ラベルに基づくロールベースアクセスコントロール（RBAC）

セキュリティマルチテナンシー
Pipedの設計により、セキュアなマルチテナンシーが実現されています。Pipedエージェントは各クラスタの中で実行され、Control Planeへのアウトバウンドのリクエストのみが送られます。Control Planeからクラスタのエンドポイントへのリクエストが送られることはなく、プライベートクラウドなどネットワークの制限された環境でも動作することができます。

また、各プロダクトチームのクラスタ、ホスト環境のクレデンシャルをプロダクトチームの外に出したり、Control Planeに保存したりもしません。Control Planeが多くのプロダクトのクレデンシャルを保存する場所にならないため、安全が保たれます。

キーレスデプロイメント
Pipedエージェントは各ホスト環境の中で実行され、直接KubernetesクラスタやGoogle Colud Run、AWSのクラウドとインターナルで通信しているので、デプロイするときにキーが要らず、キーの運用・発行、漏れるリスクがなくなります。

ラベルに基づくロールベースアクセスコントロール（RBAC）
「PipeCD」では、ロールベースアクセスコントロール（RBAC）機能を現在実装中です。この機能はラベルに基づくアクセスコントロールで、各「PipeCD」リソースがラベルのリストを持っています。環境（environment）のラベルやグループのラベル、チームのラベルなどのほか、任意のラベルを設定することができます。

ログインしたユーザーは最低限1つのチームに属する必要があります。たとえば、GitHubのチーム、Googleグループ、GitLabのチームなどです。

各チームが、各リソースにラベルをマッチングして、アクセスできるかどうか、どの権限・ロールを持っているかを設定することができます。

■サイバーエージェントにおける「PipeCD」の利用状況

現在、サイバーエージェントでは「PipeCD」を使ってCDプラットフォームを提供しています。それをTerraformアプリケーション、Kubernetesアプリケーション、Cloud Runアプリケーション、そしてLamdaのアプリケーション、ECSアプリケーションをデプロイおよび管理しています。今年の1月時点で1,000個のアプリケーションを「PipeCD」に移動済みで、これからも移動を進めていく予定です。

■まとめ

今後については、Control Plane、Pipedエージェント、CNCFの3つに注目しています。

Control Planeは先述したとおり、現在RBACを実装中です。また、Control Planeの運用をもう少し楽にするために、DBがなくてもControl Planeを動作させられる機能も設計が済んでおり、現在実装中です。その後、各サービスのデリバリーパフォーマンスのInsightsの機能を実装していきます。

Pipedエージェントについては、どのアプリケーション、どのプラットフォームでもデプロイできるというのが「PipeCD」のビジョンなので、Pipedエージェントをより拡張できるようにしていきます。別のアプリケーションの種類に対応したり、同じ既存のアプリケーションの種類でも別のデプロイ手法を自分で定義したりできるようにしていきます。

また、コンフィギュレーションドリフトについては、現在はKubernetesとCloud Runしかサポートできていませんが、次はTerraform、ECSなどもサポートしていきたいと考えています。フィードバック、プランプレビューの機能についても、より多くのフィードバックを追加し、自動分析についてもプロバイダを追加していきます。

本日ご紹介した「PipeCD」については、誰でも体験していただくことが可能です。ぜひお試しください。

PipeCDホームページ：https://pipecd.dev/
PipeCD – GitHub：https://github.com/pipe-cd/pipecd
PipeCD Playground環境：https://play.pipecd.dev/applications?project=play