Blacksmithは小規模リポジトリでも高速化するのか実測してみた

どうも！オペ部の西村祐二です！

GitHub Actionsの高速化プラットフォームBlacksmithは、大規模なCI/CDパイプラインでの導入事例をよく見かけます。一方で、ワークフローの数が少ない小規模なリポジトリでも導入する価値があるのかは気になるところです。

今回、実際に小さめのサンプルリポジトリにBlacksmithを導入して計測してみたので、セットアップから各機能の設定方法、計測結果までをまとめます。

そして、どんなプロジェクトにマッチしそうか検討してみました。

Blacksmithとは

Blacksmithは、GitHub Actionsのruns-onを書き換えるだけで導入できるdrop-in replacementのランナーサービスです。ベアメタルのゲーミングCPUとNVMeストレージを活用し、以下のような改善が見込めるとされています。

• ランナーの実行速度が約2倍
• キャッシュダウンロードが約4倍高速
• Dockerビルドが最大40倍高速
• コストはGitHubホストランナーと比較して約60%削減（顧客事例では最大75%の削減例もあり）

ランナーの高速化以外にも、ダッシュボードによるジョブ分析やSSHデバッグなど、CI/CDの可観測性を向上させる機能も充実しています。

前提条件

• GitHub組織（Organization）を持っていること
• GitHub Actionsを利用していること
• リポジトリの管理者権限があること

セットアップ

アカウント作成とGitHub Appのインストール

Blacksmithのダッシュボードにアクセスし、GitHubアカウントで認証します。

認証後、対象のGitHub組織にBlacksmith GitHub Appをインストールします。

インストールが完了したらダッシュボード画面にアクセスすることができます。

インストール状況はgh apiで確認できます。

$ gh api /orgs/<org名>/installations --jq '.installations[].app_slug'
blacksmith-sh

これだけでセットアップは完了です。あとはワークフローのruns-onを書き換えるだけで使い始められます。

各機能の設定と検証

ここからは、デモリポジトリを使って各機能を設定し、GitHub hostedランナーとの比較結果を見ていきます。

検証には、FastAPI + uv + ruff + pytest のPythonプロジェクトを用意しました。GitHub hostedとBlacksmithの両方のワークフローで同じ処理を実行し、比較しています。

blacksmith-demo/
├── src/blacksmith_demo/
│   ├── __init__.py
│   └── main.py          # FastAPI API
├── tests/
│   └── test_main.py     # pytest テスト
├── Dockerfile            # マルチステージビルド
├── pyproject.toml        # uv + ruff 設定
└── .github/workflows/
    ├── ci-github.yml           # CI（GitHub Hosted）
    ├── ci-blacksmith.yml       # CI（Blacksmith）
    ├── docker-github.yml       # Dockerビルド（GitHub Hosted）
    └── docker-blacksmith.yml   # Dockerビルド（Blacksmith）

ランナーの切り替え

既存のワークフローファイルのruns-onを変更するだけでBlacksmithランナーに切り替えられます。

変更前:

jobs:
  build:
    runs-on: ubuntu-latest

変更後:

jobs:
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2204

ランナー名はblacksmith-[vCPU数]vcpu-[OS]-[バージョン]の形式で指定します。ARM64を使いたい場合は末尾に-armを付けます（例: blacksmith-8vcpu-ubuntu-2204-arm）。

依存関係キャッシュ + Sticky Disk

Blacksmithでは、actions/cache@v4や各言語のセットアップアクションのキャッシュ機能がそのまま利用できます。キャッシュデータはBlacksmithのデータセンター内のNVMeストレージに保存されるため、GitHubのキャッシュと比較して約4倍高速にダウンロードできるとのことです。

今回の検証ではuv + astral-sh/setup-uv@v4を使用しました。追加の設定は不要で、Blacksmithランナー上で実行するだけで自動的にBlacksmithのキャッシュインフラが使われます。

さらに、Sticky Diskを使ってuvのキャッシュディレクトリを永続化しました。Sticky Diskはランナー間でファイルを永続化するためのストレージ機能で、公式ドキュメントによると6GBのデータで400MB/s（GitHub Actionsのキャッシュは90MB/s）のダウンロード速度が得られるとのことです。

- uses: astral-sh/setup-uv@v4
  with:
    enable-cache: true

- uses: useblacksmith/stickydisk@v1
  with:
    key: ${{ github.repository }}-uv-cache
    path: ~/.cache/uv

ポイント:

• 依存関係キャッシュはリポジトリあたり週25GBの無料ストレージが付属
• ブランチ保護キャッシュが標準搭載されている
• Sticky Diskの料金は$0.50/GB/月（us-westとeu-centralリージョンで利用可能）

CI計測結果（小規模構成: 依存4パッケージ）

まず、依存4パッケージ・テスト5ケースの小規模構成で計測しました。

CI（ruff lint + ruff format + pytest）:

