Herokuの新しい有料プランのまとめと、無料プラン終了後の個人的な移行方針について

はじめに

2022年8月25日に、Herokuが無料プランを終了することを発表しました。

blog.heroku.com

また、9月26日には前回のアナウンス時にはなかった、低コストプランが発表されました。

blog.heroku.com

いずれの内容も英語なので、日本語で要点をまとめてみます。
また、エントリの後半では無料プラン終了後の個人的な移行方針についても書いてみます。

おことわり

このページの情報は2022年10月4日時点の情報です。時間が経つと情報が古くなっている可能性があります。
また、内容の正確性は保証しないので、正確な情報を知りたい場合は上記ページを参照してください。

8月25日に発表された無料プラン終了のまとめ

2022/10/26から1年以上活動のないアカウントとそのストレージを削除する
2022/11/28から無料プランの提供を停止し、無料Dynoと無料DBの稼働を停止していく
影響を受けるユーザーにはメールで通知する
Dynoは$7/月〜、Postgresは$9/月〜、Redisは$15/月〜

9月26日に発表された低コストプランのまとめ

$5/月で1000時間（約41.6日）使えるEco Dynoプランを用意する
使用時間は自分が立てた全Eco Dynoで共有される
30分リクエストがなければスリープする
PostgresのMiniプランは1万レコードの制限付きで$5/月
RedisのMiniプランは25MBの制限付きで$3/月
2022/11/28に無料プランが終わるが、Eco/Miniプランはそれまでに用意される
アップグレード手順は11月上旬にお知らせする

なお、「使用時間は自分が立てた全Eco Dynoで共有される」というのは以下の文面を翻訳したものです。

With that in mind, we’re thrilled to announce our new Eco Dynos plan, which will cost $5 for 1,000 compute hours a month, shared across all of your eco dynos.
Introducing Our New Low-Cost Plans | Heroku

"shared across all of your eco dynos."というのは、アプリA、アプリBというEco Dynoを使う別々のアプリがあって、アプリAとアプリBの稼働時間の合計が1000時間以下なら、2つ合わせて5ドルで済む、というふうに解釈しているのですが、本当に合っているかどうかは確信がありません……。

（追記）
無料プランにも1000時間制限があることに気付きました。Eco Dynoがこれと同じルールだとすると、上記の認識は間違ってなさそうです。

個人のアカウントには、月ごとに 550 時間の基本の Free dyno 時間が割り当てられています。この基本の時間のほかに、クレジットカードで認証を行っているアカウントには、月単位の Free dyno 割り当てに 450 時間が追加されます。つまり、アカウントをクレジットカードで認証しているユーザーには、月ごとに合計で 1000 Free dyno 時間が割り当てられます。
Free dyno 時間 | Heroku Dev Center

ちなみに、1000時間を超えると強制的にスリープさせられるようですね。

その月の Free dyno 時間を使い切ると、そのアカウントの無料のアプリはその月が終わるまで強制的に休眠状態になります。
Free dyno 時間 | Heroku Dev Center

（追記：2022-11-8）
低コストプランが公開されたので実際に移行してみました！
blog.jnito.com

無料プラン終了後の有料プラン一覧

上記の話をまとめて新しい有料プランを一覧化すると次のようになります。

プラン	コスト	制限等
Eco Dyno	$5/月	1000時間（約41.6日）まで、スリープあり。使用時間は全Eco Dynoで共有
Basic Dyno	$7/月	時間制限やスリープなし
Mini Postgres	$5/月	1万レコード、1GBまで
Basic Postgres	$9/月	1000万レコード、10GBまで
Mini Redis	$3/月	メモリ = 25MB
Premium 0 Redis	$15/月	メモリ = 50MB

で、結局有料プランになるとどれくらいお金がかかるの？

有料化によってどれくらいお金がかかるのかは状況によって変わってきますが、いくつかシミュレーションしてみます。

単純なRailsアプリを1つだけ運用していた場合

Dynoがスリープしても構わない、データベースも1万レコードもあれば十分、という場合は、

Eco Dyno = $5/月
Mini Postgres = $5/月

で、合計すると毎月$10の支払いが発生します。

1ドル=144円だとすると、日本円にして毎月1,440円の支払いが発生します。
1年運用すると17,280円になります。

単純なRailsアプリを3つ運用していた場合

Dynoがスリープしても構わない、データベースも1万レコードもあれば十分、というRailsアプリを3つ運用していた場合は

Eco Dyno = $5/月（3つのRailsアプリで1000時間ぶんを共有）
Mini Postgres x 3 = $15/月

で、合計すると毎月$20の支払いが発生します。

1ドル=144円だとすると、日本円にして毎月2,880円の支払いが発生します。
1年運用すると34,560円になります。

個人的な所感

