💻

Railsをdeployする時に使えそうなPaaSのメモと簡単な評価

2023/09/27に公開

どうも個人開発者のみなさんこんにちは

Railsは好きだけどDeploy先にいつも困る

.

開発してるとあるあるですよね

業務であればterraformでロードバランサーとCloud FrontとEC2とAuroraと……みたいな欲張りワガママセットで良いと思うのですが、個人でやろうと思うと最低料金でも$80~とかになってしまうと思うのでちょっと高いし何よりそんな構成をインフラに慣れていない自分が管理したり運用したりするのは超めんどくさい!!

……という事で、最近自分で使うためにいくつかPaaSを調査したので折角なのでその時のメモを貼っておこうかと思います

求めること

最初に求めることを明確にしておきましょう。スモールなサービスをとりあえずdeployしたい時は自分は以下のような点を重視しています

重要な事

  • 使いやすい
  • 安い
  • 料金が読みやすい / 従量課金は分かりづらい
  • 運用が簡単
  • 地理的に近い
  • 学習コストが低い

重要ではない事

  • 運営元の信頼性 / 出来て1年のスタートアップのPaaSとかでも良い
  • 可用性 / サービスが落ちないかどうかはそこまで重視しない

こう眺めてみると業務サービスとは全くモチベーションが違うことが分かると思います。サーバーがちょくちょく落ちようが、1年で運営元が倒産しようが、アメリカ西海岸からの牧歌的レイテンシーだろうがとりあえず動けばなんでもいいので 「安くて簡単で料金が分かりやすい」 が正義って事ですね

※無料枠についてはどうせPV増えてきたら有料に移行するので最初から有料プラン前提で考えています

その1 Heroku

おすすめ度 ★☆☆

https://jp.heroku.com/

知名度No1、似たようなサービスはだいたい「alternative Heroku」や「next Heroku」を名乗るまさにPaaSの先駆者で代名詞とも言うべき存在

他の後追いサービスと比較してダッシュボードの使い勝手や分かりやすさ、直感的な使い勝手はNo1に近いと思います

分かる人には分かると思いますがあの dev.to もheroku + Railsで運用されてます

.

◆ メリット

  • 使いやすい、分かりやすい
  • 解説記事が多い
  • 普通に本番運用までいける(事例も沢山ある)
  • githubにpush -> 自動deploy

.

◆ デメリット

  • 一番近いのがUS(最低 200ms)
  • tokenを流出させた過去がある
  • heroku独自のxxxみたいな学習コストがある
  • スペックに対して割高

.

個人的評価は可もなく不可もなくという感じです。昔は無料枠があったのですが今は(多分)無くなってしまった事で他のPaaSの方が条件が良いし安いので使わなくなりました

その2 render

おすすめ度 ★★★

https://render.com/

「Herokuで出来ることは大体できる。しかも安い」が売り?のHerokuっぽいPaaS

herokuを除くと一番ダッシュボードがわかりやすく、操作もGUIでポチポチ出来るので超簡単。料金体系もわかりやすくオートスケールなどもサクッと出来るすぐれものです

.

◆ メリット

  • 使いやすい、分かりやすい
  • 公式ドキュメントが多い
  • スペックに対して安い
  • 無料枠がある
  • githubにpush -> 自動deploy

.

◆ デメリット

  • 一番近いのがシンガポール(最低 80ms)
  • 運営「◯◯対応します」→ 2年放置みたいなIssueが散見してるのでスピード感やサポートは望み薄かも

.

ここ数年はrenderを使うことが多かったです(過去形)。料金も安くGUIベースでなんでも出来るからめちゃくちゃ使うのが簡単で、リージョンもシンガポールを選べばそこまで遅くなく、無料枠だけでも一応サービス展開出来て、料金表なども分かりやすいので初心者が初めて使うならとりあえずrender一択で良いと思います

その3 fly.io

https://fly.io

おすすめ度 ☆☆☆

検証でしか使ってないので採用しなかった理由だけ並べておきます

.

◆ メリット

  • 公式ドキュメントが多い
  • 無料枠がある
  • 東京リージョンがある
  • 細かくスペック指定できるので最低料金は安く出来る

.

◆ デメリット

  • とにかく分かりづらい
  • githubからのdeployフローなどを自分で構築する必要がある

.

デメリットに書いた通り「とにかく分かりづらい」につきます。machineが何を示しているのかもわからないし、課金システムもわかり辛いし、操作もCUIベースなのでとっつき辛いですし、自分が今何の操作をしていてそれにはいくらの料金がかかるのか?みたいなのがドキュメントを読み込まないと分からない上に直感と反する初期設定などがあり「本当にこれで合ってるのか?」みたいな不安を常に抱えて作業することになります

deployなどもクセがあり自分で構築しないと行けないですし料金も別にそんなに安いわけではないので、自分と同じく面倒くさいのが嫌な人は使えないかなーと思います

他にも初期設定だとRailsをdeployしてconsoleを開くだけでmemoryオーバーして落ちるのでコンソール作業をするためには課金が必要だったり~と、色々残念な感じです

唯一きらめくメリットが「東京リージョンがある」という点なので、そこをどうしても譲れない人は選択肢に入るかと思います

その4 Koyeb

おすすめ度 ★★☆

https://www.koyeb.com/

新進気鋭のイケてるPaaS。最近Tokyoリージョンに対応したので直近で作ったものはここでdeployしています

.

◆ メリット

  • render.comとほぼ同じメリット
  • 東京リージョンがある

.

◆ デメリット

  • 公式ドキュメントが少なめ
  • スタートアップなので信頼度は未知数

.

分かりやすさ、使いやすさで言うとrenderの方がもう一段上ですがrenderと比べても「ちょっと細部細部が使いづらいかな?」くらいの気持ちでGUIベースでやれる感じなのでそこまでマイナスには感じません。何と言っても東京リージョンがあるのが良くて、金額もrender.comと比べても同じくらいの水準で、何をしたらいくらかかる~といったコスト面も分かりやすいので非常に使い勝手が良いです

マルチリージョンにサクッと対応出来るなどのメリットもあるので、日本人と海外の人の交流掲示板みたいなニッチなものを作るときでも手間を掛けずに展開できる強みがありそうです

※まだ使い始めたばかりなので可用性や障害対応などについてはわかりません

シンガポールと東京リージョンの差について

RDBのデータを数件取得して表示するシンプルなRailsアプリを作ってレスポンス速度を試すと以下のような感じでした

  • render.com
    • 140ms
  • koyeb
    • 50ms

まとめ

ざーっと殴り書きしてしまいましたが何かしら参考になれば嬉しいです

まとめるとこんな感じ

  1. シンガポールでも良いならrender → 使用感が非常に良いし分かりやすい
  2. 東京がいいならkoyeb → renderほどじゃないけど使いやすい
  3. 本格的にビジネス展開を考えていてレスポンスが遅くてもいいならheroku → 最大手で信頼性高い
  4. 完璧を求めるならAWS or GCP → 無限の資本さえあれば全てが叶う

残念ですが他と比較してfly.ioを積極的に選ぶ理由は個人的にはありませんでした(誰かfly.ioのみのエッジを知っていたら教えてほしいです)

他にもRailwayとかもあるそうですが東京リージョンが無いためそれを上回るほどのメリットは感じられず……という感じです

.

もしかしたら、imahさんが書いた記事も参考になるかもしれません(koyebはこの記事で知りました thanks)

https://zenn.dev/imah/articles/a41e889dbf54da

何か間違いやつっこみなどあれば 優しく 教えていただけるとうれしいです

Discussion