🚀

次世代Herokuと噂のRender.comで、Railsアプリをデプロイしてみる

2021/01/11に公開

Render.comについて、日本語記事が全然なかったので紹介します。

(2021/08/01追記 使用感を追加しました)

Render.comとは

様々なWebアプリをGitHub連携で簡単にデプロイできるPaaSです。
https://render.com/

RailsのようなWebサーバーのデプロイ以外にも、静的サイトやバックグラウンドジョブ、またデータベースやスケジュール実行なども提供されており、よほど尖ったことをしない限りは大体のWebサービスはこれひとつでカバーできそうです。
またデプロイプレビュー、様々なミドルウェアのワンクリックデプロイなど、いろいろな便利機能が揃っています。

自分はBlitz.jsのデプロイ先として一番先頭で紹介されていたので知りました。日本だとほぼ知名度がないように見えますが、Twitterで検索してみると「次世代のHeroku」などと紹介されており、徐々に盛り上がりを見せているように感じます。

https://twitter.com/peteskomoroch/status/1345780560610775040?s=20

Render.com公式でもHerokuについての言及があり、「Herokuは古いPaaSである(legacy Platform-as-a-Service solutions like Heroku)」などとなかなか挑戦的なことをいっています。
実際、Render.comのコストは非常に安く、またHerokuよりも諸々が洗練されているように感じました。

https://render.com/render-vs-heroku-comparison

自分はまだ少し触ってみただけですが、確かに非常に体験がよかったので紹介記事を書いてみます。

※筆者はHerokuにあまり詳しくないので、Herokuいいよ!っていう意見があればぜひコメントお願いします

Railsのデプロイ

Railsアプリとバックグラウンドジョブ(Sidekiq)をデプロイするまでの流れを簡単に説明します。
デプロイまでの所要時間はリアルに1分です。簡単。

サンプルレポジトリはこちら(Rails+postgres+sidekiq+redis)
https://github.com/nullnull/rails-rendercom-sample

※せっかくなのでわざわざ記事を書いていますが、触ってれば分かるので特に読む必要もないです。忙しい人向け。

Web Serviceの作成

RailsアプリをデプロイするときはNew Web Serviceを選んで、GitHub連携します。

Image from Gyazo

デプロイ設定

ビルド方法とサーバー起動コマンドを書くだけ。

Image from Gyazo

高度な設定(というほどでもないが)として、環境変数やディスク容量、ヘルスチェックのパスなどを指定できる。

Image from Gyazo

インスタンス別の料金はこんな感じで、だいぶ安め。
GAEがそこそこ高いというのはありつつ、GAEの1/5くらいに抑えられそうなのでありがたい。

Image from Gyazo

デプロイ

ここまでの設定で、GitHubにブランチをpushするとデプロイが始まります。簡単ですね。

push後にすぐデプロイが始まるのと、bundle installのキャッシュが効いているので、デプロイは基本的に爆速です。今回のミニマムなサンプルアプリだと、ブランチpushからサーバー起動まで1分で完了しますね。
自分で試していませんが、native docker supportにより、サービス種別でDockerを選んだ際には docker build に対してもキャッシュが効くようです。これは嬉しい。

環境変数の設定を変更した際も、自動的にデプロイしてくれます。サンプルアプリをそのままリリースすると SECRET_KEY_BASE がなくて怒られるので、適当に設定してみてください。

ログは下記のようにリアルタイムで確認でき分かりやすいです。

Image from Gyazo

デプロイが完了すると、 https://sample-application.onrender.com/ のようなURLでhttpsでホスティングされます。もちろんカスタムドメインも可能。

データベースのセットアップ

New Databaseを選んで設定するだけ。簡単。

Image from Gyazo

こちらの料金も安めですね。

Image from Gyazo

作成後、ホスト名とユーザー名、パスワードをコピーして環境変数に設定すると、サンプルアプリでもDB接続できるようになります。( config/database.yml を参照)

シェル実行

タブの Shell をクリックすると、即時シェルが立ち上がります。上記の通りDB接続できるようにしたら、 bin/rails db:migrate を実行してみましょう。

※ちなみに、db migrationはbuildの際にやるのが公式の推奨らしいです。

https://render.com/docs/deploy-rails#go-production-ready

シェルは bin/rails c していろいろ確認したいときなど便利ですね。

Sidekiqのデプロイ

Sidekiqを動かすために、まずredisをセットアップします。

Redisの設定

以下からOne Click Deployを押すとデプロイできます。
https://render.com/docs/deploy-redis

Image from Gyazo

※この辺で課金設定が必要になります

Redisは公式にサポートされているわけではなく、DockerベースのRedisを動かす形になるようです。
とりあえずSidekiqで使いたいくらいの目的であれば、特に問題なし。

公式のサンプルの通り、render.ymlを書くとdockerベースのアプリを簡単にデプロイできるみたいです。設定を変更したければこれを変更してデプロイすれば良さそう。
https://github.com/render-examples/redis/blob/master/render.yaml

Sidekiqの設定

RailsをNew Web Serviceで作成したのと同様に、SidekiqをBackground Workerとして作成します。その後の手順は特に変わらず、ビルドコマンドとSidekiq起動のコマンドを書くだけです。

