🦁

負荷増加時のスケールアップ・スケールアウトの方針が整理されているか？

に公開
Cloud Run
マルチテナント
AlloyDB
スケーラビリティ
saas設計
tech

負荷増加時のスケールアップ・スケールアウトの方針が整理されているか？

背景・概要

リリース直後は想定通りでも、事業やデータ量の成長に伴ってパフォーマンス劣化や限界が訪れる

あらかじめスケール戦略が明示されていれば、障害前に対応可能

例

  • マネージドなコンテナ実行環境（例：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