モノリスアーキテクチャ
単体アプリケーションの構造と限界
モノリスの構造
🌐
Browser
📱
Mobile
↓
Monolith Application
UI Layer
Business Logic
Data Access
↓
🗄️
Single Database
モノリスの特徴
利点
- ✓シンプル: 単一のコードベース、ビルド、デプロイ
- ✓開発効率: IDEサポート、リファクタリング容易
- ✓トランザクション: 単一DBでACID保証
- ✓テスト: E2Eテストが容易
- ✓デバッグ: スタックトレースが追いやすい
欠点
- ✗スケール限界: 垂直スケールのみ
- ✗デプロイリスク: 全体を再デプロイ
- ✗技術固定: 単一技術スタック
- ✗チーム競合: コード変更の衝突
- ✗障害影響: 一部の問題が全体に波及
スケールの限界
垂直スケール（Scale Up）
Server
2 CPU, 4GB RAM
↓ スペックアップ
Server
8 CPU, 32GB RAM
↓ スペックアップ
Server
32 CPU, 128GB RAM
⚠️ 物理的・コスト的限界
水平スケール（Scale Out）
App
App
↓
Single DB
問題:
- • セッション共有
- • DBがボトルネック
- • ステート管理
モノリスを卒業すべきサイン
📈
スケール限界
垂直スケールでは性能要件を満たせない
👥
チームの成長
10人以上でコード競合、コミュニケーションコスト増大
🚀
デプロイ頻度
一部の機能を独立してデプロイしたい
💥
障害の影響範囲
一部の障害が全体に波及し、可用性が低下
Modular Monolith（中間選択肢）
Modular Monolith
Module A
API
Logic
Module B
API
Logic
Module C
API
Logic
Shared Infrastructure
利点
- • モジュール間の境界が明確
- • 将来の分割が容易
- • デプロイは単一のまま
実現方法
- • パッケージ/名前空間で分離
- • モジュール間はAPIで通信
- • DBスキーマもモジュール単位
モノリスのベストプラクティス
モジュラー設計
将来の分割を見越して、モジュール境界を意識
CI/CDの整備
テスト自動化、デプロイ自動化で安全にリリース
ステートレス化
セッションは外部（Redis等）に保存、水平スケール準備
監視・ログ
将来のデバッグのために、構造化ログとメトリクス