はじめに
「マイクロサービス」は、ソフトウェア アーキテクチャで最も注目されているバズワードです。しかし、マイクロサービスから始めるのは多くの場合間違いです。この記事では、どのアーキテクチャをいつ使用するか、安全に移行する方法について分析します。
1. モノリスアーキテクチャ
1.1 モノリスとは何ですか?
┌─────────────────────────────────────────┐
│ Monolith Application │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ User │ │ Order │ │ Payment ││
│ │ Module │ │ Module │ │ Module ││
│ └────┬─────┘ └────┬─────┘ └────┬─────┘│
│ │ │ │ │
│ ┌────▼────────────▼────────────▼─────┐ │
│ │ Shared Database │ │
│ └────────────────────────────────────┘ │
│ │
│ 1 deployable unit │
│ 1 process │
│ 1 database │
└─────────────────────────────────────────┘
1.2 メリットとデメリット
Ưu điểm:
✅ Simple development & debugging
✅ Simple testing (1 app)
✅ Simple deployment (1 artifact)
✅ No network overhead (function calls)
✅ ACID transactions dễ dàng
✅ Phù hợp team nhỏ (< 10 devs)
Nhược điểm:
❌ Code base lớn → khó hiểu
❌ Build/deploy chậm
❌ Scale phải scale TOÀN BỘ app
❌ Technology lock-in (1 language/framework)
❌ 1 module crash → toàn bộ app crash
❌ Team lớn → merge conflicts, coordination overhead
2. モジュラーモノリス
┌─────────────────────────────────────────────┐
│ Modular Monolith │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ User │ │ Order │ │ Payment │ │
│ │ Module │ │ Module │ │ Module │ │
│ │ │ │ │ │ │ │
│ │ Public │ │ Public │ │ Public │ │
│ │ API only │ │ API only │ │ API only │ │
│ │ │ │ │ │ │ │
│ │ Private │ │ Private │ │ Private │ │
│ │ DB schema│ │ DB schema│ │ DB schema│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 1 deployable, nhưng modules tách biệt │
│ Module giao tiếp qua PUBLIC interfaces │
│ Không shared database tables │
└─────────────────────────────────────────────┘
→ 80% benefits của Microservices
→ 20% complexity
→ Best starting point cho hầu hết projects
3. マイクロサービス アーキテクチャ
3.1 原則
1. Single Responsibility:
Mỗi service làm 1 việc, làm tốt
2. Bounded Context (DDD):
Mỗi service sở hữu domain riêng
e.g., "Order" trong Order Service ≠ "Order" trong Shipping
3. Independently Deployable:
Deploy service A mà không ảnh hưởng service B
4. Decentralized Data Management:
Mỗi service có database riêng
KHÔNG shared database!
5. Design for Failure:
Assume services WILL fail
Circuit breakers, retries, fallbacks
6. Smart Endpoints, Dumb Pipes:
Logic trong services, không trong message bus
3.2 アーキテクチャ
API Gateway
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ User │ │ Order │ │ Payment │
│ Service │ │ Service │ │ Service │
│ │ │ │ │ │
│ REST API │ │ REST API │ │ gRPC API │
│ │ │ │ │ │
│ Own DB │ │ Own DB │ │ Own DB │
│(Postgres)│ │(MongoDB) │ │(Postgres)│
└──────────┘ └──────────┘ └──────────┘
│ │ │
└───────────────┼───────────────┘
│
Message Bus
(Kafka/RabbitMQ)
4. マイクロサービスを使用しない場合
❌ Team < 10 developers
❌ Startup giai đoạn đầu (chưa rõ domain boundaries)
❌ Simple CRUD application
❌ Không có DevOps maturity (CI/CD, monitoring, container)
❌ Team chưa có kinh nghiệm distributed systems
❌ Tight deadline, cần ship nhanh
Microservices Tax:
- Network latency giữa services
- Distributed transactions (phức tạp!)
- Service discovery, load balancing
- Distributed tracing, centralized logging
- Container orchestration (K8s)
- Data consistency challenges
- Testing complexity (integration tests)
→ Nếu team < 5 người, chi phí này > lợi ích
5. 移行: ストラングラー フィグ パターン
5.1 概念
Giống cây sung bóp nghẹt (strangler fig):
Cây mới mọc BỌC QUANH cây cũ
Dần dần thay thế
Cây cũ chết, cây mới đứng vững
Phase 1: Monolith + New Service
┌──────────────────────┐
│ API Gateway/Proxy │
└──────┬───────────────┘
│
┌────▼────┐ ┌──────────┐
│Monolith │ │ New User │
│(all) │ │ Service │
└─────────┘ └──────────┘
/api/users → New Service
/api/* → Monolith
Phase 2: More Services
┌──────────────────────┐
│ API Gateway/Proxy │
└──────┬───────────────┘
│
┌────▼────┐ ┌──────────┐ ┌──────────┐
│Monolith │ │ User │ │ Order │
│(shrink) │ │ Service │ │ Service │
└─────────┘ └──────────┘ └──────────┘
Phase 3: Monolith eliminated
┌──────────────────────┐
│ API Gateway │
└──────┬───────────────┘
│
┌──────▼──┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ User │ │ Order │ │Payment │ │Inventory│
│Service │ │ Service │ │Service │ │Service │
└────────┘ └─────────┘ └─────────┘ └─────────┘
5.2 ステップ
1. Identify Boundaries:
DDD → Bounded Contexts → Service boundaries
Tìm module ÍT coupling nhất → Extract trước
2. Build Proxy:
Đặt API Gateway/Proxy trước Monolith
Route traffic theo path
3. Extract Service:
a) Copy code sang service mới
b) Tạo database riêng
c) Migrate data
d) Route traffic → new service
e) Remove old code từ monolith
4. Repeat:
Extract tiếp service khác
Monolith thu nhỏ dần
6. サービス分解戦略
1. By Business Capability:
Marketing → Marketing Service
Sales → Sales Service
Fulfillment → Fulfillment Service
2. By Subdomain (DDD):
Core domain → Core services (in-house)
Supporting domain → Supporting services
Generic domain → Buy/SaaS (auth, email, payment)
3. By Data Ownership:
User data → User Service
Product data → Catalog Service
Order data → Order Service
4. By Team:
Team A owns Service A
Team B owns Service B
Conway's Law: System mirrors org structure
比較の概要
| 基準 | モノリス | モジュラーモノリス | マイクロサービス |
|---|---|---|---|
| 複雑さ | 低い | 中 | 高 |
| 導入 | シンプル | シンプル | 複雑な |
| スケーリング | 垂直 | 垂直 | 水平/サービス |
| 技術の多様性 | シングルスタック | シングルスタック | 多言語対応 |
| チームの規模 | 1-15 | 5-30 | 20歳以上 |
| データの一貫性 | 酸 | 酸 | 最終的な |
| 推奨スタート | ✅ | ✅✅ | ❌ |
演習
-
アーキテクチャの決定: Fintech スタートアップ、6 人の開発者チーム、MVP は 3 か月以内に出荷する必要があります。機能: ユーザー認証、ウォレット、トランザクション、KYC。モノリス、モジュラーモノリス、またはマイクロサービスを選択しますか?説明する。
-
Strangler Fig プラン: Monolith e-commerce (15 開発者) には、認証、ユーザー、製品、注文、支払い、在庫、通知、分析のモジュールがあります。移行計画を作成します。どのサービスを最初に抽出するか、その理由は何ですか?
-
境界コンテキスト: 「製品」という単語は、カタログ (名前、説明、画像)、在庫 (在庫、倉庫)、価格設定 (コスト、割引、マージン) で異なる意味を持ちます。境界のあるコンテキスト マップを描画します。