1. はじめに：なぜマイクロサービスにAPIゲートウェイが必要なのか
分散マイクロサービスアーキテクチャにおいて、クライアントアプリケーション（Web、モバイル、サードパーティ連携）が数十から数百の個別サービスと直接通信することは、深刻なアンチパターンです。
直接通信モデルでは次のような重大な問題が発生します：
- クライアントと内部サービスの強結合: サービスの分割や名前変更、URLパスの変更がクライアント側の修正を強制します。
- セキュリティ攻撃面の拡大: すべてのマイクロサービスがパブリックインターネットに直接公開され、個別のファイアウォール、CORS、SSL/TLS管理が必要になります。
- 認証とレート制限の重複実装: 各チームが認証トークン検証やトラフィック制限を車輪の再発明として開発し、不整合やセキュリティ脆弱性を生みます。
- 高レイテンシのチャッティな通信: モバイル画面1枚を描画するためにクライアントが10回以上のHTTPリクエストを順次実行し、モバイル回線の遅延が累積します。
直接接続 vs APIゲートウェイパターン
===================================
直接接続モデル（アンチパターン）:
[モバイルアプリ] ──┬──► [認証サービス :8081]
├──► [注文サービス :8082]
├──► [決済サービス :8083]
└──► [在庫サービス :8084]
APIゲートウェイモデル（推奨パターン）:
┌────────────────────────────────────────────────────────┐
│ APIゲートウェイ (:443) │
│ - SSL終端 & CORSポリシー │
│ - JWT暗号検証 & クレーム伝播 │
│ - 分散Redisトークンバケットレート制限 │
│ - パスルーティング & タイムアウト / サーキットブレーカー │
└──────────────────────────┬─────────────────────────────┘
│ プライベートVPCネットワーク
┌────────────────────┼────────────────────┐
▼ ▼ ▼
[認証サービス] [注文サービス] [決済サービス]APIゲートウェイは、システム境界における単一エントリーポイント（リバースプロキシ）として機能し、横断的関心事（Cross-Cutting Concerns）を集約します。
2. コア機能アーキテクチャ
本番運用に耐えうるAPIゲートウェイは、以下の必須機能を備えています：
| 機能レイヤー | ゲートウェイの責務 | 実装メカニズム / プロトコル |
|---|---|---|
| リバースプロキシ & ルーティング | クライアントパスを内部プライベートIP/ポートへマッピング | プレフィックスマッチ、正規表現ルーティング、加重ルーティング（カナリア） |
| エッジ認証 & トークン検証 | 受信リクエストの暗号署名検証、メタデータ付与 | JWT RS256/EdDSA検証、JWKSキーローテーション、mTLS |
| トラフィック制御 & ガバナンス | サービス保護とDoS対策、テナント別クォータ | Redisトークンバケットアルゴリズム、スライディングウィンドウ |
| 耐障害性 (Resilience) | カスケード障害の防止、一時的ネットワーク障害の緩和 | リクエストタイムアウト、指数バックオフ再試行、サーキットブレーカー |
| 可観測性 (Observability) | エンドツーエンドのトランザクション追跡 | W3C TraceContext (traceparent)、分散トレーシング |
| プロトコル変換 | エッジと内部サービスのプロトコル分離 | HTTP/1.1・HTTP/2・WebSocketから内部gRPC/Protobufへの変換 |
3. 認証・認可と多層防御（Defense in Depth）
重要な原則：ゲートウェイ認証は下流の認可を代替しない
多くの開発チームが「ゲートウェイで認証を通過したため、下流のマイクロサービスは認証・認可をチェックしなくてよい」と誤認します。これは極めて危険な設計です。
ゲートウェイが不正侵入された場合、または内部ネットワーク経由でサービスが直接呼び出された場合、すべての下流サービスが無防備になります。多層防御（Defense in Depth）アーキテクチャを適用しなければなりません：
多層防御認証フロー
------------------
[クライアント]
│ 1. Authorization: Bearer <JWT>
▼
[APIゲートウェイ]
│ 2. JWKS公開鍵でJWT暗号署名を検証
│ 3. トークン有効期限(exp)と発行者(iss)を確認
│ 4. 不正リクエストを401 Unauthorizedで即座に拒絶
│ 5. 有効なクレームを内部ヘッダーに変換:
│ - X-User-Id: 98412
│ - X-User-Roles: billing_admin,user
│ - X-Tenant-Id: tenant_corp_a
▼
[下流マイクロサービス (注文・決済)]
│ 6. mTLSでゲートウェイからの接続であることを検証
│ 7. ヘッダーのX-User-Rolesがリソース操作権限を満たすかローカルで認可判断
│ 8. ビジネスロジックを実行4. 分散レート制限：Redisトークンバケットアルゴリズム
インメモリな単一プロセスレート制限は、水平スケーリング環境で機能しません。ゲートウェイインスタンスが10台にスケールした場合、1台あたりの制限が10倍に緩和されてしまいます。
集中型RedisクラスターとLuaスクリプトを用いることで、完全なアトミック性とナノ秒精度のトークンバケットレート制限を実現します：
-- Redis Token Bucket Rate Limiting (atomic Lua Script)
-- KEYS[1]: レート制限キー (例: ratelimit:tenant_123:orders)
-- ARGV[1]: バケット最大容量 (Max Burst)
-- ARGV[2]: 補充レート (トークン/秒)
-- ARGV[3]: 現在のUnixタイムスタンプ (秒)
-- ARGV[4]: 消費トークン数 (通常 1)
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local fill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])
local data = redis.call('HMGET', key, 'tokens', 'last_updated')
local tokens = tonumber(data[1])
local last_updated = tonumber(data[2])
if not tokens then
tokens = capacity
last_updated = now
else
local elapsed = math.max(0, now - last_updated)
tokens = math.min(capacity, tokens + (elapsed * fill_rate))
last_updated = now
end
if tokens >= requested then
tokens = tokens - requested
redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
redis.call('EXPIRE', key, math.ceil(capacity / fill_rate) * 2)
return {1, math.floor(tokens)} -- 1 = 許可, 残りトークン数
else
redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
return {0, 0} -- 0 = 拒絶 (429 Too Many Requests)
end5. 耐障害性パターン：タイムアウト、リトライ、サーキットブレーカー
サーキットブレーカー状態遷移マシン
----------------------------------
┌─────────── エラー率閾値超過 (例: 50%失敗) ───────────┐
│ │
▼ │
┌───────────┐ クールダウン時間経過 (例: 30秒) ┌───────────┐
│ OPEN │ ──────────────────────────────────────► │ HALF-OPEN │
└───────────┘ └───────────┘
▲ │
│ ┌───────── テストリクエスト成功 ───────────┘
│ ▼
┌───────────┐
│ CLOSED │ (通常通信状態)
└───────────┘- 厳格なタイムアウト: ゲートウェイの上流接続タイムアウトは必ず下流サービスの内部タイムアウトよりも短く設定します。
- 安全なリトライポリシー: 冪等（Idempotent）なHTTPメソッド（GET、PUT、DELETE）のみリトライを許可します。POSTリクエストの安易なリトライは決済の二重引き落としを引き起こします。
- サーキットブレーカー: 下流サービスが連続してタイムアウトする場合、サーキットを即座にOPENにしてリクエストを遮断し、フォールバックレスポンスを返します。
6. 実装テクノロジー比較：Envoy vs NGINX vs Kong
| 項目 | Envoy Proxy | NGINX (Open Source / Plus) | Kong Gateway |
|---|---|---|---|
| 開発言語 | C++ (高いメモリ局所性と低レイテンシ) | C (成熟したイベント駆動アーキテクチャ) | Lua / OpenResty (NGINX基盤) |
| 設定更新 | 動的（xDS API経由で無停止ホットリロード） | 静的（設定ファイル変更後のリロードプロセス） | 動的（REST APIまたは宣言型decK） |
| ネイティブプロトコル | HTTP/1.1, HTTP/2, HTTP/3, gRPC | HTTP/1.1, HTTP/2, gRPC (リバースプロキシ) | HTTP/1.1, HTTP/2, gRPC |
| 拡張性 | WebAssembly (Wasm) プラグイン、C++フィルタ | Cモジュール、njs (JavaScript) | Luaプラグイン、Wasmプラグイン |
| 推奨ユースケース | クラウドネイティブ、Kubernetesイングレス、サービスメッシュ | ハイパフォーマンス静的配信、シンプルなリバースプロキシ | プラグインエコシステム重視のエンタープライズAPI管理 |
Envoy Proxy 本番設定スニペット
static_resources:
listeners:
- name: ingress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: api_service
domains: ["api.ladestack.in"]
routes:
- match: { prefix: "/api/v1/orders" }
route:
cluster: orders_backend_cluster
timeout: 3.0s
retry_policy:
retry_on: "5xx,connect-failure,reset"
num_retries: 2
per_try_timeout: 1.0s
http_filters:
- name: envoy.filters.http.jwt_authn
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router7. APIゲートウェイ vs サービスメッシュ
両者は競合するものではなく、相補的な技術です：
- APIゲートウェイ (North-South トラフィック): パブリッククライアントから内部インフラストラクチャへの境界トラフィックを制御します。公開APIの認証、レート制限、マネタイズ、APIバージョニングに特化します。
- サービスメッシュ (East-West トラフィック): 内部マイクロサービス間の通信を保護します（例: Istio, Linkerd）。内部通信の自動mTLS暗号化、サービス単位の詳細メトリクス、きめ細かなトラフィックシフティングを提供します。
8. まとめと本番運用のチェックリスト
堅牢なAPIゲートウェイを運用するための確認ポイント：
- シングルポイント障害の排除: ゲートウェイインスタンスを複数アベイラビリティゾーンに分散し、クラウドロードバランサーでトラフィックを二重化する。
- 暗号検証のローカル化: JWT検証時に外部IdPを同期呼び出しせず、ローカルにキャッシュされたJWKS公開鍵で署名を即座に検証する。
- 下流認証の継続: 内部ヘッダーとmTLSを用いた多層防御を徹底する。
- 分散トレーシングの標準化: W3C TraceContextヘッダーをゲートウェイで付与し、下流の全ログとスパンを紐付ける。
