サイバーエージェントのプロダクトリリースを支える「PipeCD」が、世界に通じるOSSになるまで。

── サイバーエージェント Developer Productivity室が開発したCDツール 「PipeCD」について、その技術的な役割を教えてください。

「PipeCD」は、サイバーエージェントが2020年10月にオープンソースとして公開した継続的デリバリーツール(Continuous Delivery Tool)です。私は「PipeCD」の開発責任者をしています。

「CI/CD」と連なった単語で表現されがちですが、ソースコードのビルドから単体テスト, コンテナイメージの作成までといったアーティファクト(生成物)をレジストリーに保存するCI(Continuous Integration)の役割であり、Jenkins, GitHub Actions, CircleCIなどが知られています。その一方、アーティファクトをステージングや本番環境などのプラットフォームにデプロイするツールがCD(Continuous Delivery)であり、Harness, FluxCD, ArgoCD等が知られていて、中には１つのツールがCI、CDの両方の役割も持っている場合も多かったりもします。「PipeCD」はCDにあたります。

サイバーエージェントでは、約3,500のアプリケーションが「PipeCD」を利用し、毎日何千回ものデプロイが行われています。当社の「ABEMA」でも毎日デプロイが行われいますし、他事業部のプロジェクトでは1日に3桁のデプロイが観測されることもあります。「PipeCD」を通じて計測できるこれらの数字は「ユーザーに高品質なサービスをスピーディに提供する」という企業カルチャーを示していると言えます。

2023年5月には、クラウドネイティブ技術を推進するCNCF (Cloud Native Computing Foundation) のSandboxプロジェクトに採択されました。国内のプロジェクトがSandboxプロジェクトに採択されることは珍しく、その点でも「PipeCD」は信頼性と将来性をそなえたOSSとして世界的に認められたOSSと言えます。また、継続的デリバリーシステム(CD)に特化したプロダクトとしては、国内初の採択となりました。

── 「PipeCD」は、開発におけるどんな課題を解決するツールなのですか？

「PipeCD」のプロダクトビジョンは「The One CD for All {applications, platforms, operations}」です。

昨今の開発プロジェクトにおいては、Kubernetes、Google Cloud Run、Amazon ECS、AWS Lambdaなどの様々なプラットフォームが選択肢にありますが、複数のプラットフォームを使い分けるようなマルチプラットフォーム環境においても、GitOps等を活用した統一的なプログレッシブ・デリバリーを実現することを目指しています。

「PipeCD」の開発の背景には、CIとCDがツールの役割的に混在したり、複数のプラットフォームが複数のチームによって絡み合って運用が複雑化するなど、大規模開発ならではのデプロイ環境に関する課題がありました。

社内の具体的な事例で言えば「GitOpsを活用してアプリケーションのライフサイクル全体をGitリポジトリで管理したい」と考えた際、サービスによってはKubernetesをプラットフォームとして導入しているものもあれば、Amazon ECSを採用しているサービスもあります。そのため、継続的デリバリーの手法や運用の一貫性が保てず、デプロイにコストがかかるなどの課題が存在していました。

── なぜマルチプラットフォーム環境になるのでしょうか？

各プラットフォームには独自の特徴があります。例えば、開発に必要な特定の機能がパブリッククラウドAには存在し、パブリッククラウドBには存在しない場合などです。サービスはパブリッククラウドAで運用していながら、機械学習のために特定のデータベースを利用する必要があり、部分的にパブリッククラウドBを利用するといったケースも考えられます。

また、セキュリティやコストの問題から、一部の機能をオンプレミスに置くというアーキテクチャも考えられます。パブリッククラウドでは、VPNや専用線などを用いてオンプレミスと併用するハイブリッド運用を可能にする事も想定されています。

── ビジネス要件を満たすためにはマルチプラットフォーム環境が前提になりつつある中で、開発からデプロイまでに見られる課題とは何ですか？

