負荷増加時のスケールアップ・スケールアウトの方針が整理されているか？¶
Type: DeepDive
Category: パフォーマンス・スケーラビリティ
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
リリース直後は想定通りでも、事業やデータ量の成長に伴ってパフォーマンス劣化や限界が訪れる
あらかじめスケール戦略が明示されていれば、障害前に対応可能
例¶
- マネージドなコンテナ実行環境（例：GCP Cloud Run、AWS Fargate、Azure Container Apps）を採用し、負荷に応じてインスタンス自動スケール
- データベースはCloud SQL（GCP）→ AlloyDB（GCP）や、RDS → Aurora（AWS）、Azure SQL → Hyperscale（Azure） のように、スケーラブルな移行計画が中長期視点で明記されている
- テナント単位でDB分離を可能にするスキーマ構成（マルチテナント脱却を見据えた構造）
よくある失敗例¶
- 高負荷時にAPIのタイムアウトや接続枯渇が頻発
- 単一のDBで全テナントのデータを管理し続け、移行コストが爆発
- スケーリング対象（DB/Worker/API）を特定していないためボトルネック特定が困難
FAQ¶
Q. スケールアップとスケールアウトの違いは？
A. スケールアップは「同じマシンを強くする」ことで、スケールアウトは「マシンを分散させて複数動かす」こと
Q. 必要ない段階でも考えるべき？
A. すぐに実装しなくてよいが、拡張時の障壁や移行コストは事前に理解しておくべき