ニュースApr 18, 20256 分 READ

大規模環境での CI/CD：CircleCI と GitHub Actions のパフォーマンスを分析

Nick Smith

DevOps カスタマーエンジニア

CI/CD プラットフォームを評価する際、どれも同じ機能を持つ交換可能なツールと見なされがちです。しかし、開発チームが拡大するにつれ、プラットフォームのわずかな性能の違いが大きな影響を及ぼし、開発速度やリソースの利用効率に大きな差を生み出します。

これらの違いを理解するために、CircleCI と GitHub Actions の比較実験を行い、大規模エンタープライズ環境でのパフォーマンスを測定しました。その結果、ジョブ実行速度とキューイングの効率に大きな違いがあり、コードの迅速かつ安定したデリバリー能力に影響を与えることが判明しました。

分析方法

厳密かつ公平な比較を行うために、React のコードベースを中心に実験を設計しました。React は、複数のテストパイプライン、安定したコントリビューションの頻度、そして実際の企業向け CI/CD の複雑さを反映したジョブのマトリクスを備えており、理想的な候補といえます。

実験の主なパラメータは以下のとおりです：

同時に500ジョブを実行できる Enterprise GitHub 組織
CircleCI も同様に同時500ジョブの制限で設定
パブリックキューによるばらつきを排除するため、リポジトリは非公開に設定
24時間分のコミットを高速で再現するスクリプトを使用
各コミットで6つのワークフローがトリガーされ、合計184ジョブを実行
両プラットフォームでパイプラインを同時に実行
同等のコンピュートリソースを使用：
- GitHub Actions：ubuntu-latest（2 CPU / 7GB RAM）、linux-amd64-large（4 CPU / 16GB RAM）
- CircleCI：linux-large（4 CPU / 15GB RAM
毎日テストを実行し、メトリクスは API 経由で収集

このテスト手法は、現代のエンタープライズ開発環境の要求を反映するよう特別に設計されました。現在の主要なテクノロジー企業では、複数のチームにまたがる数百人の開発者が、日々継続的にコードを統合しています。こうした組織では、1つのコミットごとに数百のジョブを含むこともある、複雑なテストスイートや高度な CI/CD パイプラインを実行するのが一般的です。

React のコードベースを選んだ理由は、エンタープライズ環境の特徴をよく体現しているからです。具体的には、複数の堅牢なテストパイプライン、さまざまな構成にまたがるマトリクス型テスト、そしてジョブ間の複雑な依存関係を備えています。

24時間分のコミットを高速で再現することで、マイクロサービスアーキテクチャを採用している企業や複数のプロダクトを運用している企業に見られる、高スループットな環境をシミュレートしました。

結果

分析の結果、開発生産性やインフラコストに直結する2つの重要な点で、両プラットフォームのパフォーマンスに大きな差があることが判明しました。

パイプライン実行速度：開発者の生産性への直接的影響

CircleCI と GitHub Actions のデフォルトランナー（ubuntu-latest）を比較したところ、CircleCI の方が中央値で40.29%速く実行されることがわかりました。この速度差により、開発者がビルドやテストの完了を待つ時間が短縮され、より迅速に機能をリリースしやすくなります。50人の開発者が1日に複数回コミットするチームでは、月間で数百時間のエンジニアリング作業時間を節約できる可能性があります。

さらに、GitHub の高性能ランナー（linux-amd64-large）と比較しても、CircleCI は2.09%の速度優位性を維持しました（CircleCIのRAMは15GB、GitHub ActionsのRAMは16GB）。ほぼ同じリソースを使用しながらも一貫して優れたパフォーマンスを発揮していることは、CircleCI のジョブ実行における基本的なアーキテクチャの優位性を示しています。これにより、コンピューティングリソースをより効率的に活用でき、インフラコストの削減につながることが明らかになりました。

キュー管理：CI/CDコストを左右する隠れた要素

両プラットフォームの最大の違いは、高負荷環境でのキュー管理能力でした。

CircleCI は、利用可能な同時実行キャパシティを即座に最大限活用し、複数のワークフローにわたって最大500ジョブを同時に実行することで、優れたリソース活用効率を示しました。
一方、GitHub Actions は大規模環境での開発スピードに深刻な影響を与える制限があることが明らかになりました。500ジョブの同時実行キャパシティを持っているにもかかわらず、実際には約124ジョブしか同時実行できず、ワークフローごとの処理も約6つに制限されていました。

このボトルネックにより、GitHub Actions ではキュー待ち時間が長くなり、処理速度が低下しました。GitHub のデフォルトランナーでは、中央値で153秒以上、最大22分超のキュー待ち時間が発生しました。さらに、大型の Actions ランナーでは、中央値22分超、最大63分もの待ち時間が発生しました。対照的に、CircleCI のキュー待ち時間は常に30秒以下（最大30.85秒）を維持しました。

ビジネスの観点から見ると、CircleCI は GitHub Actions のデフォルトランナーと比較してキュー待ち時間が90.13%短縮され、大型ランナーと比較すると99.12%短縮されました。成長中のエンジニアリング組織にとって、このキュー管理の効率性は、1日に複数回リリースできるか、それともリリース頻度が制限されるかの違いを意味します。

また、コストにも直接的な影響を及ぼします。開発者がビルドの完了を待っている間は、価値を生み出していません。CI/CD プラットフォームはリソースを消費しているにもかかわらず、出力を生み出していない状態になります。

高負荷時の性能：予想通りにスケールする信頼性

成長中の組織にとって最も重要なのは、増加する負荷に対して各プラットフォームがどのように対応するかです。本実験の結果、CircleCI は需要が増加しても安定したパフォーマンスを維持し、効果的な負荷分散と予測可能なキュー時間を実現しました。これにより、エンジニアリングリーダーはキャパシティ計画を安心して進めることができ、チームの成長に合わせて一貫したデリバリー速度を維持できます。

一方、GitHub Actions は負荷の増加に伴いパフォーマンスが低下し、ワークフローの数が増えるにつれてキュー時間が大幅に長くなることが確認されました。この挙動はキャパシティ計画を困難にし、重要なデプロイメントパイプラインに予期せぬ遅延を引き起こす可能性があります。継続的デプロイメントを実施している組織や、複数のチームを管理している企業では、これらの遅延がスケジュールの遅れや開発者のフラストレーションにつながる可能性があります。