xDev Asia

Monolith からの実際の移行ロードマップ。ストラングラーフィグパターン。モノリス分析: ホットスポット、カップリング、依存関係。移行バックエンド: サービスの抽出。移行フロントエンド: MFE の抽出。二重書き込み、データ移行。タイムラインとチーム組織。

マイクロサービスとマイクロフロントエンドのシステム設計 — 基本から運用まで

パート 10: ケーススタディと移行ガイド

xdev.asia

はじめに

ほとんどの実用的なシステムはモノリスから始まります。そして、それは優れたモノリスです。マイクロサービス + マイクロフロントエンドへの移行は、長いプロセスであり、ビッグバンの書き換えではありません。この記事では、安全な段階的な移行パスについて説明します。

Strangler Fig パターン — モノリスからマイクロサービスへの移行

1. ストラングラーフィグパターン

1.1 アイデア

Strangler Fig Tree: cây phụ bao quanh cây chủ,
dần dần thay thế cho đến khi cây chủ biến mất.

Phase 1: Monolith xử lý mọi thứ
┌──────────────────────┐
│      Monolith        │
│ Users│Products│Orders│
└──────────────────────┘

Phase 2: Extract service, route traffic
┌───────────────────────┐
│     API Gateway       │
├───────────┬───────────┤
│ Monolith  │  Product  │
│ (Users,   │  Service  │
│  Orders)  │  (new)    │
└───────────┴───────────┘

Phase 3: Extract more services
┌───────────────────────────┐
│       API Gateway         │
├────────┬────────┬─────────┤
│Monolith│Product │  Order  │
│(Users) │Service │ Service │
│        │        │  (new)  │
└────────┴────────┴─────────┘

Phase N: Monolith is gone
┌────────────────────────────────┐
│          API Gateway           │
├────────┬────────┬──────────────┤
│  User  │Product │    Order     │
│Service │Service │   Service    │
└────────┴────────┴──────────────┘

2. 移行の評価

2.1 モノリス解析

Trước khi migration, hiểu monolith:

Code Analysis:
├── Module coupling (which modules call which?)
├── Database coupling (shared tables?)
├── Hot spots (most changed code)
├── Complexity (cyclomatic, LOC)
└── Team ownership (ai maintain gì?)

Prioritization Matrix:
┌──────────────────────────────────────┐
│         Business Value               │
│ High │ ★ Extract first │ Rewrite    │
│      │   (Product,     │ later      │
│      │    Order)       │            │
│──────┼─────────────────┼────────────│
│ Low  │ Leave in        │ Consider   │
│      │ monolith        │ removing   │
│      │ (low ROI)       │            │
│      └──── Low ─────── High ────────│
│           Change Frequency           │
└──────────────────────────────────────┘

3. バックエンド移行ハンドブック

3.1 フェーズ 1: API ゲートウェイ (第 1 ～ 4 週)

1. Deploy API Gateway trước monolith
2. Route ALL traffic qua Gateway
3. Gateway forward mọi thứ đến Monolith
4. Không thay đổi behavior — chỉ thêm routing layer

Frontend → API Gateway → Monolith (no change)

3.2 フェーズ 2: 最初のサービスの抽出 (第 5 週から第 12 週)

Chọn service ít coupling nhất (ví dụ: Product Catalog)

Steps:
1. Create Product Service (new codebase)
2. Copy/rewrite product logic
3. Setup database (copy product tables)
4. Dual-write: monolith write cả old DB + new service
5. Verify data consistency
6. Switch reads: Gateway route GET /products → new service
7. Switch writes: Gateway route POST/PUT /products → new service
8. Remove product code from monolith
9. Drop product tables from monolith DB (after verification)

3.3 データ移行戦略

Dual-Write Pattern:

Phase A: Monolith writes to Old DB + New DB
         Reads from Old DB
         → Verify New DB data matches

Phase B: Monolith writes to Old DB + New DB
         Reads from New DB (switch)
         → Verify reads correct

Phase C: New Service writes to New DB only
         Monolith no longer involved
         → Clean up Old DB tables

