はじめに
システムに 10、50、または 100 のマイクロサービスがある場合、クライアントは各サービスを直接呼び出すことはできません。 API ゲートウェイは 単一のエントリ ポイントとして機能し、横断的な問題を一元的に処理します。
1. API ゲートウェイが必要な理由は何ですか?
1.1 ゲートウェイがない場合の問題
❌ Client gọi trực tiếp:
Mobile App ──▶ Order Service (https://order.internal:8080)
──▶ Payment Service (https://payment.internal:8081)
──▶ User Service (https://user.internal:8082)
──▶ Catalog Service (https://catalog.internal:8083)
Vấn đề:
├── Client cần biết địa chỉ từng service
├── Mỗi service tự implement auth, rate limit, CORS
├── Thay đổi service address → update client
├── Không có single point để monitor traffic
└── Security: expose internal services ra internet
1.2 API ゲートウェイ ソリューション
✅ Single entry point:
Mobile App ──▶ API Gateway (https://api.example.com)
│
├──▶ /orders → Order Service
├──▶ /payments → Payment Service
├──▶ /users → User Service
└──▶ /products → Catalog Service
Gateway xử lý tập trung:
├── Authentication (JWT validation)
├── Rate Limiting
├── Request Routing
├── Protocol Translation
├── Response Caching
├── Logging & Metrics
└── CORS, Compression
2. 詳細な機能
2.1 リクエストのルーティング
# Kong declarative config
services:
- name: order-service
url: http://order-service.services-prod:8080
routes:
- name: order-routes
paths:
- /api/v1/orders
methods:
- GET
- POST
strip_path: false
- name: payment-service
url: http://payment-service.services-prod:8080
routes:
- name: payment-routes
paths:
- /api/v1/payments
2.2 認証
Client ──Bearer Token──▶ API Gateway
│
JWT Validation:
├── Verify signature (RS256/ES256)
├── Check expiration
├── Validate issuer
└── Extract claims (user_id, roles, tenant_id)
│
Forward headers:
X-User-ID: usr-042
X-Roles: admin,editor
X-Tenant-ID: tenant-001
│
▼
Downstream Service
(trust gateway headers)
2.3 レート制限
Rate Limiting Strategies:
Per User:
user-A: 100 requests / minute
user-B: 100 requests / minute
Per API:
GET /orders: 1000 requests / minute
POST /orders: 100 requests / minute
Per Service Plan:
Free tier: 60 requests / minute
Pro tier: 600 requests / minute
Enterprise: 6000 requests / minute
Response khi exceed:
HTTP 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1711872000
2.4 プロトコルの変換
Browser (REST/JSON) ──▶ API Gateway ──▶ gRPC Service
│
Translate:
- JSON → Protobuf
- HTTP/1.1 → HTTP/2
- REST method → gRPC method
WebSocket ──▶ API Gateway ──▶ Streaming Service
GraphQL ──▶ API Gateway ──▶ REST Services (aggregation)
3. ゲートウェイ ソリューションの比較
| 特長 | コン | アピシックス | 特使 | トレフィク |
|---|---|---|---|---|
| コア | Nginx + Lua | Nginx + Lua | C++ | 行く |
| 構成ストア | ポストグレSQL | etcd | xDS API | ファイル /K8s |
| プラグイン システム | Lua/Go/JS | Lua/Java/Go/WASM | C++/WASM | Goミドルウェア |
| パフォーマンス | 曹操 | 非常に高い | 非常に高い | 曹操 |
| K8s ネイティブ | Kong イングレス コントローラー | APISIX イングレス | エンボイゲートウェイ | トレフィクイングレス |
| サービス メッシュ | コングメッシュ | — | Istio データ プレーン | トレイフィックメッシュ |
| 管理 UI | Kong マネージャー (エンタープライズ) | ダッシュボード (無料) | — | ダッシュボード |
| 学習曲線 | 平均 | 平均 | 曹操 | 低い |
| 最適な用途 | エンタープライズ、プラグインが豊富 | 高性能 | サービスメッシュ | K8s 自動検出 |
3.1 推奨事項
Startup / Small team:
→ Traefik (auto-discovery, Let's Encrypt built-in)
Medium / High performance:
→ APISIX (etcd-backed, hot reload, dashboard free)
Enterprise / Plugin-rich:
→ Kong (mature ecosystem, enterprise support)
Service Mesh integration:
→ Envoy (Istio data plane, xDS API)
AWS ecosystem:
→ AWS API Gateway + ALB
4. フロントエンド用バックエンド (BFF) パターン
クライアント タイプ (Web、モバイル、IoT) に 異なる API が必要な場合:
┌──────────┐ ┌──────────────┐
│ Web │──▶│ Web BFF │──┐
│ Browser │ │ (REST, rich) │ │
└──────────┘ └──────────────┘ │
│
┌──────────┐ ┌──────────────┐ │ ┌──────────────┐
│ Mobile │──▶│ Mobile BFF │──┼───▶│ Backend │
│ App │ │ (compact) │ │ │ Services │
└──────────┘ └──────────────┘ │ └──────────────┘
│
┌──────────┐ ┌──────────────┐ │
│ IoT │──▶│ IoT BFF │──┘
│ Devices │ │ (minimal) │
└──────────┘ └──────────────┘
Web BFF: Trả full data, rich response
Mobile BFF: Response compact, ít fields, optimized bandwidth
IoT BFF: Minimal payload, binary protocol
5. Kubernetes でのデプロイメント
5.1 Kong Ingress コントローラー
# Cài đặt Kong qua Helm
# helm install kong kong/ingress -n gateway --create-namespace
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: rate-limiting
config:
minute: 100
policy: redis
redis_host: redis.platform
plugin: rate-limiting
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: jwt-auth
plugin: jwt
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-ingress
annotations:
konghq.com/plugins: rate-limiting, jwt-auth
konghq.com/strip-path: "false"
spec:
ingressClassName: kong
tls:
- hosts:
- api.example.com
secretName: api-tls
rules:
- host: api.example.com
http:
paths:
- path: /api/v1/orders
pathType: Prefix
backend:
service:
name: order-service
port:
number: 8080
- path: /api/v1/payments
pathType: Prefix
backend:
service:
name: payment-service
port:
number: 8080
6. API ゲートウェイのアンチパターン
❌ Business logic trong Gateway
→ Gateway chỉ xử lý cross-cutting concerns
→ Business logic thuộc về downstream services
❌ Gateway là single point of failure
→ Deploy multiple replicas + load balancer
→ Health check + auto-restart
❌ Quá nhiều aggregation trong Gateway
→ Dùng BFF pattern thay vì biến Gateway thành "God Service"
❌ Không có fallback khi downstream down
→ Implement circuit breaker tại Gateway layer
→ Trả cached response hoặc degraded response
7. まとめ
| コンセプト | キーポイント |
|---|---|
| APIゲートウェイ | 単一のエントリ ポイントで横断的な問題を一元的に処理 |
| ルーティング | リクエストを正しいダウンストリーム サービスにルーティングする |
| 認証 | JWT 集中検証、ヘッダー経由でクレームを転送 |
| レート制限 | バックエンド サービスをトラフィックの急増から保護する |
| 親友 | 各クライアント タイプには、最適化された独自のゲートウェイがあります。 |
| アンチパターン | ビジネス ロジックをゲートウェイに配置しないでください。 |
次の記事: サービスごとのデータベースと多言語永続性 — マイクロサービス アーキテクチャでデータを管理する方法。