#บทนำ

ในระบบสมัยใหม่ โดยเฉพาะสถาปัตยกรรมแบบ Microservices เรามักมี Backend API หลายบริการ เช่น User Service, Product Service และ Order Service หาก Client ต้องเชื่อมต่อแต่ละบริการโดยตรง จะทำให้การจัดการ URL, Security, Rate Limiting, Logging และ Load Balancing ซับซ้อนขึ้น

API Gateway ช่วยแก้ปัญหานี้ด้วยการทำหน้าที่เป็น Single Entry Point สำหรับ Client ก่อนส่ง Request ไปยัง Backend Service ที่เหมาะสม

Workshop นี้ใช้ Kong Gateway แบบ DB-less, Docker Compose และ API จำลองด้วย httpbin เพื่อให้เห็นแนวคิดสำคัญโดยไม่ต้องสร้าง Backend Application ก่อน

#วัตถุประสงค์

เมื่อจบ Workshop ผู้อ่านจะสามารถ

  • อธิบายหน้าที่ของ API Gateway ได้
  • ติดตั้ง Kong Gateway ด้วย Docker Compose
  • กำหนด Service และ Route
  • Routing Request จาก Gateway ไป Backend
  • ทำ Load Balancing ระหว่าง Backend หลาย Instance
  • เพิ่ม Rate Limiting
  • ตรวจสอบ Gateway ผ่าน Admin API
  • ทดสอบระบบด้วย curl
  • เข้าใจแนวทางต่อยอดไปสู่ Authentication, Observability และ Production

#1. API Gateway คืออะไร

API Gateway เป็นชั้นกลางระหว่าง Client และ Backend Services

                    +------------------+
Web / Mobile ------>|                  |----> User Service
Frontend ---------->|   API Gateway    |----> Order Service
External Client --->|                  |----> Product Service
                    +------------------+
                             |
                    Routing / Security
                    Rate Limiting
                    Load Balancing
                    Logging / Metrics

Client ไม่จำเป็นต้องรู้ว่า Backend จริงทำงานอยู่ที่ Host หรือ Port ใด แต่เรียก API ผ่าน Gateway เช่น

http://localhost:8000/api

Gateway จะรับ Request และเลือก Upstream ที่เหมาะสม

#2. หน้าที่สำคัญของ API Gateway

#Routing

กำหนดว่า URL แต่ละ Path ต้องส่ง Request ไปที่ Service ใด

/users     -> User Service
/products  -> Product Service
/orders    -> Order Service

#Authentication และ Authorization

Gateway สามารถตรวจสอบ Credential ก่อนอนุญาตให้ Request ผ่านไปยัง Backend เช่น

  • API Key
  • Basic Authentication
  • JWT
  • OAuth 2.0 / OpenID Connect

#Rate Limiting

จำกัดจำนวน Request ที่ Client สามารถส่งเข้ามาในช่วงเวลาหนึ่ง เพื่อลด Abuse และช่วยป้องกัน Backend จาก Traffic ที่มากเกินไป

#Load Balancing

กระจาย Request ไปยัง Backend หลาย Instance

API Gateway
   |
   +----> API #1
   +----> API #2
   +----> API #3

#Observability

Gateway เป็นจุดที่เหมาะสำหรับเก็บข้อมูล เช่น

  • Access Log
  • Request Count
  • Response Time
  • HTTP Status Code
  • Error Rate

#3. Architecture ของ Workshop

เราจะสร้างระบบดังนี้

                 http://localhost:8000
                         |
                         v
                 +----------------+
                 |  Kong Gateway  |
                 +----------------+
                         |
                         v
                 +----------------+
                 |    Upstream    |
                 | backend-pool   |
                 +----------------+
                    |          |
                    v          v
              +----------+ +----------+
              | backend1 | | backend2 |
              | httpbin  | | httpbin  |
              +----------+ +----------+

Kong Proxy เปิดที่ Port 8000 และ Kong Admin API เปิดที่ Port 8001

Admin API ใน Workshop เปิดให้เข้าจากเครื่อง Host เพื่อการเรียนรู้เท่านั้น ใน Production ไม่ควรเปิด Admin API สู่ Public Internet โดยตรง

#4. สิ่งที่ต้องเตรียม

ตรวจสอบ Docker

docker --version

ตรวจสอบ Docker Compose

docker compose version

สร้างโฟลเดอร์ Workshop

