API Gateway は『マイクロサービスの玄関口』
マイクロサービス時代、複数サービスへのアクセスを統一的に管理する API Gateway は重要な基盤です。本記事では編集部の視点で、設計と運用を公開情報をもとに整理します。マイクロサービス設計 もご参考に。
API Gateway の主要機能
(1) ルーティング：パス/ヘッダ/メソッドで振り分け。(2) 認証・認可：JWT 検証 / API Key / OAuth。(3) レート制限：ユーザー/IP/エンドポイント単位。(4) 変換・集約：複数サービスのレスポンス結合。(5) 観測性：統一的なログ・メトリクス・トレース。
主要プロダクト
(1) AWS API Gateway：REST/HTTP/WebSocket。(2) Kong：OSS+商用版・プラグイン豊富。(3) Cloudflare API Gateway：CDN との一体運用。(4) Apigee：エンタープライズ・分析機能。(5) Tyk / Krakend：軽量OSS。料金・機能は最新の公式情報をご確認ください。
認証の戦略
(1) JWT 検証を Gateway で：バックエンドの負荷削減。(2) OAuth Token Introspection：失効も検知。(3) API Key：シンプルな B2B API向け。(4) mTLS：マシン間通信に。(5) SCIM / SAML 連携：エンタープライズ要件。OAuth/OIDC 実装 もご参考に。
レート制限の設計
(1) 無料/有料プラン別の制限。(2) エンドポイント別の差：重い処理は厳しく。(3) burst と sustained：短期/長期の組合せ。(4) 429 + Retry-After：標準レスポンス。(5) X-RateLimit-* ヘッダ：透明性確保。API レート制限実装 もご参考に。
ルーティングと変換
(1) パスベースルーティング：/api/v1/users → users-service。(2) ヘッダベース：X-Tenant でテナント分離。(3) レスポンス集約：複数サービスの呼び出しを1リクエストに。(4) 変換：内部スキーマ→公開スキーマ。(5) BFF (Backend For Frontend)と組合せ。GraphQL 実践 もご参考に。
運用上の注意点
(1) ゲートウェイ自体の可用性：単一障害点回避。(2) レイテンシ：追加コストを把握。(3) ログとトレース：必ず計装。(4) 変更の影響範囲：複数サービスに波及。(5) バージョン管理：API バージョニング戦略。API バージョニング も合わせて。
失敗しがちなパターン
(1) ゲートウェイで全ロジック：太りすぎる。(2) レート制限を本番で初設定：制限値ミスで障害。(3) 認証ロジックを Gateway とサービス両方に：二重保守。(4) SPOF (単一障害点)。(5) 変更のロールアウトが粗い：全顧客影響。対策は、(1)ロジック分離、(2)段階的制限導入、(3)責任分担明示、(4)冗長化、(5)カナリア配信、です。