リバースプロキシ/APIゲートウェイの配置設計 — どこで終端しどこに置くか

リバースプロキシとAPIゲートウェイをどこに配置するかは、TLS終端・認証・ルーティングという横断機能を「誰が持つか」を決める設計の核心です。要件が増えるたびに前段を後付けで挿入すると、構成が絡まり単一障害点が増殖します。この記事では、配置の責任境界をどこに引くか、TLS終端と認証をどの層に集めるか、冗長化と肥大化防止をどう両立させるかを、具体的な判断軸とともに整理します。

前段を後付けで挟んで構成が絡まる構造

「とりあえず前に置く」が積み重なる現場

多くの構築現場で繰り返されるパターンがあります。最初はnginxによるリバースプロキシだけで運用していたところに、APIレートリミットの要件が追加されてAPIゲートウェイを手前に挿入し、さらにWAFが加わり、やがてCDNエッジも前段に入る——という段階的な拡張です。それぞれの判断は単体では合理的でも、結果として4段構成になり、どの層がTLSを終端しているか、どこで認証が走っているかが追いにくくなります。構築を担当したエンジニアですら設定ファイルを横断しなければ全体像を把握できない状態は、5台規模の小さなシステムでも頻繁に発生します。

責任境界が曖昧になるタイミング

後付け挿入が問題になるのは、機能追加の瞬間よりも「誰が何を決定するか」がずれ始めたときです。たとえば認証トークンの検証をAPIゲートウェイが担っているつもりで、バックエンドサービス側でも二重に検証しているケースがあります。片方を外そうとすると「なぜここで検証していたのか」の文脈が失われており、外せないまま両方が動き続けます。こうした重複は後の設計変更コストを押し上げ、開発・ステージング・本番・DRの4環境が並ぶ構成では、環境間で設定がずれるリスクも高まります。

後付け挿入が生む二重終端・二重認証のコスト

もっとも見落とされやすい落とし穴が、TLSの二重終端です。エッジCDNでHTTPSを終端した後、内部LBとリバースプロキシ間でもTLSを再確立しているケースでは、証明書の更新対象が倍増します。管理する証明書が10枚を超えてくると、更新漏れやドメイン不一致によるダウンタイムリスクは無視できません。どこで終端するかは「セキュリティ境界をどこに引くか」という問いに直結しており、後付けで変えるほど設定の整合コストが膨らむため、構成の最初期に固めるべき判断です。

リバースプロキシとAPIゲートウェイの役割の違い

リバースプロキシが担う通信制御の範囲

リバースプロキシは「通信の代理転送」を主とするコンポーネントです。TLS終端、ロードバランシング、キャッシュ、圧縮、静的コンテンツの配信といった機能は、HTTPの通信レベルで完結します。バックエンドが何台いるか、どのパスをどのホストに流すかといったルーティングも担いますが、これは「どのサービスへ届けるか」という転送の制御であり、「誰が呼んでいるか・何を呼んでよいか」という業務の制御ではありません。nginx・HAProxy・Traefikなどが代表例で、設定はリクエスト・レスポンスの変換と転送に特化しています。

APIゲートウェイが担う業務制御の範囲

APIゲートウェイが担うのは、APIとしての公開管理です。レートリミット、APIキー認証・JWT検証、クライアント別のアクセス制御、リクエスト変換・バージョン管理、ログ・メトリクスの集約といった機能は、「誰が・何を・どれだけ呼んでよいか」という業務ポリシーの執行に相当します。Kong・APISIX・AWS API Gatewayなどは、こうした横断的なポリシー管理を単一の設定で行えることを強みとしています。通信の転送効率よりも、APIライフサイクルの管理とオブザーバビリティが設計の中心に置かれます。

混同しやすい機能と境界線の引き方

両者の機能が重なるのは主に「認証」と「ルーティング」の領域です。リバースプロキシもBasic認証やIP制限はできますし、APIゲートウェイもL7ルーティングは行います。どちらに持たせるかの判断軸は「変更頻度と変更主体」です。インフラチームが管理し変更頻度が低い制御——証明書の更新や転送先の切り替え——はリバースプロキシが自然です。一方、アプリチームが管理しAPIごとに異なるポリシー——レートリミット値・クライアント権限——はAPIゲートウェイ側に持たせる方が、変更の権限と実態が一致します。この分担を明文化しないまま進むと、後で設定の修正権限が宙に浮きます。

