เวิร์กช็อปภาษาไทยสำหรับเรียนรู้การทำ Load Balancing ด้วย Kong API Gateway ตั้งแต่การสร้าง Service, Route, Upstream, Target ไปจนถึง Weighted Load Balancing และ Health Check

#1. เป้าหมายของ Workshop

หลังจากจบ Workshop นี้ ผู้เรียนจะสามารถ

  • อธิบายบทบาทของ Service, Route, Upstream และ Target ใน Kong Gateway ได้
  • สร้างระบบจำลองที่มี Backend หลาย Instance ด้วย Docker Compose
  • กำหนดให้ Kong กระจาย Request ไปยัง Backend หลายตัวแบบ Round Robin
  • ปรับสัดส่วน Traffic ด้วย Target Weight
  • ตรวจสอบสถานะของ Target
  • ทดลอง Active Health Check
  • จำลองกรณี Backend ล่ม และสังเกตการ Failover ไปยัง Backend ที่ยังทำงาน
  • เข้าใจแนวทางเลือก Load Balancing Algorithm สำหรับระบบจริง

#2. สถาปัตยกรรมของระบบ

Workshop นี้จะสร้าง Backend จำนวน 3 Instance และให้ Kong Gateway ทำหน้าที่เป็น API Gateway และ Load Balancer

flowchart LR
    C[Client] -->|HTTP :8000| K[Kong API Gateway]

    K --> R[Route /api]
    R --> S[Service demo-service]
    S --> U[Upstream api-upstream]

    U -->|Load Balance| B1[backend1 :80]
    U -->|Load Balance| B2[backend2 :80]
    U -->|Load Balance| B3[backend3 :80]

    K -. Admin API :8001 .-> A[Administrator]

แนวคิดสำคัญคือ Service ไม่ได้ชี้ไปยัง Backend ตัวใดตัวหนึ่งโดยตรง แต่ชี้ไปยังชื่อของ Upstream จากนั้น Kong จะเลือก Target ภายใน Upstream ตาม Load Balancing Algorithm ที่กำหนด

#3. องค์ประกอบที่เกี่ยวข้อง

#3.1 Service

Service เป็นตัวแทนของ Backend API ที่ Kong จะ Proxy Request ไปหา

ตัวอย่าง

demo-service

ใน Workshop นี้ Service จะกำหนด

host = api-upstream

ดังนั้น api-upstream จึงไม่ใช่ DNS จริง แต่เป็นชื่อของ Kong Upstream

#3.2 Route

Route ใช้กำหนดเงื่อนไขว่า Request แบบใดจะถูกส่งไปยัง Service

ตัวอย่าง

/api

เมื่อ Client เรียก

http://localhost:8000/api

Kong จะจับคู่ Route /api และส่ง Request ไปยัง demo-service

#3.3 Upstream

Upstream คือกลุ่ม Backend Servers หรือ Service Instances ที่ Kong สามารถกระจาย Request ไปหาได้

ตัวอย่าง

api-upstream

หนึ่ง Upstream สามารถมีหลาย Target

#3.4 Target

Target คือ Backend Instance จริง เช่น

backend1:80
backend2:80
backend3:80

Target แต่ละตัวสามารถกำหนด weight เพื่อควบคุมสัดส่วน Traffic ได้

#4. Load Balancing Algorithms ที่ Kong รองรับ

Kong Gateway รองรับ Load Balancing หลายรูปแบบผ่าน Upstream เช่น

Algorithm แนวคิด เหมาะกับ
round-robin กระจาย Request หมุนเวียนตาม Weight ระบบทั่วไป
consistent-hashing Hash ค่า เช่น IP/Header/Cookie เพื่อเลือก Backend Session affinity / cache locality
least-connections เลือก Backend ที่มีงานค้างน้อยกว่า Request ใช้เวลาประมวลผลไม่เท่ากัน
latency เลือก Backend ที่ตอบสนองเร็วกว่าโดยอิง latency Multi-region / Backend latency ต่างกัน
sticky-sessions ใช้ Cookie ทำให้ Client เดิมกลับไป Target เดิม Web session บางประเภท

Workshop หลักจะใช้

round-robin