mkdir api-gateway-workshop
cd api-gateway-workshop

โครงสร้างไฟล์

api-gateway-workshop/
├── docker-compose.yml
└── kong.yml

#5. สร้าง Backend Services

สร้างไฟล์ docker-compose.yml

services:

  backend1:
    image: kennethreitz/httpbin
    networks:
      - gateway-network

  backend2:
    image: kennethreitz/httpbin
    networks:
      - gateway-network

  kong:
    image: kong:3
    environment:
      KONG_DATABASE: "off"
      KONG_DECLARATIVE_CONFIG: /kong/declarative/kong.yml
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
    volumes:
      - ./kong.yml:/kong/declarative/kong.yml:ro
    ports:
      - "8000:8000"
      - "8001:8001"
    depends_on:
      - backend1
      - backend2
    networks:
      - gateway-network

networks:
  gateway-network:
    driver: bridge

ใน Workshop นี้ Backend ทั้งสองตัวใช้ httpbin เพื่อให้ทดสอบ HTTP Request/Response ได้ทันที

#6. กำหนด Kong Gateway

สร้างไฟล์ kong.yml

_format_version: "3.0"

services:
  - name: demo-api
    host: backend-upstream
    port: 80
    protocol: http

    routes:
      - name: demo-route
        paths:
          - /api
        strip_path: true

    plugins:
      - name: rate-limiting
        config:
          minute: 10
          policy: local

upstreams:
  - name: backend-upstream
    algorithm: round-robin

    targets:
      - target: backend1:80
        weight: 100

      - target: backend2:80
        weight: 100

องค์ประกอบสำคัญคือ

Route
  |
  v
Service
  |
  v
Upstream
  |
  +--> Target backend1
  |
  +--> Target backend2

#7. เริ่มต้นระบบ

รัน

docker compose up -d

ตรวจสอบ Container

docker compose ps

ควรพบ Kong, backend1 และ backend2 ทำงานอยู่

ดู Log

docker compose logs -f kong

กด Ctrl+C เมื่อต้องการออกจากการดู Log

#8. ตรวจสอบ Kong Admin API

ทดสอบ

curl http://localhost:8001

ตรวจสอบ Service

curl http://localhost:8001/services

ตรวจสอบ Route

curl http://localhost:8001/routes

ตรวจสอบ Upstream

curl http://localhost:8001/upstreams

Admin API มีประโยชน์สำหรับการดู Configuration และสถานะของ Kong แต่ควรถูกจำกัดการเข้าถึงอย่างเข้มงวดในระบบจริง

#9. ทดสอบ Routing

เรียก API ผ่าน Gateway

curl http://localhost:8000/api/get

Flow คือ

curl
 |
 v
localhost:8000
 |
 v
Kong Route: /api
 |
 v
Service: demo-api
 |
 v
Upstream: backend-upstream
 |
 v
backend1 หรือ backend2

ทดสอบ POST

curl -X POST \
  http://localhost:8000/api/post \
  -H "Content-Type: application/json" \
  -d '{"name":"Kong","type":"API Gateway"}'

#10. ทดสอบ Load Balancing

ใน Configuration เรากำหนด

upstreams:
  - name: backend-upstream
    algorithm: round-robin

และมี Target สองตัว

targets:
  - target: backend1:80
  - target: backend2:80

Kong จึงสามารถกระจาย Request ไปยัง Backend Pool ได้

ส่ง Request หลายครั้ง

for i in {1..10}
do
  curl -s http://localhost:8000/api/get > /dev/null
  echo "Request $i completed"
done

ดู Access Log ของ Backend

docker compose logs backend1

docker compose logs backend2

จะเห็น Request ถูกส่งไปยัง Backend ทั้งสอง Instance

#11. เพิ่ม Rate Limiting

เราได้กำหนด Plugin ไว้ที่ Service

plugins:
  - name: rate-limiting
    config:
      minute: 10
      policy: local

หมายความว่า Client จะถูกจำกัด Request ตามนโยบายที่กำหนด

ลองเรียกหลายครั้ง

for i in {1..15}
do
  echo "Request $i"
  curl -i http://localhost:8000/api/get
done

เมื่อเกิน Limit จะได้รับ HTTP Status ที่บ่งชี้ว่ามี Request มากเกินไป เช่น

HTTP/1.1 429 Too Many Requests

