個人開発のための cloud 利用を考える (2025春 時点)

個人の趣味で web service を開発、運用する場合の cloud 利用についての考察。

ひと昔前は自宅 server 運用かレンタルサーバーという選択だったと思うがそれも遠い昔。 2025年時点では cloud (IaaS, PaaS, etc.) 利用が第一候補でしょう。

2025年時点での私の選択

月間 100k req. 程度までを想定するなら AWS CloudFront + Lambda + SQLite on EFS の構成を選択。Always free で多くが無償、EFS の課金が月間 10円程度になる。(SQLite 100MB として)

大規模側への scalablity は全く無いが、zero 方向への scalablity は良好。可用性、耐久性も高く、SLA (Service Level Agreement) の対象 service で構成できる。

SQLite on EFS について、詳しくは SQLite on EFS はどの程度実用的か を参照。

個人開発をする上で何が課題か

個人開発の場合、開発行為そのものよりも継続して運用することに課題が大きい。

VPS を借りてその上に自前で必要なものを構築するという方法は自由度は高いものの、security update 対応や、OS 層から上の障害対応などを自分で面倒をみなければならない。 特にいつ起こるかわからない障害対応を考えると、目を離せないというストレスを抱えることになる。
# もちろん、自宅 server に比べると VPS は hardware 障害の対応を hosting 事業者に任せることができる面では楽にはなっているけど。

すべての要素をいわゆる serverless の構成にすれば障害対応はかなり楽になる。一方で、費用面であったり、取れる構成の制約面で不利になる。

これらの要素をいい塩梅で両立(妥協)できるかが悩みどころとなる。

どんな選択肢があるか

まず、どんな選択肢がありそうかあげてみる。 ただし、要求事項を絞らないと発散してしまうので以下の条件を前提に考えていく。

PaaS はどうだろうか?

Heroku を始めとした PaaS (Platform as a Service) は簡単に始められるという点で魅力的な選択である。 しかも OS 以下を platform として提供・管理してもらえるため、管理の手間も軽減できるし、無償 plan もあったりする。

ただ、個人的には継続利用に懸念を感じる。 Heroku や Fly.io の例をみても、無償 plan で利用者を増やす時期(=投資家に needs があることを示すことが重要な時期)が過ぎると、基本的には収益化のために有償化される。 PaaS では platform に特化して開発しているので、他の platform への移行(移植)もそれなりの修正規模になりがち。PaaS 有償化のたびに移行先を探したり修正をするというのは運用に手をかけたくないというところから外れていく。

Proof of Concept として作るもので、1年程度の運用期間限定として考えるなら PaaS はありだろう。長い期間で利用考えるとちょっと選びにくい。 もしくは、きちんと収益化できて経営的に安定していそうな PaaS に課金して使うかのどちらかだろうか。

Shared hosting service (レンタルサーバー)

昔からあるレンタルサーバーという選択は1つの現実解にはなりうる。 個人開発という視点では、残念ながらこの10年ほどでレンタルサーバーは WordPress 専用あつあいになってきていて、個人開発したものを載せたいという場合には制約がある場合もある。 演算処理中心ではなく、contents 配信が中心の用途であれば検討する価値はあるだろう。

Public cloud (AWS, Azure, Google Cloud)

3大 cloud vendor の中で、個人開発用途で利用しやすいのは AWS であろう。 理由としては2つあり、2021年から CloudFront 経由の転送量が 1TB まで無償になった点は大きく、また課金の最小単位が小さいものが多いことも使いやすい。

Public cloud 利用において費用面で特に注意が必要なのは転送量課金である。多少の差はあるものの、概ね各社 送信 1GB あたり $0.1 の課金となる。 Web page １PV あたりのデータ量は 1〜2MB (HTML+JavaScript+画像等) が平均値との調査から、1PV = 1MB送信と仮定してみつもると、月間 100k PV で $10 (約1 500円)、1M PV で $100 (約15 000円) となる。 小規模であればよいが、CPU課金よりも転送課金のほうが高くなりがちなので注意が必要。

小規模に安価に、かつ運用の楽な serverless ということを考えると、以下あたりが候補だろう。

選択肢まとめ

Storage (database) の選択

ここまででおおまかに選択肢をあげてみた。ここからはもう少し具体的に個別の要素を見ていく。

File を保管する storage としては、AWS S3 はじめとした object storage の利用で迷うことはあまりない。 どの cloud vendor も保存した data 量に応じた課金なので、少量であれば少額の課金で済む。

選択が難しいのは database。Data model、検索性、整合性などの要求により多数の選択肢がでてくる。

Public cloud 各社の NoSQL

Server 管理不要で少額から利用可能となると、public cloud 各社の NoSQL database が候補にあがる。 AWS DynamoDB, Google Cloud Firestore, Azure CosmosDB はどれも固定費なしで少額からの運用が可能、無料利用枠も設定されている。 Scalability の観点から、→0 も →∞ もどちらの方向にも良好に scale する。

一方で、NoSQL には標準的な data model が定まっていない点は考慮しておいたほうが良い。 それぞれの database に固有の data 構造となるため、他の database へ移行しようとしたら API 書き換えだけでは済まずに根本的な書き直しが必要になるだろう。