เพราะเห็นพฤติกรรมการกระจาย Request ได้ชัดเจนที่สุด

#Part 1: เตรียม Environment

#5. สิ่งที่ต้องติดตั้ง

ควรมี

  • Docker
  • Docker Compose
  • curl
  • Terminal / PowerShell / Command Prompt

ตรวจสอบ Docker

docker --version
docker compose version

#6. สร้าง Project

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

mkdir kong-load-balancing
cd kong-load-balancing

สร้างไฟล์

docker-compose.yml

#7. Docker Compose

ใส่เนื้อหาต่อไปนี้ลงใน docker-compose.yml

services:

  kong-database:
    image: postgres:16
    container_name: kong-database
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kongpass
    volumes:
      - kong_data:/var/lib/postgresql/data
    networks:
      - kong-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U kong -d kong"]
      interval: 5s
      timeout: 5s
      retries: 10

  kong-migrations:
    image: kong:3.9.3
    container_name: kong-migrations
    command: kong migrations bootstrap
    depends_on:
      kong-database:
        condition: service_healthy
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kongpass
      KONG_PG_DATABASE: kong
    networks:
      - kong-net
    restart: on-failure

  kong:
    image: kong:3.9.3
    container_name: kong
    depends_on:
      kong-migrations:
        condition: service_completed_successfully
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kongpass
      KONG_PG_DATABASE: kong

      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
      KONG_PROXY_LISTEN: 0.0.0.0:8000
    ports:
      - "8000:8000"
      - "8001:8001"
    networks:
      - kong-net

  backend1:
    image: nginxdemos/hello:plain-text
    container_name: backend1
    networks:
      - kong-net

  backend2:
    image: nginxdemos/hello:plain-text
    container_name: backend2
    networks:
      - kong-net

  backend3:
    image: nginxdemos/hello:plain-text
    container_name: backend3
    networks:
      - kong-net

networks:
  kong-net:
    driver: bridge

volumes:
  kong_data:

ในระบบจริงควร pin image version ตามมาตรฐานขององค์กร และไม่ควรเปิด Admin API (8001) สู่ Public Network

#8. Start Containers

docker compose up -d

ตรวจสอบ

docker compose ps

ควรเห็น Container หลัก

kong
kong-database
backend1
backend2
backend3

ตรวจสอบ Kong Admin API

curl http://localhost:8001

หาก Kong ทำงาน จะได้ข้อมูล JSON ของ Kong Gateway

#Part 2: สร้าง Upstream และ Targets

#9. สร้าง Upstream

สร้าง Upstream ชื่อ

api-upstream

ด้วย Algorithm แบบ Round Robin

curl -i -X POST http://localhost:8001/upstreams \
  --data name=api-upstream \
  --data algorithm=round-robin

ตรวจสอบ

curl http://localhost:8001/upstreams/api-upstream

#10. เพิ่ม Target ตัวที่ 1

curl -i -X POST \
  http://localhost:8001/upstreams/api-upstream/targets \
  --data target=backend1:80 \
  --data weight=100

#11. เพิ่ม Target ตัวที่ 2

curl -i -X POST \
  http://localhost:8001/upstreams/api-upstream/targets \
  --data target=backend2:80 \
  --data weight=100

#12. เพิ่ม Target ตัวที่ 3

curl -i -X POST \
  http://localhost:8001/upstreams/api-upstream/targets \
  --data target=backend3:80 \
  --data weight=100

ตรวจสอบ Targets

curl http://localhost:8001/upstreams/api-upstream/targets

แนวคิดตอนนี้คือ

api-upstream
│
├── backend1:80   weight=100
├── backend2:80   weight=100
└── backend3:80   weight=100

ทั้งสาม Target มี Weight เท่ากัน จึงควรได้รับ Traffic ในสัดส่วนใกล้เคียงกัน

#Part 3: สร้าง Service และ Route

#13. สร้าง Service

สร้าง Service ที่ชี้ไปยัง Upstream

curl -i -X POST http://localhost:8001/services \
  --data name=demo-service \
  --data protocol=http \
  --data host=api-upstream \
  --data port=80

จุดสำคัญคือ

host=api-upstream

