🚀

【格安本番運用が可能に】Render.com のメリット・デメリットを Heroku と比較してみた

2022/04/24に公開

4件

はじめに

先日 Heroku で OAuth トークンが流出し、連携している GitHub の private リポジトリの中身が盗まれたとニュースになりました。

特に Rails を簡単に運用する上で Heroku は重宝しているのですが、以前から「Render.com はいいぞ」という話を聞いていたので、この機会に調べて移行してみました。

結論から言うと、 Heroku でできたことはほぼすべてカバーしており、その上安い です。

使い勝手もよさそうだったので、今回 Heroku と比較しながらご紹介したいと思います。

現状、Render.com を日本語で解説している記事が圧倒的に足りないので、これをきっかけに利用者が増えたらなと思っています。（2022年には東京リージョン対応も予定しているそうで、それを推し進めるきっかけになれば。）

それでは本題に入っていきましょう。

Render.com とは

静的サイトからWebアプリまで、さまざまなアプリを簡単に運用できる PaaS です。GitHub だけでなく GitLab とも連携してサービス運用できます。

https://render.com

Render.com vs Heroku

気になるのは Heroku との違いだと思います。日本語の情報量としては Heroku のほうが圧倒的に多いですし、実際に Heroku を利用して運用しているサービスもそこそこありますしね。
Heroku からの移行を検討している方もご覧になっていると思うので、まずはわかりやすく表でまとめます。

	Render.com	Heroku
料金	安い	Render.comよりは高い
対応 Region	US, Europe(Germany), Asia(Singapore)	US, Europe
DB	Postgresql を標準サポート	Postgresql を標準サポート
Pipeline	なし	あり
Blueprint	あり	なし
Team	あり	あり
Preview環境	あり	あり
Redis	あり	あり
Private Service	あり(安価)	あり(超高額)
Cron	あり	あり(Heroku Scheduler)
Worker	あり	あり
CD(Continuous Deployment)	あり	あり
Auto Scaling	あり	あり
Logging	あり	あり

料金

そもそも準備されているプランが違うので、厳密な比較はできませんが、例を出しながら料金を比較したいと思います。

Heroku

	Staging	Production
Postgres	$0	$50(Standard0)
Redis	$0	$15(Premium0)
Logging(Papertrail)	$0	$8(Fixa)
Application Server(Dyno)	$7(Hobby)	$25(Standard1X)
Total	$7	$83

総計: $90

本番運用する上での最小構成がこれくらいかなというものの試算になります。
多少選択するプランは多少異なるかもしれませんが、アプリ運用を「まぁこれくらいからやってみるか」と言えるのはこんなもんかなと。

Render.com

	Staging	Production
Postgres	$0	$20(Standard)
Redis	$0	$10(Starter)
Logging	$0	$0
Application Server	$0	$7(Starter)
Total	$0	$37

総計: $37

上記とおおよそ同じ程度のパフォーマンスが出るプランを選択すると、おおよそ半額で運用可能です。

選択しているプランの比較と雑感

別サービスで厳密にプラン比較をするのが難しいので、印象を伝えつつ可能な範囲で比較します。

DB(Postgresql)

DB(Postgres) に関しては、Heroku の方が高いというより、Heroku よりも Render.com のほうが細かいプランが多いという印象です。サービスはスモールスタートがほとんどだと思うので、そういう意味で Render.com のほうが始めやすいかな。

引用元: Heroku Postgres

Redis

Redis のプランはシンプルに Render.com のほうが安くて性能がいいです。Render.com なら $10 出せば、Heroku Redis の $60 くらいのプランと同等のものが利用可能です。

引用元: Heroku Redis

Logging

Heroku では Papertrail という Logging 向けのプラグインがあり、必要に応じてそちらに課金して利用しますが、Render.com は過去ログの保存に関しては別サービスを利用するような形をとっています。

直近のログはデフォルトで閲覧できるようになってるので、それくらいであれば何も入れなくても問題ありませんが、ある程度の期間ログを保管しておきたい場合は外部サービスと連携することが必須になります。

