Actions Runner Controller (ARC) vs Managed Runners
ARC は自社の Kubernetes クラスタ上でセルフホストランナーを実行します。強力ですが、クラスタ、スケーリング、アップグレードはすべて自分で運用します。
Actions Runner Controller (ARC) は、オートスケーリング付きで Kubernetes 上に Pod としてセルフホストランナーを実行する、GitHub 提供のツールです。すでに K8s を運用しているなら最適ですが、それでもセルフホスティングです。マネージドランナーとの比較を見ていきます。
| ARC (K8s 上のセルフホスト) | Managed (Latchkey) | |
|---|---|---|
| コンピュートコスト | クラスタの実コスト | 低い (hosted 比 約70%減) |
| Kubernetes が必要 | はい (自分で運用) | いいえ |
| スケーリング | オートスケーリングを自分で設定 | ウォームプール (標準搭載) |
| パッチ / アップグレード | controller + node を自分で管理 | 自動対応 |
| 不安定な失敗からの回復 | なし | 自己修復による自動リトライ |
| セットアップの手間 | 高い (Helm, controller, スケーリング) | label の入れ替え |
ARC が適する場面
すでに Kubernetes を運用しており、クラスタと同じ場所にランナーを配置したく、controller、node プール、オートスケーリングを運用できるプラットフォームチームがあるなら、ARC は有力な選択肢です。
運用の現実
ARC はやはりセルフホスティングです。controller のアップグレード、ランナーイメージの保守、スケーリングのチューニング、基盤 node の信頼性は自分で担います。これは実際に発生し続けるプラットフォーム作業です。
マネージドという選択肢
Latchkey のようなマネージドランナーは、運用すべき Kubernetes なしに同等のコンピュート削減 (GitHub-hosted 比 約70%減) を実現し、即時ピックアップのためのウォームプールと、一時的な失敗を自動リトライする自己修復を備えます。
結論
Kubernetes のプラットフォームチームがあり、自社クラスタ内にランナーを置きたいなら ARC を使いましょう。K8s を運用せずにコスト削減を得たいなら、マネージドランナーの方が手間が少なく自己修復もあります。無料で始められます。
関連ガイド
Self-Hosted vs Managed Runners: Ops & ReliabilitySelf-hosted vs managed GitHub Actions runners compared on cost, ops, scaling, and reliability. Get self-hoste…
GitHub-Hosted vs Managed Runners: Cost & SpeedGitHub-hosted vs managed runners compared on cost, queue time, caching, and reliability. Why managed runners…
GitHub-Hosted vs Self-Hosted Runners: Cost & OpsGitHub-hosted vs self-hosted runners compared on cost, speed, maintenance, and reliability - plus where manag…
GitHub Actions Cost Calculator - Estimate & Cut Your CI BillFree GitHub Actions cost calculator: enter your monthly CI minutes and runner size to see your current bill a…