AWSと自宅サーバーを試して、Cloudflareを選んだ理由【Cloudflare運用記録 #1】
はじめに
こんにちは。
なかのひとカンパニーの archer です。
個人でWebサービスを作ることが増えてきて、
「作ったサービスをどこで動かすか」
を考える機会も増えました。
最初に考えたのはAWSでした。
その後、自宅サーバーでもサービスを動かしました。
そして最近は、Cloudflare WorkersやD1、R2を使ってサービスを公開しています。
Cloudflareを選んだ一番の理由は、
個人開発でサービスを作ってから公開するまでの距離が短かったこと
です。
今回は、AWS、自宅サーバー、Cloudflareと試してきて、なぜ今Cloudflareを使っているのかをまとめます。
最初はAWSを使おうとした
クラウドでサービスを公開するとなると、最初に思いついたのはAWSでした。
EC2。
RDS。
S3。
Route 53。
CloudFront。
サービスも多く、できることも多いです。
仕事でも触れる機会があり、将来的に大きな構成にすることを考えれば有力な選択肢だと思います。
ただ、個人開発では少し違いました。
私が作りたいのは、まず小さなWebサービスです。
その段階でも、
- どのサービスを使うか
- ネットワークをどうするか
- サーバーをどう構成するか
- 月にいくらかかるか
- 使っていないリソースが残っていないか
など、考えることが増えます。
もちろん、きちんと設計すればいい話です。
ただ、
サービスを作りたいのに、サービスを動かすためのことを考えている時間が長い
と感じることがありました。
それなら自宅サーバーでいいのでは
次に使ったのが自宅サーバーです。
自宅にProxmoxを用意し、UbuntuのVMを作り、その上でDockerを動かす。
Webアプリをコンテナ化して、Nginxを置いて外部公開する。
これはこれでかなり面白いです。
自分で全部触れます。
VMを作る。
Dockerを動かす。
ネットワークを設定する。
リバースプロキシを設定する。
障害が起きれば自分で調べる。
インフラを触ること自体が目的なら、かなり楽しい環境です。
一方で、サービスを公開して維持することが目的になると、別の問題も出てきます。
サーバーを起動しておく必要があります。
OSも管理します。
Dockerも管理します。
ディスクもあります。
停電や再起動もあります。
機械なので、いつか壊れます。
クラウドの利用料金はなくても、ハードウェア代や電気代はかかります。
無料に見えて、運用するものは結構多い。
これが自宅サーバーを使って感じたことでした。
Cloudflareを使ってみた
そんな中で使い始めたのがCloudflareです。
最初はDNSやCloudflare Tunnelを使っていました。
その後、
- Workers
- D1
- R2
- Wrangler
- GitHub Actions
なども使うようになりました。
使っていて一番大きかったのは、
リリースするまでが楽だったこと
です。
自分の場合、開発コードはGitHubで管理しています。
そのため、
コードを書く
↓
GitHubへpushする
↓
CIが動く
↓
Cloudflareへデプロイする
↓
公開される
という流れを作れました。
サーバーへSSHして、
git pull
docker compose build
docker compose up
のような作業を毎回する必要もありません。
サーバーそのものを意識する時間がかなり減りました。
GitHubとの相性がよかった
これもCloudflareを選んだ大きな理由です。
個人開発では、GitHubを中心に開発しています。
Issueを作る。
実装する。
PRを作る。
CIを通す。
mainへマージする。
その延長線上にデプロイがあります。
Cloudflare WorkersはGitHubと連携して、pushを契機にビルド・デプロイする構成も取れます。
GitHub ActionsからWranglerを使ってデプロイすることもできます。
つまり、
開発の流れとデプロイの流れを分離しなくていい。
これは思っていた以上に便利でした。
サービスを公開するために別の管理画面へ行って、毎回手作業で何かをする必要が減ります。
お金がかかりにくいのも大きかった
そして、個人開発ではやはりお金も重要です。
サービスを作ったからといって、使われるとは限りません。
アクセスが1日10人かもしれない。
もしかしたら誰も来ないかもしれない。
そんな状態で、
「公開しているだけで毎月固定費がかかる」
となると、サービスを増やしにくくなります。
CloudflareにはWorkers、D1、R2など、それぞれ無料で利用できる範囲があります。
小さなサービスであれば、無料枠の中で試せるものも多いです。
これが個人的にはかなり大きいです。
思いついたら作る。
公開する。
しばらく動かしてみる。
ダメならやめる。
良さそうなら育てる。
このサイクルを回しやすくなります。
「無料」だけで選んだわけではない
ただ、Cloudflareを選んだ理由を、
無料だから
だけにはしたくありません。
自宅サーバーも、すでに機材を持っていればクラウド利用料はほとんどかかりません。
AWSにも小さく始める方法はあります。
それでも現在Cloudflareを使っているのは、
料金
+
公開の容易さ
+
サーバー管理の少なさ
+
GitHubとの相性
このバランスが、自分の個人開発に合っていたからです。
AWSほど多くのサービスを最初から考えなくていい。
自宅サーバーほどインフラそのものを管理しなくていい。
GitHubへコードを置いて、その延長で本番へ出せる。
今の自分には、このくらいがちょうどいいと感じています。
AWSや自宅サーバーを使わなくなったわけではない
もちろん、
「CloudflareがあるからAWSも自宅サーバーもいらない」
という話ではありません。
自宅サーバーは今でも面白いです。
自由度も高く、インフラの勉強にもなります。
AWSは、必要な構成が大きくなったときに選択肢が非常に多いです。
Cloudflareにも制限があります。
Workersには実行時間やリクエスト数などの制限があり、D1やR2にも容量や利用回数の上限があります。
だから、
何でもCloudflareにすればいいわけではない。
ただ、
「思いついたWebサービスを、とりあえず公開してみる」
という自分の使い方では、かなり相性がよかった。
それが今Cloudflareを選んでいる理由です。
今回使ったサービスの料金
今回の記事では、Cloudflareを選んだ理由を中心にしたため、細かな料金までは扱いません。
Cloudflareには各サービスに無料で利用できる範囲があります。
一方で、
- リクエスト数
- CPU時間
- データベース容量
- Read / Write回数
- ストレージ容量
- API操作回数
など、それぞれ制限の考え方が違います。
「Cloudflareは無料」と一括りにすると、少し危険です。
何が無料で、どこを超えると有料になるのか。
ここは個人開発でも知っておいた方がいいと思います。
次回は、
Cloudflareは無料でどこまで使えるのか
をテーマに、Workers、D1、R2などの無料枠と制限を具体的に確認していきます。
※料金・無料枠・制限は記事執筆時点の情報を前提としています。
Cloudflareの料金体系や上限は変更される可能性があるため、実際に利用する際は公式ドキュメントも確認してください。
まとめ
最初はAWSを考えました。
次に自宅サーバーでサービスを動かしました。
そして現在はCloudflareを使うことが増えています。
Cloudflareを選んだ理由は、
- 小さく始めやすい
- 無料で試せる範囲がある
- サーバーそのものを管理しなくていい
- GitHubとの相性がいい
- 公開までの手順が少ない
というところでした。
特に自分にとって大きかったのは、
「作る」と「公開する」がかなり近くなったこと
です。
個人開発では、作るだけでも結構大変です。
なのでインフラについては、できるだけ簡単にしたい。
今のところ、その要求にCloudflareがうまくはまっています。
次回は、Workers・D1・R2を中心に、
Cloudflareを無料でどこまで使えるのか
を調べていきます。