https://render.com/docs/log-streams

Application Server

$7 程度の安いプランだとほとんど差はありませんが、Heroku と比べると Render.com のほうが段階的に価格を上げながら運用が可能なことがわかります。単なるメモリでの比較ではあるが、価格を上げるほど、同程度の金額を出した場合のメモリが Render.com のほうが大きいですね。多くのサービスにおいて、サービススケールしてくるとここのコストが上がってくるので、安くて性能が高いのはとてもよさそう。

引用元: Heroku Dyno

対応 Region

Heroku

Heroku は Private Spaces を利用すれば東京リージョンも利用できるようなのですが、価格が異常に高く、利益が大きく出ているプロダクトでない限り、そうそうお目にかかることはありません。

つまり、一般的な価格で Heroku を利用する場合、東京リージョンを利用することができません。Asia の Region も一切なく、北米とヨーロッパの2つからしか選択できないため、日本での利用を考えたときにここがレスポンス速度に大きく影響する要因となります。

東京リージョン対応していないなら Heroku 使わねーわ、と判断した方も多いんじゃないでしょうか。

Render.com

https://render.com/docs/regions

Render.com は、Heroku と比較すると対応している Region の種類が多く、2022年4月20日現在、以下のリージョンに対応しています。

Region	Country
Oregon	USA
Frankfurt	Germany
Ohio	USA
Singapore	Singapore(Asia)

現時点でも、Singapore Region に対応しているので、Asia の Region が選択できる状況です。（レスポンスタイムの実値比較などはしていませんが、USA, Europeよりは早い？）

また、2022年には東京リージョン対応も予定しているようなので、今後の開発にも期待が持てます。利用者が増えないことにはリスケされそうなので、1人でもこの記事を読んでユーザー数が増えたらなと思っていますw

DB

基本的にはどちらも Postgresql を推奨（デフォルト設定）していますが、MySQL も利用可能なようです。

Heroku

通常プランでは public にアクセスできる DB のみ利用可能です。

Render.com

Render.com 内のアプリケーションからのみアクセスできるような設定が可能です。

Pipeline

Heroku

Heroku には Pipeline と呼ばれる

Preview環境 -> Staging環境 -> Production 環境

の流れでアプリケーション群を管理する機能が備わっています。

個人的にこの機能、アプリケーションを管理しやすく好みなのですが、これ自体は Render.com には備わっておりません。

Render.com

残念ながら存在しません。

Blueprint

Render.com

BluePrint という機能を利用することで、アプリケーションを構成するサービスをひとまとめにすることが可能です。また、そもそもこの機能は Infrastructure as code(IaC) のための機能です。

https://render.com/docs/blueprint-spec

render.yaml に、構成を記述すると、自動的にそのシステムが組み上がるようになっています。

メリット1. 構成をひとまとめにしてわかりやすくする

例えば、何かしらアプリを作る場合は

Application Server
Postgresql
Redis

といったように、複数のサービスを組み合わせてひとつのアプリケーションを動かしますが、Render.com は、これらのサービスがダッシュボード上ですべて混ぜられた状態で一覧に並びます。

これは同一アプリの Staging と Production を用意しています。名前も自由につけられるので、整理しておかないとパッと見どれがなんなのかわかりませんし、どれとどれを組み合わせてアプリが動いているのかがわからないのですよね。
例えば負荷テストをしたいとなったときに、それ用の環境を Staging と Production 以外に追加したりしますが、そのように扱うサービスの個数がどんどん増えていくと、とてもじゃないですが管理できなくなってきます。

これを、Blueprint を利用してサービスを構築すると、ひとつのアプリケーションを動かすためにどれを組み合わせているのかを一覧で確認できるようになります。

Blueprints で管理している構成を一覧表示
選択した Blueprint が整理しているサービス一覧を表示

ダッシュボードを見てもひとつのアプリケーションを構築するのにどのサービスを利用しているのかわかりませんでしたが、これで比較わかりやすく管理できるようになりました。

メリット2. PaaS で IaC が実現できる

