KubeCon North America 2024から、ローカルPC上でCIを実行することでクラウドコストを激減させるDaggerのセッションを紹介

KubeCon＋CloudNativeCon North America 2024から、ソフトウェアのビルドからテストを自動化するCI（Continuous Integration）ワークフローをパブリッククラウドやSaaS、オンプレミスのサーバーで実行せずにデベロッパーのPCで実行することで、コストと処理時間を削減するDaggerのセッションを紹介する。このセッションは2024年11月14日に行われた「You're Overpaying for CI」というタイトルのセッションで、プレゼンターはDaggerのエコシステムグループのエンジニアであるKyle Penfound氏だ。

プレゼンテーションを行うDaggerのPenfound氏

セッションの動画は以下のリンクから参照して欲しい。

●動画：You're Overpaying for CI

直訳すれば「あなたはCIにお金を払い過ぎている」となるタイトルが示す内容について例を示しながら解説し、その解決策としてデベロッパーが開発に使用しているPCでCIを実行することでコストと処理時間を減らすという内容だ。DaggerはDockerの共同創業者だったSolomon Hykes氏が立ち上げたベンチャーで、Hykes氏には2024年2月にテキサス州オースティンで開催されたCIVO Navigate 2024でインタビューを行っている。

●参考：Civo Navigate North America 2024、元Dockerで現DaggerのCEO、Solomon Hykesのインタビューを紹介

このセッションのアイデアはHykes氏のTwitter（現X）への投稿

セッションの起点となったのは2023年10月のSolomon Hykes氏の投稿であることを最初に紹介。ここではHykes氏の投稿に加えて、37signalsの共同創業者であるDavid Heinemeier Hasson氏のブログを紹介。このブログでは37signalsが開発するソフトウェアにおいて、CIをGitHub ActionsやCircleCIなどのサービスやリモートサーバーによる実行から、デベロッパーが使うPCに戻したことを解説した内容となっている。

●参考：We're moving continuous integration back to developer machines

David Heinemeier Hasson氏は37signalsというソフトウェア開発のスタートアップを経営しているだけではなく、Ruby on Railsの開発者としても知られている人物で、メールとカレンダーサービスのHey.comやプロジェクト管理サービスのBasecampなどの開発及び運営をしている。ソフトウェア開発においては多くの経験を持つベテランだ。そのベテランが「サービスとしてのCIを利用するよりは、デベロッパーが開発に使用するPC上でビルドとテストを実行するほうがコストと時間の削減になる」という意思表示をしたことは、Daggerの目指す姿に沿った考えだ。

プレゼンテーションに戻ろう。Penfound氏はGitOpsのフローを見せながら、ソフトウェア開発がGitリポジトリに格納されたソースコードがビルドされてテストされる流れを説明し、その中核にプルリクエストがコードの編集、レビュー、承認などのプロセスを経てビルド、テストが行われることを解説した。

GitOpsのフローを説明

GitOpsの中核にはプルリクエスト、その周りにビルド及びテストツールやレビュワーが存在する

GitOpsの中核はGitリポジトリに対するプルリクエストであり、それを中心にさまざまなツールや人が連携して動いていることがわかる。ここでビルドとテストについてはCIランナーと呼ばれるプロセスがビルドとテストを自動実行するのが一般的だが、次のスライドではそのプロセスにどれだけの処理時間とコストがかかっているのかを解説している。

1ヶ月間でCIのために15万3000分余りが使われていることを紹介

このスライドではLinuxとMacOSで1ヶ月につき約15万分がCIのために使われていると解説。15万3000分は日数に換算すれば106日という長時間であり、CIの実行回数も36000回超という回数になると説明した。ここではCIのプロセスにはコードの初期のプロトタイプから難解なデバッグの結果のコード変更だけではなく、単純なコメントのタイプミスまでビルドとテストの処理時間が発生していることを示している。

GitHub ActionsとCircleCIのCI処理時間の比較

このスライドではGitHub ActionsとCIサービスの大手CircleCIで、同じビルドとテストを処理した際にどれくらいの時間が必要なのかを説明。GitHub ActionsとCircleCIそしてセルフホストしたランナーで実行に使われるプロセッサコア数とメモリーサイズが異なることで、処理時間が変化しているのがわかる。高速でコア数の多いインスタンスを使えば当然処理は速くなるが、コストも比例して高くなる。

GitHub ActionsとCircleCIでコストを比較

この比較表ではGitHub ActionsとCircleCIで無償分を使いながら、LinuxとMacOSを使ってビルドとテストが繰り返されると想定すると、GitHubへの支払いが4000ドル、CircleCIの場合でも3700ドルが発生してしまうことを紹介。

パブリッククラウドのインスタンスを使ってセルフホストした場合のコスト比較

ここではセルフホストした場合でのコストを比較している。GitHub ActionsとCircleCIで約900ドルから約2000ドルが費用として発生してしまうことを紹介した。

セルフホストでのコストとデベロッパーが使うMacBookのコストを比較

ここでローカルランと書かれているのは、デベロッパーが日常使用しているMacBookのコストを追加して比較しているという意味だ。Apple M1チップを実装した16GBメモリーのMacBookではGitHub Actionsに比べて処理時間が約半分になっていること、コストもセルフホストのケースと比較しても安価になっていることに注目したい。セルフホストは月額、MacBookは標準小売価格だろうから通年で計算すればコスト比較はさらに大きな差が出てくると思われる。