Kong จะตรวจพบว่า api-upstream เป็น Upstream และใช้ Load Balancer ของ Kong ในการเลือก Target

#14. สร้าง Route

curl -i -X POST \
  http://localhost:8001/services/demo-service/routes \
  --data name=demo-route \
  --data 'paths[]=/api' \
  --data strip_path=true

ตรวจสอบ

curl http://localhost:8001/routes

#Part 4: ทดสอบ Round Robin Load Balancing

#15. เรียก API

curl http://localhost:8000/api

nginxdemos/hello จะแสดงรายละเอียดของ Server ที่ตอบกลับ เช่น Hostname

ทดลองหลายครั้ง

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

ควรเห็น Response สลับกันระหว่าง Backend หลายตัว

แนวคิด

Request 1 → backend1
Request 2 → backend2
Request 3 → backend3
Request 4 → backend1
...

เนื่องจาก Kong ใช้ Weighted Round Robin ลำดับจริงไม่ควรถูกใช้เป็นข้อสมมติด้าน Business Logic แต่เมื่อ Weight เท่ากัน การกระจายในระยะยาวควรใกล้เคียงกัน

#16. ทดสอบแบบ Loop

#Linux / macOS / Git Bash

for i in {1..12}; do
  echo "===== Request $i ====="
  curl -s http://localhost:8000/api | grep -E "Server name|Hostname"
done

ถ้า Image แสดง Server name ในรูปแบบอื่น สามารถดู Response เต็มก่อนแล้วปรับ grep

#PowerShell

1..12 | ForEach-Object {
    Write-Host "===== Request $_ ====="
    curl.exe -s http://localhost:8000/api
}

#Part 5: Weighted Load Balancing

#17. แนวคิด Weight

สมมติว่า Backend มีความสามารถไม่เท่ากัน

backend1 = 300
backend2 = 100
backend3 = 100

แนวคิดคือ backend1 จะได้รับ Traffic มากกว่า Backend อื่น

สัดส่วนโดยประมาณ

backend1 = 300 / 500 = 60%
backend2 = 100 / 500 = 20%
backend3 = 100 / 500 = 20%

#18. เปลี่ยน Weight

Kong เก็บ Target เป็นประวัติการเปลี่ยนแปลง โดยการ POST Target เดิมพร้อม Weight ใหม่จะสร้างสถานะล่าสุดของ Target นั้น

curl -i -X POST \
  http://localhost:8001/upstreams/api-upstream/targets \
  --data target=backend1:80 \
  --data weight=300

คง Backend อื่นไว้ที่

backend2 = 100
backend3 = 100

ทดสอบหลาย Request เพื่อดูแนวโน้ม

for i in {1..30}; do
  curl -s http://localhost:8000/api
done

สำหรับการวัดจริงควรนับ Hostname จาก Response มากกว่าดูด้วยสายตา

#Part 6: Health Check และ Failover

#19. ปัญหาหาก Backend ล่ม

สมมติ

backend2

หยุดทำงาน

docker stop backend2

หากไม่มี Health Check ระบบอาจต้องอาศัยการตรวจพบ Connection Failure ระหว่างการ Proxy และพฤติกรรม Retry ที่กำหนดไว้

Kong รองรับ Health Check เพื่อให้ Load Balancer สามารถหลีกเลี่ยง Target ที่มีปัญหาได้

#20. Active vs Passive Health Check

#Active Health Check

Kong ส่ง Probe ไปหา Target เป็นระยะ

Kong
  |
  +---- GET / ----> backend1
  +---- GET / ----> backend2
  +---- GET / ----> backend3

ข้อดี

  • ตรวจพบปัญหาได้แม้ไม่มี User Traffic
  • สามารถตรวจพบว่า Target กลับมาทำงานและนำกลับเข้าสู่ Pool ได้

ข้อเสีย

  • มี Probe Traffic เพิ่มขึ้น

#Passive Health Check

Kong วิเคราะห์ผลจาก Traffic จริง

ตัวอย่าง

Client → Kong → backend2 → 500

เมื่อ Error ถึง Threshold Kong จะ Mark Target เป็น Unhealthy

ข้อดี

  • ไม่มี Probe Traffic เพิ่ม