アプリケーションのルートディレクトリに、 render.yaml というファイルを作成し、ここに必要なサービスを記述することで Render.com にどのような構成のサービスを作成するかを管理することができます。
いわゆる、Infrastructure as code(IaC) というやつです。

使い方は簡単で、ドキュメントを読みつつ必要なサービスができるように render.yaml を調整します。

https://render.com/docs/blueprint-spec

あとは管理画面から Blueprint を作成することで、記載されている構築のサービスが全自動で作成されます。

本来インフラ構築の自動化までやろうとすると、Terraform や Ansible などを駆使する必要がありますが、PaaSである程度基本的な部分は自動でやってくれる上、一度よく使う構成の render.yaml を作ってしまいさえすれば使い回して構築することが可能なので、IaCにしては実装・運用負荷が小さく、個人的にここはかなりいいなと感じています。めっちゃよい。

本記事の最後に、よくある Rails API を構成する場合の render.yaml のサンプルを置いておきますので、よければ参考にしてみてください。

Heroku

Blueprint の機能はありません。

Team

運用するプロダクトごとに作成するチームです。
プロジェクトごとに関与するメンバーは変わるので、基本的に Heroku でも Render.com でもプロダクトごとに Team を作って運用することをおすすめします。

ここから先は、僕の感想が主なので、興味ない人は読み飛ばしてください。

Team はプロジェクトごとにひとつ作るのがおすすめ ということだけ押さえておいていただければ OK かと。

Heroku

1つの Enterprise に複数の Team が含まれるような形になっており、複数のアプリケーションを管理することを考えたときに、扱いやすいのが特徴です。

Heroku の場合、Team の配下に Pipeline の一覧が並ぶようになっているため、直感的に Team は Pipeline をまとめる概念であることがわかるようになっています。
Pipeline 自体、Staging から Production へのアプリケーションの運用をするものなので、Team 配下に　「Backend, Frontend のアプリケーション、さらにはこのサービスの LP なども、同じ Team で管理するとよさそうだ。」という意図が読み取りやすいです。

ここに関しては Pipeline のおかげで、Heroku のほうがわかりやすいですね。

Render.com

https://render.com/docs/teams

Render.com には Pipeline の機能がなく、ひとつの Team で管理する各種サービスがダッシュボード上に並ぶ形になっています。それらを Blueprint で管理することで、サービスのまとまりを表現することが可能となっていますが、 Pipeline がないせいで、ひとつのプロジェクトごとにひとつ Team を作った方がよいことに気付けない ように思うのですよね。

まぁ、単なる管理の問題なので好きなようにすればいいのですが、設計思想として、僕はここは Heroku のほうがわかりやすさを感じますね。

Team の機能自体はどちらも同じです。

Preivew 環境

Heroku

Heroku では Heroku Review Apps という機能があり、PR ごとにプレビュー環境を準備することが可能です。

有効にすると、Pipeline に PR ごとの環境が作られます。コードレビューする際に、動作も確認したいという場合に、各開発者のローカル環境で再現する必要がなくなるので、結構便利です。

Render.com

Render.com にも同様の機能が備わっています。
Static Site Web Service のサービスを作成後、PRs から有効にすることで利用可能です。

Redis

Heroku

通常プランでは public にアクセスできる Redis のみ利用可能です。

Render.com

Render.com 内のアプリケーションからのみアクセスできるような設定が可能です。

Private Service

Heroku

あるにはありますが、超高いです。

https://jp.heroku.com/private-spaces

Render.com

Free プランがないだけで、通常の Web Service と同様の価格でリーズナブルに利用できます。

傾向として、Heroku よりも Render.com のほうが閉じたネットワーク構成にしていて、外部からのアクセスが必要のないものは、外に晒さずに済むようになっているのでセキュリティ的にもベターです。

余談ですが、Render.com に Redis はもともとなく、Private Service で Docker に Redis 入れて使うような構成で運用されていたようです。こういったことも比較的簡単にでき、自由度も高いです。

Cron

Heroku

