Lesson 01: Core Architecture & 4 เสาหลักของ Kong Gateway

Part 1 ทำความเข้าใจก่อนเริ่ม: API Gateway และ Kong คืออะไร?

โลกที่ "ไม่มี" API Gateway เป็นอย่างไร?

สมมติว่าคุณมีระบบหลังบ้านที่แยกออกเป็นหลายระบบย่อย (Microservices) เช่น ระบบจัดการสมาชิก (Auth Service), ระบบสินค้า (Product Service) และ ระบบชำระเงิน (Payment Service)

หากไม่มีตัวกลางคั่นอยู่ หน้าบ้าน (Mobile App หรือ Web Frontend) จะต้องยิงคำขอตรงไปยัง IP/Domain ของทั้ง 3 ระบบด้วยตัวเอง สิ่งที่จะเกิดขึ้นตามมาคือ:

• ความยุ่งยากระดับวิกฤต: ฝั่ง App ต้องจำ URL และพอร์ตของทุกระบบหลังบ้าน ถ้าทีม Backend ย้ายเครื่องหรือเปลี่ยน IP หน้าบ้านจะพังทันที
• เขียนโค้ดซ้ำซาก: ทุกระบบหลังบ้านต้องมานั่งเขียนโค้ดตรวจ Token (JWT), โค้ดป้องกันยิงถล่ม (Rate Limit) และโค้ดเปิดรับข้ามโดเมน (CORS) ซ้ำๆ กันทุกระบบ
• ความเสี่ยงด้านความปลอดภัย: เซิร์ฟเวอร์หลังบ้านทั้งหมดต้องเปิดรับเน็ตเวิร์กจากอินเทอร์เน็ตภายนอกโดยตรง ทำให้มีช่องโหว่ให้โดนโจมตีสูงมาก

API Gateway เข้ามาแก้ปัญหานี้อย่างไร?

เรานำ API Gateway (เช่น Kong) มาตั้งเป็นจุดเข้า-ออกจุดเดียว (Single Entry Point) โดยให้ Client ทุกคนยิงเข้ามาที่ Kong เพียงจุดเดียว เช่น api.example.com แล้ว Kong จะทำหน้าที่เป็นเหมือน เคาน์เตอร์ประชาสัมพันธ์อัจฉริยะ ที่คอยดูว่า:

1. คำขอนี้ต้องการอะไร? (Routing)
2. ผู้ใช้งานมีสิทธิ์เข้าถึงหรือไม่? (Authentication & Authorization)
3. ยิงคำขอถี่เกินกำหนดหรือยัง? (Rate Limiting)
4. แล้วจึงส่งต่อไปยังเซิร์ฟเวอร์หลังบ้านที่ถูกต้องอย่างปลอดภัย

Part 2 นิยามศัพท์ทางการ 4 เสาหลัก (Core Entities)

ในการตั้งค่า Kong Gateway ไม่ว่าคุณจะใช้งานในระบบขนาดเล็กหรือใหญ่ หัวใจทั้งหมดจะประกอบด้วย 4 Entity หลักนี้เสมอ เพื่อความเข้าใจที่แม่นยำ นี่คือนิยามทางการตามข้อกำหนดของ Kong:

Part 3 เรื่องเล่าจากสนามจริง: วิกฤต Black Friday Blackout

องค์กร: แพลตฟอร์มอีคอมเมิร์ซขนาดใหญ่ที่มีทราฟฟิกระดับ 45,000 req/sec

ความผิดพลาด: ระบบเดิมไม่มี Gateway กลาง ฝั่งหน้าบ้าน (Mobile App) ยิงตรงเข้าสู่ Cart Service (ระบบตะกร้าสินค้า) เมื่อถึงช่วงเที่ยงคืน Flash Sale ปรากฏว่า Cart Service เริ่มตอบสนองช้าลงจาก 50ms พุ่งทะลุไปถึง 3,500ms

เนื่องจากไม่มี Gateway คอยคุม Timeout ส่วนกลาง ทำให้ Mobile App พยายามยิงซ้ำ (Auto-retry) จนเกิดปรากฏการณ์ Retry Storm (พายุการยิงซ้ำ) ถล่มซ้ำเติมจนเซิร์ฟเวอร์ล่มทั้งหมด พ่วงด้วยการที่แต่ละเครื่องต้องเสียแรง CPU ไปกับการถอดรหัส Token และทำ TLS Handshake ซ้ำซ้อน ยอดขายเสียหายไปกว่า 1.8 ล้านเหรียญใน 42 นาที

การแก้ไขด้วย Kong Gateway: ทีมงานนำ Kong มาตั้งด่านหน้า ทำ TLS Termination และ JWT Verification เบ็ดเสร็จที่ตัว Gateway เซิร์ฟเวอร์หลังบ้านจึงประหยัด CPU ได้ทันที และใช้ Upstream Circuit Breaker ของ Kong ช่วยตัดการส่งคำขอไปยังเครื่องที่เริ่มตอบสนองช้า เพื่อป้องกันไม่ให้ระบบล่มลามเป็นโดมิโน

Part 4 ภาพจำลองเชิงอุปมาอุปไมย (Mental Model) & สถาปัตยกรรม

