個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある
「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。
そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。
通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。
ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。
仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいかなーと見込むことにする。
ではこの1万円をどこに割り振っていくかというと一般的なWebサービスではコスト最適化のボトルネックはDBになりがちである。それはCPUやメモリと違いストレージ領域のリソースが24/356の時間に対して発生するからであり、現在の次元で暮している限りそうそう変化しそうにない。
開発者に無料のPostgreSQLサーバーを提供しているfly.ioの人も以下のようにストレージ領域の特殊性を説明している
Stored data occupies space all the time, though, whether your app is running or not. Recovering data from hardware failure means you have to be storing it with some redundancy. You need replication and backups. This means more disk space, but it also means more management. Disks are not easy! https://fly.io/blog/free-postgres/
ではDBのコスト削減を目指す個人開発者の戦略としてどうするのがいいかというと以下が一般的な方法だと思う
1. SQLあきらめる
「SQLあきらめる」というのはマスターデータの保存先をMySQLやPostgreSQLなどの馴染みのあるDB製品を使わずにドキュメント単位のスケールを前提としたDBを活用する。個人開発は規模が小さく収まるのでコストも抑えられるという考え方になる。
実際によく利用されているDB製品は以下がある
- Cloud Firestore(Fibaseのバックエンド)
- Amazon DynamoDB(AWS Amplifyのバックエンド)
- MongoDB Atlas(次点)
自分はFirestoreでReadクエリが1日に3-4万回、Writeクエリが1万回程度の小規模なサイトを管理しているけど無料枠の範囲内なのでDBのコストは月¥5になってる(¥5て)
(データの大半はGoogle Driveに逃がしているので、それもFirestoreに含めたらもっと上がると思う)
ただこれらのDBは現在広く普及しているRailsやLaravelやSpringなどのWebフレームワークがSQL互換DBとの連携を基盤にしているので、それらから見たら非主流なWebフレームワークを使うことになる。
00-10年代はSQL互換サーバーを使った開発に慣れてしまっているのでこのギャップを越えられる人は多くない。
整合性やトランザクションなどのDB特性を考慮して避ける例もあるが、エンタープライズ領域ならまだしも個人開発でそれらを気にしている人は少数派である。
個人開発界隈でのここの選択肢はNode.js系の独壇場で例えば以下がある
デメリットとしては規模に応じて従量課金されるので、SQL互換DBの方がコストが抑えられる分岐点がくるというのがあると思う。むしろその時を向かえたことがないので大ヒットサービスを運用している人に感想を聞きたい。
2. DBサーバー使い回す
プロジェクト間で同じDBインスタンスを使う方法。プロジェクトが増えるごとにコスト優位になる。
デメリットとしてはプロジェクト間の依存関係を受け入れる必要がある。これは想像に難しくないのでこのぐらの説明でよさそう
3. DB自分で立てる
アプリケーションサーバーとDBサーバーを物理的に分散させず、同じVMやVPS環境にインストールして動かす。パブリッククラウドが主流になるまで取られていた懐しの手法。
デメリットとしてはマネージドサービスではないのでDBサーバーのメンテナンスを自分で行う必要がある。
これは自分的には「コスト削減できるけどメンテナンス時間10倍になる」方法だと認識しているので避けてる。
4. 実行環境でDBに接続しない
静的サイトをして書き出しあとはフロントエンドの実行コードでなんとかする手法。Jamstackとか呼ばれがちである。
例えばDBにマスターデータを保存して管理画面で管理して利用しつつ、サイトにデプロイする時だけビルドサーバーからDBに接続できればいい、という考え方になる。
Webアプリ向けの方法だと思われがちだけど例えば /api/items.1.json に直接レスポンス実体を置いておく、などをしてバックエンドAPIとしても構築できる。
デメリットとしてはWebサービスの要件が限られる。最も顕著なのは実行時に書き込みを伴うUGMのようなサービスは作れない。
いかがでしたか?
いかがでしたか? SQLをあきらめよう
5. 安いSQLを使う
新興のPaaSはパブリッククラウドのプラットフォームより価格が低いことが多いのでそれを使うという方法もある*1
具体的には選択肢としては以下がありそう
(各社フリープランは本番運用を想定していなさそうなので省いた)
デメリットとしては価格は変わる可能性があるのと、利用実績がAmazon RDSやGoogle Cloud SQL等より少ないから個別の問題解決の機会が発生することもあるという感じでしょうか。
自分は月1万予算と言わずできるなら1千円ぐらいまで最適化したいので、このあたりは選択肢に入れてなかった。
Aurora Serverless*2については以前試した時はVPC内のアプリケーションから接続しないといけなくシステム総合でコストがどの程度になるのか見積れてないのでどのぐらいの金額になりそうか不明。最近v2になっていろいろ環境は変わっているので知ってる人は教えて欲しい。
いかがでしたか? SQLをあきらめるな
*1: 安いSQL: https://twitter.com/razokulover/status/1521747504546869249 の反応を拾った
*2:Aurora Serverless: https://b.hatena.ne.jp/entry/4719081102410498498/comment/thaim のコメントから
