DepotからLatchkeyへの移行: GitHub Actions runner
DepotとLatchkeyはどちらも高速でドロップイン、より安価なGitHub Actionsのマネージドrunnerです。優先事項が不安定な再実行を減らすことなら、DepotからLatchkeyへの移行はruns-onの1行変更です。
DepotのGitHub Actions runnerは、GitHubホスト型runnerのドロップイン代替です。Depotのドキュメントによれば、runs-onのラベルを変更するだけでどのジョブでも導入できます。Depotは自社の「Ultra Runners」をGitHubホスト型の最大3倍高速とうたい、第4世代AMD EPYC「Genoa」CPU（Depotによればネイティブrunnerより約30%高速）上で分散キャッシュを統合して動作します。Latchkeyもruns-onの入れ替えでアクセスできるドロップインのマネージドrunnerですが、自己修復CIを中心に構築されています。一時的および機械的な失敗が自動的に検出、診断、修正、再試行されます。このページは、Depotが得意とすること、なぜ一部のチームが移行するのか、そして具体的な乗り換え方法を率直に見ていきます。
Depot対Latchkey早わかり
| 機能 | Depot | Latchkey |
|---|---|---|
| runs-onラベルによるドロップイン | 対応 | 対応 |
| GitHubホスト型より安価 | 対応（Depot: GitHubホスト型の約半分のコスト） | 対応（分単価が最大70%低い） |
| 組み込みキャッシュ | 対応（統合分散キャッシュ、Depotによる） | 対応（依存関係 + Dockerレイヤー） |
| Dockerビルド統合 | 強力（runnerの隣にBuildKitビルダー） | 標準的なDockerレイヤーキャッシュ |
| 自己修復CI（一時的な失敗の自動修正 + 再試行） | 非対応 | 対応 |
| runnerの種類 | Intel x86、ARM、macOS、Windows、GPU（GPUはBusinessプラン） | マネージドLinux runnerサイズ |
| 最も知られている点 | 高速CPU + 強力な分散キャッシュ + Dockerビルド | 自己修復による信頼性 + 低コスト |
Depotとは
Depotは、既存のworkflowにドロップインするマネージドGitHub Actions runnerを提供します。Depotのドキュメントによれば、runs-onラベルを変更してジョブを切り替えるので、YAML、actions、stepsはそのままです。Depotは第4世代AMD EPYC「Genoa」CPU上で動作し、統合分散キャッシュを備えます。Depotによれば最大約1000 MiB/sのアップロード/ダウンロードと、設定変更なしで約10倍高速なキャッシュを実現します。Dockerイメージのビルドにも Depotを使う場合、BuildKitビルダーはrunnerの隣で動作します。depot.dev/docs/github-actions/overview を参照してください。
Depotが本当に得意なこと
評価すべき点は評価します。Depotの分散キャッシュとリモートDockerビルドとの緊密な統合は本物の強みです。キャッシュヒット率とBuildKitのビルド速度がCI時間を支配するコンテナ中心のパイプラインでは、Depotは強力な選択で、高速なGenoa CPUはCPUバウンドのstepsにも役立ちます。Depotの有名な「最大55倍高速なビルド」というキャッチコピーは、runnerではなくリモートDockerビルド製品を指すことに注意してください。
なぜ一部のチームがLatchkeyに移行するのか
最も一般的な理由は信頼性です。高速なrunnerでも、メモリ不足によるkill、ディスク満杯エラー、registryのタイムアウトなど一時的および機械的な問題で失敗し、それらのジョブの再実行はお金と時間を消費します。Latchkeyは自己修復CIを加えます。これらの失敗を自動的に検出、診断、修正、再試行するので、不安定なビルドがパイプラインを落とすことがなくなります。Latchkeyはまた、GitHub Actionsより分単価が最大70%低いこと、待ち時間ゼロ、AIによるビルド最適化を挙げています。あなたの痛みが生のDockerビルドのスループットではなく不安定な再実行とコストなら、それが報われる乗り換えです。
移行方法（ステップバイステップ）
- パイロットする workflowを1つ選びます。理想的には時々不安定な失敗が起きるものです。
- 現在のDepotでは、そのジョブのruns-onはDepotのrunnerラベルを指しています。1行で戻すか横に切り替えます。runs-onを対象のマネージドrunnerラベルに変更します。
- Latchkeyでは変更は対称的です。runs-onをLatchkeyのrunnerラベルに設定します。新しいCIプラットフォームも、インフラも、YAMLの書き直しもありません。
- パイロットを実行し、実時間、コスト、赤くなる代わりに自己修復した一時的な失敗の数を比較します。
- 満足したらラベル変更を残りのworkflowに展開し、Dockerビルドに支配されたジョブでDepotが勝つなら、そこにはDepotを残します。
結論
CIがDockerイメージのビルドとキャッシュヒット率に支配されているなら、Depotは堅実な選択で、それらのジョブでは維持する価値があります。より大きな問題が不安定な再実行と分単価なら、Latchkeyへの移行はruns-onの1行変更で、低コストのマネージドrunnerの上に自己修復による信頼性を加えます。単一のworkflowでパイロット導入し、実際のビルドと比較してください。ベンダー価格は変わるため、常にdepot.dev/pricingで現在のDepotの価格を確認してください。