ข้อควรระวัง

  • Passive check ไม่สามารถนำ Target ที่ถูก Mark unhealthy กลับมา healthy โดยอัตโนมัติได้ด้วยตัวมันเอง

ดังนั้นระบบจริงมักพิจารณาใช้ Active และ Passive ร่วมกันตาม Requirement

#21. สร้าง Upstream สำหรับ Health Check

เพื่อให้ Workshop ทำซ้ำได้ง่าย เราจะสร้าง Upstream ใหม่

curl -i -X POST http://localhost:8001/upstreams \
  -H "Content-Type: application/json" \
  -d '{
    "name": "health-upstream",
    "algorithm": "round-robin",
    "healthchecks": {
      "active": {
        "type": "http",
        "http_path": "/",
        "timeout": 1,
        "healthy": {
          "interval": 5,
          "successes": 2
        },
        "unhealthy": {
          "interval": 5,
          "tcp_failures": 2,
          "timeouts": 2,
          "http_failures": 2
        }
      }
    }
  }'

Active Health Check จะ Probe ทุกประมาณ 5 วินาทีตามค่าที่กำหนด

#22. เพิ่ม Targets

curl -X POST \
  http://localhost:8001/upstreams/health-upstream/targets \
  --data target=backend1:80 \
  --data weight=100

curl -X POST \
  http://localhost:8001/upstreams/health-upstream/targets \
  --data target=backend2:80 \
  --data weight=100

curl -X POST \
  http://localhost:8001/upstreams/health-upstream/targets \
  --data target=backend3:80 \
  --data weight=100

ถ้า backend2 ยังถูก Stop อยู่ ให้ Start ก่อน

docker start backend2

#23. เปลี่ยน Service ให้ใช้ Health-checked Upstream

curl -i -X PATCH \
  http://localhost:8001/services/demo-service \
  --data host=health-upstream

รอสักครู่ให้ Active Health Checker เริ่มตรวจ Targets จากนั้นทดสอบ

curl http://localhost:8000/api

#24. ตรวจสอบ Health

curl http://localhost:8001/upstreams/health-upstream/health

ควรเห็นสถานะของ Target แต่ละตัว

แนวคิด

backend1:80 → HEALTHY
backend2:80 → HEALTHY
backend3:80 → HEALTHY

#25. จำลอง Backend ล่ม

หยุด backend2

docker stop backend2

รอ Health Check ทำงานหลายรอบ แล้วตรวจสอบ

curl http://localhost:8001/upstreams/health-upstream/health

คาดหวังให้ backend2 ถูกมองเป็น unhealthy หลังถึง Threshold

จากนั้นยิง Request ต่อเนื่อง

for i in {1..10}; do
  curl -s http://localhost:8000/api
done

Traffic ควรถูกส่งไปยัง Target ที่ยัง Healthy เช่น

backend1
backend3

แทนที่จะพยายามใช้ Target ที่ถูก Mark ว่า unhealthy

#26. Recovery

Start Backend กลับมา

docker start backend2

รอ Active Health Check พบ Success ตาม Threshold

ตรวจสอบอีกครั้ง

curl http://localhost:8001/upstreams/health-upstream/health

เมื่อ Target กลับมา Healthy Kong จะสามารถนำ Target กลับเข้าสู่ Load Balancing Pool ได้โดยอัตโนมัติ

#Part 7: Least Connections

#27. เปลี่ยน Algorithm

อีก Algorithm ที่สำคัญคือ

least-connections

เหมาะกับระบบที่ Request แต่ละรายการใช้เวลาไม่เท่ากัน เช่น

  • Report generation
  • File processing
  • AI inference
  • Database-heavy API

สร้าง Upstream ใหม่

curl -i -X POST http://localhost:8001/upstreams \
  --data name=least-upstream \
  --data algorithm=least-connections

เพิ่ม Targets

curl -X POST \
  http://localhost:8001/upstreams/least-upstream/targets \
  --data target=backend1:80 \
  --data weight=100

curl -X POST \
  http://localhost:8001/upstreams/least-upstream/targets \
  --data target=backend2:80 \
  --data weight=100