Rate Limiting เป็นกลไกสำคัญสำหรับ Public API และระบบที่ต้องควบคุมการใช้ Resource

#12. ตรวจสอบ Header

ลอง

curl -i http://localhost:8000/api/get

นอกจาก Response จาก Backend แล้ว Gateway/Plugin อาจเพิ่ม Header ที่เกี่ยวข้องกับการประมวลผลและ Rate Limit ซึ่งสามารถใช้ตรวจสอบพฤติกรรมของ Gateway ได้

#13. ทดลองปิด Backend หนึ่งตัว

ตรวจสอบชื่อ Container

docker compose ps

จากนั้นหยุด Backend หนึ่งตัว

docker compose stop backend1

ทดลองเรียก API

curl http://localhost:8000/api/get

การทดลองนี้ช่วยให้เห็นประเด็นสำคัญเรื่อง Availability, Health Checking และ Failure Handling ของระบบที่มีหลาย Backend

เปิด Backend กลับ

docker compose start backend1

ใน Production ควรกำหนด Active/Passive Health Checks และกลยุทธ์ Retry/Timeout ให้เหมาะกับระบบ ไม่ควรสมมติว่า Load Balancer เพียงอย่างเดียวจะแก้ Failure ได้ทุกกรณี

#14. แก้ไข Configuration

หากแก้ kong.yml วิธีที่ง่ายสำหรับ Workshop คือ Restart Kong

docker compose restart kong

ตรวจสอบ Log

docker compose logs kong

หาก Configuration ผิด Kong อาจไม่สามารถเริ่มต้นได้ ดังนั้นควรตรวจสอบ YAML indentation และชื่อ Plugin ให้ถูกต้อง

#15. เพิ่ม Route ใหม่

ตัวอย่างเพิ่ม Route /demo

services:
  - name: demo-api
    host: backend-upstream
    port: 80
    protocol: http

    routes:
      - name: api-route
        paths:
          - /api
        strip_path: true

      - name: demo-route
        paths:
          - /demo
        strip_path: true

Restart Kong

docker compose restart kong

ทดสอบ

curl http://localhost:8000/demo/get

ทั้ง /api/get และ /demo/get จะสามารถส่งไปยัง Service เดียวกันได้

#16. API Gateway กับ Reverse Proxy ต่างกันอย่างไร

Reverse Proxy เน้นรับ Request แล้ว Forward ไป Backend ส่วน API Gateway มักเพิ่มความสามารถที่ออกแบบมาสำหรับ API Management โดยตรง

ความสามารถ Reverse Proxy API Gateway

Reverse Proxy ✓ ✓ Routing ✓ ✓ Load Balancing ✓ ✓ TLS Termination ✓ ✓ API Authentication ต้องคอนฟิก/เสริม ✓ Rate Limiting ขึ้นกับผลิตภัณฑ์ ✓ API-specific Plugin จำกัด ✓ Consumer Management ไม่ใช่หน้าที่หลัก ✓ API Analytics จำกัด ✓/ขึ้นกับผลิตภัณฑ์

เส้นแบ่งไม่ตายตัว เพราะผลิตภัณฑ์ Reverse Proxy บางตัวสามารถเพิ่มความสามารถจนทำงานคล้าย API Gateway ได้

#17. API Gateway ใน Microservices

ตัวอย่างระบบจริง

                        +------------------+
                        |   API Gateway    |
                        +------------------+
                         /       |        \
                        /        |         \
                       v         v          v
                +---------+ +---------+ +---------+
                | User API| |Order API| |Pay API  |
                +---------+ +---------+ +---------+
                     |          |           |
                    DB         DB          DB

Client ติดต่อ Gateway เพียงจุดเดียว

/api/users
/api/orders
/api/payments

Gateway จัดการ Routing ไปยัง Microservice ที่เกี่ยวข้อง

#18. Security ที่ควรพิจารณา

API Gateway ไม่ได้ทำให้ระบบปลอดภัยโดยอัตโนมัติ ควรออกแบบ Security หลายชั้น เช่น

Internet
   |
   v
Firewall / WAF
   |
   v
API Gateway
   |
   +-- TLS
   +-- Authentication
   +-- Authorization
   +-- Rate Limiting
   +-- Request Validation
   |
   v
Backend Services

