はじめに
API ゲートウェイは、フロントエンドからのすべての API 呼び出しに対する 単一のエントリ ポイントです。認証、レート制限、ルーティング、監視などの横断的な問題に対応し、マイクロサービスがビジネス ロジックに集中できるように支援します。
1. API ゲートウェイが必要な理由は何ですか?
1.1 ゲートウェイなし
❌ Client gọi trực tiếp services:
Frontend ──► User Service (port 8001)
──► Product Service (port 8002)
──► Order Service (port 8003)
──► Cart Service (port 8004)
Vấn đề:
- Frontend phải biết địa chỉ từng service
- Mỗi service tự implement auth, rate limit, CORS
- Không có single point for monitoring/logging
- Service addresses thay đổi → frontend phải update
1.2 API ゲートウェイを使用する
✅ Single entry point:
Frontend ──► API Gateway (/api/*) ──► User Service
──► Product Service
──► Order Service
API Gateway handles:
├── Authentication (JWT verification)
├── Rate Limiting (100 req/min per user)
├── Routing (path-based → service)
├── Load Balancing (round-robin)
├── SSL Termination
├── CORS
├── Request/Response transformation
└── Monitoring & Logging
2. API ゲートウェイの比較
| 特長 | コン | APISIX | エンボイ ゲートウェイ | AWS API GW |
|---|---|---|---|---|
| コア | Nginx/OpenResty | Nginx/etcd | 特使代理人 | 管理 |
| パフォーマンス | 高 | 非常に高い | 非常に高い | 高 |
| プラグイン | 100+ | 80+ | フィルター経由 | AWS ネイティブ |
| K8s ネイティブ | コングイングレス | APISIX イングレス | K8s ゲートウェイ API | 該当なし |
| 構成 | DB/宣言型 | etcd/YAML | K8s CRD | コンソール/CF |
| ダッシュボード | コングマネージャー | Apache ダッシュボード | 該当なし | コンソール |
| コスト | オープンソース | オープンソース | オープンソース | リクエストごとに支払う |
| こんな用途に最適 | 一般 | 高パフォーマンス、中国 | K8s ネイティブ | AWS エコシステム |
3. Kong の構成
3.1 宣言型構成 (kong.yml)
_format_version: "3.0"
services:
- name: product-service
url: http://product-svc:8080
routes:
- name: product-routes
paths:
- /api/v1/products
strip_path: false
plugins:
- name: jwt
- name: rate-limiting
config:
minute: 100
policy: redis
redis_host: redis
- name: cors
config:
origins: ["https://app.example.com"]
methods: ["GET", "POST", "PUT", "DELETE"]
- name: order-service
url: http://order-svc:8080
routes:
- name: order-routes
paths:
- /api/v1/orders
plugins:
- name: jwt
- name: rate-limiting
config:
minute: 50
3.2 主要なプラグイン
| プラグイン | 目的 |
|---|---|
jwt | JWT トークンを検証する |
rate-limiting | 消費者ごとのレート制限 |
cors | CORS ヘッダー |
request-transformer | リクエストのヘッダー/本文を変更する |
response-transformer | 応答を変更 |
prometheus | メトリクスエンドポイント |
file-log / tcp-log | ロギング |
ip-restriction | ホワイトリスト/ブラックリスト IP |
4. APISIX 構成
routes:
- uri: /api/v1/products/*
upstream:
type: roundrobin
nodes:
"product-svc:8080": 1
plugins:
jwt-auth:
key: "product-key"
limit-req:
rate: 100
burst: 50
key_type: "var"
key: "consumer_name"
- uri: /api/v1/orders/*
upstream:
nodes:
"order-svc:8080": 1
plugins:
jwt-auth: {}
5. ゲートウェイのパターン
5.1 パスベースのルーティング
/api/v1/products/* → Product Service
/api/v1/orders/* → Order Service
/api/v1/users/* → User Service
/api/v1/cart/* → Cart Service
5.2 ヘッダーベースのルーティング
X-API-Version: v2 → v2 service
X-Client-Type: mobile → mobile-optimized service
5.3 カナリアルーティング
95% traffic → Product Service v1 (stable)
5% traffic → Product Service v2 (canary)
6. API ゲートウェイの GitOps
Repository:
├── gateway/
│ ├── kong.yml (declarative config)
│ ├── plugins/
│ └── consumers/
└── .github/workflows/
└── deploy-gateway.yml
CI/CD:
1. PR: change gateway config
2. Review: team review routing/auth changes
3. Merge: auto-apply via deck sync (Kong)
4. Monitor: check metrics after deploy
概要
- API ゲートウェイ = すべての API 呼び出しに対する 単一のエントリ ポイント
- 横断的な処理: 認証、レート制限、ルーティング、モニタリング
- Kong: 汎用、成熟した、豊富なプラグイン
- APISIX: etcd を介した高性能の動的プラグイン
- Envoy ゲートウェイ: K8s ゲートウェイ API ネイティブ
- GitOps: 宣言型構成、バージョン管理