1.初めに
今回は、タイトルにある通り、Renderでデプロイしたアプリで、気が付いたらNeonのCU-hrs/月の無料枠を超えてしまっていた件について書きたいと思います。割と、プログラミングスクールでポートフォリオを作成される方は、インフラはRenderでデプロイして、DBはNeonを利用されてる方が多いと思うので、今回の件が役に立てばと思います。
採用技術
- Ruby 3.3 / Rails 7.2
- Tailwindcss
- PostgreSQL
- Render
- Neon
2.問題発生の経緯
たまにRenderのメモリがオーバーすることがあったのでログを見ていたら、DBと接続できな状況になっていました。
（※その時のlogは現状見れませんでした。）
そこで、Neonを確認したところ、CU-hrs/月の無料枠を超えてしまっていました。
（※補足：CU-hrsとは、CUは「データベースのパワー」、CU-hourは「そのパワーをどれくらいの時間使ったか」を表す指標です。）引用記事：https://qiita.com/Noa-aoN/items/49a884207027dab2966d
3.今回の原因
なぜ、CU-hrs/月の無料枠を超えてしまっていたのでしょうか？実は、GASで15分おきにRenderをkeep-aliveしていた宛先のトップページの中にSQLが組み込まれていたのが原因でした。
railsあるあるだと思うのですが、ヘッダーやフッターはpartinal化するのが一般的だと思います。ですので、トップページにはSQLはなかったのですが、ヘッダーの中にSQLが組み込まれていたので、GASで15分おきにSQLを叩いていたのがオチでした。その結果、CU-hrs/月の無料枠を超えてしまっていました。
<% StudyUnit.ordered.each do |unit| %>
上記が原因のコードでした(汗)
4.対策
今回なのですが、対策方法として、ヘルスチェックを利用することにしました。
(※ヘルスチェックとは、アプリケーションが正常に動いているのかを確認する行為です)
Rails7.1以降は、標準で/upというヘルスチェック用のエンドポイント(システムが外部と通信するための窓口)が準備されるようになりました。
get "up" => "rails/health#show", as: :rails_health_check
実際に上記のようなコードが作成されます。
いままでは GASの先がトップページでしたが、以下の様に宛先を変更することでSQLが実行されないように回避できました。
function wakeUpRender() {
var url = "https://culture-link.onrender.com/up"; // /up に変更
UrlFetchApp.fetch(url);
}
5.まとめ
周りで、Neonの無料枠を超えたという話を聞いたことがなかったので、最初は驚きましたが、無事に解決できてよかったです。インフラ周りというのは奥が深く、パフォーマンスや何をしたらコストが掛かるといった観点の重要性を痛感しました。また、railsのヘルスチェックという機能を使いこなせていなかったので、ここで触れられてよかったと思います。この記事が、役に立てば幸いです。
参考記事