แนวทางสำคัญ ได้แก่

  • ใช้ HTTPS/TLS
  • ไม่เปิด Admin API สู่ Internet
  • ใช้ JWT/OAuth 2.0/OIDC ตาม Use Case
  • เก็บ Secret ใน Secret Manager
  • จำกัด Network Access ของ Backend
  • Validate Input
  • ตั้ง Timeout และ Request Size Limit
  • เก็บ Audit/Access Logs
  • Patch Gateway และ Plugin อย่างสม่ำเสมอ

#19. Observability

ใน Production ควรตรวจสอบอย่างน้อย

Request Rate
Latency
HTTP 4xx
HTTP 5xx
Upstream Latency
Gateway Latency
Rate-limit Rejections
Authentication Failures

Architecture ที่นิยมคือ

Client
  |
  v
Kong Gateway
  |
  +------> Backend API
  |
  +------> Metrics
              |
              v
          Prometheus
              |
              v
           Grafana

นอกจากนี้สามารถส่ง Log ไปยังระบบรวมศูนย์ เช่น OpenSearch/Elasticsearch หรือระบบ Observability อื่นได้

#20. Production Checklist

ก่อนนำ API Gateway ไปใช้งานจริง ควรตรวจสอบ

  • [ ] เปิด HTTPS
  • [ ] ปิดหรือจำกัด Admin API
  • [ ] กำหนด Authentication
  • [ ] กำหนด Authorization
  • [ ] เปิด Rate Limiting
  • [ ] ตั้ง Connection/Read/Write Timeout
  • [ ] วาง Health Check Strategy
  • [ ] กำหนด Logging
  • [ ] เก็บ Metrics
  • [ ] ตั้ง Alert
  • [ ] จัดการ Secret อย่างปลอดภัย
  • [ ] ทดสอบ Failure Scenario
  • [ ] ทดสอบ Load/Performance
  • [ ] Backup Configuration
  • [ ] Version Control Configuration
  • [ ] วางแผน Upgrade Gateway

#21. แบบฝึกหัดเพิ่มเติม

#Exercise 1 --- เพิ่ม Service

สร้าง Backend Service ตัวที่สาม แล้วเพิ่มเข้า backend-upstream

#Exercise 2 --- Route แยก Service

สร้าง

/users
/orders
/products

แล้ว Routing ไป Backend คนละตัว

#Exercise 3 --- ปรับ Rate Limit

เปลี่ยน Limit จาก

minute: 10

เป็น

minute: 5

แล้วทดสอบ HTTP 429

#Exercise 4 --- Authentication

เพิ่ม Authentication Plugin เช่น Key Authentication หรือ JWT แล้วเปรียบเทียบ Request ที่มีและไม่มี Credential

#Exercise 5 --- Observability

เชื่อม Kong กับ Prometheus และสร้าง Grafana Dashboard สำหรับ Request Rate, Latency และ Error Rate

#22. คำสั่งที่ใช้บ่อย

เริ่มระบบ

docker compose up -d

ดูสถานะ

docker compose ps

ดู Log

docker compose logs -f

Restart Gateway

docker compose restart kong

หยุดระบบ

docker compose down

ทดสอบ Proxy

curl http://localhost:8000/api/get

ตรวจสอบ Admin API

curl http://localhost:8001/services

#23. สรุป

API Gateway เป็นองค์ประกอบสำคัญของระบบ API และ Microservices เพราะทำให้สามารถรวม Cross-cutting Concerns ไว้ที่จุดกลาง เช่น Routing, Authentication, Rate Limiting, Load Balancing และ Observability

Workshop นี้แสดง Flow หลัก

Client
  |
  v
API Gateway
  |
  +-- Routing
  +-- Rate Limiting
  +-- Load Balancing
  |
  v
Backend Services

เมื่อเข้าใจพื้นฐานแล้ว สามารถต่อยอดเป็นระบบที่ใกล้ Production มากขึ้นด้วย

Kong Gateway
   |
   +-- JWT / OAuth 2.0 / OIDC
   +-- Rate Limiting
   +-- Load Balancing
   +-- Health Check
   +-- Prometheus
   +-- Grafana
   +-- Centralized Logging
   |
   v
Microservices / Kubernetes

หัวข้อ Workshop ถัดไปที่เหมาะสมคือ Kong API Gateway Authentication ด้วย JWT, OAuth 2.0, Prometheus + Grafana และการ Deploy Gateway บน Kubernetes

#แหล่งศึกษาเพิ่มเติม