Kong Gateway は何をする製品なのか – API Gateway とリバースプロキシを分けて考える

Kong Gateway は、API Gateway としてよく名前を聞く製品です。

ただ、API Gateway という言葉は少し分かりにくいところがあります。リバースプロキシのようにも見えますし、ロードバランサーのようにも見えます。Kubernetes で使う場合は Ingress Controller のようにも見えます。

そのため、Kong Gateway を理解するときは、まず「何ができるか」よりも、どの境界に置く製品なのかから考えた方が分かりやすいです。

結論から言えば、Kong Gateway は API の入口に置き、リクエストを上流サービスへ転送しながら、認証、レート制限、ログ、ルーティング、変換、可観測性などの共通制御を扱うための API Gateway です。

Kong Gateway は単なるリバースプロキシではない

Kong Gateway は、実装上はリバースプロキシとして振る舞います。クライアントからリクエストを受け、条件に合う上流サービスへ転送するからです。

しかし、Kong Gateway を「高機能なリバースプロキシ」とだけ見ると、少し浅くなります。重要なのは、通信を中継することそのものではなく、API の入口でどの制御を共通化するかです。

たとえば、複数のアプリケーションがそれぞれ認証、レート制限、ログ出力、CORS、ヘッダー処理を個別に実装していると、API の入口がアプリケーションごとにばらけます。仕様も運用も揺れやすくなります。

Kong Gateway は、そのような入口の共通処理をアプリケーションの外側へ出し、API 境界で扱うための製品として見ると理解しやすいです。

API Gateway は API の制御点である

API Gateway の主語は、サーバーではなく API です。

ロードバランサーは、複数のサーバーや Pod へ通信を分散することに関心があります。一方で API Gateway は、どのクライアントが、どの API に、どの条件でアクセスできるのかを扱います。

もちろん、これらは完全に別物ではありません。API Gateway も通信を転送しますし、ロードバランサーの背後に置かれることもあります。Kubernetes では Ingress Controller として入口を担うこともあります。

ただし、設計上の関心は異なります。Kong Gateway を使う意味は、単に上流へ転送できることではなく、API の入口を制御点として扱えることにあります。

Kong の基本要素は Service、Route、Plugin で見る

Kong Gateway を理解するときは、まず Service、Route、Plugin の関係を見ると分かりやすいです。

この構造で考えると、Kong Gateway は「入口条件」「転送先」「入口で適用する共通処理」を分けて管理する製品だと分かります。

たとえば、同じ Service に対して、社内向け Route と外部向け Route を分けることができます。外部向け Route には認証やレート制限を強くかけ、社内向け Route には別のログ出力やアクセス制御を適用する、といった設計ができます。

Plugin は共通処理を入口へ寄せる仕組みである

Kong Gateway らしさが出るのは Plugin です。

API の入口では、アプリケーション本体とは別に、共通して必要になる処理があります。認証、レート制限、IP 制限、CORS、ログ出力、リクエスト変換、レスポンス変換、メトリクス出力などです。

これらをすべてアプリケーション側に実装すると、各サービスの実装方針に依存します。言語やフレームワークが違えば、認証やログの出し方も揺れます。チームが違えば、制限の考え方も変わります。

Plugin によって入口の共通処理を Gateway 側へ寄せると、アプリケーションごとの差をある程度吸収できます。これは、アプリケーションの責務を軽くするというより、API 公開時の責務境界を明確にするという意味があります。

Kong と NGINX、F5、WAF の責務を混ぜない

Kong Gateway を導入するときに難しいのは、既存の入口装置との関係です。

多くの環境では、すでにロードバランサー、F5、NGINX、Apache、クラウドロードバランサー、WAF、Ingress などが存在します。その中に Kong Gateway を追加すると、入口が増えるだけにも見えます。

ここで重要なのは、製品名ではなく責務を分けることです。

たとえば、Kong Gateway で API キーや JWT を確認するとしても、業務上の認可判断まで Kong に寄せるべきとは限りません。請求データを見てよいか、どのテナントの情報にアクセスできるか、といった判断はアプリケーション側のドメイン知識を必要とします。

逆に、全 API に共通するレート制限やログ出力、標準的な認証チェックは Gateway 側へ寄せた方が扱いやすい場合があります。この線引きをしないまま導入すると、Kong が便利な置き場所になり、設計の責任境界がかえって曖昧になります。

Kubernetes では Ingress の延長だけで見ない

Kong Gateway は Kubernetes 環境でも使われます。Kong Ingress Controller を使えば、Kubernetes の Ingress や Gateway API などのリソースを通じて、Kong 側のルーティングやポリシーを管理できます。

ただし、Kubernetes で使う場合でも、Kong を単なる Pod への振り分け装置として見ると、API Gateway としての意味が薄くなります。

Kubernetes の Ingress は、クラスタ外からクラスタ内サービスへ入る入口です。一方で Kong Gateway は、その入口で API 単位の認証、制限、ログ、変換などを扱うための制御点になります。

セルフマネージドと Konnect は運用境界が違う

Kong Gateway を使う場合、セルフマネージドで運用する形と、Kong Konnect を使って管理面を外部サービスに寄せる形があります。

ここも、単純に機能の多さだけで選ぶものではありません。どこにコントロールプレーンを置き、どこにデータプレーンを置き、誰が設定変更を管理し、どのネットワーク境界をまたぐのかという問題です。

API Gateway は入口に置くため、設定変更の影響範囲が大きいです。Route を一つ間違えれば API が到達不能になりますし、Plugin の適用範囲を間違えれば、本来制限すべき API が制限されなかったり、逆に必要な通信を止めたりします。

そのため、Kong Gateway の運用では、誰が設定を変えるのか、変更はレビューされるのか、設定は Git で管理するのか、障害時にどう切り戻すのかを最初に決めておく必要があります。

小規模環境では過剰になる場合もある

Kong Gateway は便利ですが、すべての環境で必要になるわけではありません。

API が少なく、公開先も限定され、認証やログの方式も単純であれば、Nginx やクラウドロードバランサー、アプリケーション側の実装で十分な場合があります。

逆に、API が増え、利用者が増え、複数チームが API を公開し、認証、制限、ログ、監査、バージョン管理を標準化したくなったとき、API Gateway の価値が出てきます。

これは、Kong Gateway が良いか悪いかではなく、入口を抽象化する必要があるかどうかの問題です。抽象化には価値がありますが、運用できない抽象化は負債になります。

導入前に決めること

Kong Gateway を導入する前に、少なくとも次の点は決めておきたいところです。

特に管理 API の扱いは重要です。API Gateway は入口の制御点であり、その設定を変更できる権限は非常に強い権限です。管理面をアプリケーション公開面と同じ感覚で扱うべきではありません。

まとめ

Kong Gateway は、API の前段に置く API Gateway です。ただし、単にリクエストを上流へ転送するだけの製品として見ると、本質を捉えにくくなります。

重要なのは、API の入口で何を標準化し、何をアプリケーション側に残し、何をロードバランサーや WAF、認証基盤に任せるのかです。

Kong Gateway は、Route、Service、Plugin という単位で API の入口を設計するための製品です。そこでは、通信の転送だけでなく、認証、制限、ログ、観測、変更管理、責任分界が問題になります。

つまり Kong Gateway を理解することは、API の入口をどのような制御点として設計するかを考えることでもあります。

参考情報

• Kong Gateway Get Started
• Kong Gateway Services
• Kong Gateway Plugins
• Kong Ingress Controller