マイクロサービス
独立してデプロイ可能な小さなサービスの集合
マイクロサービスは、ビジネス機能ごとに独立したサービスとして分割するアーキテクチャ。 各サービスは独自のデータストアを持ち、APIで通信する。
マイクロサービスアーキテクチャ
👥
Clients
↓
API Gateway
認証、ルーティング、レート制限
↓
👤
User Service
PostgreSQL
📦
Order Service
MongoDB
🏷️
Product Service
PostgreSQL
💳
Payment Service
Redis + MySQL
Message Broker (Kafka/RabbitMQ)
非同期通信、イベント駆動
モノリス vs マイクロサービス
Monolith
User Module
Order Module
Product Module
Payment Module
Single Database
単一プロセス、単一DB
Microservices
User
DB
Order
DB
Product
DB
Payment
DB
独立プロセス、独立DB
マイクロサービスの特徴
利点
- ✓独立デプロイ: サービスごとに個別リリース
- ✓技術選択の自由: サービスごとに最適な技術
- ✓スケーラビリティ: 必要なサービスのみスケール
- ✓障害の局所化: 一部障害が全体に波及しない
- ✓チームの自律性: サービスごとにチーム所有
欠点・課題
- ✗分散の複雑性: ネットワーク障害、データ整合性
- ✗運用コスト: 多数のサービスの監視・管理
- ✗テストの難しさ: サービス間の統合テスト
- ✗デバッグの困難: 分散トレースが必須
- ✗オーバーヘッド: ネットワーク通信、シリアライズ
サービスの分割方法
ビジネスケイパビリティによる分割
組織の業務機能に沿って分割
注文管理在庫管理請求配送
ドメイン駆動設計（DDD）による分割
境界づけられたコンテキスト（Bounded Context）に沿って分割
注文コンテキスト
Order, OrderLine
在庫コンテキスト
Stock, Warehouse
顧客コンテキスト
Customer, Address
サービス間通信
同期通信
Service A
→ HTTP/gRPC →
Service B
REST API: シンプル、広く採用
gRPC: 高性能、型安全
非同期通信
Service A
→ publish →
Queue
→ consume →Service B
Kafka: 大規模ストリーム処理
RabbitMQ: 汎用メッセージング
データ管理パターン
Database per Service
各サービスが専用のデータベースを持つ。 データの独立性を確保するが、サービス間のデータ整合性は結果整合性になる。
Saga パターン
分散トランザクションを複数のローカルトランザクションに分解。 失敗時は補償トランザクションでロールバック。
1. 注文作成
→2. 在庫確保
→3. 決済処理
→4. 配送手配
失敗時: 逆順で補償処理を実行
CQRS (Command Query Responsibility Segregation)
書き込みと読み込みを分離。 書き込みは正規化されたDBへ、読み込みは最適化されたビューから。
マイクロサービスを採用すべき時
適している場合
- • 大規模な組織（複数チーム）
- • 独立したリリースサイクルが必要
- • 異なる技術スタックが必要
- • 部分的な高スケーラビリティが必要
- • ドメインの境界が明確
適さない場合
- • スタートアップ初期
- • 小規模チーム
- • ドメインが不明確
- • 強いトランザクション一貫性が必要
- • 運用能力が不足
Monolith First: まずモノリスで始め、 スケール・組織の成長に応じて段階的にマイクロサービス化するのが推奨される戦略。