【スタートアップ・個人開発向け】俺が考えた最強のGCPシステムアーキテクチャ
🎯 目的
自分が個人開発しているアプリのシステムアーキテクチャをまとめて、他の方の参考になること、そして成長するサービスに対応できる堅牢な基盤を構築すること
👤 自己紹介
2018年から2025年までヤフーやBASE株式会社などで、システムアーキテクチャ/アプリケーションアーキテクチャ設計、開発、保守運用を行いました。システム設計のご相談も募集していますので、下記の Wantedly や LinkedIn , X まで気軽にご連絡ください！
| 企業 | 活動内容 |
|---|---|
| ❗ヤフー 2018/4~2022/5 |
・ヤフーショッピングのマーケティングシステムの設計/開発/保守運用を行いました。 ・マイクロサービスアーキテクチャの設計/開発を行いました ・ドメイン駆動設計を導入したアプリケーションの設計を行い、開発効率を向上させました ・15,000rpsのシステムの負荷対策や開発、保守運用を1人で行いました |
| 🛍️ BASE 2022/6~2025/1 |
・モジュラモノリスアーキテクチャのシステム設計/開発を行いました ・テックリードとしてドメイン駆動設計を用いた設計を行い、開発効率を向上させました |
| 🚀 起業 2025/1~現在 |
・フリーランスのアーキテクトとして独立 ・マイクロサービス,モジュラモノリスなどのシステムアーキテクチャの設計コンサル ・ドメイン駆動設計の導入コンサル |
💡 前提
この記事で紹介するアーキテクチャは、以下の想定を前提にしています。
- 👥 MVPは構築済みですでに継続的に利用してくれてるユーザーがいる
- 🛠️ これからユーザー数や利益を増やすために、継続的に開発を行うことを決定している
- 💴 運用費用はできるだけ抑えたい
- 🚀 将来的な拡張性を考慮しつつ、初期段階では過剰な投資を避けたい
そのため、サービスとして当たるかわからないけどとりあえず作ってみるみたいなアプリに本記事で紹介するシステムアーキテクチャはオーバースペックです。まずは Vercel でとりあえずリリースしてみて、ユーザーが継続利用してくれてることを確かめましょう。
また、タイトルが個人開発と題していますが、上記のケースに該当するベンチャーやスタートアップ、大手企業の新規事業アプリなどでも参考になるはずです。
🗺️ システムアーキテクチャ
- 🧮 Compute: Cloud Run
- 💾 DB: Cloud SQL (PostgreSQL)
- ⚡️ Cache: Upstash (Redis)
- 📤 Mail: Resend
- 🌍️ IaC: Terraform
- 🐋 DevOps: Docker Compose
- 🚨 エラー/ログ監視ツール: Sentry / New Relic
- 📊 分析: Google Analytics 4
✨ 設計のポイント
💸 無料枠を活用し、運用費用を抑える
個人開発のため、運用費用をできるだけ抑える必要がありました。そのため、無料枠のあるサービスを利用しています。また、紹介したツール以外にも無料のサービスがあるのでご利用を検討してみてください。
- 📤 メールサービス : Resend / SendGrid (月1万通まで無料)
- ⚡️ Redis : Upstash (無料枠で1日10,000リクエストまで)
- 💾 データベース : Neon / Supabase (無料枠あり)
💪 Cloud Run を採用し、ユーザーが増加した場合も安定した体験を提供
- サーバーレスの Cloud Run を採用し、スケーラビリティとパフォーマンスを維持
- トラフィックに応じて自動でスケールするため、突発的なアクセス増加にも対応可能
- インスタンス数0にスケールダウンする機能で、アクセスがない時間帯のコストを削減
- 初期段階では最小インスタンス数を0に設定し、コールドスタート許容でコスト削減
スケーラビリティ設計
- 初期設定: 最小インスタンス0, 最大インスタンス3, CPU: 1vCPU, メモリ: 512MB
- 成長段階: 最小インスタンス1, 最大インスタンス10, CPU: 2vCPU, メモリ: 1GB
- 急成長時: 最小インスタンス2, 最大インスタンス自動, CPU/メモリは負荷テスト結果から決定
⚡️ フロントエンドとバックエンドを1つのコンテナで起動し、オーバーヘッド&運用費用を抑える
私は、フロントエンドに TypeScript の Next.js App Router を利用し、バックエンドには Python の FastAPI を採用しています。
当初、フロントエンドとバックエンドそれぞれに Cloud Run コンテナを立てて運営していたのですが、以下の問題が出てきました。
- 運用費用の問題: Cloud Run の費用が増加（フロントエンドとバックエンド分）
- ユーザー体験が悪い: 最小インスタンスを0にした場合、ロードバランサー→フロントエンドコンテナ→バックエンドコンテナへの通信でコールドスタート問題が発生し、フロントエンドとバックエンドそれぞれで発生し、レスポンスが遅くなり、ユーザー体験が悪化
そのため、Cloud Run のサイドカーを利用し、1つの Cloud Run コンテナでフロントエンドとバックエンド、プロキシとしての Nginx を起動するようにしました。その結果
- 運用費用削減: これまで2つの Cloud Run を起動していたのが1つになったことで運用費用が削減されました
- ユーザー体験の改善: フロントエンドとバックエンドは同じ Cloud Run で動いているため、フロントエンドからバックエンドのサーバーサイド通信は
localhost:8000で行えます。その結果、連続したコールドスタート問題が解消され、レスポンスが早くなりました。
また、ルーティング制御としてプロキシとしての Nginx コンテナも起動しています。この Nginx コンテナは、
-
example.comならlocalhost:3000のフロントエンドへ -
api.example.comorexample.com/py/apiならlocalhost:8000のバックエンドへ
ルーティングするように conf ファイルを記述しています。
コンテナ共有の利点と欠点
利点:
- インスタンス数が少なくて済むため、運用コスト削減
- フロントエンドとバックエンドの通信がローカルホスト経由で高速
- デプロイが一元化できて管理が容易
欠点:
- コンテナサイズが大きくなり、ビルド・デプロイ時間が長くなる
- フロントエンドとバックエンドが強結合になりがち
- スケーリングの柔軟性が低下（個別にスケールできない）
解決策:
- マイクロフロントエンド化を検討し、特に負荷の高い機能は分離可能に設計
- BFFを導入し、フロントエンドとバックエンドの将来的な分離を容易にする
- ビルドキャッシュを活用し、デプロイ時間を短縮
🔐 セキュリティ設計のポイント
セキュリティは小規模サービスでも非常に重要です。以下の対策を施しています：
- Cloud Armorによるウェブアプリケーションファイアウォール（WAF）の設定
- API通信はJWTトークンを使用し、有効期限を短めに設定（1時間）
- Secret Managerで機密情報を一元管理
- データベースはVPCネットワーク内に配置し、外部からの直接アクセスを制限
- CSRFトークン、Rate Limitingなどの標準的なセキュリティ対策を実装
🚨 モニタリングとロギング戦略
小規模サービスでも問題の早期発見と迅速な対応は重要です：
-
Sentryによるエラー監視（無料枠で十分）
- フロントエンド、バックエンドの両方でエラーをキャプチャ
- Slack連携でエラー発生時に即時通知
-
ログ管理
- 構造化ロギングの導入（JSON形式）
- 重要度別にログレベルを設定（ERROR、WARN、INFO、DEBUG）
- 開発環境ではDEBUGまで、本番環境ではINFOまでを記録
-
パフォーマンスモニタリング
- New Relicの無料枠でAPMを導入（月100GBまで無料）
- ユーザー体験に直結するメトリクスを重点的に計測（TTFB、LCP、CLS）
🚀 CI/CDパイプラインの設計
継続的な開発・デプロイのための自動化パイプラインを構築：
- GitHub Actionsを利用した無料のCI/CD
- ブランチ戦略：GitHub Flow（main + feature branches）
- 自動テスト（単体テスト、結合テスト）の実行
- Terraformによるインフラのコード化（IaC）
- Blue/Greenデプロイによる無停止更新
📈 段階的な拡張計画
サービス成長に合わせた段階的な拡張計画：
Phase 1（現在）: 単一コンテナでのモノリス構成
- コスト効率を優先
- 機能追加と安定運用
Phase 2（MAU 1万人突破時）: 部分的な分離
- フロントエンドとバックエンドの分離
- 負荷の高い機能のみマイクロサービス化
Phase 3（MAU 5万人突破時）: 完全なマイクロサービス化
- ドメイン別の完全な分離
- 専用のサービスメッシュ導入
- マルチリージョン展開の検討
💡 まとめ
個人開発やスモールスタートアップには、過剰な複雑さを避けつつも拡張性を確保したアーキテクチャが最適です。本記事で紹介したシステム構成は、初期コストを抑えながらも、サービスの成長に合わせて段階的に拡張できる柔軟性を持っています。
特に重要なポイントは：
- コスト効率: 無料枠の活用と最小構成での開始
- 将来性: 拡張を見据えた設計
- 自動化: CI/CDとインフラのコード化
- セキュリティ: 基本的な対策は最初から実装
アーキテクチャは完璧である必要はなく、サービスの成長とともに進化させていくものです。まずは小さく始めて、ユーザーのフィードバックを基に改善していきましょう。
ご質問やご相談があれば、記事冒頭の連絡先までお気軽にご連絡ください。
Discussion