小規模構成では、処理自体が軽いためBlacksmith側のランナーセットアップやSticky Disk初期化のコストが相対的に目立つ結果となりました。

Dockerレイヤーキャッシュ

Dockerビルドの高速化には、Blacksmith専用のアクションを使います。NVMeドライブ上にDockerレイヤーを永続化することで、最大40倍の高速化が可能とされています。

ワークフローではuseblacksmith/setup-docker-builder@v1でDocker Builderを初期化し、useblacksmith/build-push-action@v2でビルドを実行します。

jobs:
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2204
    steps:
      - uses: useblacksmith/checkout@v1
      - uses: useblacksmith/setup-docker-builder@v1
      - uses: useblacksmith/build-push-action@v2
        with:
          context: .
          push: false
          tags: blacksmith-demo:latest

GitHub hosted側では通常のdocker/setup-buildx-action@v3とdocker/build-push-action@v6を使い、GHAキャッシュで比較しました。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: false
          tags: blacksmith-demo:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

Dockerビルド計測結果（小規模構成）

python:3.12-slimベースのマルチステージDockerfileでの結果です。

Dockerビルドについても、小規模構成ではGitHub hostedのほうが速い結果でした。特に差が大きかったのは1回目（キャッシュなし）で、Blacksmith側が約2分かかっています。これはuseblacksmith/setup-docker-builderによるDocker Builder初期化のオーバーヘッドが大きいためと考えられます。一方で、GitHub hosted側はdocker/setup-buildx-action + GHAキャッシュの組み合わせが軽量に動作しており、キャッシュありでは17秒まで短縮されています。

2回目（キャッシュあり）でもBlacksmithが80秒かかっている点を見ると、Dockerレイヤーキャッシュの効果よりもDocker Builder初期化のコストが支配的な状態です。公式が謳う「最大40倍の高速化」は、ビルド自体に数分〜数十分かかるような大規模イメージで初めて実感できるものと思われます。

Gitチェックアウトキャッシュ（Beta）

useblacksmith/checkout@v1を使うと、リポジトリのクローンをキャッシュし、2回目以降は差分のみ取得するようになります。actions/checkout@v4をそのまま差し替えるだけで使えます。

- uses: useblacksmith/checkout@v1

dissociate: trueオプションを指定すると、キャッシュから独立した自己完結型のチェックアウトが作成されます。

大規模リポジトリでチェックアウトに時間がかかっている場合に有効ですが、今回の小規模リポジトリでは効果を確認できませんでした。

追加検証: 依存を増やして再計測

小規模構成ではBlacksmithの高速化効果が見られなかったため、依存パッケージを大幅に増やし、Dockerイメージも重くして再検証しました。

追加検証構成

• 依存パッケージ: 90個（pandas, polars, scikit-learn, numpy, scipy, matplotlib, boto3, SQLAlchemy, Celery 等）
• テスト: 15ケース（CRUD + データ分析 + ML推論）
• Docker: マルチステージビルド（python:3.12フルイメージ + build-essential + uv）

FROM python:3.12 AS builder

RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential gfortran libopenblas-dev liblapack-dev pkg-config \
    && rm -rf /var/lib/apt/lists/*

COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/

WORKDIR /app

COPY pyproject.toml uv.lock README.md ./

RUN uv sync --frozen --no-dev --no-install-project

COPY src/ src/

RUN uv sync --frozen --no-dev

FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    libopenblas0 libgomp1 curl \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY --from=builder /app/.venv /app/.venv

ENV PATH="/app/.venv/bin:$PATH"

EXPOSE 8000

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
    CMD curl -f http://localhost:8000/health || exit 1

CMD ["uvicorn", "blacksmith_demo.main:app", "--host", "0.0.0.0", "--port", "8000"]

追加検証構成での計測結果

小規模構成をそのまま修正して依存を追加したため、小規模構成時のキャッシュ（uvキャッシュ、Dockerベースイメージのレイヤー等）が一部残った状態での計測です。

CI（ruff lint + ruff format + pytest）:

Dockerビルド:

依存を大幅に増やしても、CI処理はほぼ同等の結果でした。これは今回の検証の限界で、依存パッケージ数を増やしただけではCI全体の処理時間はあまり変わりませんでした。ruff lint + pytestの実行時間が支配的で、依存インストール自体はボトルネックではなかったためです。Blacksmithの高速化効果を引き出すには、ビルドやテスト実行そのものに数分以上かかる構成で検証する必要がありそうです。

可観測性機能

Blacksmithのダッシュボードでは、追加料金なしで以下の機能が利用できます。これらの機能は高速化の効果に関わらず魅力的です。

ジョブ分析: 全リポジトリのジョブ実行状況を可視化し、パフォーマンスのボトルネックを特定できます。

ログ検索: 正規表現に対応した高速なログ検索機能です。ブランチやログレベルでフィルタリングできます。

branch:main level:error,warn -"econn refused"

マシンメトリクス: CPU使用率、メモリ使用率、ネットワークI/Oが自動的に収集され、ジョブステップ別のタイムラインで確認できます。

アラート設定: Slackと連携し、ジョブの連続失敗時に通知を受け取れます。

SSHデバッグ: 実行中のジョブにSSHでアクセスし、VMの状態を直接調査できます。最大8時間までVMを保持できます。今回未検証ではありますが、CI上のトラブルシューティングでとても便利そうな機能です。

どんなプロジェクトにマッチしそうか

今回の構成ではBlacksmithの高速化効果を体感するには至りませんでした。今回の検証環境がBlacksmithの強みを引き出しにくい構成だったためと考えています。

今回差が出にくかった要因:

• ワークフロー全体が軽量: CI全体が20秒前後、Dockerビルドも数十秒で完了する構成では、Blacksmith側のランナーセットアップやSticky Disk初期化（数秒〜十数秒）の固定コストの比率が大きくなり、処理速度の向上分を相殺してしまう
• 依存インストールが処理時間のボトルネックではなかった: 今回のCIでは、ruff lint + pytest の実行が時間の大部分を占めており、依存インストール自体は短時間で終わっていた。そのため、キャッシュ高速化の恩恵を受ける場面が少なかった

Blacksmithがマッチしそうなプロジェクト:

以下のようなプロジェクトではBlacksmithの強みが活きると考えられます。

• CI全体のビルド時間が長いプロジェクト: テスト実行やビルドに数分〜数十分かかるような場合、ベアメタルのゲーミングCPUによる処理速度の向上が効いてくる。ランナーセットアップの固定コスト（数秒〜十数秒）の比率も小さくなる
• 依存インストールがボトルネックになっているプロジェクト: pip + requirements.txtで依存インストールに数分かかるようなケースでは、NVMeベースのキャッシュ高速化やSticky Diskの恩恵が大きい
• 大規模なDockerイメージをビルドするプロジェクト: ベースイメージが数GB、ビルド時間が10分を超えるようなケースでは、Sticky Disk上のレイヤーキャッシュが効果的
• モノレポや大規模リポジトリ: Git履歴が数万コミット、リポジトリサイズが数GBに達する場合、useblacksmith/checkoutによるチェックアウトキャッシュの効果が見込める
• キャッシュサイズが大きいプロジェクト: GitHub Actionsのキャッシュ制限（10GB）に悩んでいる場合、Blacksmithの25GB/週の無料枠やSticky Diskが有効

ポイントは、Blacksmithのランナーセットアップには固定のオーバーヘッドがあるという点です。ワークフロー全体の処理時間が長いほどそのオーバーヘッドの比率が下がり、高速化の効果を実感しやすくなります。今回の検証（CI: 20秒前後）ではこのオーバーヘッドが相対的に大きかったため差が出ませんでしたが、数分〜数十分かかるワークフローであれば結果は異なると考えられます。

料金について

詳細はBlacksmith公式の料金ページを参照してください。

ランナー料金（従量課金）

すべてのプランに月3,000分の無料枠が付いています。

Blacksmithは「2倍高速なハードウェア + 分単価の削減」を組み合わせることで、GitHub hostedと比較して最大75%のコスト削減が見込めるとしています。処理が2倍速で終われば利用分数が半分になり、さらに分単価も安いためです。

基本機能（追加料金なし）

• 依存関係キャッシュ（リポジトリあたり25GB/週）
• ダッシュボード（ジョブ分析・ログ検索・マシンメトリクス）
• SSHデバッグ
• 4倍高速なキャッシュダウンロード

アドオン

その他

• Enterpriseプラン: 99.9% SLA、24/7優先サポート、専用Slackチャネル等（要問い合わせ）
• スタートアップ割引: 従業員100名未満・資金調達5,000万ドル未満・設立5年未満の企業向けの割引あり
• OSSプログラム: オープンソースプロジェクト向けに無償提供あり

まとめ

Blacksmithは、runs-onの変更だけで導入でき、キャッシュやDockerビルドの高速化、充実した可観測性機能など多くの機能が利用できます。セットアップの手軽さは魅力的で、既存のワークフローをほぼそのまま移行できる点が好印象でした。
依存関係キャッシュやダッシュボード機能は無料で、runs-onを戻すだけで元に戻せるため、自分のプロジェクトで気軽に試せる点も良かったです。

今回の小規模リポジトリでは高速化効果を実感するには至りませんでしたが、これはワークフロー全体が軽量（CI: 20秒前後）で、Blacksmithの固定オーバーヘッドを吸収するほどの処理量がなかったためです。
ビルドやテストに数分以上かかるプロジェクト、大規模なDockerビルド、モノレポなどでは、Blacksmithの強みが活きる場面が多いと思われます。

誰かの参考になれば幸いです。

参考リンク:

• Blacksmith公式サイト
• Blacksmithドキュメント
• Blacksmith料金ページ
• Blacksmith GitHub App