Latchkey vs self-hosted ランナー: コスト・運用・信頼性
self-hosted ランナーは紙の上では最も安く見えます。運用にかかるエンジニアリング時間まで数えたときの本当の比較と、マネージドで自己修復するランナーが計算をどう変えるかを解説します。
self-hosted ランナーは、素の計算コストが最も安く、完全な制御を与えます。自分のマシン（EC2、Kubernetes、ベアメタル）でランナーソフトウェアを実行します。隠れたコストは運用です。オートスケーリング、イメージのパッチ適用、セキュリティ分離、ディスクのクリーンアップ、フリートが壊れたときのオンコール。Latchkey はマネージドです。そのインフラを一切所有せずに、低い1分あたりの料金と好きなランナーサイズを選べ、さらにすべてのジョブに自己修復が付きます。
self-hosted vs Latchkey 一目でわかる比較
| self-hosted | Latchkey | |
|---|---|---|
| 素の計算コスト | 最安 | 低い（$0.0025/min から） |
| 真のコスト | 加えてエンジニアリングとオンコールの時間 | 1分単位、運用時間ゼロ |
| 維持するインフラ | スケーリング、パッチ適用、クリーンアップ、セキュリティ | なし |
| ジョブ起動 | ウォームに保てば高速 | ウォームプール（マネージド） |
| 分離 / セキュリティ | 自分の責任 | マネージド、ジョブごとに分離 |
| 不安定な障害からの回復 | なし（自前で対応） | 自己修復による自動リトライ |
| 最適な用途 | 大規模での完全な制御 | 低コスト + 低運用 |
self-hosted が勝る点
最大限の制御と、ユニットあたり最安の計算コスト。特定のハードウェア（GPU、大容量メモリ）や厳密なネットワーク配置が必要な場合、あるいはランナーフリートを大規模に運用できるプラットフォームチームがすでにある場合に最適です。
self-hosting の隠れたコスト
誰かがオートスケーラーを構築・所有し、ランナーイメージにパッチを当てて再構築し、あるワークフローが次を汚染しないようジョブを分離し、実行間でディスクを掃除し、ランナーがパイプラインの途中でオフラインになったときに対応しなければなりません。この繰り返しのエンジニアリング時間こそが本当の請求で、クラウドの請求書には表れません。
Latchkey が勝る点
Latchkey は低い1分あたりの料金と好きなランナーサイズを保ちつつ、GitHub Actions からはマネージドランナーに見え、インフラは一切維持不要です。各ジョブは分離して実行され、ジョブはウォームプールから起動し、一時的・機械的な障害は人を呼び出す代わりに自己修復して自動でリトライします。
How to evaluate a managed runner honestly
- Compare at equal machine shape. A lower rate on fewer vCPUs is not cheaper per unit of work.
- Check billing granularity: per-minute rounding costs real money across a wide matrix of short jobs.
- Include queue and boot time. Cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. Paying twice for the same work is invisible on every rate card.
- Switching is a one-line
runs-onchange in both directions, so a two-week trial beats modelling.
結論
完全な制御とカスタムハードウェアが、ランナーフリートを自分で運用する価値があるなら self-hosted を選びましょう。運用負荷なしで低コストにしたい、そして不安定な障害から自力で回復するパイプラインが欲しいなら、Latchkey は self-hosted 並みの料金で、自己修復を組み込んだマネージドランナーを提供します。