サイバーエージェントでは、開発チームが技術選択の裁量権を持ち、ビジネス要件に応じてアーキテクチャを自由に設計するのが企業カルチャーです。その一方、チームごとに異なる技術スタックを持つ可能性や、統一されたプラットフォームが存在しない事によるコストも伴います。

特に、各チームがそれぞれ独自のCI/CDツールを選定し、自分たちのチームで維持・運営する必要性も生じます。結果として、各開発チームでデプロイを担当するエンジニアのアサインが求められるケースも出てきます。

また、チームごとに異なるCI/CDツールが存在すると、新規メンバーのオンボーディングコストが増加したり、デプロイ環境のツール習得に時間がかかり、開発に集中できなくなるデメリットも生じます。これらの課題を解決するために、マルチプラットフォーム環境で一元的にデプロイを提供できる「PipeCD」が、サイバーエージェント社内で開発されたという経緯です。

── 他のCDツールとの違いや「PipeCD」ならではの強みは何ですか？

「PipeCD」の開発メンバーが国内外のカンファレンスに登壇すると、まさにそのような質問が寄せられます。

PipeCDを開発することになったチームでは上記のような社内課題を解決するために、当初HarnessやArgoCDなどの商用のCDツールを検討したりしていました。しかし、期待する機能を持ったプロダクトが市場に存在していなかったため自社開発に踏み切りました。このように「PipeCD」の成り立ちは、「ABEMA」を初めとした社内プロダクトチームの開発ニーズを満たすための内製化OSSであって、それを実現したのが「PipeCD」という背景になります。そのため「ABEMA」のような大規模プロダクトに必要な機能や、実用的な運用フローが備えられているという点が強みと言えます。

また、機能的なメリットの点では、プログレッシブデリバリーを軸としたCD中心の機能とインターフェースが挙げられます。マルチプラットフォーム環境であっても「PipeCD」が統一したインターフェースとオペレーションを提供するので、学習コストやメンテナンスコストを大幅に下げることができます。

── ビジネス要件に応じて柔軟にプラットフォームを組み合わせても、発生しうるコストや課題を吸収してくれるのは、技術選定の自由度も増すので良い効果がありそうですね。

サイバーエージェントには、エンジニアが自らの裁量権で、技術選定やアーキテクチャを決める組織カルチャーがあります。ビジネス価値を追求する手段として、最新技術やレガシーな技術を柔軟にとりいれ、自己の裁量と責任で選定していく組織カルチャーに、私は強く共感しています。そのため「PipeCD」を開発する際は「技術選定の自由さ」を大切にする事を心がけています。

たくさんの選択肢の中から「PipeCD」を検討にいれる際、「ABEMA」のような大規模プロダクトで活用されているという実績は、安心にもつながります。

このように、国内・国外問わず、ビジネスニーズに対して「PipeCD」が大きな役割を担っている事を誇りに思っています。

── 「PipeCD」の主要な機能の1つである「プログレッシブデリバリー」についても、その特徴を教えてください。

「PipeCD」はGitHub上の構成ファイルに変更が加えられると自動で検知し、デプロイを実行します。デプロイに失敗した場合は、自動で直前の状態にロールバックする機能が特徴で、この手法はGitOpsと呼ばれています。

「PipeCD」では、カナリアリリースやブルーグリーンデプロイメントという2つのデプロイ手法が選択可能です。また外部ツールからシステムメトリクスを取得し、あらかじめ設定した閾値に基づいてデプロイ後のサービスが正常に動作しているかを分析します。その他にもデプロイメントを進めるために特定ユーザーからの承認ステップを挿入したりと細かな調整が可能になっています。たとえば、カナリアリリースでは、アプリケーション全体に対して一度に100%のユーザーに向けてアップデートを行うのではなく、初めに3%のユーザーのみを対象に段階的にリリースし、5分間システムメトリクスを監視して問題がない場合は自動的に残りロールアウトします。