ただしこれまでCIサービスとして使っていたビルドとテストのフローをデベロッパーが使うPCに置き換える場合、いくつかの選択肢があり、それぞれに利点と欠点が存在することをここから解説している。

CIのエージェントをデベロッパーが使うPCに移す場合の利点と欠点

単にこれまでCIサービスで実行されていたCIジョブをデベロッパーが使うPCに移しただけだとコストと処理時間の削減は実現できるが、CI自体が元のサービスのままの独自仕様になってしまうこと、CIジョブだけではなく全体のフローを制御する部分も移行する必要があり、複雑さは変わらないという欠点があると説明した。そしてそもそも「ビルドしてテストを行うことをローカルで実行できないのはなぜか？」と自問し、YAMLの構成ファイルで実装されたワークフローをデベロッパーのローカルPCで実現できないことなどを挙げて、その難しさを説明した。

CIパイプラインをローカルPCに移行するフェーズの説明

その次のフェーズとして、CIジョブだけではなくパイプラインに移植性を持たせてローカルでCIパイプラインを実行することの利点と欠点を説明した。

ここではGitにコードの修正をプッシュする前にビルドとテストをローカルで実行し、それがパスしたらGitへのプルリクエストを行うというやり方を説明。しかしこの場合でもプルリクエストの段階でCIランナーが実行されてしまうという欠点があることを指摘。CIのエージェント、CIのパイプラインだけを移行しても、コストと処理時間の削減には不十分であることを説明した。

リモートのGitリポジトリを使いながらパイプライン処理をローカルPCで実行する

そしてCIランナーを移植するのではなく、パイプラインの処理自体をランナーに依存させずにローカルPCで実行することが最善の策であると説明。この結果、処理時間とコストを大幅に削減できると説明した。

セッションのまとめ。CIのロジックを記述するYAMLファイル自体を変更する必要がある

まとめのスライドでは、ビルドとテストをCIランナーやパイプラインの呪縛から解き放ってローカルで実行できるようにすれば、コストと処理時間の問題は解決できると説明した。このセッションでは表層的にコストと時間の削減だけに焦点を絞って解説しているが、それをどうやって実現するのか？ については詳細な説明を行っていない。Daggerの動作を知るためにはKubeCon North Americaの共催イベントであるAppDeveloperConで行われたセッションを参照して欲しい。このセッションもDaggerのプレゼンテーションだが、解説を行ったのはエコシステムグループのリーダーであるJeremy Adams氏だ。

●Daggerの概要：Introducing Dagger Modules: Open Source CI/CD Building Blocks You Already Know How to Write

このセッションで使用されたスライドも公開されている。

●スライド（PDF）：Introducing Dagger Functions＆Modules

より深く理解するためにはDaggerの公式ドキュメントが頼りになるだろう。

●公式ドキュメント：https://docs.dagger.io/

Adams氏のセッションでは、最初はシンプルだったCIジョブがさまざまな要因から複雑なものに変化してしまい、デベロッパーがソースコードの変更をプルリクエストの形でプッシュしてもそれがビルドされテストにパスするまで祈るしかないという状況になってしまうことに対して、DaggerがYAMLファイルを使わずにコンテナ化した環境の中で必要なモジュールのダウンロードとインストール、ビルド、テストを行うことを可能にすることを解説している。デモも交えた説明ではGoやPythonを使ってビルドやテストのスクリプトを記述し、ターミナルを介して操作する部分を解説している。

Daggerの紹介を行うJeremy Adams氏

Daggerを実現している要素技術として、YAML（Jenkinsの場合はGroovy）をデベロッパーが使い慣れたプログラミング言語に置き換えたこと、コンテナによってCIパイプラインの実行をどの環境でも実行できるようにパッケージ化したこと、そしてデベロッパーが使うマルチコアを備えた高速なPCが出現したことなどを挙げている。

Daggerを実現した要素技術について解説

このスライドではコアとなるDagger Engineに加えてAPIでコマンドラインからもプログラミング言語からも呼び出せること、Daggerverseと呼ばれるマーケットプレイスがあることなどを説明している。

このセッションではnginxを使ったWebサイトを開発するというケースをデモで紹介しているが、実際のユースケースとなるであろうGitHub ActionsやCircleCI、Jenkinsなどの既存のCIパイプラインをどのように置き換えるか？ についてはごく簡単な説明に留まっていた。ドキュメントをビルドやテストなどの部分はそのままのCIジョブを使い、エラー処理や環境に依存する条件分岐などをGoやPythonのプログラミング言語に置き換えるという方法が安全な移行方法と言うことだろう。

YAMLからの移行に関しての解説は、専用のページが用意されているので公式サイトを参照して欲しい。

●公式の移行ガイド：https://docs.dagger.io/ci/adopting/

Penfound氏のセッションはオンラインサービスとしてのCIを使うことのコストと処理時間の増大をDaggerで解決する結果を解説し、Adams氏のセッションはデモを交えてビルドのプロセスをローカルで実行するまでを解説するものであった。CI自体について、アプリケーションデベロッパーもOpsエンジニアも避けて通りたい厄介な問題と考えるのではなく、どうやったら高速にそして安価にできるのか？ を考えた結果としてDaggerが生まれていることを知っておくべきだろう。