弊社ではGitHub Actionsのサードパーティのランナーサービスとして「Blacksmith」を導入しました。
導入から１ヶ月以上経過したので簡単な導入結果を記載しておきます。
なぜBlacksmithを採用したのか
弊社ではラッコキーワードやラッコM&Aなど様々な自社サービスを抱えており、テストやデプロイなど様々な場面でGitHub Actionsを使用しています。
開発規模の拡大に伴ってランナーの要求スペックが少しずつ上がってきたため、コスパを求めてGitHub Actionsのサードパーティのランナーサービスを比較し、移行のしやすさとDockerビルドの高速性でBlacksmithを採用しました。
導入結果
タイトル通りですがコストは約75%削減され、実行時間は平均50%高速化しました。
| 導入 | GitHubのコスト | ジョブの平均速度 |
|---|---|---|
| Blacksmith導入前 (9月) | 約160ドル | 約2分 |
| Blacksmith導入後 (10月) | 約160ドル | 約1分 |
↓以前のGitHub Actionsのコスト
↓Blacksmith導入後の現在のGitHub Actionsのコスト (Blacks smithのコスト)
↓以前のGitHub Actionsのジョブの平均速度
↓Blacksmith導入後のGitHub Actionsのジョブの平均速度
注意点
Migration Wizardのランナーのデフォルトが4vCPU
BlacksmithにはMigration Wizardというリポジトリのランナーの記述を書き換えるPRを作成してくれる便利な機能があります。
ですが、デフォルトの4vCPUのままだとGitHub Actionsの標準ランナーは2vCPUなので過剰スペックになります。
セレクトボックスで2vCPUへの変更を忘れないように注意してください。
ごく稀にワークフローが動かないケースがある
なぜかPHPの単体ユニットのワークフローだけcomposer installがコケて動きませんでした。
Your lock file does not contain a compatible set of packages. Please run composer update.
ロックファイルに互換性のあるパッケージセットが含まれていません。composer updateを実行してください。
エラー通りにロックファイルを更新しても解消しないので、このワークフローだけ移行せずに標準ランナーのままにしています。
動かなかったのはこのワークフローだけでGitHub Actionsの無料枠で収まる実行頻度なので大きな問題はありませんでした。
所感
2x faster + 50% per-minute cost reduction = 75% savings.
https://www.blacksmith.sh/pricing
Blacksmithは2倍早くて50%安いのでコストを最大75%削減できると謳っています。
弊社の導入では偶然にもその通りコストを約75%削減できましたが、実際には処理の数など変動要素があるのであくまで理論上の話だと思います。
ですがGitHub Actionsのコストを削減できることはほぼ間違いないと思うので、GitHub Actionsを多用する方はぜひBlacksmithを導入してみてください。
Discussion