デプロイに問題が検知された場合は、デプロイ処理が停止し、即座にロールバックされます。同様に、ブルーグリーンデプロイメントでは、運用中のバージョン（ブルー）とリリース対象の新バージョン（グリーン）を並行して稼働させ、問題がないことを確認した上で即座に切り替えることができ、サーバーメンテナンスを行うことなく継続的なサービス提供が可能です。

プログレッシブデリバリーを実現することで、マニュアルの動作確認をなくしたり、、カナリアリリースのように新機能を限定された少数のユーザーに対して段階的にリリースすることで、デプロイ失敗時のユーザー影響の最小化が可能になります。これは「ABEMA」のような大規模サービスにおいて、迅速かつ頻繁に機能更新を行うための、大きなメリットとなっています。

── カインさんが所属するDeveloper Productivity室では「PipeCD」や「Bucketeer」など数多くのOSSをリリースしています。社内の利用を想定していたツールを、OSSとしてリリースする意図は何でしょうか？

CI/CDツールのような社内基盤の開発と維持は、どの会社にとっても共通の課題と言えます。なぜなら、市場には常に新しい競合製品が登場し、内製ツールと比較された上で、フラットな視点で技術選定のテーブルに並ぶからです。内製ツールの利用が既定路線で決まっているようなトップダウン式の組織でもない限り、内製ツールが優先的に採用されることはありません。サイバーエージェントのように自由度が高い企業では、この傾向が顕著です。

そこでDeveloper Productivity室が採用した方法が「社内の技術的な課題を解決するために開発した基盤をOSSとして公開し市場競争に晒すこと」でした。これにより、社内だけでなく社外からの多くのフィードバックを得ることができ、製品の改善と発展が促進されました。

特に、ドキュメントが充実し、継続的にメンテナンスされているOSSは、利用者にとって安心材料となります。また、他の企業でも使用され、外部の意見が取り入れられることで、ソフトウェアの信頼性が高まります。

確かに「PipeCD」の発端は社内のデプロイ環境の改善のために開発していますが、OSSとして公開して幅広く利用されることで、ソフトウェアの品質は飛躍的に向上します。サイバーエージェントでは3,500のアプリケーションを利用していますが、中には逆輸入のような形で、他のOSSと同じ目線で比較検討された結果、利用されていたりもします。ましてや、社内部署が開発およびメンテナンスを行っていれば、より安心して開発できますし、リクエストがあれば開発者とすぐにコンタクトをとることもできます。

その他にも、単にツールを提供するだけでなく、その認知を広げるための工夫をしました。情報発信の戦略を立て、ドキュメントの整備、カンファレンスへの登壇などを通じて、社内外での注目を集め、ブランディングと利用の促進を図りました。露出が増えると、フィードバックが活発に得られることも大きな利点です。

このように、社内と社外のフィードバックループを形成することで、社内サービスの利用を促進し、より有効に活用していくことができました。

── そんなDP室のエンジニアの中から、カインさんがサイバーエージェントの次世代を担うエンジニア「NextExperts」として認定されました。エンジニアとして日々意識している事を教えて下さい。

エンジニアとして心がけているのは、まず足元のプロダクト課題や、サイバーエージェント内の課題に対して目をそらさず、地に足のついた課題解決に励むことです。その際、直面している課題をサイバーエージェント固有のものとして捉えるだけでなく、その解決策がグローバルにおいても共通する事を意識しています。

つまり、目の前で直面している社内の課題は、世界のどこかの誰かも同様に直面している可能性があり、その解決策が世界的にも通用する可能性があると信じる事です。

「PipeCD」は、サイバーエージェント内での課題解決を優先しながら、その過程で得た知見や経験を基にして生まれました。そして、OSSとしてリリースすることで、世界中で貢献できるようになりました。

日頃から「PipeCD」がCNCF (Cloud Native Computing Foundation) のような国際的な品質基準に適合しているかを考え、自信を持って開発したプロダクトをアピールすることが大切だと考えています。