Heroku Scheduler というプラグインを利用して cron と同等のことが実現可能です。
可能ですが、cron とは異なり、1分単位の細かな時間設定ができず、最短で10分間隔がデフォルトです。頑張れば1分ごとに設定できるようになりますが、正直ちょっと使いづらさを感じますね。

Render.com

サービスのひとつとして Cron が選択できるようになっています。
Web Service と同様、どのアプリケーションに対して cron を設定するのかを選択し、あとは実行するコマンドと頻度を cron 式に則って指定すれば OK です。

他の Web Server と同様、インスタンスのプランを選択できるようになっていて、Render.com 全体の統一感があって使いやすさを感じます。

Worker

They are most often used to run event loops that listen on a queue backed by a datastore such as Redis and process events as they come in.
引用: Background Workers

キューを投げて非同期処理するためのサーバーを、アプリケーションを動かすサーバーとは別に建てることが多いですが、これは Heroku も Render.com もどちらも対応しています。

Heroku

ざっくりいうと、Heroku のサーバーインスタンスを Dyno と呼びますが、この Dyno にはいくつかタイプがあり、一番一般的なのが web タイプ、つまり Rails などのアプリを動かすためのものです。

このタイプのなかに worker タイプの Dyno があり、これを選択することでキューを捌くようなサーバーを作ることが可能です。

Render.com

Heroku は worker タイプの Dyno を作成するのに少し手間取ることが多いですが、Render.com では、そもそも Web Server とは完全に別のサービスとして扱われているので、管理画面から新たに作成するのも容易ですし、他でもお伝えしている通り Blueprint で管理するのがおすすめです。

CD(Continuous Deployment)

Heroku

2022年4月16日に発生したインシデントにより、GitHub連携機能は一時停止されていますが、もともとは GitHub 連携した後、ボタンひとつで自動的にデプロイされるようにできました。
GitHub連携直後は、この設定は OFF になっており、使用したいユーザーのみ ON に変更するような機能となっています。

デフォルトがOFFである理由の推測ですが、Heroku は基本的に Pipeline の Staging 環境に対して管理画面からデプロイを行い、問題なければ Pipeline の Promote の機能を利用することが想定されています。

なので、Production で GitHub 連携し、デフォルトが ON だと Promote の機能が死んでしまうためにこうしているのかなと。

Heroku が本題ではないのでこれ以上は興味があればご自身で調べてみてください。

Render.com

GitHub, GitLab のリポジトリと連携しておくことで、指定のブランチに push されると自動的にデプロイがされます。この設定は OFF にすることも可能です。最近の PaaS だとよくありますね。

Branch に push したら本番反映される怖さ

最近なぜだか多い気がしますが、push したら即時本番反映されるというのは実はかなり危ういです。

例えば、main ブランチに push するなどして更新が入った場合に、即時本番環境に自動的にデプロイされる場合、間違って migration ファイルに変更が入った場合、最悪サービスが止まります。

特に、何か調整していてすでに存在しているテーブルの一部が drop されていた場合...大変なことになりそうです笑

人間何かしらミスはするということを前提で仕組みを作っておいた方がいいなと思っているので、僕はこの方式の CD は基本的に使用しないようにしています。

Staging 環境のみ、対応する branch に修正が入った場合に自動的にデプロイするようにする。（最悪データ吹っ飛んでも問題ないので）
Production 環境においては、反映する内容を確認した上で、手動でデプロイを走らせる。

このような仕組みを、CI/CD サービス側（GitHub Actions など）に集約しています。

一度仕組みを作ってしまいさえすれば、運用するインフラが異なる場合であっても、デプロイフローを統一できるので、デプロイを担当する開発者の学習コストを軽減できるため結構気に入ってます。

Auto Scaling

どちらもボタンぽちぽちするだけでオートスケールできる簡単設計です。これだけオートスケール設定楽なのは PaaS のメリットですね。

Heroku

オートスケールアルゴリズムによって、過去の時間からのデータが使用され、現在のリクエストスループットでの受信リクエストの 95% についての望ましい応答時間を実現するために必要な Web dyno の最低数が計算されます。

