Blacksmith의 GitHub Actions 러너가 동일 작업을 GitHub 호스팅 러너보다 3~4배 빠르게 처리했습니다 — 10회 반복 벤치마크

AI 요약

작성자는 Blacksmith와 아무런 제휴가 없으며, 비용을 받거나 의뢰를 받아 작성한 것이 아니라고 밝힙니다. 같은 GitHub Actions 작업을 GitHub-hosted의 ubuntu-latest와 Blacksmith의 blacksmith-4vcpu-ubuntu-2404 러너에 각각 지정하고, 실제 작업 구간을 10회씩 측정했습니다. GitHub 화면에 표시되는 전체 job wall-clock 시간이 아니라, Node.js 스크립트 호출 전후에 date +%s%N을 실행해 얻은 작업 구간의 wall-clock 밀리초를 사용했습니다. 반복 측정 전에 워밍업 1회를 수행하고 결과에서는 제외했습니다.

■ 개인 저장소에서 바로 실행되지 않는 제약

가장 먼저 확인된 제약은 Blacksmith가 개인 GitHub 저장소를 지원하지 않는다는 점입니다. 개인 계정 아래에 있던 gzip 압축 측정 harness 저장소에서 Blacksmith job을 실행했지만 오류 메시지 없이 무기한 queued 상태에 머물렀습니다. Blacksmith의 quickstart 문서에는 organization이라는 표현이 33회 등장하고 personal repo 관련 언급은 2회 있으며, 작성자는 이를 조직 저장소만 지원한다는 의미로 해석해 저장소를 새 GitHub organization으로 옮겼습니다. 해당 organization에 Blacksmith GitHub App을 설치하자 job은 수 초 안에 대기열을 벗어났습니다.

따라서 무료 월 3,000분과 신용카드 없이 시작할 수 있다는 조건이 있더라도, GitHub 개인 계정에 CI가 있는 경우에는 먼저 저장소를 organization으로 옮겨야 합니다. 앱 설치 뒤에는 저장소의 ubuntu-latest 설정을 Blacksmith용 설정으로 바꾸는 Migration Wizard pull request가 자동으로 생성됐습니다. 여러 workflow를 옮길 때는 편리하지만, 기본 브랜치에 자동 pull request가 생기는 것을 원하지 않는 경우에는 확인이 필요합니다.

■ 이미지와 초기 실행 과정에서 발생한 문제

Migration Wizard가 생성한 pull request는 blacksmith-4vcpu-ubuntu-2204를 가리켰지만 이 태그의 Ubuntu 22.04 이미지는 Blacksmith 인프라에서 제공되지 않아 다시 무기한 queued 상태가 됐습니다. blacksmith-4vcpu-ubuntu-2404로 바꾸자 실행이 진행됐습니다. 이후 한 번은 두 job이 모두 시작된 뒤 Blacksmith job이 약 5분 후 단계 하나도 실행하지 않은 채 취소됐습니다. 작성자는 이를 runner 이미지 문제보다는 계정 검증 과정의 문제로 보았지만, 원문에서는 원인을 확정하지 않습니다. 다음 실행은 정상 완료됐고, 아래 수치는 workflow에 반복 측정을 추가한 뒤 깨끗한 baseline을 확보한 다음 실행한 10회 측정에서 나왔습니다.

작성자는 이 과정이 평가를 막는 수준의 문제는 아니지만, 일정이 촉박하다면 무기한 queued 상태가 되는 원인 불명의 실행 한 번과 조용히 취소되는 실행 한 번 정도를 감안해야 한다고 설명합니다. job이 오류 없이 queued 상태에 머물 경우 계정 문제를 먼저 의심하기보다, organization 사용 여부와 Blacksmith에서 실제 제공하는 이미지 태그를 확인해야 합니다.

■ 10회 반복 벤치마크 결과

두 개의 병렬 job이 같은 두 Node.js 스크립트를 각각 10회 실행했습니다. 하나는 GitHub-hosted의 ubuntu-latest에서, 다른 하나는 blacksmith-4vcpu-ubuntu-2404에서 실행했습니다.

- client.js 메인 sweep: GitHub-hosted 평균 399.2ms, 범위 368~468ms입니다. Blacksmith 평균은 126.2ms, 범위 115~166ms로 3.17배 빠릅니다. - crossover.js fine sweep: GitHub-hosted 평균 278.3ms, 범위 256~307ms입니다. Blacksmith 평균은 73.7ms, 범위 69~83ms로 3.77배 빠릅니다.