curl -X POST \
  http://localhost:8001/upstreams/least-upstream/targets \
  --data target=backend3:80 \
  --data weight=100

เปลี่ยน Service

curl -X PATCH \
  http://localhost:8001/services/demo-service \
  --data host=least-upstream

#Part 8: Consistent Hashing

#28. ใช้ Header เป็น Hash Key

Consistent Hashing เหมาะกับกรณีที่ต้องการให้ Client หรือ Request กลุ่มเดิมมีแนวโน้มไปยัง Backend เดิม

ตัวอย่างสร้าง Upstream

curl -i -X POST http://localhost:8001/upstreams \
  --data name=hash-upstream \
  --data algorithm=consistent-hashing \
  --data hash_on=header \
  --data hash_on_header=X-User-ID

เพิ่ม Targets ตามเดิม แล้วเปลี่ยน Service ให้ชี้ไปยัง

hash-upstream

ทดลอง

curl -H "X-User-ID: user001" http://localhost:8000/api
curl -H "X-User-ID: user001" http://localhost:8000/api
curl -H "X-User-ID: user001" http://localhost:8000/api

เมื่อ Hash Input เดิมเหมือนกัน Request ควรมีแนวโน้มเลือก Target เดิม ตราบใดที่ Ring และสถานะ Target ไม่เปลี่ยน

ทดลอง User อื่น

curl -H "X-User-ID: user999" http://localhost:8000/api

อาจถูก Hash ไปยัง Target อื่น

#Part 9: Request Flow

Request Flow ของ Workshop สามารถสรุปได้ดังนี้

sequenceDiagram
    participant C as Client
    participant K as Kong Gateway
    participant R as Route
    participant S as Service
    participant U as Upstream
    participant B1 as Backend 1
    participant B2 as Backend 2
    participant B3 as Backend 3

    C->>K: GET /api
    K->>R: Match Route
    R->>S: Resolve Service
    S->>U: host = Upstream
    U->>U: Select healthy Target
    U->>B2: Forward Request
    B2-->>K: HTTP Response
    K-->>C: HTTP Response

#Part 10: Monitoring และ Troubleshooting

#29. ดู Kong Logs

docker logs -f kong

#30. ดู Backend Logs

docker logs backend1
docker logs backend2
docker logs backend3

#31. ดู Upstreams

curl http://localhost:8001/upstreams

#32. ดู Targets

curl http://localhost:8001/upstreams/api-upstream/targets

#33. ดู Health

curl http://localhost:8001/upstreams/health-upstream/health

#34. ปัญหาที่พบบ่อย

#Kong ติดต่อ Backend ไม่ได้

ตรวจสอบว่าอยู่ Network เดียวกัน

docker network inspect kong-load-balancing_kong-net

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

docker compose ps

#ได้ HTTP 404 จาก Kong

ตรวจสอบ Route

curl http://localhost:8001/routes

และตรวจสอบว่าเรียก

http://localhost:8000/api

ตรงกับ Path ที่สร้างไว้

#ได้ HTTP 503

สาเหตุที่เป็นไปได้

  • ไม่มี Target ที่ใช้งานได้
  • Target ถูก Mark unhealthy
  • Upstream อยู่ต่ำกว่า Health Threshold
  • DNS/Container network มีปัญหา

ตรวจสอบ

curl http://localhost:8001/upstreams/health-upstream/health

#Active Health Check ไม่ทำงาน

ตรวจสอบว่า

  • healthy.interval มากกว่า 0
  • unhealthy.interval มากกว่า 0
  • Target สามารถเข้าถึงได้จาก Kong container
  • Path ที่ใช้ตรวจ Health ตอบ HTTP Status ตามที่กำหนด

#Part 11: แบบฝึกหัด

#Exercise 1

เพิ่ม Backend ตัวที่ 4

backend4

แล้วเพิ่มเป็น Target ของ api-upstream

เป้าหมายคือให้ระบบมี

backend1
backend2
backend3
backend4

#Exercise 2

กำหนด Weight

backend1 = 400
backend2 = 200
backend3 = 100
backend4 = 100

คำนวณสัดส่วน Traffic ที่คาดหวัง

เฉลยเชิงแนวคิด

