ドキュメントメニュー
はじめに
ダッシュボードと分析
マネージドランナー
キャッシュ
チームと通知
請求とプラン
ヘルプ
マネージドランナーの概要
Latchkey ランナーとは何か、4 つのサイズとその価格、GitHub ホステッドランナーとの違い、そして最初のジョブの前に必要なものについて説明します。
Latchkey のマネージドランナーは、GitHub Actions のジョブを実行するエフェメラルな仮想マシンです。各ランナーは正確に 1 つのジョブを実行し、その後破棄されるため、すべてのジョブはクリーンで隔離されたマシンから始まります。すべてのランナーには 自己修復 も組み込まれています。
サイズと価格#
| ラベル | vCPU | メモリ | ディスク | 価格 |
|---|---|---|---|---|
latchkey-small | 2 | 8 GB | 100 GB | $0.0025/min |
latchkey-medium | 4 | 16 GB | 100 GB | $0.0050/min |
latchkey-large | 8 | 32 GB | 100 GB | $0.0100/min |
latchkey-xlarge | 16 | 64 GB | 200 GB | $0.0200/min |
すべてのランナーは x86_64 上の Ubuntu 24.04 LTS (AWS m6a クラスのハードウェア) で、包括的なプリインストール済みツールチェーン を備えています。課金は 1 分単位で、ジョブごとに切り上げられ、すべてのプランに毎月の無料分が含まれます (Developer で 2,000、Launch で 4,000、Scale で 6,000。つまり中位ティアでは月 4,000 で、GitHub の 3,000 に対してです)。ランナーの使用量と無料分 を参照してください。
どのサイズを選ぶべきか?#
以下の内容は規則ではなく指針として扱ってください。あなた自身のジョブの実行時間こそが本当のベンチマークです。ほとんどのチームに役立つパターンは、すべてを latchkey-small にデフォルト設定し、より多くを必要とすると証明された特定のジョブだけを昇格させることです。
| サイズ | 最初によく合う用途 | 理由 |
|---|---|---|
latchkey-small | Lint、ユニットテスト、スクリプト、小規模ビルド | ほとんどの CI ジョブは I/O バウンドまたはシングルコアバウンドで、2 vCPU / 8 GB が最低料金でそれらをカバーします |
latchkey-medium | 一般的なアプリのテストスイート、Docker イメージビルド | small の 2 倍の CPU とメモリで、並列テストランナーとマルチステージイメージビルドに対応します |
latchkey-large | コンパイル負荷の高いビルド、並列統合スイート | 8 vCPU / 32 GB はコア数に応じてスケールする作業に適しています: 大規模な TypeScript、Rust、Java、C++ のビルド |
latchkey-xlarge | モノレポビルド、メモリを大量に消費するエンドツーエンドスイート | 16 vCPU / 64 GB に加えて 200 GB のディスクで、そうでなければ分割が必要な最も重いジョブに対応します |
このラインナップの 2 つの特性が、適切なサイジングを考えやすくします。1 段階上がるごとに vCPU、メモリ、1 分あたりの料金が倍になるため、あるジョブを 1 サイズ上げるのは、そのジョブの所要時間を少なくとも半分にできるときに割に合います: 同じかそれ以下のコストで、より速いフィードバックが得られます。そして runs-on はワークフローごとではなくジョブごとに選択されるため、latchkey-large 上の 1 つの重いビルドジョブが、あなたの lint ジョブを latchkey-small から追い出すことは決してありません。
チームが乗り換える理由#
- 価格: GitHub ホステッドよりランナー 1 分あたり最大 70% 安く、GitHub が含めるよりも多くの無料分があります (中位ティアで 3,000 に対して 4,000)。
- 速度: コールドスタートが約 10 秒 (GitHub ホステッドは通常 30-60 秒) でキュー待ち時間ゼロ、ウォームピックアップは数秒で完了します。
- 自己修復: 一時的な障害 (レジストリのタイムアウト、OOM kill、ディスク満杯、ツール欠如) が実行中に検出され修正されます。
- 隔離: ランナーごとに 1 ジョブで、インバウンドアクセスのないプライベートネットワーク上にあり、ジョブ後に破棄されます。
- 管理すべきインフラがゼロ: ビルドすべきランナーイメージも、調整すべきオートスケーリングも、パッチを当てるべきランナーエージェントもありません。
設計によりエフェメラル#
すべてのランナーは 1 つのジョブのために作成され、そのジョブが終了した瞬間に破棄されます。ジョブ間で何も持続しません: 残ったプロセスも、古いキャッシュも、以前のジョブがディスクに書き込んだファイルもありません。そのクリーンマシンの保証こそが、実行を再現可能にするものです。ジョブが今日は成功し明日は失敗する場合、その違いはあなたの変更や依存関係にあり、長命なマシンに蓄積された状態にあるのではありません。
同じ特性がセキュリティのストーリーも支えます。ランナーは単回使用の認証情報でジャストインタイムに登録され、インバウンドアクセスのないプライベートネットワーク上で動作し、正確に 1 つのジョブを受け取って破棄されます: あるジョブが別のジョブを観測する余地はなく、パッチや堅牢化を要する長命なマシンもありません。全体像は セキュリティと権限 を参照してください。
これを念頭に計画してください: ランナーのローカルディスクに書き込まれたものは、ジョブが終わると消えます。GitHub ホステッドランナーとまったく同じように、ビルド出力はアーティファクトとして永続化し、インストールはキャッシュで高速化してください。
前提条件#
- Latchkey の GitHub App がインストールされている こと (組織に対して)。
- リポジトリが Latchkey で 監視されている こと。
- マネージドランナーがワークスペースで有効になっていること (アプリのインストール時に自動的にセットアップされます。ダッシュボードの Latchkey Runners ページで準備状況と構成を確認できます)。
- サブスクリプションまたはトライアルがアクティブであること。期限切れのトライアルや失効したサブスクリプションではランナーの起動がブロックされます。ランナーの使用量と無料分 を参照してください。
プロビジョニングの仕組み#
GitHub が latchkey-* ラベルの付いたジョブをキューに入れると、Latchkey はそれを既にウォームなランナーに渡すか、新しいランナーを起動します:
ウォームランナーが利用可能
- 数秒でピックアップ
- Launch と Scale はウォームプール容量を含みます
- Scale はより大きく、複数サイズのプールを備えています
新しいランナー (コールドスタート)
- 新しいマシンがあなたのジョブのためだけに起動します
- 単回使用の認証情報でジャストインタイムに登録します
- 約 10 秒で稼働し、キュー待ち時間はゼロです
いずれの場合も、ランナーはジョブの後に破棄されます。4 つのプリセットに加えて、独自のラベルを持つ カスタムランナー構成 を作成でき、ダッシュボードの Runners ページ がそのすべてを管理する場所です。
うまくいく移行戦略#
一括移行は必要なく、避けることをお勧めします。GitHub ホステッドのラベルは latchkey-* ラベルと並行して機能し続けるため、一度に 1 ジョブずつ移動し、あなた自身のワークロードで両者を直接比較できます。
不安定または遅いワークフローが最良のパイロットになるのは、安い分、速いピックアップ、自己修復 がすべて、既に痛みのある場所に現れるからです。1 週間後、Runners ページ がコスト、節約、修復アクティビティを判断材料として提供します。確信が持てたら、Runners ページ の Migrate Runners ツール (オーナーと管理者) が、一度に最大 20 のリポジトリを切り替えるマージ準備済みのプルリクエストを開きます。GPU、Windows、macOS、arm64 ホストを必要とするジョブは GitHub ホステッドや他のランナーに留まり、単一のワークフロー内で混在させても問題ありません。
プロバイダー間で迷っていますか? Learn ライブラリには、GitHub ホステッド、Blacksmith、BuildJet などをカバーする独立した ランナー比較ハブ があり、さらに切り替える前にあなた自身の数字で支出を見積もる GitHub Actions コスト計算機 もあります。