self-hosted runnerのコストとは？安い分単価の先へ

self-hosted runnerは分単位のコンピュートコストが低いことがありますが、その真のコストには、アイドルな容量、運用、そして比較にはめったに現れない信頼性の作業が含まれます。

チームがself-hosted runnerに移行するのは、hostedの分単位レートから逃れるためであり、生のクラウドコンピュートコストは確かにより低いものです。しかし「分あたりが安い」ことは「全体で安い」ことと同じではありません。fleetを自分で運用する隠れたコストは、しばしばその節約を打ち消します。これはまさに、managed runnerが埋めるために存在する隙です。

魅力的な部分：コンピュートレート

コモディティなクラウドVM上のself-hosted runnerは、分あたりおよそ生のインスタンス価格でコストがかかり、GitHub-hostedの割増である約$0.008/minを十分に下回ります。大量のCIでは、分単位の差は紙面上では大きな節約に見えます。

アイドルと利用率のコスト

self-hosted fleetはピークに合わせてサイズを決めなければならないのに、継続的に課金されます。オフピークには、それらのインスタンスはアイドルで座り、それでもお金がかかります。利用率が非常に高くない限り、忙しいminuteあたりの実効コストは、見出しのインスタンスレートをはるかに上回ります。

運用コスト

誰かがrunnerをプロビジョニングし、パッチを当て、スケーリングを管理し、ディスクを掃除し、tokenをローテーションし、imageを最新に保たなければなりません。このエンジニアリング時間は本物のお金であり、self-hostedのコスト比較で最も一般的に省かれる項目です。

信頼性コスト

長命なrunnerは古びていきます。ディスクが埋まり、cacheが破損し、jobの間で状態が漏れてflakyな失敗を引き起こします。各flakyな失敗は再実行とトリアージであり、hostedなephemeralなrunnerが回避するコンピュートと人的コストを加えます。

セキュリティとコンプライアンスのコスト

プライベートリポジトリ上のself-hosted runnerは攻撃対象領域を広げ、ハードニング、分離、監視を必要とします。そのガバナンス作業は、CIのminuteを一切課金しないにもかかわらず、真の所有コストです。

managed runnerが勝つところ

managed runnerは、運用なしにself-hosted風の経済性を与えます。Latchkeyはあなたのjobを、適正サイズのephemeralなクラウドインスタンス上でGitHub-hostedよりおよそ70%低く実行し、warm poolとクリーンアップを扱い、一時的な失敗を自己修復します。そのため、アイドル、運用、信頼性の税なしに低いレートが得られます。

重要なポイント

self-hostedの分単位コンピュートは安いですが、それがコストのすべてではありません。
アイドルなfleet、運用、信頼性、セキュリティは急速に積み上がります。
低い利用率は、忙しいminuteあたりの実効コストをはるかに高くします。