4. フロントエンド移行ハンドブック

4.1 フェーズ 1: シェルアプリ (第 1 ～ 4 週)

1. Create Shell App (new React app)
2. Shell wraps existing monolith frontend (iframe initially)
3. Shell provides Header, Footer, Navigation
4. Gradually replace iframe sections with MFEs

4.2 フェーズ 2: 最初の MFE の抽出 (第 5 ～ 8 週)

Extract Product pages as first MFE:

1. Create product-mfe project
2. Configure Module Federation (expose ProductList, ProductDetail)
3. Shell loads product-mfe via Module Federation
4. Remove product pages from monolith frontend
5. Verify routing, styling, functionality

Shell App
├── Header (Shell)
├── /products/* → Product MFE (new, Module Federation)
├── /cart/* → Monolith Frontend (iframe, temporary)
├── /orders/* → Monolith Frontend (iframe, temporary)
└── Footer (Shell)

4.3 段階的な置き換え

Month 1: Shell + Product MFE
Month 2: + Cart MFE
Month 3: + Order MFE
Month 4: + Account MFE
Month 5: Remove iframe, monolith frontend retired

5. 移行のアンチパターン

❌ Big Bang Rewrite
   → 12-18 months later: "it's not ready yet"
   → Business can't wait, original monolith diverges

❌ Extract based on technical layers
   → "API service", "DB service", "Auth service"
   → Should be business domains: Product, Order, User

❌ Shared database between old and new
   → Defeats the purpose of database per service
   → Temporal coupling, schema changes break both

❌ Migration without observability
   → Can't compare old vs new behavior
   → Can't detect regressions

6. 移行タイムライン (標準)

E-Commerce Monolith → Microservices + MFE:

Month 1-2:  Infrastructure setup
            (K8s, CI/CD, monitoring, API Gateway)

Month 3-4:  First service extraction
            (Product Service + Product MFE)

Month 5-6:  Second service extraction
            (Order Service + Order MFE)

Month 7-8:  Third + Fourth services
            (Cart, User)

Month 9-10: Supporting services
            (Payment, Notification, Inventory)

Month 11-12: Cleanup monolith
              Remove old code, drop old tables

Ongoing:    Optimize, add services as needed

7. 成功の指標

メトリクス	前（モノリス）	後（マイクロ*）
導入頻度	1/週	1 チームあたり 5 ～ 10/日
リードタイム	2週間	1～2日
MTTR	2～4時間	15～30分
故障率の変更	15%	< 5%
チームの自主性	低 (PR の競合)	高（独立）
ビルド時間	15分	2 ～ 3 分 (サービスごと)

概要

ストラングラーフィグパターン: ビッグバン書き換えではなく、段階的に移行します
技術層ではなく、ビジネスドメイン別に抽出
二重書き込みによるデータ移行の安全性
最初に API ゲートウェイ → トラフィックを段階的にルーティングします
フロントエンド: シェルアプリ → MFE を 1 つずつ抽出します
スケジュール: 一般的な電子商取引の場合は 9 ～ 12 か月
成功を測定: 導入頻度、リードタイム、MTTR

🎉 シリーズの完了おめでとうございます!

あなたは旅全体を終えました:

プラットフォーム: モノリス → マイクロサービス → マイクロフロントエンドの進化
バックエンド: サービス分解、API 設計、非同期通信
データ: サービスごとのデータベース、サガ、イベントソーシング
フロントエンド: マイクロフロントエンドアーキテクチャ、モジュールフェデレーション、シェルアプリ
統合: BFF、API ゲートウェイ、GraphQL フェデレーション
品質: テスト戦略、契約テスト
デプロイメント: CI/CD、カナリア、GitOps
本番: 可観測性、パフォーマンス、セキュリティ
実践: ケーススタディ、移行ガイド

次へ: 実際のプロジェクトに適用してください!小規模に開始し、早期に検証し、迅速に繰り返します。

レッスン 30: 移行ガイド — モノリスからマイクロサービスおよびマイクロ フロントエンドへ