HN 소개: 오픈소스 x64 및 Arm GitHub 러너

 (ubicloud.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Ubicloud는 GitHub Actions용 관리형 러너를 제공해, 워크플로에서 1줄만 바꾸면 기존 사용 방식을 유지하면서 빌드 속도와 비용을 개선할 수 있다고 내세움
  • 가격은 Standard 분당 $0.0010, Premium 분당 $0.0016부터 시작하며 GitHub-hosted runners 대비 각각 85%, 70% 낮은 비용을 제시함
  • Standard는 AMD EPYC Genoa와 30GB 무료 캐시 스토리지, Premium은 AMD Ryzen 9와 100GB 무료 캐시 스토리지로 구분됨
  • 보안은 Linux KVM 기반 완전 격리 VM, 작업별 일회성 VM, GitHub Just-In-Time 러너 설정, 암호화와 키 순환을 중심으로 구성됨
  • Ubicloud는 오픈소스 클라우드를 지향하며, GitHub에서 소스 코드를 확인하거나 필요하면 자체 러너를 직접 관리할 수 있음

GitHub Actions 통합 방식

  • Ubicloud는 GitHub Actions용 관리형 러너를 제공하며, GitHub 워크플로에서 러너 설정을 1줄 바꾸는 방식으로 통합됨
  • 월 1,250분 무료 사용량을 제공함
  • “5분 안에 시작”, “2배 빠르게”, “4~7배 절감”을 주요 장점으로 내세움
  • 빠른 시작 문서를 통해 통합을 시작할 수 있음

요금과 러너 사양

  • Standard 러너

    • 시작 가격은 분당 $0.0010
    • GitHub-hosted runners보다 85% 낮은 비용을 내세움
    • AMD EPYC Genoa 기반 CPU를 사용함
    • 30GB 무료 캐시 스토리지를 제공함

  • Premium 러너

    • 시작 가격은 분당 $0.0016
    • GitHub-hosted runners보다 70% 낮은 비용을 내세움
    • AMD Ryzen 9 기반 CPU를 사용함
    • 100GB 무료 캐시 스토리지를 제공함

  • 하드웨어별 가격

    • 2 vCPU, 8GB RAM: Standard $0.0010/min, Premium $0.0016/min
    • 4 vCPU, 16GB RAM: Standard $0.0020/min, Premium $0.0032/min
    • 8 vCPU, 32GB RAM: Standard $0.0040/min, Premium $0.0064/min
    • 16 vCPU, 64GB RAM: Standard $0.0080/min, Premium $0.0128/min

격리와 보안

  • 보안 모델은 Linux KVM 기반 격리 VM과 작업별 일회성 VM을 중심으로 함
  • GitHub Just-In-Time 러너 설정으로 일회성 시크릿을 처리함
  • 저장 중·전송 중 암호화, 내장 키 순환, 자동 방화벽 구성, 자동 취약점 알림을 포함함

오픈소스 클라우드 지향

  • Ubicloud는 오픈소스 클라우드로, 독점 운영체제에 대한 Linux 같은 클라우드 제공자 대안을 지향함
  • 소스 코드는 GitHub에서 확인할 수 있음
  • 사용자는 원하면 자체 러너를 직접 관리할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 출시 축하함. 흥미로워 보이고, 랜딩 페이지에서 가격은 아주 좋아 보임
    지금 하는 일은 전부 오픈소스에 무료 GitHub Actions라서 현재는 대상 고객이 아니지만, 왜 더 싸고 빠른지 / 함정이 뭔지가 궁금해짐
    14" MBP에서 흔한 창 크기인 990px~약 1200px 구간에 가로 패딩이 부족한 시각적 문제도 보임
    “Ubicloud는 오픈소스 클라우드입니다. Linux가 독점 운영체제의 대안인 것처럼 클라우드 제공자의 열린 대안이라고 생각하세요”라는 문구는 이해하기 어려웠고, 처음 몇 번은 Linux 대안이라고 말하는 줄 알았음
    문서의 “What is Ubicloud?” 섹션처럼 “Hetzner, OVH, AWS Bare Metal 같은 베어메탈 임대 제공자 위에서 IaaS 기능을 제공하고, 관리형 서비스로도 제공된다”처럼 구체적으로 무엇인지 먼저 말하는 편이 더 명확함
    엔지니어 대상 마케팅은 효용보다 실제로 무엇인지 구체적으로 말하는 게 더 잘 먹힌다는 오래된 격언이 있었던 것 같고, 여기서는 둘 다 필요해 보임. 실제 정체와 왜 더 싸고 좋은지 함께 말하면 좋겠음
    해당 문단에는 systems.Ubicloud처럼 공백이 빠진 오타도 있음

    • 제품이 멋져 보여서 사소한 문구 개선을 더 적어보면, “Imagine to do more”는 무슨 뜻인지 모르겠고 홍보성 문구처럼 들려서 빼는 게 낫겠음
      “Fast runs even at this price point”에서는 point를 빼는 게 좋음. “Price point”는 “price”의 동의어가 아니고, 이미 더 싸다고 말했으니 태그라인 없이 섹션 제목을 “Faster than GitHub Actions”로 바꾸는 편이 낫겠음
      “Ubicloud is an open, free, and portable cloud...” 문단도 흐릿함. “Ubicloud는 공개되고 무료인 클라우드입니다. 원하는 호스팅 제공자에서 실행하거나, 직접 보유한 하드웨어를 가져올 수 있습니다. GitHub에서 소스 코드를 확인하세요!” 정도가 더 명확해 보임
    • Ubicloud는 처음 들어보지만 GitHub Actions는 많이 써왔고, 더 싸고 빠른 이유는 GitHub가 Actions 컴퓨팅에 원가 대비 엄청난 마진을 붙이기 때문으로 보임
      대충 보니 기본 요금이 분당 $0.008 수준인데, EC2 시간당 요금과 비교해도 크게 이상하지 않은 비율임
      단일 EC2 인스턴스를 띄워 Actions에 연결하는 것만으로 비용을 크게 줄이고 빌드 시간도 개선한 프로젝트를 해본 적 있음
    • 피드백 반영해서 문구를 더 명확하게 몇 군데 수정했고, UX 버그도 고치면서 앞으로 몇 주 안에 더 큰 업데이트를 할 예정임
    • 빌드 서버를 운영하는 비용이 그렇게 비싸지는 않다고 봄

  • Rust 프로젝트 [0]에서 몇 달 동안 Ubicloud 빌더를 써왔고 꽤 잘 동작했음. CI 시간은 10~15분에서 6~7분으로 줄었고, 비용은 월 $300에서 $30으로 내려감
    의외였던 점은 캐시 저장/복원이 느리다는 것임. 머신의 CPU가 좋아서 우리에게는 캐시를 완전히 끄고 매 빌드마다 전부 다시 하는 편이 더 빨랐음
    [0] https://github.com/ArroyoSystems/arroyo

    • 공식 GitHub Actions 러너가 아닌 러너로 바꾼 저장소의 실제 사례를 보는 게 좋음. GitHub vs Buildjet/Warpbuild/Ubicloud vs 내 솔루션 RunsOn의 저장소별 실행 시간 비교를 천천히 모으는 중임
      이 워크플로는 AWS 임시 머신에서 Ubicloud와 같은 가격으로 5분 안에 돌릴 수 있음: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
    • SPDK 링크가 매우 흥미로웠음: https://www.ubicloud.com/blog/building-block-storage-for-clo...
      고성능 애플리케이션에 파일시스템을 쓰는데, ZFS가 XFS ± mdadm ± 암호화 같은 더 단순한 구성보다 병목이 되는 경우가 많았음
      논쟁적인 지점이지만 비슷한 결과도 있음: https://klarasystems.com/articles/virtualization-showdown-fr... : “많은 독자에게 놀라울 수 있지만 개인적으로는 놀랍지 않았다. OpenZFS와 Linux KVM의 게스트 스토리지 성능을 10년 넘게 테스트했는데, zvol은 매번 비교적 성능이 나빴다”
      OpenZFS도 ZFS가 만들어진 회전식 디스크와 성능 특성이 매우 다른 최신 드라이브(SSD, NVMe)에 맞춘 최적화를 검토하기 시작한 듯함
      SPDK 요약에서는 “VM 프로비저닝 시간을 줄이려고 호스트 OS를 ext4에서 btrfs로 바꿨다”, “호스트 파일시스템을 btrfs로 바꾸자 디스크 성능이 눈에 띄게 떨어졌고 처리량이 ext4의 약 1/3이 됐다”고 함
      Ubicloud의 문제는 쓰기 시 복사 파일시스템 전반에 걸친 것으로 보이고, CoA라는 약간 다른 변형을 택한 점은 흥미롭지만 XFS, Ext4 같은 저널링 파일시스템에 오버레이를 얹는 더 단순한 대안은 검토했는지 궁금함
      또는 UFS2 + 스냅샷으로 초기화된 테스트 준비 상태를 복원하고 테스트 사이마다 그 상태로 되돌리는 방법도 가능해 보임
      고객들이 캐시를 끄는 게 더 낫다고 느낀다면 CoA도 CoW와 비슷한 문제가 있다는 뜻으로 보임
      개인적으로는 복잡도를 더하기보다 고객별 네임스페이스를 둔 SR-IOV를 써보고 끝냈을 것 같은데, 분명 좋은 이유가 있었을 테니 그 이유가 궁금함
    • 캐시를 완전히 끄고 매 빌드마다 다시 하는 방식이 비슷한 성격의 모든 회사/작업 규모로 커졌을 때 탄소 발자국이 어떻게 될지 궁금함
    • 공유 고마움. 저장소를 보니 일부 작업은 아직 GitHub 호스팅 러너에서 돌고 있던데, 전부 Ubicloud에서 돌리지 않는 이유가 궁금함

  • Ubicloud 창업자 중 한 명인 Ozgun임
    현재 수십 곳의 고객이 프로덕션에서 Ubicloud 러너를 쓰고 있고, 지금 캐싱 계층을 설계 중임. Docker 인스턴스 레지스트리, Docker 레이어 캐시, 패키지 캐시 같은 부분에 대한 의견을 듣고 싶어서 공개함
    더 넓게는 공개되고 이식 가능한 클라우드라는 주제에 관한 포인트도 있으면 알려주면 좋겠음

    • Depot처럼 빠른 영구 디스크를 빌드 가까이에 두고 Docker 레이어를 캐시해주면 좋겠음
      GitHub Actions 러너, CircleCI 등에서 레이어를 수동 캐시하려고 비싼 네트워크 호출을 추가하는 방식은 늘 시간을 많이 잡아먹었고, 많은 사람이 캐시를 아예 제거하게 만드는 것 같음
    • GitHub의 러너 이미지를 빌드해서 Docker Hub에 올려줄 수 있으면 좋겠음
      act [0] 같은 다른 GitHub Actions 클론 사용자에게 꽤 유용할 것임
      [0]: https://github.com/nektos/act

  • BuildJet [0]을 1년 넘게 만족스럽게 써왔음
    GH Actions 대비 CI 비용을 $25k 넘게 절감했고, BuildJet도 Hetzner의 강력한 베어메탈 서버를 쓰고 있어서 빌드 시간이 약 94% 줄었음
    정말 만족하고 있으며, 시장에 더 많은 회사가 생기는 건 반가움
    [0] https://buildjet.com

  • 우리 GHA 비용에서 가장 큰 부분은 MacOS 실행임. MacOS를 관리형 서비스로 제공하나, 혹은 제공할 계획이 있나? GitHub보다 얼마나 싼지도 궁금함

    • 가까운 미래에는 제공하지 않을 예정임
      Ubicloud는 베어메탈 제공자 위에서 동작하는데, 그들이 Mac 하드웨어를 임대하지 않음
      기술적으로는 arm64에서 MacOS VM을 돌릴 수 있지만, Apple 최종 사용자 사용권 계약(EULA)을 보면 그렇게 하면 안 된다고 해석하고 있음
      이 저장소에 관련 참고 자료가 잘 정리되어 있음: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
    • MacOS의 가장 큰 문제는 물리 Mac이 필요하고, 가상화가 안 되며, 기억상 Apple 라이선스가 최소 24시간 대여 기간 같은 조건을 요구한다는 점임
      OS X 약관에는 이렇게 되어 있음:
      3. 허용된 개발자 서비스용 임대. A. 임대. 유효하게 라이선스된 Apple Software 전체를 개인 또는 조직(각 “Lessee”)에 임대 또는 재임대할 수 있으며, 다음 조건을 모두 충족해야 함: (i) 임대된 Apple Software는 허용된 개발자 서비스 제공 목적으로만 사용되어야 하고 각 Lessee는 이 라이선스 조건을 검토하고 이에 구속되는 데 동의해야 함; (ii) 각 임대 기간은 최소 24시간 연속이어야 함
    • WarpBuild [1]에서는 M2 Pro 기반 GitHub MacOS 13 러너를 지원함
      동급 GitHub 호스팅 러너보다 약 25% 빠르고 분당 비용은 50% 저렴함
      [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64

  • Resmo에서 한동안 Ubicloud를 써왔고 실제로 10배 저렴함. 성능을 조금 더 얻으려고 인스턴스 크기를 2배로 올렸지만 그래도 5배 저렴함
    핵심 이유는 플랫폼이 Hetzner 전용 인스턴스 위에서 호스팅되기 때문임

    • 그렇다면 GitHub Action에서 Hetzner에 있는 자체 CI로 웹훅 요청을 보내면 안 되는 이유가 궁금함

  • PeerDB[1]에서 Ubicloud 러너를 한동안 써왔음. 가성비가 좋고 특히 ARM 러너가 CI 비용을 낮추는 데 도움이 됐음
    팀 반응도 빠르고, 우리가 요청한 지 몇 주 안에 ARM 러너 지원을 추가해줬음
    [1] https://github.com/PeerDB-io/peerdb

  • GitHub Actions 러너 가격에서 답답한 부분은 분 단위 과금임. 초 단위로 청구할 수는 없나? 최소 1분을 두더라도 그 이후는 초 단위로 받으면 좋겠음
    작업 사이에 VM이 재부팅되는 시간을 충당하려고 이렇게 하는 것 같긴 함

    • WarpBuild에서는 정확히 그렇게 하고 있음. 무작위 비용을 사용자에게 떠넘기지 않고 공정하게 하려는 목적이 큼
      VM 재부팅 시간이 빠르게 누적되기 때문에 아마 그게 이유일 것임
      다만 2초 정도 걸리는 린트 작업을 16 vCPU 인스턴스에서 돌리는 사용자도 있어서 최소 1분 과금은 유지했음

  • Elastic 라이선스를 오픈소스라고 부르지는 않았으면 함. 소스가 공개되어 있는 건 좋지만, 오픈소스 라이선스는 아님
    답변들을 보니 이 정보는 오래된 듯하고, 이제 프로젝트가 AGPL을 쓰는 것으로 보임

  • 출시 축하함. Ubicloud가 이전 프로젝트인 Citus보다 더 성공하길 바람

답변달기