TLS終端・認証・ルーティングをどこに寄せるかの判断

TLS終端の配置を決める条件

TLS終端の場所は、「誰がその先の通信を信頼するか」によって決まります。エッジ（CDN・外部LB）で終端する場合、そこから内部までは平文か内部証明書での暗号化になります。金融・医療など規制要件が厳しい環境では内部通信も暗号化が求められるため、終端をエッジに集約しつつ内部でmTLSを追加する二層構成が選ばれます。一方、1日あたり数百万リクエスト規模でTLS処理がCPUのボトルネックになる場合は、HWアクセラレータを持つロードバランサーに終端を集中させてオフロードする判断が有効です。

認証をエッジで処理するかサービスに委ねるか

認証をエッジやAPIゲートウェイで一元処理するメリットは、バックエンドサービスから認証ロジックを排除できる点です。しかし、サービスごとに異なるスコープ・権限モデルが必要な場合、エッジで全部を判断するのは困難です。現場でよく選ばれる分担は「エッジはトークンの有効性（署名検証）だけを担い、スコープ確認はサービスが行う」というモデルです。この方式では、エッジの設定変更なしにサービス側の権限モデルを更新できます。ただし、バックエンドが20サービスを超えるマイクロサービス構成では、認証ロジックの分散が監査を複雑にするため、サービスメッシュとの組み合わせを検討する段階に入ります。

ルーティングロジックの複雑度で置き場所を決める

ルーティングの判断基準は「変更のたびにインフラ再デプロイが発生するか」です。パスベース・ホストベースの単純な振り分けはリバースプロキシの設定で十分です。クライアント属性（APIバージョン・ユーザーロール）やリクエストヘッダーの内容によって転送先を動的に変える場合は、APIゲートウェイかサービスメッシュの制御プレーンに委ねる方が変更コストを下げられます。ルーティングルールが50件を超えたあたりで設定ファイルの保守コストが急上昇するという経験談は構築現場でよく共有されており、その手前で設計の切り替えを検討するタイミングです。

比較表: エッジ集約/サービス前段/両段の向き不向き

前段の配置パターンは大きく「エッジ集約」「サービス前段」「両段構成」の3つに分類できます。それぞれの向き不向きを下表に整理します。

配置パターン	向いているケース	注意すべき点	代表的な選定例
エッジ集約（CDN/外部LBに集中）	グローバルトラフィックが多い・静的コンテンツ比率が高い・内部構成をシンプルに保ちたい	内部通信の可視性が下がる・エッジの設定変更がリリースフローに入る・ベンダーロックインのリスク	Cloudflare Workers + オリジンLB、AWS CloudFront + ALB
サービス前段（バックエンドごとにリバースプロキシ）	チームごとにデプロイが独立している・サービス間でルーティングポリシーが大きく異なる	前段コンポーネントが増殖しやすい・横断ポリシーの一貫性を保ちにくい・運用が属人化しやすい	各チームがnginx/Traefikを個別管理
両段構成（エッジ + 内部APIゲートウェイ）	外部公開APIと内部サービス間通信を分けたい・規制対応で内部も暗号化が必要・APIポリシーを組織横断で統一したい	管理レイヤーが2つになり運用コストが上がる・TLSの二重終端を意図的に設計する必要がある	CDN（TLS終端）+ Kong/APISIX（内部ポリシー管理）

単一障害点にしないための冗長配置の設計

フェイルオーバーとヘルスチェックの設計方針

前段コンポーネントを冗長化する場合、まず問いを立てるべきは「ヘルスチェックが検知できる障害の範囲はどこまでか」です。TCPの疎通チェックだけでは、プロセスは生きていても処理能力が劣化しているケースを検知できません。HTTPステータスでのアクティブチェックに加え、レスポンスタイムの閾値超過をアンヘルシー判定に含める設計が有効です。本番環境では10〜30秒の検知間隔と2〜3回の連続失敗を条件にフェイルオーバーを発動させる設定が多く見られます。間隔を短くするほど誤検知が増えるため、サービス特性に合わせた閾値の調整が判断のポイントです。

アクティブ・アクティブとアクティブ・スタンバイの選択