ざっくり説明すると、Heroku が「これくらいの応答時間は実現してくれよな」と規定している値を 95% 以上のリクエストで上回るかどうかでオートスケールするかどうかを決めているようです。基準値の設定は少しわかりにくいですね。

ただ、オートスケール設定は本当にぽちぽちするだけで終わるので設定から切り替えまで超絶楽です。

Performance-M dynos($250/month) から利用可能で、それ以下の場合は使えません。

Render.com

管理画面からぽちぽちして設定できるのはもちろん、Blueprint で設定も可能です。

CPU利用率, メモリ利用率それぞれに閾値を定め、規定の数値を超えたらオートスケールするというわかりやすい基準になっています。

どのプランでも利用可能です。

その他

ローカルマシンからアプリケーションの DB にアクセスする

データベースの中身を見たり、ちょっと修正したりは実務でもよくあるシーンです。

Render.com は、基本設定では Render.com 内のアプリケーションからのみ接続を可能にしています。
そのため、一旦主にDBに接続しているアプリケーションサーバー（Web Service）を踏み台サーバーにして閲覧する方法を紹介します。

ただ、Freeプランでは ssh 接続ができないので、staging 環境は節約したい！という場合を想定して、DBに直接接続できるようにする設定も紹介します。（Access Control）

整理するとこう。

アプリケーションサーバーを踏み台サーバーにしてDBにアクセスする
セキュリティを少し緩めて直接DBにアクセスする

僕は様々なDBに対応していることもあり、TablePlus というアプリを使って DB 閲覧・操作をすることが多いので、サンプルとしてこちらを使ってアクセスするような形でお見せしますね。

https://tableplus.com

1. アプリケーションサーバーを踏み台サーバーにしてDBにアクセスする

有料プランの Web Server であれば、サーバーに対して ssh アクセスが可能です。
ssh でサーバーにアクセスし、そのサーバー経由で目的である DB にアクセスする方法を取ります。

公開鍵と秘密鍵のペアを作成する

まずは Render.com 向けの公開鍵と秘密鍵を作成します。
以下のようにわかりやすく名前をつけて公開鍵と秘密鍵を作成しましょう。

$ cd ~/.ssh
$ ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/chinju/.ssh/id_rsa): render-com

すると、キーペアが作成されますので、公開鍵の中身をコピーします。

$ less ~/.ssh/render-com.pub

出力されるファイルの中身をクリップボードにコピーしてください。

Render.com に公開鍵を登録する

有料プランの Web Server にアクセスすると、画面上に Connect というボタンが表示されていますので、SSH のメニューから、 add an SSH public key をクリックしてください。

すると、各ユーザーの公開鍵登録画面が表示されますので、先ほどコピーした公開鍵を Key の部分に貼り付けて登録します。

これで公開鍵の登録が完了しました。

TablePlus に ssh に関する情報を入力する

普段使っている方は適当に読み飛ばしつつ設定してください。

まずは TablePlus を開いて、PostgreSQL を選択して設定画面を開きます。

今回踏み台サーバーにアクセスしてから目的のデータベースに接続を試みるので、Over SSH をクリックして設定できるようにします。

公開鍵が正しく設定されている場合、アプリケーションの Connect ボタンの SSH タブから、接続する際の ssh コマンドが閲覧できます。

ssh <User>@<Server>

の対応関係になっているので、これをもとに TablePlus の ssh アクセス情報を入力します。
Password ではなく、作成した秘密鍵を使って接続するので、手順通り作成しているなら ~/.ssh/render-com を選択してください。

TablePlus に DB に関する情報を入力する

Render.com で作成済みの PostgreSQL の詳細情報ページにアクセスします。

ここの情報をもとに、以下のように入力します。

あとはテスト接続して、問題なくアクセスできれば踏み台サーバー経由でDBにアクセスできている状態になります。

セキュリティを少し緩めて直接DBにアクセスする

Web Server が無料の場合、ssh 接続ができません。直接外部から DB に接続できるように Access Control を調整することで接続が可能になるので、それを簡単に紹介します。