두 스크립트 모두 양쪽 측정 범위가 한 번도 겹치지 않았습니다. client.js에서는 GitHub-hosted의 가장 빠른 실행인 368ms조차 Blacksmith의 가장 느린 실행인 166ms보다 느렸습니다. 실행 편차도 Blacksmith 쪽이 작았습니다. client.js의 범위 폭은 Blacksmith가 51ms, GitHub-hosted가 100ms였고, crossover.js에서는 각각 14ms와 51ms였습니다. 따라서 이 소규모 측정에서는 Blacksmith가 평균적으로만 빠른 것이 아니라 반복 실행 결과도 더 일정하게 나타났습니다.

■ 결과를 실제 CI 성능으로 일반화할 때의 한계

이 테스트는 CPU 사용량이 낮은 작은 Node.js 스크립트를 실행한 것이며, 전체 작업 시간은 약 2초 수준의 측정 loop에 가깝습니다. 의존성 설치, Docker layer build, 대규모 test suite가 시간을 지배하는 workflow에서는 속도 차이가 더 크거나 작게 나타날 수 있습니다. 또한 이번 비교는 4vCPU 크기의 runner와 하나의 job 유형만 사용했으며, Blacksmith가 제공하는 더 큰 runner 크기는 시험하지 않았습니다.

모든 실행이 Blacksmith의 무료 월 3,000분 범위 안에서 이뤄졌기 때문에 작성자는 실제 청구서를 만들지 않았습니다. 따라서 Blacksmith가 제시하는 분당 0.004달러 가격은 독립적으로 확인한 수치가 아니라 pricing page에 적힌 주장입니다. 별도의 dev.to 글에서 사용자가 전환 후 실행 시간 41% 감소, 실행당 비용 45% 감소, 실행 속도 2.4배 향상을 보고했다는 내용도 언급되지만, 이는 이번 작성자의 측정이나 Blacksmith의 공식 측정이 아니며 검증할 수 없다고 선을 긋습니다.

■ 성능 외의 도입 판단

Blacksmith는 bare-metal 하드웨어와 공유 가상화 환경을 사용하는 GitHub-hosted runner의 대안으로, gaming CPU 기반 Firecracker microVM을 제공한다고 설명합니다. 설정 변경은 runs-on: ubuntu-latest를 runs-on: blacksmith-4vcpu-... 형태로 바꾸는 방식이 핵심입니다. 작성자의 두 측정값인 3.17배와 3.77배는 Blacksmith가 자체적으로 내세우는 2~4배 빠른 build라는 범위 안에 들어가지만, 이는 하나의 소규모 통제 비교 결과이지 production pipeline 전체를 검증한 결과는 아닙니다.

작성자는 성능 자체는 실제로 확인됐다고 보면서도 자신의 CI를 Blacksmith로 옮기지는 않겠다고 말합니다. 실제 workload가 개인 저장소에 있어 organization으로 옮기는 변경이 필요하고, GitHub App 설치 시 actions, workflows, contents, pull requests, self-hosted runners에 대한 write access를 부여하기 때문입니다. 이 권한 범위는 기능상 이해할 수 있지만, 저장소에 상당한 접근 권한을 갖는 제3자 앱이라는 점을 고려해야 합니다. 하루에 짧은 job 몇 개만 실행하는 환경에서는 3~4배 속도 향상이 체감할 만큼 중요하지 않아 GitHub-hosted runner를 그대로 사용하겠다는 판단입니다. 반대로 organization에서 이미 CI를 운영하고 실행 시간이 누적되는 pipeline이라면, 이번 측정은 Blacksmith 도입을 검토할 근거가 될 수 있다고 설명합니다.

벤치마크 workflow와 원시 실행 로그는 Shed-engineering/gzip-threshold-json-api 저장소에 공개되어 있으며, workflow 파일은 .github/workflows/blacksmith-benchmark.yml, 반복 측정 스크립트는 .github/scripts/run-trials.sh입니다. 다른 workload를 같은 방식으로 실행하려면 이 구성을 복사해 비교할 수 있습니다.

원문: dev.to / 번역·요약: Trawling