関連記事：Web開発の技術マップ
アプリケーションのアーキテクチャには、大きく「モノリス」と「マイクロサービス」の2つのアプローチがあります。それぞれにメリットとデメリットがあり、プロジェクトの状況に応じた選択が重要です。
モノリスアーキテクチャとは
すべての機能が1つのアプリケーションにまとまっている構造です。
┌─────────────────────────────┐
│ モノリスアプリ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ 認証 │ │ 商品 │ │ 注文 │ │
│ └──────┘ └──────┘ └──────┘ │
│ ┌──────┐ ┌──────┐ │
│ │ 決済 │ │ 通知 │ │
│ └──────┘ └──────┘ │
│ 1つのデータベース │
└─────────────────────────────┘
モノリスのメリット
- シンプル：構造がわかりやすい
- 開発しやすい：ローカルで全体を動かせる
- デバッグが容易：問題箇所を特定しやすい
- デプロイが簡単：1つのアプリをデプロイするだけ
モノリスのデメリット
- コードベースが大きくなると変更の影響範囲が広がる
- スケーリングが全体単位になる（一部だけスケールできない）
- 技術の統一が必要（一部だけ別言語にしにくい）
- チームが大きくなると開発のボトルネックになりやすい
マイクロサービスアーキテクチャとは
機能ごとに独立したサービスに分割し、それぞれが独立してデプロイ・スケール可能な構造です。
サーバーレス入門も参考にしてください。
┌──────┐ ┌──────┐ ┌──────┐
│ 認証 │ │ 商品 │ │ 注文 │
│サービス│ │サービス│ │サービス│
│ DB │ │ DB │ │ DB │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└────────┼────────┘
│
API Gateway
マイクロサービスのメリット
- サービスごとに独立してデプロイできる
- 技術選択の自由度が高い（サービスごとに異なる言語を使える）
- スケーリングが柔軟（負荷の高いサービスだけスケール可能）
- チームがサービス単位で独立して開発できる
マイクロサービスのデメリット
- 複雑さが大幅に増す
- サービス間の通信コストが発生する
- 分散トランザクションの管理が難しい
- 運用・監視の負荷が高い（サービスが増えるほど大変）
- デバッグが困難（問題がどのサービスで起きているか特定しにくい）
比較表
| 項目 | モノリス | マイクロサービス |
|---|---|---|
| 構造 | シンプル | 複雑 |
| デプロイ | 全体を一括 | サービス単位 |
| スケーリング | 全体単位 | サービス単位 |
| 技術選択 | 統一 | サービスごとに自由 |
| チーム規模 | 小〜中規模に適する | 大規模に適する |
| 運用コスト | 低い | 高い |
| 障害の影響 | 全体に波及しやすい | サービス単位で隔離可能 |
どちらを選ぶべきか
モノリスを選ぶべき場面
- スタートアップや新規プロジェクトの初期段階
- チーム規模が10人以下
- プロダクトの要件がまだ固まっていない
- 運用チームが小規模
マイクロサービスを選ぶべき場面
- チーム規模が数十人以上
- サービスごとに異なるスケーリング要件がある
- 独立したデプロイサイクルが必要
- 十分な運用・監視体制がある
実際のところ
多くの場合、最初はモノリスで始めて、必要に応じてマイクロサービスに移行するのが現実的です。最初からマイクロサービスにすると、複雑さに対応するコストが大きく、開発速度が落ちるリスクがあります。
中間的なアプローチ
モジュラーモノリス
モノリスの内部をモジュールに分割し、将来的にサービスとして切り出せるようにする手法です。モノリスのシンプルさを保ちつつ、マイクロサービスへの移行パスを残せます。
まとめ
マイクロサービスは魅力的に見えますが、そのメリットを享受するには十分なチーム体制と運用能力が必要です。まずはモノリスで始めて、本当に分割が必要になったタイミングで移行を検討するのが、多くのプロジェクトに適したアプローチです。