また、例えば DynamoDB の best practice にあるように use case に合わせて設計する必要があり、これは裏を返せばあとから要件が追加になった場合の対応が難しい場合がありうるということ。 DynamoDB の場合であれば、あとから local secondary index の追加ができないため、検索要件が変更/追加になると対応が難しい場合がありえる。

Relational database ( SQL ) を使いたい

上記で NoSQL の特徴を書いたが、開発初期段階で要件も明確になっていない状態から try & error しながら作っていく際にはやっぱり SQL が使いやすい。 排他制御や整合性といった面倒なところは database 側でやってくれるし、schema(=data構造) と query(=data利用方法) を分離して考えて設計できる。

設計変更に対する柔軟性という観点では、schema に変更を入れる必要があっても、SQL 言語を利用した migration script を少し書くことで新しい schema へ移行できる。 NoSQL の場合には、自前で旧→新形式へ移行用の変換 code を書く、もしくは新旧両方の data 形式を扱えるように coding したりといったことが必要になる場合もあるが、SQL であればそのあたりの面倒も軽減される。

別の観点で、SQL であれば、ほぼすべての cloud service で MySQL 互換か PostgreSQL 互換の managed database service を使うことができる。 = 開発したものが scale するのに応じて platform を乗り換えるということが容易である。

ということで、SQL を利用できるとだいぶ楽をできる & 自由度が増すのだが、instance 単位の課金が多く →0 の場合でも固定費用が発生してしまいがちな点が課題。

小規模向けに使いやすい SQL

AWS RDS, Google Cloud SQL をはじめ、SQL の場合は instance 単位での毎月固定費用が課金される形態が多い。 Google の db-f1-micro が中でも安価な部類だが、$7.6/月 〜 の固定費がかかる。耐久性が必要なら $15/月〜。

これよりも安価に SQL を使いたい場合の選択は、SQLite を使うか、DaaS(Database as as Service)の無償 plan という選択がある。

SQLite は client-server 型とは異なり、library として application に組み込み、OSの file system I/O だけで SQL を実装したものである。 POSIX の read, write, lock が動けば利用できるので、レンタルサーバーの CGI から cloud まで非常に幅広い環境で利用できるのが特徴である。 欠点としては、書き込みの制御を調停する process がなく file lock の取得だけで排他制御を行っているため、複数接続からの同時処理がある場合には性能がでない。 PostgreSQL や MySQL は CPU core 数までは同時接続数の増加にともなって性能は上がっていくが、SQLite の場合 1接続時が性能最大で同時2接続から性能が低下していくため、この点は注意が必要である。

様々な環境に SQLite database を載せる選択肢があるが、安価かつ高信頼を確保できる利用方法として冒頭にあげた AWS EFS に SQLite を載せる方法がある。 詳しくは SQLite on EFS はどの程度実用的か を参照。

SQLite を使う方法以外では、以下のような DaaS の無償 plan という選択肢もある。 無償 plan の場合は可用性や耐久性の保証はない点には注意。

Compute 部分の選択 (自分で書いた code を走らせる環境)

Cloud が普及してきて、immutable infrastructure という考え方が浸透してきた。 Docker container がその代表例だが、一度 setup したものを修正しながら利用するのではなく、毎回すべて作り直し次の版に更新する際に廃棄するという使い捨て方式で service 更新していくという考え方になる。

これまでの管理方法だと、server の状態 + 差分修正で管理していくため、server の状態を正しく把握しておくことが必須になる。 これが immutable infrastructure になると現状には影響されなくなり、運用管理がかなり楽になる。 個人開発でも積極的に取り入れるべきだろう。

Scale to zero

"Immutable" (=不変、内部に状態を保存しない)ことで、使い捨てできるだけでなくいつでも on-demand で同じ構成の複製を起動できるようになった。 これは cloud と相性がよく、負荷に応じて必要な計算資源を自動で増減させる auto-scale が容易に実現できることにつながる。

Auto-scale を小規模側に拡張したのが "scale to zero" という考え方である。 使っていないときは計算資源割当は0まで落としてしまい、request が来たときに起動するという方式で、2016年の AWS Lambda 登場以降、Google Cloud Run などに広がっている。 個人開発の面では、この scale to zero infrastructure をうまく活用することで運用の手間と費用の削減を両立できる。

Scale to zero の場合の注意点として、cold start 時間の確認はしておくべき。 資源確保が 0 になっている状態で request がきた場合は起動、初期化から開始されるためどうしても1回目の応答には余分に時間がかかってしまう。 検索すれば測定例は出てくるが、Lambda + Rust であれば 100ms 程度で大きな問題はないが、runtime が大きな処理系(言語)では長めになるため自分の使う処理系で実測しておくのがよい。

移植性という観点からは、Docker container で deploy できる platform を利用するのが最も汎用性は高いだろう。

Scale to zero できる代表的な service としては以下があげられる。

組み合わせ例

運用の手間、運用費用、設計自由度 すべてを同時に満たす解は見つけられていないが、以下の組み合わせあたりが候補になるのではないか。