Network Load Balancer: กระจาย Traffic ให้เซิร์ฟเวอร์อย่างมืออาชีพ
เมื่อ web application มีผู้ใช้มากขึ้น server เครื่องเดียวอาจรับไม่ไหว ช้า หรือล่มไปเลย Load Balancer กระจาย traffic จากผู้ใช้ไปยัง server หลายเครื่องพร้อมกัน ทำให้ระบบรองรับผู้ใช้ได้มากขึ้น มี high availability (ถ้า server ตัวหนึ่งล่ม traffic จะถูกส่งไปตัวอื่นอัตโนมัติ) และ performance ดีขึ้น
สำหรับองค์กรที่มี web applications, APIs หรือ services ที่สำคัญ Load Balancer เป็นอุปกรณ์ที่ขาดไม่ได้ บทความนี้จะอธิบายหลักการทำงาน ประเภทของ load balancer, algorithms ที่ใช้กระจาย traffic, health checks และ best practices
Load Balancer ทำงานอย่างไร
Load Balancer ทำหน้าที่เป็นตัวกลางระหว่าง client กับ backend servers เมื่อ client ส่ง request มา load balancer จะเลือก backend server ที่เหมาะสมแล้วส่ง request ไปให้ response จาก server จะถูกส่งกลับผ่าน load balancer ไปยัง client
Layer 4 vs Layer 7 Load Balancing
Layer 4 (Transport) ตัดสินใจจาก IP address และ port number เท่านั้น เร็วมาก ใช้ทรัพยากรน้อย ไม่ inspect content ของ request เหมาะสำหรับ TCP/UDP traffic ทั่วไป เช่น database connections, game servers
Layer 7 (Application) ตัดสินใจจากเนื้อหาของ HTTP request เช่น URL path, hostname, headers, cookies สามารถ route /api/* ไป API servers และ /images/* ไป CDN servers ได้ ทำ SSL termination, content caching, compression เหมาะสำหรับ web applications
Load Balancing Algorithms
| Algorithm | วิธีทำงาน | ข้อดี | ข้อเสีย | เหมาะกับ |
|---|---|---|---|---|
| Round Robin | วนส่ง request ทีละ server | ง่าย กระจายสม่ำเสมอ | ไม่สนใจ server load จริง | Servers spec เท่ากัน |
| Weighted Round Robin | วนตาม weight ที่กำหนด | รองรับ servers spec ต่างกัน | ต้อง configure weight manual | Servers spec ต่างกัน |
| Least Connections | ส่งไป server ที่ connections น้อยสุด | กระจาย load ตามจริง | ซับซ้อนกว่า round robin | Long-lived connections |
| IP Hash | Hash client IP เลือก server | Client เดิมไป server เดิม | กระจายไม่สม่ำเสมอ | Session persistence |
| Least Response Time | ส่งไป server ที่ response เร็วสุด | Performance ดีที่สุด | ต้อง measure response time | Performance-critical apps |
Health Checks: ตรวจสอบ Server ก่อนส่ง Traffic
Health Check เป็นฟีเจอร์สำคัญของ load balancer ที่ตรวจสอบว่า backend server ยังทำงานปกติหรือไม่ ถ้า server ไม่ตอบ health check จะถูกเอาออกจาก pool ทันที ไม่ส่ง traffic ไปให้
ประเภท Health Check
TCP Health Check ตรวจว่า port เปิดอยู่ไหม ง่ายที่สุด แต่ไม่รู้ว่า application ทำงานปกติหรือเปล่า HTTP Health Check ส่ง HTTP GET ไปยัง URL ที่กำหนด (เช่น /health) ตรวจว่า response code เป็น 200 OK เชื่อถือได้มากกว่า TCP Custom Health Check ตรวจ database connectivity, disk space, memory usage หรือ custom logic ที่ application กำหนด เช่น /health ตรวจว่า connect database ได้ cache ทำงาน message queue accessible
ประเภทของ Load Balancer
Hardware Load Balancer
Hardware LB เป็นอุปกรณ์เฉพาะ เช่น F5 BIG-IP, Citrix NetScaler (Citrix ADC), A10 Networks Thunder ข้อดีคือ performance สูงมาก (handle ล้าน concurrent connections) มี advanced features (SSL offloading, WAF, DDoS protection) มี dedicated support ข้อเสียคือราคาแพงมาก (หลักล้านบาท) ต้อง maintenance hardware เหมาะสำหรับ enterprise ที่ต้องการ performance สูงสุดและ compliance
Software Load Balancer
Software LB รันบน commodity server หรือ VM ตัวอย่างยอดนิยม HAProxy เป็น open-source LB ที่ performance สูงมาก ใช้โดยบริษัทใหญ่ๆ เช่น GitHub, Stack Overflow Nginx เป็นทั้ง web server และ load balancer ยอดนิยม configure ง่าย Envoy เป็น modern proxy ที่ใช้ใน service mesh (Istio) ข้อดีคือฟรี (open-source) ยืดหยุ่น scale ง่าย ข้อเสียคือต้อง manage server เอง
Cloud Load Balancer
Cloud LB เป็น managed service จาก cloud provider AWS ALB/NLB/CLB Application LB (Layer 7), Network LB (Layer 4), Classic LB Azure Load Balancer และ Application Gateway GCP Cloud Load Balancing ทั้ง internal และ external ข้อดีคือ fully managed ไม่ต้อง maintain auto-scale ตาม traffic จ่ายตามใช้ ข้อเสียคือค่าใช้จ่ายสะสมถ้า traffic สูง
SSL/TLS Termination
SSL Termination ที่ load balancer เป็น best practice ที่แนะนำ load balancer จัดการ SSL/TLS encryption/decryption แทน backend servers ลด CPU load บน backend servers (SSL handshake ใช้ CPU เยอะ) จัดการ SSL certificates ที่จุดเดียว ง่ายต่อการ renew traffic ระหว่าง load balancer กับ backend servers อาจเป็น HTTP (ถ้าอยู่ใน network เดียวกัน) หรือ re-encrypt เป็น HTTPS (ถ้าต้องการ end-to-end encryption)
Session Persistence (Sticky Sessions)
บาง application ต้องการให้ client เดิมถูกส่งไป server เดิม ทุกครั้ง เช่น application ที่เก็บ session ใน memory ของ server (ไม่ได้ใช้ shared session store) วิธีทำ session persistence: Cookie-based load balancer แทรก cookie ระบุ server ที่เลือกไว้ IP-based ใช้ client IP เลือก server เดิม (ปัญหาเมื่อ client อยู่หลัง NAT)
อย่างไรก็ตาม best practice คือออกแบบ application ให้เป็น stateless เก็บ session ใน shared store (Redis, Memcached, database) แทน server memory ทำให้ไม่ต้องพึ่ง sticky sessions และ load balancer กระจาย traffic ได้อิสระมากขึ้น
Best Practices สำหรับ Load Balancing
Multiple Load Balancers (HA)
Load Balancer เป็น single point of failure ต้องมี HA เสมอ ใช้ Active/Passive pair ด้วย VRRP (Virtual Router Redundancy Protocol) หรือ keepalived สำหรับ cloud ใช้ managed LB ที่มี HA built-in
Monitor ทุกอย่าง
Monitor metrics สำคัญ: active connections, requests per second, response time, error rate, backend server health ใช้ Prometheus + Grafana หรือ Datadog สร้าง dashboard ตั้ง alert เมื่อ error rate สูงขึ้น, response time นาน, หรือ backend server down
ทิ้งท้าย: Load Balancer เป็นรากฐานของ High Availability
Load Balancer ไม่ใช่แค่กระจาย traffic แต่เป็นรากฐานของ high availability, scalability และ performance ของ application เลือกประเภทที่เหมาะ ตั้ง health checks ที่ดี monitor อย่างต่อเนื่อง และออกแบบ application ให้เป็น stateless เพื่อประสิทธิภาพสูงสุด
อ่านเพิ่มเติมเกี่ยวกับ QoS Network และ VPN ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
