🦁
負荷増加時のスケールアップ・スケールアウトの方針が整理されているか？
負荷増加時のスケールアップ・スケールアウトの方針が整理されているか？
背景・概要
リリース直後は想定通りでも、事業やデータ量の成長に伴ってパフォーマンス劣化や限界が訪れる
あらかじめスケール戦略が明示されていれば、障害前に対応可能
例
- マネージドなコンテナ実行環境（例：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. すぐに実装しなくてよいが、拡張時の障壁や移行コストは事前に理解しておくべき
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：📊 パフォーマンス・スケーラビリティ
レベル：DeepDive（実装・運用レベル）
推奨読者：設計リーダー / SRE / インフラ設計者 / レビュー担当者
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion