2 ポイント 投稿者 GN⁺ 2024-01-31 | 1件のコメント | WhatsAppで共有
  • Ubicloud は GitHub Actions 向けマネージドランナーを提供しており、ワークフローで1行だけ変更すれば、従来の使い方を維持したままビルド速度とコストを改善できるとうたっている
  • 価格は Standard が 1分あたり $0.0010、Premium が 1分あたり $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 ランナー

    • 開始価格は 1分あたり $0.0010
    • GitHub-hosted runners より 85%低コストをうたう
    • AMD EPYC Genoa ベースの CPU を使用する
    • 30GB の無料キャッシュストレージを提供する
  • Premium ランナー

    • 開始価格は 1分あたり $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 で確認できる
  • ユーザーは望めば自前のランナーを直接管理できる

1件のコメント

 
GN⁺ 2024-01-31
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 コストを 25,000 ドル以上削減でき、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 に Webhook リクエストを送ればよいのでは、と思います。
  • PeerDB[1] で Ubicloud ランナーをしばらく使ってきました。コストパフォーマンスが良く、特に ARM ランナーが CI コスト削減に役立ちました。
    チームの反応も早く、私たちが依頼してから数週間以内に ARM ランナー対応を追加してくれました。
    [1] https://github.com/PeerDB-io/peerdb

  • GitHub Actions ランナーの価格で不満なのは、分単位課金です。秒単位で請求できないのでしょうか? 最低1分はあっても、その後は秒単位にしてくれるとよいです。
    ジョブ間で VM が再起動する時間を補うためにこうしているのだとは思います。

    • WarpBuild ではまさにそうしています。ランダムなコストをユーザーに押し付けず、公平にするのが大きな目的です。
      VM の再起動時間はすぐ積み上がるので、おそらくそれが理由でしょう。
      ただし、2秒ほどで終わる lint ジョブを 16 vCPU インスタンスで走らせるユーザーもいるため、最低1分課金は維持しています。
  • Elastic ライセンスをオープンソースと呼ぶのはやめてほしいです。ソースが公開されているのは良いことですが、オープンソースライセンスではありません。
    返信を見る限り、この情報は古いようで、今はプロジェクトが AGPL を使っているようです。

    • ドキュメントにはまだ Elastic ライセンスを使うと書かれていますが、https://github.com/ubicloud/ubicloud/blob/main/LICENSE を見ると、プロジェクトは1日ほど前に GNU Affero General Public License v3.0 に変わったようです。
  • リリースおめでとうございます。Ubicloud が以前のプロジェクトである Citus よりさらに成功することを願っています。