個人開発の本番構成は,過剰でも貧弱でもいけない.VPS1台で完結する「ちょうど良い」ミニマル構成を,責務分割の考え方とともに提示する.
対象は最初のサービスを本番運用する個人開発者.読み終えたとき,1台に何をどう載せるかの全体像が手に入ります.
なぜ「ミニマル構成」を最初に決めるのか
最初からマイクロサービスやクラウド満載にすると,運用負荷とコストで自滅する.個人開発の敵は複雑さだ.
逆に行き当たりばったりだと,後から手がつけられない密結合になる.最初に「ちょうど良い型」を決めておくと,育てやすい.
全体像 ― 1台に4つの役割を載せる
ミニマル構成は(1)リバースプロキシ (2)静的フロント (3)APIサーバー (4)DBの4役を,1台のVPSにDockerで同居させる形だ.
前段のNginxがHTTPS終端と振り分けを担い,静的ファイルは直接配信,API呼び出しだけアプリに回す.DBはlocalhostでアプリからのみ繋ぐ.
- Nginx:HTTPS終端・静的配信・/api をアプリへ振り分け
- フロント:ビルド済み静的ファイル(高速・安全)
- API:アプリ本体(Node/Python/Go等)
- DB:localhostバインドでアプリからのみ接続
なぜ静的フロント+APIに分けるのか
フロントをビルド済みの静的ファイルにすると,配信が速く攻撃面も小さい.サーバーは純粋にAPIだけ担えば良くなる.
この分離は将来フロントだけCDNに逃がすといった発展も容易にする.責務がきれいに切れているからだ.
compose1枚で全体を宣言する
4役を1つのcompose.ymlにまとめる.構成全体が1ファイルで再現でき,サーバー移行も一発だ.
ミニマル構成のcompose.yml(骨子)
services:
proxy: # Nginx(443終端・振り分け)
image: nginx
ports: ["80:80", "443:443"]
restart: always
api:
build: ./api
restart: always
env_file: .env
db:
image: postgres:16
restart: always
volumes: ["dbdata:/var/lib/postgresql/data"]
volumes: { dbdata: {} }1台で足りる根拠 ― 個人開発のトラフィック規模
個人開発の初期トラフィックは,適切に設定した1台のVPSで十分さばける.静的配信は軽く,APIも最適化すれば余裕がある.
「将来のスケール」を理由に最初から分散させるのは過剰投資だ.必要になってから分ければ良い.
将来の分離ポイントを「印」だけ付けておく
成長したときに最初に分けるのは,たいていDBかフロント配信だ.Docker化しておけば,どちらの分離も比較的低コストで行える.
今は1台,でも分けられる設計── これがミニマル構成の真価だ.
補論:1台構成は「速いVPS」と「巻き戻し」で完成する
1台に4役を載せる構成は,ディスク速度とメモリ余裕が安定性を左右する.遅い1台に詰め込むと全部が遅くなる.
高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はNVMe SSDで複数コンテナの同居が軽快に回り,後からメモリ増強もできる.スナップショットを取っておけば構成変更の失敗からも即復旧でき,「小さく始めて育てる」に最適だ.
公開の入り口は独自ドメインだ.取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ で取得し,Nginxの前段でHTTPS終端すれば,1台構成のまま本格的なサービスの顔になる.
よくある質問
Q1:本当に1台で大丈夫?
個人開発・初期の規模なら十分だ.適切に設定した1台は,想像以上のトラフィックをさばける.足りなくなってから分ければ良い.
Q2:フロントとAPIは同じドメインでいい?
同一ドメインで/api だけパスで振り分けるのがシンプルで,CORSの悩みも減る.Nginxの振り分け1つで実現できる.
Q3:いつ分散構成にすべき?
1台の増強(スケールアップ)で間に合わなくなったときが目安だ.多くの個人開発はそこに到達する前に,まず1台を使い切ることを考えれば良い.
まとめ ― 「1台で完結,でも分けられる」が最適解
個人開発の本番は,VPS1台に4役を載せ,責務をきれいに分けておくのがちょうど良い.過剰でも貧弱でもない,育てやすい型だ.
まずはcompose1枚でこの構成を立ててみよう.1台で完結する手応えを掴めば,複雑さに振り回されず中身の改善に集中できる.