Home » Load Balancing: L4 vs L7, HAProxy, NGINX, F5, GSLB, Health Checks และ Session Persistence
Load Balancing: L4 vs L7, HAProxy, NGINX, F5, GSLB, Health Checks และ Session Persistence
Load Balancing: L4 vs L7, HAProxy, NGINX, F5, GSLB, Health Checks และ Session Persistence
Load Balancing กระจาย traffic ไปยัง servers หลายตัวเพื่อ performance และ availability L4 Load Balancing ทำงานที่ transport layer (TCP/UDP), L7 ทำงานที่ application layer (HTTP/HTTPS), HAProxy เป็น open-source high-performance proxy, NGINX เป็น web server + reverse proxy, F5 เป็น enterprise-grade ADC, GSLB กระจาย traffic ข้าม data centers, Health Checks ตรวจสอบสุขภาพ backend และ Session Persistence ให้ user กลับไป server เดิม
Load balancing เป็น หัวใจของ high-availability architecture: ถ้าไม่มี load balancer → single server = single point of failure, limited capacity, no horizontal scaling Modern web applications ทุกอัน (Google, Netflix, Facebook) ใช้ load balancers หลายชั้น: DNS-based GSLB → L4 load balancer (high throughput) → L7 load balancer (smart routing) → backend servers
L4 vs L7 Load Balancing
| Feature |
L4 (Transport) |
L7 (Application) |
| Layer |
TCP/UDP — ดู IP + port เท่านั้น |
HTTP/HTTPS — ดู URL, headers, cookies, content |
| Speed |
Very fast (no content inspection) |
Slower (must parse HTTP/TLS) |
| Routing |
Round-robin, least-connections, hash |
URL path, host header, cookie, header-based routing |
| TLS |
TCP passthrough (no termination) |
TLS termination → inspect → re-encrypt or plain HTTP to backend |
| Use Case |
High throughput, non-HTTP protocols (DB, SMTP, gaming) |
Web apps, API gateway, microservices, content-based routing |
| Example |
AWS NLB, LVS, HAProxy (TCP mode) |
AWS ALB, NGINX, HAProxy (HTTP mode), Envoy |
Load Balancing Algorithms
| Algorithm |
How |
Best For |
| Round Robin |
Rotate through servers sequentially (A → B → C → A) |
Equal-capacity servers, stateless apps |
| Weighted Round Robin |
Round robin but more requests to higher-weight servers |
Different capacity servers (8-core vs 4-core) |
| Least Connections |
Send to server with fewest active connections |
Long-lived connections, varying request duration |
| IP Hash |
Hash source IP → always same server |
Simple session persistence without cookies |
| Least Response Time |
Send to fastest responding server |
Performance-critical apps |
| Random |
Random server selection |
Large server pools (statistically even) |
| Consistent Hashing |
Hash ring → minimal disruption when adding/removing servers |
Caching layers, distributed systems |
HAProxy
| Feature |
รายละเอียด |
| คืออะไร |
Open-source high-performance TCP/HTTP load balancer and proxy — C-based, extremely fast |
| Performance |
Handles millions of connections, sub-ms latency, minimal resource usage |
| Modes |
TCP mode (L4) and HTTP mode (L7) — flexible configuration |
| ACLs |
Powerful content switching: route based on URL, headers, cookies, query strings |
| Stats |
Built-in statistics dashboard: connections, response times, error rates, backend status |
| SSL |
TLS termination, SNI-based routing, OCSP stapling, HTTP/2 |
| Used By |
GitHub, Stack Overflow, Reddit, Tumblr, Airbnb |
NGINX
| Feature |
รายละเอียด |
| คืออะไร |
Web server + reverse proxy + load balancer — event-driven, non-blocking I/O |
| Market Share |
#1 web server (34%+ of internet), used by most high-traffic sites |
| Load Balancing |
Round robin, least_conn, ip_hash, random — upstream blocks in config |
| Reverse Proxy |
Terminate TLS, cache static content, compress, add headers, rewrite URLs |
| Plus (Commercial) |
Active health checks, session persistence, JWT validation, API gateway, dynamic config |
| Ingress |
NGINX Ingress Controller: standard Kubernetes ingress for routing traffic to pods |
| vs HAProxy |
NGINX = web server + LB (versatile) | HAProxy = pure LB (better for complex LB scenarios) |
Health Checks
| Type |
How |
Depth |
| TCP Check |
Open TCP connection to port → success if connection established |
Basic: confirms port is open (not that app works) |
| HTTP Check |
Send HTTP request → check status code (200 OK) |
Medium: confirms web server responds |
| Content Check |
Send HTTP request → check response body contains expected string |
Deep: confirms app returns correct content |
| Script/Custom |
Run custom script → check database, queue, dependencies |
Deepest: confirms entire stack is healthy |
| Passive |
Monitor real traffic → mark server unhealthy if errors exceed threshold |
Real-world: based on actual user traffic |
Session Persistence
| Method |
How |
Trade-off |
| Source IP |
Hash client IP → same server |
Breaks with NAT/proxy (many users = same IP) |
| Cookie-Based |
LB inserts cookie with server ID → client sends back → LB routes to same server |
Best: works through NAT, client-side affinity |
| Application Cookie |
Use existing app cookie (JSESSIONID, PHPSESSID) for routing |
App-aware but requires cookie inspection |
| URL Parameter |
Append server ID to URL query string |
Visible in URL, works without cookies |
| Best Practice |
Design stateless apps → no session persistence needed → use external session store (Redis) |
Stateless = best scalability, no persistence headaches |
GSLB (Global Server Load Balancing)
| Feature |
รายละเอียด |
| คืออะไร |
Distribute traffic across multiple data centers/regions — DNS-based or anycast |
| DNS-Based |
Return different IPs based on client location, server health, load |
| Anycast |
Same IP announced from multiple locations → BGP routes to nearest |
| Geo-Routing |
Route users to nearest DC: Asia → Singapore DC, Europe → Frankfurt DC |
| Failover |
If DC1 fails → DNS returns DC2 IP → automatic failover |
| Providers |
Cloudflare, AWS Route 53, F5 DNS, Citrix ADC, Akamai GTM |
ทิ้งท้าย: Load Balancing = Foundation of Scalable Architecture
Load Balancing L4 vs L7: L4 (TCP/UDP, fast, no inspection) vs L7 (HTTP, content-based routing, TLS termination) Algorithms: round robin, weighted, least connections, IP hash, consistent hashing HAProxy: open-source, C-based, millions of connections, powerful ACLs — pure LB champion NGINX: web server + reverse proxy + LB, #1 web server, Kubernetes ingress controller Health Checks: TCP (basic) → HTTP (medium) → content (deep) → script (deepest) → passive (real traffic) Session Persistence: cookie-based (best), source IP (simple), best practice = stateless apps + Redis GSLB: cross-DC distribution via DNS or anycast — geo-routing, failover, multi-region Key: design stateless + horizontal scaling + proper health checks = reliable, scalable infrastructure
อ่านเพิ่มเติมเกี่ยวกับ Data Center Networking Spine-Leaf VXLAN Fabric และ Cloud Networking VPC Subnet Security Group ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