Total = 800

backend1 = 50%
backend2 = 25%
backend3 = 12.5%
backend4 = 12.5%

จากนั้นยิงอย่างน้อย 100 Request และนับจำนวน Response จากแต่ละ Backend

#Exercise 3

หยุด

docker stop backend1

ตรวจสอบว่า Active Health Check ทำให้ Kong หยุดส่ง Traffic ไปยัง Backend ที่ล่มหรือไม่

จากนั้น

docker start backend1

ตรวจสอบ Recovery

#Exercise 4

เปลี่ยน Algorithm เป็น

least-connections

แล้วสร้าง Backend ที่ตอบช้า เพื่อสังเกตความแตกต่างกับ Round Robin

#Exercise 5

สร้าง Consistent Hashing โดยใช้

X-User-ID

แล้วทดสอบ User อย่างน้อย 5 ค่า

user001
user002
user003
user004
user005

ตรวจสอบว่า User เดิมถูกส่งไปยัง Backend เดิมอย่างสม่ำเสมอเพียงใด

#Part 12: แนวทาง Production

#35. อย่าเปิด Admin API สู่ Internet

Port

8001

ควรเข้าถึงได้เฉพาะ Management Network หรือ Control Plane ที่กำหนดเท่านั้น

#36. ใช้ Health Endpoint โดยเฉพาะ

Backend ควรมี Endpoint เช่น

/health
/ready
/readiness

และไม่ควรใช้ Endpoint ที่มี Business Logic หนักเป็น Health Probe

#37. แยก Liveness และ Readiness

ตัวอย่าง

/health/live
/health/ready

ready ควรสะท้อนว่า Instance พร้อมรับ Traffic จริงหรือไม่ เช่น

  • Database connection พร้อม
  • Dependency สำคัญพร้อม
  • Initialization เสร็จแล้ว

#38. เลือก Algorithm ให้ตรง Workload

#Round Robin

เหมาะเมื่อ Backend มี Capacity ใกล้เคียงกัน

#Weighted Round Robin

เหมาะเมื่อ Server มี Spec ต่างกัน หรือใช้ Canary Deployment

#Least Connections

เหมาะกับ Request ที่ Processing Time แตกต่างกันมาก

#Consistent Hashing

เหมาะเมื่อมี State, Cache locality หรือ Affinity Requirement

#Latency

เหมาะเมื่อ Backend มี Response Time แตกต่างกัน

#39. Load Balancing ไม่แทน Auto Scaling

Kong ทำหน้าที่กระจาย Traffic แต่ไม่ได้สร้าง Backend Instance ใหม่เอง

Architecture ระบบจริงอาจเป็น

Client
   |
   v
Kong Gateway
   |
   v
Kubernetes Service / Pods
   |
   +---- Pod 1
   +---- Pod 2
   +---- Pod 3
   +---- Pod N

Auto Scaling เช่น Kubernetes HPA ทำหน้าที่เพิ่ม/ลดจำนวน Pod ส่วน Kong ทำหน้าที่ Gateway, Routing, Security, Policy และ Load Balancing ตาม Architecture ที่เลือก

#Part 13: สรุป

โครงสร้างพื้นฐานของ Kong Load Balancing คือ

Client
   |
   v
Route
   |
   v
Service
   |
   v
Upstream
   |
   +---- Target 1
   +---- Target 2
   +---- Target 3

คำสำคัญที่ควรจำ

Route     = กำหนดว่า Request แบบใดเข้าระบบ
Service   = Logical Backend Service
Upstream  = กลุ่ม Backend Instances + Load Balancing Policy
Target    = Backend Instance จริง
Weight    = สัดส่วน Traffic
Health    = สถานะความพร้อมของ Target

Kong Gateway สามารถทำหน้าที่ Load Balancer ระดับ API ได้อย่างยืดหยุ่น ทั้ง Weighted Round Robin, Consistent Hashing, Least Connections, Latency-based balancing และ Health Checking ทำให้เหมาะกับ Microservices, Container และ Cloud-native Architecture

#Cleanup

หยุดระบบ

docker compose down

หากต้องการลบ Database Volume ด้วย

docker compose down -v

#References