Gateway Live Interactive Lab
Architecture & Request Lifecycle Deep-Dive

How Kong Gateway Works

Kong API Gateway はリクエストをどのように受信・ルーティングし、プラグインを実行してUpstreamへ転送しているのか。内部構造とリクエスト処理ライフサイクルを実証・解説します。

⚙️
OpenResty / Lua
Nginx イベント駆動 ＋ 高速LuaJIT
🔄
6 Execution Phases
Certificate ➔ Rewrite ➔ Access ➔ Balancer ➔ Filter ➔ Log
🧠
Shared Memory Cache
DB参照なし・ミリ秒以下のインメモリ設定解決

Kong のリクエスト処理パイプライン

クライアントから届いたリクエストは、Nginxの各フェーズでKongのLuaプラグインを順次通過します

Phase 1
Certificate

TLSハンドシェイク時にSNIに基づき動的証明書を選択

mTLS / TLS終端
➔
Phase 2
Rewrite

ルーティング判定前の早期URL書換えとリダイレクト

Early URI Transform
➔
Phase 3: Core
Access

Route照合、Consumer認証、Rate Limit、認可チェック

ここで429や401を即座に返却
➔
Phase 4
Balancer

Upstream Targetのヘルスチェックと負荷分散アルゴリズム

DNS解決 / Ring-balancer
➔
Phase 5
Header / Body Filter

Upstream応答の加工、内部Serverヘッダー削除、セキュリティヘッダー付与

Response Transformer
➔
Phase 6
Log

クライアント応答後に非同期でアクセスログ送信（レイテンシ影響ゼロ）

Prometheus / Syslog
Core Entity 1

Service と Route の関係

Kongでは「どこへ転送するか」と「どのリクエストを受け付けるか」を明確に分離します。

  • Route: リクエスト照合条件（Host: api.kong.learning..., Path: /v1/echo, Method: GET）。一致しないものは即座に 404 Not Found。
  • Service: 転送先のUpstream定義（URL: https://httpbin.org/anything、タイムアウト値、リトライ回数）。
Core Entity 2

Plugin の優先順位とスコープ

プラグインは Global / Service / Route / Consumer の4階層でアタッチできます。

  • 実行順序 (Priority): プラグインごとに定義された優先度数値に基づき実行（例: 認証プラグインが先、レート制限が次、変換がその次）。
  • インメモリ共有辞書: レート制限のカウントは lua_shared_dict（メモリ上）で原子的に加算され、超低遅延で判定されます。

実機検証ラボ & フェーズ実行トレース

実際にリクエストを送信し、KongのAccessフェーズ（Rate Limit）やFilterフェーズ（Header加工）の挙動を観測できます

リクエスト送信 & レート制限シミュレーター

※ アドレスを知っているメンバーのみがアクセスできる難読化エンドポイント（api-demo-e8f2c1.kong.learning.chu-jo.com）です。

IP クォータ残量: 60 / 60 リセットまで: -s
Kong 内部処理フェーズ・トレース:
1. Route Match ➔ 2. Access (Rate Limit) ➔ 3. Balancer & Upstream ➔ 4. Header Filter
Gateway Response Inspector
Status: Ready
Status: -
Latency: - ms
Kong Route: learning-echo-route
Response Headers (Filterフェーズで付与されたヘッダー):
Waiting for request...
Response Payload:
Click [単発リクエスト] to test the live Gateway.

DB モード vs DB-less モードの仕組み比較

Kong Gateway の2大運用アーキテクチャの差異と動作原理

項目 DB-less モード (宣言型) DB モード (PostgreSQL)
設定の持ち方 kong.yml を起動時にメモリへ一括ロード PostgreSQL に保持し、ポーリングで同期
Admin API の挙動 読み取り専用（設定変更はYAMLを再ロード） CRUD 操作で即時設定追加・更新が可能
Control Plane / Data Plane 単一コンテナで完結。インフラが極めてシンプル CP（管理）と複数のDP（中継）で分散管理が可能
向いている用途 GitOps、CI/CD、Kubernetes Ingress、ローカル実習 管理GUI（Kong Manager）、動的認証キー登録、マルチテナント