ลองจินตนาการถึง โรงแรมหรูระดับ 5 ดาว:

• Client (แขก): เดินเข้ามาหน้าประตูโรงแรม
• Route (ป้ายบอกทาง): แขกบอกว่า "ต้องการไปห้องอาหารอิตาเลียน"
• Service (แผนกห้องอาหาร): เป็นตัวแทนเชิงตรรกะว่านี่คือฝ่ายอาหารอิตาเลียน
• Upstream (ทีมเชฟในครัว): กลุ่มเชฟที่พร้อมปรุงอาหารตามคิว
• Target (ตัวเชฟแต่ละคน): เชฟสมชาย (IP: 10.0.1.10) และเชฟสมศรี (IP: 10.0.1.11) หากเชฟสมชายป่วย (Health Check ล้มเหลว) ออเดอร์จะถูกส่งไปให้เชฟสมศรีทันที

Part 5 ฝึกปฏิบัติ 3 ระดับ (Hands-on Syntax Breakdown)

เราใช้ไฟล์คอนฟิกแบบ Declarative (kong.yml) ซึ่งไม่ต้องพึ่งพาฐานข้อมูล (DB-less) เหมาะกับการทำ GitOps อย่างยิ่ง

Level 1 (ระดับเริ่มต้น): การจับคู่ Route ไปยัง Service เบื้องต้น

_format_version: "3.0"

services:
  - name: mock-service
    url: https://httpbin.org/anything  # ชี้ตรงไปยังปลายทาง
    routes:
      - name: mock-route
        paths:
          - /test-echo                  # หากยิงเข้ามาที่ /test-echo
        strip_path: true                # ให้ตัดคำว่า /test-echo ออกก่อนส่งต่อไปหลังบ้าน

Level 2 (ระดับปานกลาง): การตัดแต่ง Path (strip_path) และรวมกลุ่ม Upstream

_format_version: "3.0"

upstreams:
  - name: order-pool                   # ตั้งชื่อกลุ่ม Load Balancer
    algorithm: round-robin

targets:
  - upstream: order-pool
    target: 10.0.1.50:8080
    weight: 80                         # รับงาน 80%
  - upstream: order-pool
    target: 10.0.1.51:8080
    weight: 20                         # รับงาน 20%

services:
  - name: order-service
    host: order-pool                   # ชี้ host ของ Service มาที่ Upstream
    protocol: http
    path: /internal/orders
    routes:
      - name: order-route
        paths:
          - /orders
        strip_path: false              # เก็บ /orders ไว้ แล้วนำไปต่อท้าย /internal/orders

Level 3 (ระดับ Production): คอนฟิกระบบตรวจสอบความสมบูรณ์และตัดไฟอัตโนมัติ (Health Checks)

_format_version: "3.0"

upstreams:
  - name: payment-cluster
    algorithm: consistent-hashing
    hash_on: header
    hash_on_header: X-User-ID          # Sticky session ตาม User ID
    healthchecks:
      active:
        type: http
        http_path: /health
        timeout: 1
        interval: 2                    # ส่งคำขอไปเช็กทุก 2 วินาที
        healthy:
          successes: 2
          http_statuses: [200]
        unhealthy:
          http_failures: 2             # ตอบพังติดกัน 2 ครั้ง ให้ถือว่าเครื่องตายทันที
          http_statuses: [500, 502, 503, 504]
      passive:                         # ดักฟังจาก Request จริงของลูกค้า
        type: http
        unhealthy:
          http_failures: 3             # ถ้าลูกค้าเจอ Error ติดกัน 3 ครั้ง ตัดทิ้งทันที
          http_statuses: [500, 503]

targets:
  - upstream: payment-cluster
    target: 10.0.2.10:8443
    weight: 100
  - upstream: payment-cluster
    target: 10.0.2.11:8443
    weight: 100

services:
  - name: payment-service
    host: payment-cluster
    connect_timeout: 1500              # TCP Handshake ไม่เกิน 1.5 วินาที
    read_timeout: 4000                 # เวลารอ Backend ตอบกลับไม่เกิน 4 วินาที
    retries: 3                         # ลองส่งเครื่องสำรองได้สูงสุด 3 ครั้ง
    routes:
      - name: payment-route
        paths:
          - ~/api/v[1-2]/payments      # รองรับ Regex
        strip_path: false
        preserve_host: true

Part 6 Interactive Simulator: คำนวณช่วงเวลาตรวจจับความเสียหาย (Detection Window)

ทดลองปรับตัวแปรด้านล่างเพื่อดูว่า หากเครื่อง Backend ตัวหนึ่งตายกะทันหัน จะต้องใช้เวลานานกี่วินาทีกว่าที่ระบบ Active Health Check ของ Kong จะตรวจพบ และระหว่างนั้นมีคำขอของลูกค้าที่ต้องพังไปกี่รายการ:

Part 7 Active Recall Deep-Dive Exam (16 ข้อ)

แบบทดสอบวัดความเข้าใจและตอกย้ำความจำ ทุกข้อมีเนื้อหารองรับจากหัวข้อด้านบน 100%