何の収益も発生しない個人的な趣味サイトの場合、最低でも毎月1,440円というのはなんとも微妙なラインですね。。
最近は円安が進んでいるのも悩みの種です。
運用しているサービスに愛着があれば払える金額かもしれませんが、そうでなければやむを得ずクローズ、という選択肢も出てくるかもしれません。

Heroku以外のサービスはどうなの？

Herokuの有料化が発表されてから、「Herokuの代わりになるサービスがあるよ」という情報もよく見かけるようになりました。
たとえば、うなすけさんのブログ記事では以下の3サービスが紹介されています。

blog.unasuke.com

僕自身はこれらのサービスを試してはいないのですが、移行を試みた会社の同僚いわく、「無料であってもデプロイが面倒だったり、すごく時間がかかったりして、Herokuの方が圧倒的に開発体験が良かった」とのことです。

Heroku 以外へ移行しようとして、結局断念して Heroku の偉大さを知っただけであった。
— 中谷一郎 | ichiroc (@ichiroc) 2022年9月18日

なので、僕が考えるに、Heroku以外のサービスへの移行を検討する場合は、

多少開発体験が悪くなっても無料であることを重視する
多少お金を払っても開発体験が良いことを重視する

のどちらを自分が重視するのかを考えて、前者であればHeroku以外のサービスへ、後者であればHerokuのままにして毎月課金する、というのが正解なのかもしれません（あくまで個人の意見です）。

で、伊藤さんはどうするの？

僕が運用している趣味サイトの移行方針は、今のところこんなふうに考えています。

データベースを使っていない、完全に静的なサイト
➡️ JekyllとGitHub Pagesに移行する
データベースは使っているが、単純なデータの入れ物としてしか使っていないサイト
➡️ DBをFirestoreに移行する。DynoはEco Dynoを使う
テーブル同士の複雑な関連や複雑な検索クエリを多用しているサイト
➡️ Eco DynoとMini Postgresを使う（が、そんな趣味サイトはない）

ちなみに、上のリストにはありませんが、「移行するための工数も運用のためのお金もかけられない」と判断したサイトに関してはクローズします。

ケース1の場合

ケース1は「最初からそうしておけよ」っていう感じですね。
RailsとHerokuを使い慣れているので、つい無駄な構成を選択していました😅

ケース2の場合

ケース2は本当に単純なデータのCRUDをするだけのようなサイトです。
ここでいう単純なデータとはたとえば下記のフォームで入力している「サイト管理者からのお知らせ」みたいなデータを指します。

FirestoreはNoSQLなのでPostgreSQLのようなRDBMSとはだいぶん使い勝手が違いますし、ActiveRecordも使えないので自前でデータを出し入れする処理を書く必要はありますが、単純なCRUD処理であればちょっと頑張れば置き換えられます。

また、Firestoreの場合、アクセス数の少ない小規模なサイトであれば無料枠内で十分カバーできそうなので、最初にコードを書き替える努力さえすれば、あとは無料のまま使い続けられそうです。

firebase.google.com

なお、Eco Dynoの$5/月は他のEco Dynoと共有できるっぽいので、これは必要なコストとして受け入れることにします。

2022.12.28追記： Firestore移行のために作ったgemを紹介する記事を書きました！
qiita.com

ケース3の場合

ケース3はFirestore（NoSQL）に移行しようとすると、根本的にアプリケーションの設計を考え直さないといけないようなケースです。
こういう場合はアプリケーションを作り直す工数的なコストと、PostgreSQLを使い続ける金銭的なコストを天秤にかけて、後者を取る、という判断をするのがいいのかな〜と考えています。
ただし、僕が運用している趣味サイトではこういうケースはないので、これはあくまで「もしそんなサイトを作っていたら」という想像です。

参考：Supabaseっていうサービスもあるって聞いたんだけど？

Firebase（Firestore）のような感覚でPostgreSQLを無料で使えるSupabaseというサービスもあるようです。
もしかするとHerokuのPostgreSQLからSupabaseのPostgreSQLにがんばって移行すれば、FirestoreのようなNoSQLではなく、使い慣れたRDBMSを無料で使い続けることができるかもしれません。

supabase.com

ただ、これはあくまでネット上の情報を見ただけの感想ですが、Supabaseの無料枠はあくまでお試し用っぽい位置づけに見えるのと、SQLを直接書けない（PostgRESTというREST APIを使ってデータを読み書きする必要がある）、Ruby用の便利なクライアントライブラリも見当たらない、といった点が少し引っかかったので、僕自身は採用を見送ることにしました。

内容修正＆Supabase、触ってみました
「Supabaseは蓋を開ければただのPostgresデータベースなので、普通に接続していただいてSQLでデータのやり取りを行うことも可能ですよ！」とのコメントをいただいたので実際にやってみました。

Supabase上でデータベースを作成し、PostgreSQLの接続情報をRailsのconfig/database.ymlに書き込んだら、普通にRailsからデータを読み書きすることができました！東京リージョンを選択できるのも嬉しいですね。