RunsOnからLatchkeyへの移行方法（セルフホストからマネージドへ）
RunsOnはGitHub Actionsのランナーを自社のAWSアカウント内で実行します。Latchkeyはフルマネージドサービスとしてそれらをあなたの代わりに実行します。移行とは運用を引き渡すことであり、新しいCIシステムを学ぶことではありません。
RunsOnのドキュメントによれば、RunsOnはライセンスの下でセルフホストするコントロールプレーンです。エフェメラルなEC2ランナーが自社のAWSアカウント内で起動し、ジョブごとに1台のマシン、デフォルトでスポット、EC2/S3の請求はマークアップなしで直接あなたに届きます（runs-on.com）。これは最大限のコントロールと低いコンピュートの生コストをもたらしますが、CloudFormationスタック、IAMロール、スポットキャパシティ、AWSのクォータはあなたが所有します。Latchkeyはフルマネージドで、運用すべきAWSアカウントやスタックはなく、自己修復を追加します。一時的および機械的な障害は自動的に検出、修正、リトライされます。両者とも標準のGitHub Actionsランナーをラベルでアタッチするため、移行そのものはruns-onを1行変更するだけです。移行を計画する前に、runs-on.comで現在のRunsOnの価格と機能を確認してください。
RunsOn vs Latchkey の概要
| 機能 | RunsOn | Latchkey |
|---|---|---|
| ホスティングモデル | 自社のAWSアカウント内でセルフホスト | フルマネージド（AWSアカウント不要） |
| 運用するインフラ | CloudFormationスタック、IAM、VPC、スポット、クォータ | なし |
| コンピュートの請求 | AWSが直接請求、マークアップなし（RunsOnのドキュメント） | 分単位、マネージド |
| 自己修復による障害対応 | なし（ドキュメントによればスポットは一度だけオンデマンドへ自動リトライ） | あり（検出、修正、リトライ） |
| 切り替えに必要なワークフロー変更 | runs-onラベルを1行（RunsOnのドキュメント） | runs-onラベルを1行 |
| 最適な用途 | 最大のコントロール + 最も低い生スポットコスト | 運用ゼロ + 自己修復 |
維持するものと引き渡すもの
両者とも標準のGitHub Actionsランナーを使うため、ワークフロー、アクション、YAMLはそのままです。Latchkeyで引き渡すのは、RunsOnが自社のAWS内で運用するよう求める運用面です。CloudFormationスタック、VPCとサブネット、IAMロールとパーミッションバウンダリー、スポットキャパシティ管理、AWSのサービスクォータ（すべてruns-on.com/quickstartおよびruns-on.com/docsに記載）。Latchkeyでは管理すべきスタックもAWSアカウントもありません。
移行の手順
- 現在ワークフローが使用しているランナーラベルを棚卸しします（RunsOnのラベルは
runner=16cpu-linux-arm64やcpu=4/ram=16/family=c7a+m7aのような制約クエリです。runs-on.com/runnersを参照）。 - 各ラベルを同等のLatchkeyマネージドランナーのサイズにマッピングします。
- 1つのパイロットワークフローでruns-onラベルを切り替え、実時間と信頼性を比較します。
- 残りのワークフローを展開し、トラフィックが完全に切り替わったら、自社のAWSアカウント内のRunsOn CloudFormationスタックを廃止します。
Latchkeyが追加するもの
Latchkeyは自己修復型のCIを中心に構築されています。メモリ不足によるkill、ディスクフルのエラー、レジストリのタイムアウトなどの一時的な障害は自動的に検出およびリトライされるため、再実行に対する支払いがなくなります。また、スタック、IAM、管理すべきスポットキャパシティがないため、RunsOnがあなたに残すAWSの運用も取り除きます。
結論
データ所在地のために自社のAWSアカウント内でランナーを実行することと、最も低い生スポットコストが、スタックを自分で運用する価値に見合うなら、RunsOnに留まりましょう。CloudFormation、IAM、スポット、クォータの作業を引き渡し、すべてのジョブで自己修復を得たいなら、Latchkeyがマネージドの移行先です。無料で始めて、切り替える前に1つのワークフローでパイロットを行いましょう。