はじめに
この記事は、実際の E コマース プラットフォームに適用された、これまでの 28 の記事から得たすべての知識を要約したものです。アーキテクチャの決定→実装→展開→監視。
1. システム要件
1.1 ビジネス要件
ShopX E-Commerce Platform:
├── Product catalog: 100K+ products
├── Users: 500K registered, 50K DAU
├── Orders: 5K orders/day, peak 500 orders/hour
├── Teams: 5 feature teams + 1 platform team
├── SLA: 99.9% uptime, p95 < 500ms
└── Growth: 3x yearly
1.2 アーキテクチャ決定記録 (ADR)
ADR-001: Microservices Architecture
- Status: Accepted
- Context: Monolith đã quá lớn (500K LOC), 5 teams conflict
- Decision: Decompose thành Microservices theo DDD
- Consequences: Distributed complexity, cần invest vào infra
ADR-002: Micro Frontend with Module Federation
- Status: Accepted
- Context: Frontend monolith (React, 300+ components)
- Decision: Module Federation, 1 MFE per team
- Consequences: Shared UI library cần, performance budget enforce
ADR-003: Event-Driven Architecture (Kafka)
- Status: Accepted
- Context: Cần loose coupling, event replay, audit trail
- Decision: Apache Kafka cho domain events
- Consequences: Eventual consistency, team cần learn async patterns
2. サービス設計 (DDD ベース)
Bounded Contexts → Services:
┌─────────────────────────────────────────────────┐
│ Core Domain │
│ ├── Product Service (Catalog, Search, Review) │
│ │ DB: PostgreSQL + Elasticsearch │
│ │ Team: Product Team (4 devs) │
│ │ │
│ └── Order Service (Checkout, Tracking, History) │
│ DB: PostgreSQL (Event Sourcing) │
│ Team: Order Team (4 devs) │
├─────────────────────────────────────────────────┤
│ Supporting Domain │
│ ├── User Service (Auth, Profile, Address) │
│ │ DB: PostgreSQL │
│ ├── Cart Service (Cart, Wishlist) │
│ │ DB: Redis │
│ ├── Inventory Service (Stock, Warehouse) │
│ │ DB: PostgreSQL │
│ └── Notification Service (Email, Push, SMS) │
│ DB: PostgreSQL │
├─────────────────────────────────────────────────┤
│ Generic Domain │
│ ├── Payment Service → Stripe/VNPay integration │
│ └── Auth → Keycloak (off-the-shelf) │
└─────────────────────────────────────────────────┘
3. マイクロフロントエンドの分解
Shell App (Platform Team):
├── Global Header, Footer, Sidebar
├── Routing orchestration
├── Auth integration (Keycloak)
└── Design System (@shopx/ui)
Product MFE (Product Team):
├── Product List / Grid
├── Product Detail
├── Search & Filters
├── Reviews
└── Route: /products/*
Cart MFE (Cart Team):
├── Cart Page
├── Mini Cart (header widget)
├── Wishlist
└── Route: /cart/*, globally: MiniCart component
Order MFE (Order Team):
├── Checkout flow
├── Order History
├── Order Tracking
└── Route: /orders/*, /checkout/*
Account MFE (User Team):
├── Profile, Addresses
├── Payment Methods
├── Preferences
└── Route: /account/*
4. インフラストラクチャのアーキテクチャ
AWS Architecture:
┌─────────────────────────────────────────────┐
│ CloudFront CDN │
│ (MFE static assets, caching) │
├─────────────────────────────────────────────┤
│ ALB (Application Load Balancer) │
├─────────────────────────────────────────────┤
│ EKS Cluster (Kubernetes) │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Kong │ │ Web BFF │ │ Services│ │
│ │ Gateway │→│ (Node) │→│ (pods) │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Kafka │ │ Redis │ │ OTEL │ │
│ │ (MSK) │ │(Elasti- │ │Collector│ │
│ │ │ │ Cache) │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ RDS PostgreSQL (Multi-AZ) │
│ ElastiCache Redis │
│ Amazon MSK (Kafka) │
│ Amazon Elasticsearch │
└─────────────────────────────────────────────┘
5. 主要な技術的決定
| 決定 | 選択 | 理論的根拠 |
|---|---|---|
| フロントエンドフレームワーク | React + モジュールフェデレーション | チームの専門知識、MFE サポート |
| バックエンド ランタイム | Node.js (高速化) | FE と同じ言語、高速 I/O |
| API スタイル | GraphQL (BFF) + gRPC (内部) | 柔軟なクエリ + 高速な内部処理 |
| データベース | PostgreSQL + Redis + ES | ポリグロット、実証済み、スケーラブル |
| メッセージブローカー | アパッチカフカ | イベント ソーシング、リプレイ、耐久性 |
| 認証 | キークローク | オープンソース、OIDC、RBAC |
| CI/CD | GitHub アクション + ArgoCD | GitOps、K8s ネイティブ |
| モニタリング | グラファナ + プロメテウス + ロキ + テンポ | 完全な可観測性スタック |
| 導入 | Canary (Argo ロールアウト) | プログレッシブ自動分析 |
6. 学んだ教訓
1. Start with 3-4 services, not 15
→ Quá nhiều services ban đầu = quá nhiều complexity
2. Design System trước khi build MFE
→ UX inconsistency rất khó fix sau
3. Contract Testing saves production
→ Đầu tư vào Pact sớm, ROI rất cao
4. Observability từ Day 1
→ Không phải "thêm sau được" — cần tracing từ đầu
5. Feature Flags cho mọi feature mới
→ Decouple deploy from release
6. Event Sourcing chỉ cho Order Service
→ CQRS cho Product (search), CRUD cho User/Cart
→ Đừng over-engineer
7. Mono-repo (Turborepo) cho giai đoạn đầu
→ Cross-cutting changes dễ, shared code seamless
→ Evaluate multi-repo khi team > 50
概要
このケーススタディは、適切なパターンを適切なユースケースに適用すると、アーキテクチャが実用的で本番環境に対応できることができることを示しています。すべてのサービスがイベント ソーシングを必要とするわけではなく、すべてのフロントエンドがマイクロ フロントエンドを必要とするわけではありません。