PostgreSQL の Access Control を追加する

以下のように Render.com の PostgreSQL の Access Control を設定することで、外部から直接DBにアクセスすることが可能になります。

あとは、TablePlus の設定を

Over SSH を OFF にする
Host の値を External Connection String の値に修正する

ことで接続ができます。

※ Render.com の PostgreSQL 詳細ページに記載されています。

あとはテスト接続して、問題なくアクセスできれば OK です。

Heroku からの移行

なんと簡単に移行するための手順まで揃っています。

手順通りに進めると、Heroku の環境を Docker で再現して Render.com で再現できます。
ここについて詳しく書くと、それひとつで記事になりそうなので、今回は詳細は省略します。公式ドキュメント読めば割とスムーズにいけると思うので、頑張ってください笑

2点だけ補足しておくと

Render.com に Heroku の環境を再現しているので、Heroku で動かすための設定ファイル(Procfile等)も継続して必要になります。
DB移行時は、手順通りにやる場合ローカルマシンから対象のDBに直接アクセスしているため、Access Control で外部からのアクセスを許可しておく必要があります。
- 接続方法に関しては、本記事の「PostgreSQL の Access Control を追加する」を読んでいただいて設定すれば対応可能です。よしあしは各々ご判断ください。

個人的に、環境変数もコピーされても問題ないものは移行されることもあり、すでに Heroku で動かしているなら、この機能を使ってコピーして調整するのがおすすめです。

Blueprint の利用

Rails の話をしていたので、弊社で利用している Rails API 向け Blueprint のサンプルを掲載しておきますね。よければ参考にどうぞ。

render.yaml

services:
  - type: web
    name: cat-algorithm-xxx-api
    env: ruby
    region: singapore
    plan: starter
    branch: main
    numInstances: 1
    healthCheckPath: /
    buildCommand: ./bin/render-build.sh
    startCommand: bundle exec puma -C config/puma.rb
    domains:
      - 'sample.example.com'
    envVars:
      - key: RACK_ENV
        value: production
      - key: RAILS_ENV
        value: production
      - key: DATABASE_URL
        fromDatabase:
          name: postgresql-cat-algorithm-xxx
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: redis-cat-algorithm-xxx
          type: redis
          property: connectionString
    autoDeploy: false

  - type: redis
    name: redis-cat-algorithm-xxx
    region: singapore
    plan: standard
    maxmemoryPolicy: allkeys-lru
    ipAllowList: [] # only allow internal connections

databases:
  - name: postgresql-cat-algorithm-xxx
    region: singapore
    ipAllowList: [] # only allow internal connections

BuildScript ファイル

buildCommand: ./bin/render-build.sh

デプロイした際に走るコマンドをここで記載しています。migration は毎回自動で走るようにしておきたいので、以下のようにしています。

#!/usr/bin/env bash
# exit on error
set -o errexit

bundle install
bundle exec rails db:migrate

GitHub Actions の利用

最近の PaaS は指定した branch に push すると自動的にデプロイしてくれますが、人間ミスするものなので、間違った内容を直接 push してしまうことがあります。開発者の環境をすべて整えるよりも、そもそもミスで push してしまっても問題ないようにしておいたほうが無難なので、僕は CD は GitHub Actions にすべて集約しています。

多少は需要があると思うので、Render.com 向けの弊社の GitHub Actions の CD 設定の yml 共有します。（実運用しているものをベースに作成したサンプルになります。）

ざっくりした方針

Render.com が提供する API を利用してデプロイを実施する。

完全自動デプロイ

staging branch に push(PullRequest のマージ含む) した際にすぐにその内容を反映

半手動デプロイ

main, staging branch は、GitHub の画面上から手動でデプロイできるようにしています。
本番反映する場合は、main ブランチを選択してデプロイすることで反映されます。
その他の方法としては、Deploy を Approve する方法もあると思いますが、本題ではないので今回紹介している方法は、あくまで参考としてどうぞ。

workflows sample

# ref: https://api-docs.render.com/reference/introduction

name: cd

