コンテンツにスキップ

APIゲートウェイ

APIゲートウェイは、外部クライアントからの API リクエストを受ける入口になる仕組み。

複数のバックエンドサービスへ振り分けたり、認証、制限、ロギングなどをまとめて扱える。

まず押さえたいこと

  • クライアントから見ると API の入口
  • バックエンドの前段に置く
  • 認証やレート制限などを共通化しやすい
  • 単なるルーティングだけでなく、ポリシー管理にも使う

入口が必要になる理由

バックエンドが複数あると、クライアントが各サービスの URL や認証方式を直接意識する構成は扱いづらい。

APIゲートウェイを置くと、

  • 公開先を 1 つにまとめられる
  • 共通の認証方式を前段でそろえられる
  • バックエンドの構成変更をクライアントへ隠しやすい
  • 監視や制御を入口で一元化できる

何がうれしいか

  • バックエンドサービスを直接公開しなくてよい
  • 認証や制限をまとめて管理できる
  • URL ルーティングを整理しやすい
  • ログやメトリクスを入口で取りやすい

ざっくり構成図

[Client]
   |
   v
[API Gateway]
   |
   +--> [Service A]
   |
   +--> [Service B]
   |
   `--> [Lambda / Backend]

より実務寄りに見ると以下のようになることが多い。

[Client]
   |
   v
[API Gateway]
   |
   +--> [Auth / Authorizer]
   |
   +--> [Lambda]
   |
   +--> [ALB -> ECS/EC2]
   |
   `--> [Logs / Metrics]

よく見る機能

  • ルーティング
  • 認証 / 認可
  • レート制限
  • リクエスト変換 / レスポンス変換
  • ログ / メトリクス
  • CORS 制御
  • ステージ管理
  • API キー管理

実務で重要な論点

1. 認証をどこでやるか

  • APIゲートウェイで JWT や Authorizer を使う
  • バックエンド側でも権限チェックを行う

入口で本人確認、アプリ側で業務権限確認、という分け方がわかりやすい。

2. 何を公開し、何を隠すか

  • 公開 URL
  • HTTP メソッド
  • ヘッダー
  • ボディ形式
  • エラーレスポンス

バックエンドの都合をそのまま外へ出さないことが多い。

3. どこで制限をかけるか

  • レート制限
  • タイムアウト
  • ペイロードサイズ制限
  • WAF 連携

入口で落とせるものは早めに落とした方が、バックエンド保護につながる。

APIゲートウェイで起こる代表的な処理

  1. クライアントからリクエストを受ける
  2. 認証情報やヘッダーを確認する
  3. ルールに従ってバックエンドへ転送する
  4. バックエンドのレスポンスを返す
  5. アクセスログやメトリクスを記録する

ALB との違い

ALB も HTTP レベルでルーティングできるが、役割は少し違う。

観点 API Gateway ALB
主な役割 API の公開入口 Web/アプリへの負荷分散
認証や API 制御 強い 比較的シンプル
サーバーレス連携 しやすい 限定的
L7 ルーティング できる できる
使いどころ 外部 API 公開、制御、観測 ECS/EC2 の前段、負荷分散

迷ったときは、

  • API を外部公開し、認証や制限もまとめたいなら API Gateway
  • アプリ群の前に置く標準的な L7 LB なら ALB

という見方でよい。

AWS での見方

  • Amazon API Gateway サーバーレス API の入口としてよく使う
  • ALB HTTP の振り分けもできるので、用途によっては API 的な入口に見えることがある

よくある構成パターン

  • API Gateway -> Lambda サーバーレス API の定番
  • API Gateway -> ALB -> ECS 認証や公開制御は前段、実処理はコンテナ
  • API Gateway -> Private Backend VPC Link などで private 側へつなぐ

障害調査で見るポイント

  • 4xx が多いか 5xx が多いか
  • 認証エラーなのか、バックエンドエラーなのか
  • タイムアウトが APIゲートウェイ側か、バックエンド側か
  • CORS 設定ミスがないか
  • デプロイしたステージやルートが想定通りか

実務での見方

  • API 設計そのものより、入口ポリシーの整理が重要
  • URL 設計、認証、制限、監査ログをどこで担保するかを明確にする
  • バックエンドの責務と APIゲートウェイの責務を混ぜすぎない

実務で見るポイント

  • どこで認証するか
  • タイムアウトやサイズ制限はあるか
  • バックエンドが何か
  • ログとメトリクスをどこで見るか
  • WAF や CDN とどうつながっているか
  • ステージごとの設定差分があるか

メモ

  • APIゲートウェイは「入口を統一する仕組み」として見ると理解しやすい
  • 認証、制限、観測を入口でまとめられるのが強み
  • まずは 認証 ルーティング 制限 観測 の4点で整理すると把握しやすい