アーキテクチャ レッスン3
モノリスとマイクロサービス
単一デプロイ単位のモノリスと、サービス単位で分割するマイクロサービスそれぞれの利点とトレードオフを学ぶ
構造の違い
モノリスは1つのデプロイ単位にすべての機能を含み、マイクロサービスは機能ごとに独立したサービス・ 独立したデプロイ単位に分割します。
Monolith (単一デプロイ単位)
+---------------------------------------------+
| Order Module | Payment Module | User Module |
| (1つのプロセス / 1つのDB) |
+---------------------------------------------+
Microservices (機能ごとに独立したサービス)
+----------------+ +----------------+ +----------------+
| Order Service | | Payment Service| | User Service |
| (own process) | | (own process) | | (own process) |
| own DB | | own DB | | own DB |
+----------------+ +----------------+ +----------------+
| | |
+---------- network calls (API/queue) -----+モノリスの利点と課題
利点
- • 1つのコードベースで開発・デバッグ・デプロイが完結する
- • プロセス内の関数呼び出しなので通信の信頼性・レイテンシを気にしなくてよい
- • トランザクション管理がシンプル(単一DBで完結しやすい)
課題
- • 規模が大きくなるとビルド・テスト・デプロイの時間が伸びる
- • 一部機能だけを独立してスケールさせることが難しい
- • モジュール境界が曖昧だと変更の影響範囲が読みにくくなる
マイクロサービスの利点と課題
マイクロサービスは「善」ではなく、独立性と引き換えに分散システムの複雑さを引き受けるというトレードオフとして理解する必要があります。
利点
- • サービスごとに独立してデプロイ・スケールできる
- • チームごとに担当サービスの技術選定や開発速度の裁量を持ちやすい
- • 障害の影響を一部のサービスに限定しやすい(適切に設計すれば)
課題(必ず伴う代償)
- • ネットワーク越しの通信は失敗しうる(タイムアウト・部分的な障害への対処が必須)
- • サービスをまたぐトランザクションの整合性を保つのが難しい
- • 監視・ログ・デプロイパイプラインなど運用対象が人数分以上に増える
- • どこで何が起きたか追うための分散トレーシングが必要になる
どちらを選ぶか
判断基準は「流行しているかどうか」ではなく、チームの運用体制とサービス分割によって得られる利点が 釣り合っているかどうかです。
小〜中規模チーム
モジュール境界を明確にした「モジュラーモノリス」から始め、運用ノウハウを蓄積する
分割の判断基準
他機能との依存が少なく、独立したスケール・デプロイの必要性が高い機能から段階的に切り出す
複数チーム・大規模組織
チームの自律性やデプロイ頻度の違いが大きい場合、分割の恩恵が代償を上回りやすい
ポイント
- モノリスは単一デプロイ単位でシンプルだが、規模が大きくなるとビルド・スケールの柔軟性に限界が出る
- マイクロサービスは独立性という利点と引き換えに、分散システムの複雑さ・運用コストという代償を伴う
- 「分割可能なモノリス」を経由し、依存が少なくスケールの必要性が高い機能から段階的に切り出すのが現実的
確認クイズ
1 / 3モノリスの特徴として正しいものはどれか？