フレームワーク活用ガイドひとことで言うと#
クライアントとマイクロサービス群の間に「玄関口」を1つ置き、ルーティング・認証・レート制限などの横断的関心事を集約するアーキテクチャパターン。サービスが増えてもクライアントは1つのエンドポイントだけを見ればいい。
押さえておきたい用語#
- API Gateway（エーピーアイ ゲートウェイ）
- クライアントからのリクエストを受け取り、適切なバックエンドサービスへ振り分けるリバースプロキシのこと。認証・ログ・レート制限なども担当する。
- Cross-Cutting Concerns（横断的関心事）
- 認証、ログ収集、レート制限のように複数サービスに共通して必要な処理を指す。各サービスに個別実装するとコードが散らばる。
- Rate Limiting（レートリミティング）
- 一定時間内のリクエスト数を制限して過負荷やDDoSからサービスを守る手法。
- Request Aggregation（リクエスト アグリゲーション）
- クライアントの1回のリクエストを複数のバックエンドサービスに分散して呼び出し、結果を1つのレスポンスにまとめて返す処理。
APIゲートウェイパターンの全体像#
こんな悩みに効く#
- マイクロサービスごとに認証ロジックを実装していて変更が大変
- クライアントが複数サービスのエンドポイントを直接呼び出していてカオス状態
- APIのバージョニングやレート制限をサービスごとにバラバラに管理している
基本の使い方#
各サービスに重複実装されている処理を一覧化する。典型的なものは以下の通り。
- 認証・認可（JWTの検証など）
- レート制限・スロットリング
- リクエスト/レスポンスのログ収集
- CORS設定
- リクエストの変換・バリデーション
URLパスやHTTPメソッドに基づいて、どのバックエンドサービスにリクエストを振り分けるかを定義する。
/api/users/*→ User Service/api/orders/*→ Order Service/api/payments/*→ Payment Service
具体例#
従業員25名のECスタートアップ。マイクロサービス8つがそれぞれJWT検証ロジックを持っており、認証ライブラリのバージョンが3種類混在していた。セキュリティパッチの適用に毎回2週間かかっていた。
Kong Gatewayを導入し、認証をゲートウェイ層に集約。
| 指標 | Before | After |
|---|---|---|
| 認証ロジックの実装箇所 | 8サービス | 1箇所（Gateway） |
| セキュリティパッチ適用 | 2週間 | 半日 |
| 認証関連のコード行数 | 約4,800行 | 約600行 |
サービス側から認証コードを削除できたことで、各チームはビジネスロジックに集中できるようになった。
月間API呼び出し2億件の金融データプラットフォーム。プランごとのレート制限を各サービスに個別実装しており、プラン変更のたびに5サービスを同時デプロイする必要があった。
AWS API Gatewayを採用し、Usage Planでプランごとのレート制限を一元管理。
設計のポイント
- Free: 100 req/min、Standard: 1,000 req/min、Enterprise: 10,000 req/min
- レート超過時のレスポンス（429）もゲートウェイで統一
- API Keyの発行・管理もゲートウェイに集約
プラン変更がゲートウェイの設定変更だけで完結するようになり、リリースサイクルが 月1回 → 随時 に短縮された。
人口20万人規模の自治体。住民向けポータルのバックエンドがCOBOL時代のSOAP APIで、モバイルアプリ対応が求められていた。
全面リプレースではなく、APIゲートウェイを前段に配置してSOAP→REST変換を行う戦略を採用。
- フェーズ1: ゲートウェイで住民情報取得APIだけをREST化（2ヶ月）
- フェーズ2: 届出・申請系APIをREST化（4ヶ月）
- フェーズ3: 新規機能はマイクロサービスとして追加
レガシーシステムに手を入れずにモバイルアプリをリリースでき、開発期間は全面リプレース案の 18ヶ月 → 6ヶ月 に短縮。
やりがちな失敗パターン#
- ゲートウェイにビジネスロジックを入れてしまう — ゲートウェイはルーティングと横断的関心事だけに徹する。ビジネスロジックを入れると「賢すぎるパイプ」になり、変更のボトルネックになる
- 単一障害点への対策を怠る — ゲートウェイが落ちると全サービスが止まる。冗長化・ヘルスチェック・自動フェイルオーバーは導入時に必ず設計する
- レスポンス集約をやりすぎる — ゲートウェイで多くのサービスを呼び出して結果を合成すると、レイテンシが加算的に増える。複雑な集約が必要ならBFFパターンに分離する
- 全サービスを一度に切り替える — 段階的に移行しないと、問題発生時の切り分けが困難になる。1サービスずつ切り替えて動作確認するのが鉄則
まとめ#
APIゲートウェイパターンは、マイクロサービスの 「玄関口」 を統一することで、認証・レート制限・ログなどの横断的関心事を一箇所にまとめる設計手法。クライアントはサービス構成を意識せずに1つのエンドポイントを叩くだけでよくなり、サービス側はビジネスロジックに集中できる。ただし単一障害点になりうるため冗長化は必須で、ビジネスロジックを入れない規律も求められる。