ActuatedからLatchkeyへの移行: セルフホストmicroVM vs マネージドランナー
Actuatedは自社で所有・運用するハードウェア上でFirecracker microVMの分離を提供します。Latchkeyは運用するサーバーなしで完全マネージド・自己修復のランナーを提供します。これが正直なトレードオフであり、マネージドの方が適している場合の移行方法です。
Actuated（actuated.com）はセルフホストのCIシステムです。自社のベアメタルまたはネストされた仮想化サーバーにエージェントをインストールし、すべてのGitHub Actionsのjobは高速起動するFirecracker microVM上でVMレベルの分離とネイティブなArmサポートとともに実行されます。これにより強力な分離と自社ハードウェアへの制御が得られますが、サーバーは自分で運用します。Latchkeyは逆のアプローチを取ります。1行のruns-on変更で到達できる完全マネージドのランナー上でGitHub Actionsを実行し、自己修復CIを追加して一時的・機械的な障害が自動的にリトライされるようにし、プロビジョニング・パッチ適用・オンライン維持が必要なサーバーを一切残しません。両者の比較と移行の様子を以下に示します。
一目でわかる比較
| 機能 | Actuated | Latchkey |
|---|---|---|
| モデル | 自社サーバー上のセルフホストエージェント | 完全マネージドランナー |
| 分離 | jobごとのFirecracker microVM（強力） | jobごとに分離（マネージド） |
| プロビジョニング・運用するサーバー | あり（ベアメタルまたはネスト仮想化） | なし |
| Arm / Arm64サポート | あり（Armホスト上でネイティブ） | あり（マネージド） |
| 自己修復CI（一時的障害の自動リトライ） | なし | あり |
| セットアップ | orgの登録、サーバーのプロビジョニング、エージェントのインストール | 1行のruns-onラベル変更 |
| 得意分野 | 所有ハードウェア上のmicroVM分離 | 自己修復 + マネージドランナー |
Actuatedが本当に優れている点
Actuatedは分離と制御が最も重要な場合に強力な選択肢です。各jobは独自のFirecracker microVM上で実行され、約1秒で起動しbuild後に破棄されます。ドキュメントではこれをコンテナベースのランナーより強力な分離として位置づけており、Docker-in-Dockerの回避策なしにsudo、Docker、Kubernetesをネイティブにサポートします。自社のベアメタルまたはArmホスト上で実行するため、制御下のハードウェアにデータを保持でき、エミュレーションなしでネイティブなArm64 buildを得られます。ハードウェアの所有と分離境界が要件であれば、Actuatedはそのために作られています。
Latchkeyに移行すると何が変わるか
Actuatedで手放す主なものは、サーバーを自分で運用する点です。KVM対応ホストのプロビジョニング、パッチ適用、オフラインエージェントの監視、並行性に合わせたフリートのサイジングです。Latchkeyはこれを完全に取り除きます。完全マネージドなので運用するサーバーはなく、自己修復CIを追加します。メモリ不足によるkill、ディスクフルエラー、registryのタイムアウト、その他の一時的・機械的な障害が検出され、パイプラインを失敗させる代わりに自動的にリトライされます。またGitHubホストのランナーより最大70%低い分単価を報告し、AIによるbuild最適化を含みます。目標が分離境界の所有ではなく低運用のマネージドCIであれば、それが行うトレードオフです。
移行の仕組み
- 既存のworkflowはそのまま維持します。変わるのはruns-onの行だけです。
- まず1つのworkflowで、
runs-on: actuated-4cpu-16gbのようなActuatedのラベルをLatchkeyのランナーラベルに置き換えます。 - そのパイプラインをLatchkey上で実行し、実時間・コスト・再実行率をActuatedと比較します。
- どちらも標準のGitHub Actionsを使うため、学ぶべき新しいCIプラットフォームはなく、どちらの方向にもロックインはありません。
結論
ハードウェアの所有とmicroVMの分離境界が重要なポイントであれば、Actuatedは堅実な選択であり維持する価値があります。サーバーをまったく運用したくなく、不安定な障害から自動的に回復するパイプラインが欲しいなら、Latchkeyの方が適しています。単一のworkflowでLatchkeyを試験導入し、決定前にActuatedのbuildと比較できます。