第1章：社会人3年目インフラエンジニアが初めて個人開発をやってみた話 〜AWSで作るはずがCloudflareになった理由〜
はじめに
最初に言っておきます。
私は社会人3年目、インフラエンジニアとしてもまだまだ駆け出しです。
いわゆる 「強いエンジニア」ではありません。 雑魚です。
これを書いているのも、
ロジハラを食らわないための予防線です。笑(冗談です)
普段はL2/L3レベルのNW機器導入や、
クラウド基盤まわりの設計に関わることが多いのですが、
最近なぜか Webアプリ開発案件のPL というポジションになりました。
正直に言うと、
- インフラアーキテクチャの話はなんとかついていける
- でもフロントエンドの話になると何を言っているのかわからない
- バックエンドはAPIの概念を「なんとなく」知っているレベル
という状態。
それなのにレビューをしなければいけない。
「これはまずい…」
という危機感が、今回の個人開発のきっかけです。
どんなサービスか
実装したサービスは「(仮)tmpchat」という名称で、ユーザ認証なしの一時的なChatroomを提供するAPLです。
絶賛テスト/リファクタリング中なので中身については今後変更するかもしれませんが、現時点では以下のようなイメージです。
なぜ個人開発をやろうと思ったのか
理由は大きく4つあります。
① アプリケーションをちゃんと理解したかった
インフラエンジニアをやっていると、アプリはブラックボックスになりがちです。
- APIってどう設計するの？
- 状態管理って何？
- セッションってどうやって保持してるの？
- WebSocketって何が起きてるの？
自分で作ってみないと、レビューなんてできないと思いました。
② 設計から始める開発をやってみたかった
よくある個人開発はとりあえず作る → 後から直すだと思います。
でも今回は、
- 要件定義
- 非機能要件
- アーキテクチャ設計
から入ってみました。
理由は単純で、「AIにレビューさせやすくなるから」です。
設計書があれば、AIを“疑似テックリード”として使える。
実装力がほぼ無い自分にとって、これはかなり重要でした。
③ サービスをちゃんとローンチしたかった
社内ツールとか、学習用アプリではなく、「公開して誰でも使えるもの」を作ってみたかった。
ローンチしない個人開発は、自分の中でどこか“逃げ”な気がしていました。
④ CI/CDやDevOpsを意識した開発をしたかった
- 自動デプロイ
- マイグレーション
- 環境分離
- 運用を見据えた設計
AWSでは運用監視で業務でちょろっと触ったことがあり、資格もAWS-SAPまで取得したので多少は知識がある程度です。
インフラエンジニアなのに、このあたりを自分でやったことがなかったのも事実です。
逃げずにやろうと思いました。
当初はAWSで構築するつもりだった
最初に考えていた構成は、かなり“インフラエンジニアらしい”ものでした。
- ECS（Fargate）でBackend/Frontend
- RDSでDB
- S3で画像保存
- ALBで負荷分散
- Route53で独自ドメイン
- CI/CD込み
ローカルでは docker-compose でFrontendとBackendを分離するような「ちゃんとした構成」をやりたかった。
しかし、現実を知る
ChatGPTに料金を試算してもらいました。
- ALBの固定費
- ECSの最低構成
- RDSの維持費
- Route53 + ドメイン費用
概算で¥10,000(/月)・・・。
「誰も使わない可能性が高いアプリ」に、毎月これを払い続ける勇気はありませんでした。
勉強目的の個人開発としては、明らかにオーバースペックであったため、ここで一度立ち止まりました。
Cloudflareという選択
そこで検討したのが Cloudflare です。
調べてみると、
- Pagesで静的ホスティング
- WorkersでAPI
- Durable ObjectsでWebSocket
- D1でSQLite互換DB
- 無料枠がかなり強い
つまり、「サーバーを持たずに完結する」
実業務でも利用するようなAWS構成にしたいというのが正直なことろでしたが、CloudFlareがMVPとしては最高の選択肢でした。
CloudflareのPros / Cons
実際に触ってみて感じたことを整理します。
| 評価軸 | AWS構成（当初案） | Cloudflare構成 | 個人的所感 |
|---|---|---|---|
| 初期コスト | ❌ 高い（ALB / RDS固定費） | ✅ ほぼ無料で開始可能 | 個人開発にはCloudflareが現実的 |
| 運用負荷 | ❌ インフラ管理が必要 | ✅ サーバー管理不要 | インフラエンジニア的には少し寂しい |
| 学習コスト | △ 慣れているが深い | ❌ 独自思想が強い | Wranglerに最初混乱 |
| 拡張性 | ✅ 非常に高い | △ 制約あり | 大規模化はAWS有利 |
| リアルタイム通信 | △ API Gateway等で構築 | ✅ Durable Objectsで比較的容易 | ここは想像以上に楽だった |
| 将来の企業利用 | ✅ エンタープライズ前提 | △ MVP向け | 本番SaaS化ならAWSに軍配 |
| 思想 | 「サーバーをどう管理するか」 | 「コードをどこで実行するか」 | ここも困惑しました |
- 感想
- CloudFlareは圧倒的に安く利用者が不透明な個人開発では最初の選択肢としてアリ。（無料枠でほぼ完結）
- 特に「まずは世に出す」という観点では、Cloudflareは非常に強い
- Pythonが使えない（当初はFastAPIを想定していた）のがネック
- Wranglerという独自CLI文化がよくわからない
- AWSと思想がかなり違う
- ローカルと本番の挙動差に戸惑う
- 情報量がAWSほど多くない
Wranglerって何？
正直に言います。
最初は「何これ？」でした。
WranglerはCloudflare Workers用のCLIで、
- ローカル開発サーバー起動
- デプロイ
- D1マイグレーション
- 環境変数管理
を一手に担います。
便利ですが、最初は概念を理解するまでに時間がかかりました。
なんならデプロイ後(個人でテスト等を現在実施)の今でもあまり理解できていないのでドキュメント復習してます。。。
最終的な構成
最終的に採用した構成は以下です。
Cloudflare Pages（Frontend）
↓
Cloudflare Workers（Backend）
├─ API
├─ WebSocket
├─ Durable Objects（ChatRoom管理）
├─ D1（永続化）
└─ Cron（定期削除）
シンプルですが、
- セッション管理
- リアルタイム通信
- 有効期限付きのルーム削除
- ルーム毎のチャットファイル出力
といった機能を実現しています。
まとめ
この章では、
- なぜ個人開発を始めたのか
- なぜAWSをやめたのか
- なぜCloudflareを選んだのか
を書きました。
つよつよエンジニアの成功談ではなく、社会人3年目実装力ほぼゼロの挑戦記録です。
これから個人開発をやろうとしている人の参考になれば嬉しいです。
次章では、設計方針や思想など記載する予定です。