APIゲートウェイ & リバースプロキシエキスパート
APIゲートウェイとリバースプロキシの設定と最適化を行い、ルーティング、認証、レート制限、トラフィック管理を実現します。
決定ポイント
認証方式の選択
トラフィックパターンと要件
├── 内部サービスのみ
│ └── APIキー認証
│ ├── 低複雑性、高速検証
│ └── Kong: key-authプラグイン、Traefik: forwardAuth
├── 顧客向けAPIでセッションが必要な場合
│ └── JWT認証
│ ├── ステートレス、ユーザークレームを含む
│ └── Kong: jwtプラグイン、Nginx: lua-resty-jwt
├── エンタープライズB2B統合
│ └── mTLS認証
│ ├── 証明書ベース、最高のセキュリティ
│ └── Kong: mtls-auth、Nginx: ssl_verify_client
└── サードパーティSaaS統合
└── OAuth2フロー
├── トークン交換、委任認証
└── Kong: oauth2プラグイン、AWS API Gateway: オーソライザー
ゲートウェイテクノロジーの選択
要件 → 選択
├── プラグインエコシステムとGUIが必要
│ └── Kong Enterprise/OSS
├── Kubernetesネイティブで自動検出あり
│ └── Traefik v3 または Ingress-NGINX
├── 最大性能、最小機能
│ └── Nginx または Envoy
└── クラウド管理、サーバーレススケーリング
└── AWS API Gateway または Azure Application Gateway
上流ルーティング戦略
サービスアーキテクチャ → ルーティング方法
├── サービスディスカバリ付きマイクロサービス
│ └── 動的上流ターゲット
│ ├── Consul/Eureka統合
│ └── ヘルスチェックベースのロードバランシング
├── 静的バックエンドサービス
│ └── 固定上流プール
│ ├── ラウンドロビンまたは最小接続数
│ └── カナリアデプロイメントのための重み付きルーティング
└── マルチリージョンデプロイメント
└── 地理的ルーティング
├── レイテンシベースまたはGeo-IP
└── セカンダリリージョンへのフェイルオーバー
障害モード
ゲートウェイタイムアウトカスケード
症状: 負荷時にAPI応答が遅い（10秒以上） 検出: 応答時間が急増する一方、上流サービスは正常なレイテンシを報告 根本原因: ゲートウェイタイムアウトが上流タイムアウトより長く、リクエストキューイングが発生 修正: ゲートウェイ読み取りタイムアウトを上流タイムアウトより短く設定（ゲートウェイ: 30秒、上流: 25秒）
認証バイパス
症状: 未承認のリクエストがバックエンドサービスに到達 検出: バックエンドログに期待される認証ヘッダーがないリクエストが表示される 根本原因: ルートの順序により、許可ルールが認証ルールより先にマッチする 修正: 認証ミドルウェアをグローバルレベルに移動するか、特定のルートを設定の先頭にする
サーキットブレーカーのチャタリング
症状: トラフィックスパイク時に断続的な503エラーが発生 検出: サーキットブレーカーが頻繁に開閉（毎分数回以上） 根本原因: しきい値が敏感すぎるか、ヘルスチェックが誤設定されている 修正: 障害しきい値（5回以上の障害）と回復時間（最低30秒）を調整
SSL証明書の期限切れ
症状: HTTPSハンドシェイクの失敗、ブラウザの証明書警告 検出: SSL証明書チェックで30日以内に期限切れ 根本原因: 更新自動化なしの手動証明書管理 修正: cert-manager（K8s）またはACMEクライアントを使用した自動更新の実装
リソース枯渇
症状: ゲートウェイが接続を受け付けなくなる、メモリ/CPUが100% 検出: 接続拒否エラー、ゲートウェイヘルスチェックの失敗 根本原因: 接続制限がない、またはプラグインのメモリリーク 修正: worker_connections（Nginx）または接続プール制限（Kong）を設定し、ゲートウェイを再起動
実際の例
シナリオ: EコマースAPIゲートウェイのセットアップ
コンテキスト: JWT認証を使用して注文、在庫、支払いを処理するマイクロサービスにKongをデプロイ
ステップ1: ルート定義
# 最初にサービスエンドポイントを特定
services:
- orders: /api/v1/orders/* → http://orders:8080
- inventory: /api/v1/inventory/* → http://inventory:8080
- payments: /api/v1/payments/* → http://payments:8080
ステップ2: 決定木の適用
- トラフィックパターン: 顧客向けAPI → JWT認証
- アーキテクチャ: マイクロサービス → 動的上流ターゲット
- 要件: プラグインエコシステムが必要 → Kongを選択
ステップ3: プラグインの順序
# プラグインを正しい順序で適用
plugins:
1. cors（認証前）
2. jwt（認証）
3. rate-limiting（認証後）
4. request-transformer（最後）
エキスパート vs 初心者:
- 初心者のミス: 認証前にレート制限を適用（匿名ユーザーがクォータを消費）
- エキスパートの手法: 認証を先に行い、認証済みユーザーごとにレート制限
- 初心者のミス: グローバルCORSポリシーを使用
- エキスパートの手法: ルートごとに異なるCORS（注文は管理元を許可、支払いはフロントエンドのみに制限）
障害シナリオ: カナリアデプロイメントの失敗
状況: 新しい注文サービスバージョンに20%のトラフィックをデプロイ、500エラーが発生
検出プロセス:
- ゲートウェイメトリクスを確認: 500エラー率の急上昇がデプロイ時間と相関
- 上流ヘルスチェック: 新しいバージョンがヘルスチェックに失敗
- ゲートウェイログ: 上流接続のタイムアウト
ロールバック手順:
# ステップ1: 即時トラフィックシフト
kong:
routes:
- service: orders-v1
weight: 100 # 以前は80
- service: orders-v2
weight: 0 # 以前は20
# ステップ2: ロールバックの検証
curl -H "Authorization: Bearer $JWT" \
https://api.company.com/orders/health
# ステップ3: 障害のある上流を削除
kubectl scale deployment orders-v2 --replicas=0
根本原因分析: 新しいバージョンにデータベース接続プールの設定ミスがあり、負荷時にタイムアウトが発生
品質ゲート
- すべてのルートに明示的なパスマッチングがある（キャッチオールの/*ルートは使用しない）
- 認証ミドルウェアがビジネスロジックプラグインの前に設定されている
- ヘルスチェックが正常な上流に対して5秒以内に2xxを返す
- サーキットブレーカーのしきい値設定: 60秒ウィンドウで5回の障害、30秒の回復時間
- TLS証明書が期限切れの30日以上前に自動更新される
- レート制限がグローバルではなく認証済みユーザーごとに適用されている
- CORSポリシーがオリジンを必要なドメインのみに制限している
- ゲートウェイタイムアウト（30秒）が上流タイムアウト（25秒）より短く設定され、カスケードを防止
- アクセスログにリクエストトレーシングのための相関IDが含まれている
- ゲートウェイが高可用性のために最低2レプリカでデプロイされている
対象外の境界（NOT-FOR）
このスキルが扱うもの: ゲートウェイ設定、ルーティングルール、認証ミドルウェア、リバースプロキシのセットアップ
対象外:
- レート制限アルゴリズムの設計 →
api-rate-limiting-throttling-expertを利用 - サービスメッシュデータプレーン設定 →
service-mesh-microservices-expertを利用 - API仕様と設計 →
api-architectを利用 - データベース接続プーリング →
database-performance-expertを利用 - コンテナオーケストレーション →
kubernetes-expertまたはdocker-expertを利用 - SSL証明書の生成 →
security-infrastructure-expertを利用
委任ルール:
- カスタムレート制限アルゴリズムの場合: 「レート制限プラグインの設定は行いますが、カスタムアルゴリズムについては api-rate-limiting-throttling-expert を利用してください」
- サービスディスカバリのセットアップの場合: 「上流ターゲットの設定は行いますが、サービスメッシュのセットアップについては service-mesh-microservices-expert を利用してください」