on:
  push:
    branches:
      - staging
  workflow_dispatch:
    inputs:
      target:
        type: choice
        description: Deploy target
        required: true
        options:
          - main
          - staging

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy Render.com for stg
        uses: fjogeleit/http-request-action@v1
        if: github.ref == 'refs/heads/staging'
        with:
          url: https://api.render.com/v1/services/${{ secrets.RENDER_COM_SERVICE_ID_FOR_STG }}/deploys
          bearerToken: ${{ secrets.RENDER_COM_API_KEY }}
          method: 'POST'
      - name: Deploy Render.com for prd
        uses: fjogeleit/http-request-action@v1
        if: github.ref == 'refs/heads/main'
        with:
          url: https://api.render.com/v1/services/${{ secrets.RENDER_COM_SERVICE_ID_FOR_PRD }}/deploys
          bearerToken: ${{ secrets.RENDER_COM_API_KEY }}
          method: 'POST'

GitHub 上での GitHub Actions の変数登録

設定画面から、GitHub Actions で使用する値を入力できます。

ここでは、

RENDER_COM_API_KEY
RENDER_COM_SERVICE_ID_FOR_STG
RENDER_COM_SERVICE_ID_FOR_PRD

の3つを登録しています。いずれも Render.com から取得可能です。

Render.com の GitHub Actions に登録する値

RENDER_COM_API_KEY
Team 設定画面から、API_KEY の登録ができるようになっています。Team 自体で API_KEY を登録することはできないので、Team に参加している代表のユーザーのものを利用してください。

RENDER_COM_SERVICE_ID_FOR_XXX
Render.com はアプリごとに service_id が割り振られています。その値を各環境ごとに取得し、入力してください。

簡単な参照方法としては、管理画面の Deploy Hooks のオレンジで塗りつぶしている部分の値がそれです。

GitHub からの手動デプロイの手順

ここまで設定が終われば、staging 環境は内容が更新されれば自動的にデプロイが実行されます。

本番環境及び、staging 環境に手動でデプロイをしたい場合は GitHub の対象のリポジトリからデプロイを実行することが可能です。まずは Actions タブを選択します。

次に、デプロイを実行する workflow を選択します。
workflow_dispatch が正しい設定になっていれば、下記画像のようにどのブランチの設定で、どのブランチに対して実行するかを選択できます。

あとは、設定されている内容に沿って、指定の環境にデプロイが実行されます。

ssh接続とコンソール操作

Rails などのフレームワークでは、サーバー上で rails console を使ってデータを操作したい場合がしばしばあります。

Heroku であればローカルマシンから

$ heroku run rails c

のように Heroku CLI から直接操作できましたが、Render.com では対象のアプリケーションサーバーに ssh接続して console を立ち上げて操作すれば同様のことが可能です。

ssh の接続設定に関しては、本記事の

アプリケーションサーバーを踏み台サーバーにしてDBにアクセスする

のあたりを参照ください。

あとは、Web Server の Connect ボタンから SSH コマンドがコピーできるようになっていますので、作成済みの秘密鍵を使って接続して

$ RAILS_ENV=production bundle exec rails c

を実行すれば、コンソールが立ち上げられます。Rails でなくても、やることとしては概ね同様です。

まとめ

細かく挙げると他にも機能はあるのですが、書きすぎると読むのが大変だと思うのでここで止めておきます笑（すでにだいぶ長いですが...）

最初に機能比較の表をお見せしましたが、最後に機能ごとにどう思ったかをお見せして締めたいと思います。

	Render.com と Heroku を比較した際の感想