前段を2台以上並べる場合、アクティブ・アクティブ（常時両方で処理）かアクティブ・スタンバイ（片方は待機）かを選ぶ必要があります。アクティブ・アクティブはスループットが高く、片方の障害時もトラフィックを引き継げますが、状態の同期が必要です。特にAPIゲートウェイがレートリミット状態をメモリ保持している場合、2台のカウンターが独立してしまい制限が事実上2倍になる問題が生じます。この同期コストを許容できない規模では、レートリミットの状態をRedisなど外部ストアに持たせる設計に移行するのが定石です。

ドレインとアップデート時の無停止設計

前段コンポーネントのアップデート時に問題になるのが、処理中リクエストの扱いです。コネクションドレイン（graceful shutdown）なしでプロセスを停止させると、進行中のリクエストがエラーで終了します。具体的な設定の調整方法はセミナー・参考書側で確認するとして、設計判断として押さえるべき点は「ドレイン完了を確認してから次のノードを更新する」というシーケンスをデプロイパイプラインに組み込むことです。このシーケンスを自動化せず手動で行っている環境では、更新作業に担当者1人あたり30〜60分かかるケースが報告されています。

前段に機能を盛りすぎて重くなる境界

レイテンシ増加を招く機能の集中

前段で処理する機能が増えると、リクエストごとの処理時間が積み上がります。WAFのリクエスト検査、JWT検証、レートリミットのカウンター参照、ログの同期書き込みが一つのコンポーネントで重なると、素通しと比べて10〜50ms単位のレイテンシが乗るケースがあります。APIのSLA要件がP99で100ms以下といった厳しい環境では、この積み上がりは見過ごせません。WAFを非同期（オフパス）で動かすか、JWT検証をサービス側のミドルウェアに分散させるかを検討する必要が出てきます。

設定変更のデプロイコストが積み上がる

前段に機能を集中させると、変更の影響範囲も集中します。認証ポリシーの変更、ルーティングルールの追加、証明書の更新がすべて同一コンポーネントの設定に収束すると、変更のたびに全体テストと再起動が必要になります。複数チームがAPIゲートウェイの設定を共有している場合は特に、変更のコンフリクトや誤設定が本番に波及するリスクが高まります。GitOpsでの管理に移行したとしても、変更の粒度が粗いままでは承認・レビューのボトルネックが生まれます。設定を「インフラ層」「ルーティング層」「ポリシー層」に分割し、チームごとに管理範囲を切り分けることが、この問題への設計的な応答です。

「前段で全部やる」を手放すタイミング

前段の肥大化を手放す判断の目安は「前段の変更頻度がバックエンドの変更頻度を超え始めたとき」です。本来バックエンドサービスの変化に追随するはずの前段設定が、逆にリリースのボトルネックになっている状態です。こうした局面では、サービスメッシュ（Istio・Linkerdなど）の導入を検討し、サービス間通信のポリシー——mTLS・トラフィック分割・サーキットブレーカー——をコントロールプレーンに移管する方向性が選ばれます。この移行は一度に完了するものではなく、まず新規サービスだけをメッシュ内に置き、段階的に範囲を広げる進め方が現実的です。

配置設計チェックフレーム

以下のチェックリストを使い、構築プロジェクトの初期設計段階で配置判断を固めてください。後から変えるほどコストが高い項目から順に並べています。

1. TLS終端をどこに置くかを先に決めたか？　エッジ・内部LB・サービスのいずれかを主終端と定義し、二重終端になる箇所の意図を構成図に明示する。
2. 認証の責任分担を文書化したか？　トークン署名検証・スコープ確認・リソースオーナー確認のそれぞれを「どの層が担うか」を表にして関係チームで合意する。
3. ルーティングルールの変更主体を決めたか？　インフラチームが持つルールとアプリチームが持つルールを分け、設定ファイルのオーナーシップを明確にする。
4. 前段コンポーネントの冗長化方式を選んだか？　アクティブ・アクティブかアクティブ・スタンバイかを選び、状態同期が必要な機能（レートリミット等）の外部ストア要否を確認する。
5. ヘルスチェックの条件を定義したか？　TCP疎通だけでなくHTTPレスポンスとレイテンシ閾値を含めた判定条件と、フェイルオーバーの発動タイミングを設計する。
6. ドレイン処理をデプロイパイプラインに組み込んだか？　手動操作を排除し、更新時の無停止シーケンスを自動化してリリスクを下げる。
7. 前段の変更頻度をモニタリングする仕組みがあるか？　変更頻度がバックエンドを上回り始めたら、サービスメッシュへの移管を検討するシグナルとして扱う。