今運用しているアプリ達をすぐにHeroku以外に移すということはしないまでも、競合となるプロダクトの調査をしておくことは(特に後発のものについては)機能面で実はこんなに便利なものがあったのか、と気づくことにもなったりするので、やっておいて損はないかと思いました。
比較する対象としては、インターネットで最近見かけるPaaSを選定しました。同様のことができるIaaSのコンポーネントとして、AWS FargateやGoogle Cloud Runがありますが、そのようなIaaSの一部として提供されるものについては今回は比較対象とはしません。
今回の比較対象は以下3つです。
HerokuにdeployするようなRailsアプリに必要な要素とは何かを考えたとき、まずDBが必要なのは当たり前として、Active Job(Sidekiq)やAction Cableを使いたいからRedisも使えてほしいです。もともとHeroku上にファイルはアップロードできないのでオブジェクトストレージは不要としました。
そこで、簡単なチャット(?)アプリを作りました。GitHubアカウントでログインすると100文字以内の文字列を投稿できます。ログイン状態に関わらず、投稿は自動的に更新されます。この仕組みは勉強も兼ねてTurbo Streamsで構築しました。
公式にもHeroku対抗を謳っているだけあり、とてもHerokuに似たサービスです。僕自身、以前の記事で採用したことがあります。
Migrate from Heroku to Render | Render
実際、使い勝手としても、DBを作成すると環境変数 DATABASE_URL
が自動的に追加されたりなどの挙動がHerokuと似ていて、新しく流儀を覚えなおす手間が少なくてよかったです。ただ、リソースは全てが一覧に出てきてアプリごとに管理するようなものではなかったです。deployはGitHubにpushすると自動で行われる感じでした。
Herokuにおける app.json
と似たようなものとして、Blueprintという仕組みがあります。これによって、アプリで使用するリソース、接続情報などの環境変数、さらには接続を許可するIPアドレスなどをコードで管理できる(かつ、更新されたら自動で適用してくれる)のが便利でした。欲を言えばこのrender.yamlの書式が間違っている場合のエラーメッセージの親切さがもうちょっと欲しい1ところでした。
価格ですが、DBにHeroku Postgresのような無料プランがなく、自動的に3ヶ月後から月$7になってしまいます。RailsとRedisは稼動している時間が制限内であれば無料のまま動かせるようなので、HerokuのHobbyプランを使っていると考えれば、まあ……というところでしょうか。
また、今回deployしたアプリでは使いませんでしたが、Diskとminioを組み合わせたオブジェクトストレージを用意できるのは便利そうです。
サービスとしてはコンテナやbuildpackによってビルドしたサービスをdeployできるPaaSです。
Herokuみたいな"Deploy on Railway"ボタンが作れるのもいいですね。
また、公式及びコミュニティから提供されているStarterがかなり豊富です。
使い勝手としては、UIはすごくよくできてて操作が快適なのはよかったです。様々な言語、フレームワークに対応しているというか汎用的で、反面Herokuと比較すると自分で設定しないといけないことが多いように感じました。リソースもprojectごとにまとめて管理できるのがHerokuっぽくて良いです。deployはGitHubにpushすると自動で行われる感じでした。regionは現時点で選択できず、US-Westのみです。"We plan to add additional regions.“ と公式FAQにはあります。
公式CLIが、npmやyarn経由でインストールしても実行可能なバイナリが配置されず、GitHub releaseからダウンロードしないといけなかったりちょっと不安ですが……
UIがすごくよくできている、というかよくできすぎていて、DBの中身が見れちゃうのは凄いと思います、がそんなに気軽に見れちゃていいの……?
価格体系がpricingページからはちょっとわかりづらいです。
dashboradのbilingを見るとどのくらいのコストになるかが予測で表示されるのが嬉しいです。
サービスの使い勝手とは関係ないですが、内部の実装はJob descriptionを見るとBorgとMesosの論文から独自に開発しているようでアツいです。
GoogleのBorgとSpanner、FacebookのTwineにインスパイアされて作ったPaaS基盤らしい。KubernetesではなくBorgとMesos論文もとにした独自のオーケストレーションエンジンを開発してるってJDに書いてあった。こりゃ面白いかもしれんね。 / “Railway” https://t.co/oWvwG73xQ8
— inductor (@inductor) May 1, 2022
上記ツイートにぶら下げられているJob descriptionは今は見れません、以下に移動したようです。
https://www.notion.so/Open-Jobs-bdc641c4b72947f2ab1e09bea5362363
mizchiさんのこのブログ記事で聞いたことのあるという方は多いんじゃないでしょうか。僕もそのうちの一人です。
Edge Worker PaaS の fly.io が面白い - mizchi’s blog
現在は公式サイトに "Run your full stack apps (and databases!) all over the world. No ops required.” とあるように、マネージドなPostgreSQLも使えるようになっています。公式ドキュメントにもRailsをdeployする方法についての記載があります。
https://fly.io/docs/getting-started/rails/
感想としては、CLI (flyctl) から操作するのがメインだなという印象です。環境変数の追加も閲覧もWebからではできず、CLIからしか行うことができません。DBとしてPostgreSQLを追加するのはそんなに苦労しませんでしたが、Redisを追加するのに結構手間取りました(接続情報を自分でRails側に渡してあげないといけない)。deployも手元で flyctl deploy
をするフローです。
Herokuと比較した場合、東京リージョン(nrt)があるのが嬉しさでしょうか。
価格はこのようになっています。Herokuと比較してどうなるのかというのは一見ではわかりません。Usageを見ると現時点でのリソース消費量がわかります。
https://fly.io/docs/about/pricing/
また、これはサービスの使い勝手とは関係ありませんが、アプリケーションがFirecracker上で動くのはアツいですね。メトリクスにもFirecrackerの状態が出ています。
https://fly.io/docs/reference/architecture/
自分がHerokuに慣れているというのもあるせいか、どうしても、どれもHerokuより多少なりとも複雑だなあという印象です。これらで、僕が移行するなら以下の順で検討すると思います。
また今回、Herokuから移行するなら、という点でサービスを選定しましたが、これは複数人で管理していく2ことも考慮しています。要するに、本気でお金をかけたくないのであれば複数のサービスを組み合わせて運用するのも選択肢としてあると思います。
個人開発のサービスをVPSからVercelとCloud Runに移行した話
今回deployしたアプリは今後数ヶ月ほどはそのまま動かしておいて価格がどうなるかを見たいと思います。その後は落とすかもしれませんし、データもバックアップはしません。