環境変数にREDIS_URLを設定する必要がありますが、URLはredisのサービス画面から参照できます。redisはprivate serviceとしてデプロイされ、Render.comの同プロジェクト内からしかアクセスできないようになっています。

Image from Gyazo

その他、細かい話は公式をどうぞ。
https://render.com/docs/deploy-sidekiq-worker

この辺のデプロイも、ドキュメント読みながら数分で終わってとても簡単。

CronJobのデプロイ(スケジュール実行)

GUIでやる際は、New Cron Job をクリックしてここまでと同じ流れでデプロイするだけです。

しかしこれだと1つのスケジュール実行ごとに毎回設定が必要で、cronの量が多い時に大変です。
本番運用ではrender.ymlを使って設定することになりそうです。

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

https://render.com/docs/cronjobs

その他の良いところ

デプロイプレビュー

GitHubでPull Requestを出すたびに、そのブランチでリリースしてくれて動作確認ができます。すごい。
NetlifyやVercelだとお馴染みですが、サーバーサイドのアプリケーションでこれをやってるのは初めてみました。
※HerokuだとReview Appsという機能があるらしい(知らなかった)

Image from Gyazo

接続するデータベースの切り替えなどは、 render.yaml ファイルでプレビュー時用の環境変数を設定することで行えるようです。「3日経過で自動的に削除する」などの設定もできて素敵です。

ちなみに普通にWebに全体公開されるので、プレビュー時はベーシック認証をかけるなどの工夫は必要です。

https://render.com/docs/preview-environments

Blue-Greenデプロイ

デプロイはダウンタイムなしで良い感じに行ってくれます。
https://render.com/docs/zero-downtime-deploys

便利なミドルウェアをワンクリックデプロイ

ワンクリックでBIツールのRedashがデプロイできます。

https://render.com/docs/deploy-redash

同じプライベートネットワーク内にデプロイされるので、Railsアプリで使用されているデータベースへの接続も問題ありませんでした。

redash以外にも、便利なミドルウェアがいろいろワンクリックデプロイできて便利そうです。MetabaseとかElasticsearchなど。
いろいろ便利なのが揃ってそうなので、一通りチェックしてみたい。こういったミドルウェアを試用してみたいときにも便利ですね。
https://render.com/docs/docker

IaC

全てのリソース操作は render.yaml で記述できるため、Infrastructure as Codeがお手軽にできます。
Terraformなどの設定は、普通のWebサービスを作るには冗長だと感じており、コンパクトで分かりやすい記述でIaCできるのは個人的に嬉しいです。
似たような構成のWebサービスを別途立ち上げるときなど、render.yamlをコピーしてGitHubにpushすればそれだけで本番サービスが稼働し始めるのでとても楽ですね。

微妙な点

Japan Regionがない

Japan Regionがなく、 Oregon, USA を選ぶことになる

スケーリングの詳細は不明

Webサーバーのスケーリングは自動でやってくれるらしいが、詳しい記述が見つからず実際どうなのかわからなかった。設定の Instances の項目の以下の記述しか見当たらない。

You can scale your app horizontally by creating multiple instances that are automatically managed by Render's load balancer. Billing for each instance is prorated by the second.

関連
https://feedback.render.com/features/p/docs-on-how-renders-load-balancer-works

また、データベースのRead Replicaの作成やShardingなどはできなそうです。こういった構成が必要になるほど大規模なサービスには向いていなさそうですね。

おわりに(所感)

自分はスタートアップ界隈で所謂フルスタックエンジニアとして活動しており、アプリケーション特有のコアな開発に専念するために、そして開発だけでなくビジネスサイドをケアする時間を作るためにも、インフラ周りに使う時間(=学習時間、立ち上げにかかる時間、運用時間)は極力少なくしたいと常日頃から感じています。

そんな自分がここ2年でメインに触っているIaaS/PaaSはGCP(GAE)で、拡張性と利便性と学習コストのバランスを考えた結果(そしてスタートアップ向け無料クレジット200万のために)使い続けてきたわけですが、Render.comを使ってみて、これでも十分な気がしてきています。だいたいのWebサービス、そんなに複雑なインフラ必要ないので…。
(ちなみにHerokuは、やはり多少使いづらいのとロックインされる印象があって使わなかった)(あくまで印象)

実際に運用してみないとまだ分からないのと、特にセキュリティ面とかどうなんだって感じですが、乗り換えを検討していこうかなと思います。

(追記) 半年使ってみてどうだったか

シードラウンドのスタートアップでtoB向けSaaSを半年間Render上で運用してみたので改めて感想を書いてみます。

GOOD

  • とにかく運用が楽。インフラ周りで工数がかかることがほぼなかった。
  • 手軽にリリースができるので、マイクロサービス化への抵抗がない。「マイクロサービスにした方が理想的だけど、わざわざインフラ用意するのは多少面倒だなあ」という気持ちが一切なくなる。
  • redash, posthogなど気軽に立てて検証できる
  • 大満足

BAD

  • toB向けにサービスを出すにあたっては、セキュリティ周りがやりづらい(権限設定、監査ログ、SOCなど)
  • オートスケーリングはやはり謎で、使いづらい

Discussion