料金	Render.com のほうが安価に運用できそう。
対応 Region	Render.com は東京リージョンサポートも将来的に控えているので今後が楽しみ
DB	Render.com はサービス内からのみアクセスが可能なように設定でき、セキュリティ的にもよさげ
Pipeline	Heroku にしかなくて、わかりやすいが、なくても運用でカバーできる範囲
Blueprint	Render.com にしかなくて、PaaS での IaC のメリットを享受できてとても使用感がいい
Team	どっちも変わらない
Preview環境	どっちも変わらない
Redis	Render.com はサービス内からのみアクセスが可能なように設定でき、セキュリティ的にもよさげ
Private Service	Render.com は安価に利用できてとてもよい。ここは Heroku 高すぎる。
Cron	やや Render.com のほうが使いやすい
Worker	やや Render.com のほうが使いやすい
CD(Continuous Deployment)	Render.com は簡単に始められるが、CI/CD サービス経由の方が個人的にはおすすめ
Auto Scaling	どっちも簡単に設定できるが、設定項目は Render.com のほうがややわかりやすい
Logging	Heroku のほうが導入が簡単

これ間違ってるよとか、よかったとか、何か感想ありましたらコメントいただけると嬉しいです。

Render.com もっと流行れ！

Discussion

mugifly

良い比較記事をありがとうございます。ただ、Heroku について、認識の誤りがあるので、本質でないと思われるかもしれませんが、コメントします。

Heroku
例えば GitHub の指定のリポジトリに push したり、pull request がマージされたりした場合に、自動的にデプロイが実行されるような機能は標準では提供されていないと思います。

Heroku でも、GitHub 連携が提供されています。
指定されたブランチに基づいて自動デプロイでき、CI の成功を待つこともできます。

また、Review Apps (アドオン込み) についても、GitHub の Pull Request に連動して、自動生成できます。

むしろ、Heroku の GitHub 連携は、かなり昔からある、Heroku の大きな特徴の一つでした。
うろ覚えですが、特に自動デプロイは、Pipeline や Review Apps より昔からあったと思います。
いずれにしても、GitHub に特化している分、シンプルでわかりやすく、使い勝手も良かったです。
現在、OAuth トークン流出の事故を受けて、一時的に機能が停止されていますが、設定画面自体はそのまま残っていますよ。

※ 記事にあるように、ブランチに応じた自動デプロイが本番環境で実用できるかはさておきですが。ちなみに「人間ミスするものなので、間違った内容を直接 push してしまうことがあります。」については、GitHub 側でブランチのプロテクションをかけるという対策もあるかと思います。

かねこたくや

@mugifly
コメントありがとうございます。

Heroku でも、GitHub 連携が提供されています。

記事執筆時にすべての GitHub 連携をはずしていたのと、普段 Heroku も自動デプロイ連携を OFF にしていたので完全に失念していました。ご指摘感謝です！
後ほど記事本文についても修正させていただきますね。

「人間ミスするものなので、間違った内容を直接 push してしまうことがあります。」については、GitHub 側でブランチのプロテクションをかけるという対策もあるかと思います。

force push を禁止する設定は簡単に protection かけられますが、ローカルからの通常の push も禁止して GitHub の PR 経由の merge のみに制限するにはチームメンバーからの Approve を必要にするなど、目的の機能単体で有効にすることができないと認識していたので、このような運用を紹介させていただきました。
本題ではないのでどこまで書くべきか迷ったところではあるのですが、いろいろ対応方法はあるので好みな部分ではありますね。

koki

わかりやすくまとめていただきありがとうございます。

blueprintsについて少し教えてもらえると助かります

本記事ではstagingとproductionのblueprintsをそれぞれ分けていますが、これはmainとstagingブランチそれぞれでrender.yamlを管理して、ブランチごとにblueprintsを作成しているというやり方でしょうか？
（1のやり方どおりなのであれば）FAQを見ると、1つのrender.yamlでstg, prodを管理しているのですが、どちらが良いなどあるでしょうか？←単にblueprintsの分割単位の好みの話？（https://community.render.com/t/development-staging-production-render-yml-example/1441）

かねこたくや

@koki
おっしゃるとおり、弊社ではブランチごとに render.yaml を分けて blueprint を管理しています。

少し考えてみましたが、提示していただいたように、1つの render.yaml で管理してしまう方がコンフリクトなども考える必要がなくシンプルでいいですね！
staging ブランチの運用方針次第かと思いますが、後日時間があるときにその方針で試してみたいと思います。

コメントありがとうございました！