Home » Network Load Balancing: Layer 4 vs Layer 7, Algorithms และ Health Checks
Network Load Balancing: Layer 4 vs Layer 7, Algorithms และ Health Checks
Network Load Balancing: Layer 4 vs Layer 7, Algorithms และ Health Checks
Network Load Balancing กระจาย traffic ไปยัง backend servers หลายตัวเพื่อเพิ่ม availability, scalability และ performance Layer 4 (Transport) load balancing ตัดสินใจจาก IP + Port, Layer 7 (Application) ตัดสินใจจาก HTTP headers, URL paths, cookies Algorithms กำหนดวิธีเลือก server และ Health Checks ตรวจสอบว่า servers ยังทำงานปกติ
Single server มี capacity จำกัด: ถ้า traffic เกินจะช้าหรือล่ม Load balancer แก้ปัญหา: กระจาย requests ไปหลาย servers → scale horizontally, ถ้า server ล่ม → route traffic ไป servers อื่นอัตโนมัติ (high availability) เป็นพื้นฐานของทุก production infrastructure
Layer 4 vs Layer 7
| Feature |
Layer 4 (L4) |
Layer 7 (L7) |
| Decision Based On |
Source/Dest IP, Source/Dest Port, Protocol |
HTTP headers, URL, cookies, hostname, payload |
| Performance |
Very fast (simple header inspection) |
Slower (deep packet inspection) |
| SSL Termination |
ไม่ได้ (pass-through or TCP proxy) |
ได้ (terminate SSL → inspect HTTP → re-encrypt) |
| Content Routing |
ไม่ได้ |
ได้ (route /api → API servers, /images → CDN) |
| Session Persistence |
Source IP hash |
Cookie-based, header-based (more accurate) |
| Connection Handling |
1 connection: client↔LB↔server (TCP proxy) or DSR |
2 connections: client↔LB + LB↔server (HTTP proxy) |
| Use Case |
TCP/UDP services, databases, gaming, high throughput |
HTTP/S web apps, APIs, microservices |
Load Balancing Algorithms
| Algorithm |
วิธีทำงาน |
Use Case |
| Round Robin |
สลับ server ไปเรื่อยๆ (1→2→3→1→2→3…) |
Servers มี capacity เท่ากัน |
| Weighted Round Robin |
Server ที่ weight สูงกว่าได้ requests มากกว่า |
Servers มี capacity ต่างกัน |
| Least Connections |
ส่งไป server ที่มี active connections น้อยที่สุด |
Long-lived connections (WebSocket) |
| Weighted Least Connections |
Least connections + weight factor |
Mixed capacity + long connections |
| IP Hash |
Hash source IP → always same server |
Session persistence (stateful apps) |
| Least Response Time |
ส่งไป server ที่ response time เร็วที่สุด |
Performance-sensitive applications |
| Random |
สุ่มเลือก server |
Large server pools (statistically even) |
| Consistent Hashing |
Hash-ring: minimize redistribution เมื่อ add/remove servers |
Caching layers (minimize cache misses) |
Health Checks
| Type |
วิธีตรวจ |
Detects |
| TCP Check |
TCP connect to port → success = healthy |
Port open, process running |
| HTTP Check |
Send HTTP GET /health → expect 200 OK |
Application responding correctly |
| HTTPS Check |
HTTP check over TLS |
Application + valid SSL certificate |
| Custom Script |
Run custom health check script |
Application-specific health (DB connection, disk space) |
| gRPC Check |
gRPC Health Checking Protocol |
gRPC service health |
Health Check Parameters
| Parameter |
Description |
Typical Value |
| Interval |
เวลาระหว่าง health checks |
5-30 seconds |
| Timeout |
เวลาสูงสุดรอ response |
2-5 seconds |
| Unhealthy Threshold |
จำนวน fails ก่อน mark unhealthy |
2-3 consecutive failures |
| Healthy Threshold |
จำนวน successes ก่อน mark healthy |
2-3 consecutive successes |
| Path (HTTP) |
URL path สำหรับ health check |
/health, /healthz, /status |
| Expected Response |
Expected HTTP status code |
200 OK |
Session Persistence (Sticky Sessions)
| Method |
วิธีทำงาน |
Pros/Cons |
| Source IP |
Hash client IP → same server |
Simple แต่ NAT/proxy ทำให้หลาย users share IP |
| Cookie (LB-inserted) |
LB insert cookie → client sends back → route to same server |
Accurate, works through NAT |
| Cookie (Application) |
Application sets session cookie → LB reads it |
Application-aware, most accurate |
| URL Parameter |
Encode server ID ใน URL |
Works without cookies แต่ ugly URLs |
Load Balancer Products
| Product |
Type |
จุดเด่น |
| NGINX |
Software (L7) |
Open source, high performance, reverse proxy + LB |
| HAProxy |
Software (L4/L7) |
Open source, very high performance, widely used |
| F5 BIG-IP |
Hardware/Virtual (L4/L7) |
Enterprise-grade, iRules scripting, WAF, APM |
| Citrix ADC (NetScaler) |
Hardware/Virtual (L4/L7) |
Enterprise, application delivery, GSLB |
| AWS ALB/NLB |
Cloud (ALB=L7, NLB=L4) |
Managed, auto-scaling, AWS integration |
| Envoy Proxy |
Software (L4/L7) |
Cloud-native, service mesh (Istio), gRPC support |
| Traefik |
Software (L7) |
Cloud-native, auto-discovery (Docker, K8s), Let’s Encrypt |
Best Practices
| Practice |
รายละเอียด |
| Use L7 for web/API |
L7 ให้ content routing, SSL termination, better health checks |
| Use L4 for non-HTTP |
L4 สำหรับ TCP/UDP services (DB, gaming, custom protocols) |
| Always health check |
ทุก backend ต้องมี health check (don’t send traffic to dead servers) |
| Avoid sticky sessions |
Design stateless apps → ไม่ต้อง sticky (better distribution) |
| SSL termination at LB |
Terminate SSL ที่ LB → reduce backend CPU load |
| Connection draining |
เมื่อ remove server → drain existing connections ก่อน (graceful) |
| Monitor LB itself |
LB เป็น single point of failure → deploy HA pair (active-passive/active-active) |
ทิ้งท้าย: Load Balancing = Scale + Availability + Performance
Load Balancing L4: fast, IP+port based (TCP/UDP services), L7: smart, HTTP-aware (web/API) Algorithms: Round Robin (simple), Least Connections (long-lived), IP Hash (sticky) Health Checks: TCP (basic), HTTP /health (application-aware) — always enable Session Persistence: cookie-based (best), source IP (simple but NAT issues) Products: HAProxy/NGINX (open source), F5/Citrix (enterprise), AWS ALB/NLB (cloud) Best practice: stateless apps + L7 + SSL termination + health checks + HA pair
อ่านเพิ่มเติมเกี่ยวกับ QoS DiffServ Queuing และ Network Observability OpenTelemetry ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
