API Gateway vs Load Balancer vs Reverse Proxy

一部のコンテンツは LLM によって生成されており、まだ手動で検証されていません。

この 3 つは混同(こんどう) されがちです。すべてクライアントとサーバーの間(あいだ) に位置(いち) しますが、それぞれ異(こと) なる問題(もんだい) を解決(かいけつ) します。

機能スペクトラム

  flowchart LR
    subgraph RP["Reverse Proxy"]
        A["SSL 終端"]
        B["キャッシュ"]
        C["圧縮"]
    end
    subgraph LB["Load Balancer"]
        D["トラフィック分散"]
        E["ヘルスチェック"]
        F["フェイルオーバー"]
    end
    subgraph AG["API Gateway"]
        G["認証・認可"]
        H["レート制限"]
        I["変換・分析"]
    end
    RP --> LB --> AG

Reverse Proxy

サーバーの前段(ぜんだん) に位置(いち) するプロキシで、クライアントの要求(ようきゅう) を受(う) け取(と) り、バックエンドサーバーに転送(てんそう) します。汎用的(はんようてき) なソリューションで、コンテンツタイプを気(き) にしません。

コア機能

機能(きのう)	説明(せつめい)
SSL 終端(しゅうたん)	HTTPS の暗号化(あんごうか) /復号化(ふくごうか) を処理(しょり) し、バックエンドの負荷(ふか) を軽減(けいげん)
キャッシュ	静的(せいてき) リソースをキャッシュし、バックエンドへの要求(ようきゅう) を削減(さくげん)
セキュリティ	バックエンドサーバーの構成(こうせい) を隠蔽(いんぺい)
圧縮(あっしゅく)	レスポンスを圧縮(あっしゅく) し、転送(てんそう) を高速化(こうそくか)

よく使(つか) われるツール

Nginx - 高性能(こうせいのう) 、広(ひろ) く利用(りよう)
HAProxy - 高可用性(こうかようせい) に特化(とっか)
Caddy - 自動(じどう) HTTPS、簡単(かんたん) な設定(せってい)

Load Balancer

トラフィック分散(ぶんさん) に特化(とっか) したリバースプロキシ。スケーラビリティと高可用性(こうかようせい) を実現(じつげん) します。

負荷分散(ふかぶんさん) アルゴリズム

アルゴリズム	説明(せつめい)
Round Robin	順番(じゅんばん) に振(ふ) り分(わ) け
Least Connections	接続数(せつぞくすう) が最(もっと) も少(すく) ないサーバーに割(わ) り当(あ) て
IP Hash	クライアント IP に基(もと) づきサーバーを決定(けってい) 、同(おな) じユーザーは同(おな) じサーバーへ
Weighted	重(おも) みの比率(ひりつ) で振(ふ) り分(わ) け

L4 vs L7

  flowchart TB
    subgraph L4["Layer 4 (TCP)"]
        L4A["見えるもの：IP + Port"]
        L4B["高速だがルーティングは限定的"]
    end
    subgraph L7["Layer 7 (HTTP)"]
        L7A["見えるもの：URL, Headers, Cookies"]
        L7B["パスに基づき異なるサービスへルーティング可能"]
    end

層(そう)	利点(りてん)	欠点(けってん)
L4	高性能(こうせいのう) 、低遅延(ていちえん)	コンテンツに基(もと) づくルーティング不可(ふか)
L7	柔軟(じゅうなん) なルーティング、豊富(ほうふ) な機能(きのう)	パフォーマンスオーバーヘッドが大(おお) きい

よく使(つか) われるツール

AWS ALB - L7 アプリケーション層(そう) ロードバランサー
AWS NLB - L4 ネットワーク層(そう) ロードバランサー
GCP Load Balancer - グローバル分散型(ぶんさんがた)

API Gateway

API 管理(かんり) に特化(とっか) したリバースプロキシ。マイクロサービスアーキテクチャに最適(さいてき) で、横断的関心事(おうだんてきかんしんじ) （cross-cutting concerns）を一元管理(いちげんかんり) します。

コア機能(きのう)

機能(きのう)	説明(せつめい)
認証(にんしょう) /認可(にんか)	JWT 検証(けんしょう) 、OAuth、API Key
レート制限(せいげん)	API の濫用(らんよう) を防止(ぼうし)
リクエスト/レスポンス変換(へんかん)	ヘッダー、ボディの修正(しゅうせい) 、フォーマット変換(へんかん)
バージョン管理(かんり)	複数(ふくすう) の API バージョンを管理(かんり)
分析(ぶんせき) ・モニタリング	API の使用状況(しようじょうきょう) を追跡(ついせき)

よく使(つか) われるツール

Kong - オープンソース、拡張(かくちょう) 可能(かのう)
AWS API Gateway - クラウドネイティブ、AWS と統合(とうごう)
Apigee - Google 傘下(さんか) 、エンタープライズ向(む) け

実際(じっさい) のアーキテクチャ

  flowchart LR
    Client["Client"] --> CDN["CDN"]
    CDN --> Gateway["API Gateway"]
    Gateway --> LB["Load Balancer"]
    LB --> S1["Service A"]
    LB --> S2["Service B"]
    LB --> S3["Service C"]

実際(じっさい) には、この 3 つは組(く) み合(あ) わせて使用(しよう) され、それぞれの役割(やくわり) を果(は) たします。

判断(はんだん) フレームワーク

要件(ようけん)	推奨(すいしょう) ソリューション
サービスに複数(ふくすう) のインスタンス	Load Balancer
外部公開(がいぶこうかい) API	API Gateway
認証(にんしょう) /レート制限(せいげん) が必要(ひつよう)	API Gateway
SSL + キャッシュが必要(ひつよう)	Reverse Proxy
マイクロサービスアーキテクチャ	API Gateway + Load Balancer

まとめ

Reverse Proxy - 汎用(はんよう) プロキシ、SSL、キャッシュ、圧縮(あっしゅく) を処理(しょり)
Load Balancer - トラフィック分散(ぶんさん) と高可用性(こうかようせい) に特化(とっか)
API Gateway - API 管理(かんり) 専用(せんよう) 、認証(にんしょう) ・制限(せいげん) ・変換(へんかん) を処理(しょり)

3 つは競合(きょうごう) ではなく補完関係(ほかんかんけい) にあり、要件(ようけん) に応(おう) じて組(く) み合(あ) わせて使用(しよう) します。

CDN