สรุปรูปแบบ ของ Load balancer แต่ละแบบ ข้อดีข้อเสีย และตัวอย่าง use case ที่เหมาะสม

ก่อนอื่น เราจะแยก ออกเป็น 3 ประเภท

  1. Static Load Balancing Algorithms
  2. Dynamic Load Balancing Algorithms
  3. Specialized Algorithms

Static Load Balancing Algorithms

อัลกอริทึมที่ใช้เงื่อนไขคงที่ ในการกระจาย traffic โดยไม่คำนึงถึงสถานะปัจจุบันของ server เป็นการตัดสินใจล่วงหน้าตามเงื่อนไขที่กำหนดไว้แล้ว

ลักษณะเด่น คือ

  • Implementation ง่าย
  • Overhead ต่ำ
  • Predictable behavior
  • ไม่ต้องติดตาม server state
  • Performance เสถียร

Round Robin

เป็นการเลือก server ตามลำดับ 1 → 2 → 3 → 1 → 2 → 3...

ตัวอย่าง:

Request 1 → Server A
Request 2 → Server B  
Request 3 → Server C
Request 4 → Server A (เริ่มรอบใหม่)
Request 5 → Server B

ตัวอย่าง Round Robin

ข้อดี:

  • เข้าใจง่าย implementation ไม่ซับซ้อน
  • กระจายภาระงานแบบเท่าๆ กัน
  • Overhead ต่ำ ไม่ต้องติดตามสถานะ server

ข้อเสีย:

  • ไม่คำนึงถึงความสามารถของ server แต่ละตัว
  • ไม่เหมาะกับ server ที่มี spec ต่างกัน
  • อาจทำให้บาง server รับภาระหนักเกินไป

ประสิทธิภาพ:

ดี สำหรับ server ที่มี spec เท่ากัน หรือพวก Static websites

Use Case:

Web applications ที่มี server เหมือนกัน, Static content serving

Weighted Round Robin

เหมือน Round Robin แต่ server ที่มี weight สูงกว่าจะได้รับ request มากกว่า

ตัวอย่าง: (Server A=3, Server B=2, Server C=1)

Request 1-3 → Server A (3 ครั้ง)
Request 4-5 → Server B (2 ครั้ง)
Request 6   → Server C (1 ครั้ง)
Request 7-9 → Server A (เริ่มรอบใหม่)

ตัวอย่าง Weighted Round Robin

ข้อดี:

  • คำนึงถึงความแตกต่างของ server capacity
  • ยืดหยุ่นกว่า Round Robin ธรรมดา
  • ยังคงความเรียบง่าย

ข้อเสีย:

  • ต้องกำหนด weight ล่วงหน้า
  • ไม่ปรับตัวตาม real-time load
  • การตั้งค่า weight ผิดอาจทำให้ไม่สมดุล

ประสิทธิภาพ:

ดีมาก เมื่อรู้ capacity ของแต่ละ server

Use Case:

Server ที่มี spec ต่างกัน หรือมีการใช้งานแบบ Mixed hardware รวมถึงงาน migrate ระหว่าง server รุ่นเก่าไปรุ่นใหม่

Least Connections

เป็นการส่ง request ไปยัง server ที่มี active connections น้อยที่สุด

ตัวอย่าง:

Server A: 5 connections
Server B: 3 connections ← เลือกตัวนี้
Server C: 7 connections

หลังส่ง request:
Server A: 5 connections
Server B: 4 connections
Server C: 7 connections

ตัวอย่าง Least Connections

ข้อดี:

  • ปรับตัวตาม real-time load ได้
  • เหมาะกับ applications ที่มี session ยาว
  • กระจายภาระดีกว่า Round Robin

ข้อเสีย:

  • Overhead สูงกว่าเพราะต้องติดตาม connections
  • ไม่เหมาะกับ short-lived connections
  • อาจไม่สะท้อน actual server load ได้ถูกต้อง

ประสิทธิภาพ:

ดี สำหรับ long-lived connections

Use Case:

Database connections, WebSocket applications, FTP servers

Weighted Least Connections

เป็นการรวมกันระหว่าง Least Connections และ Weight

ตัวอย่าง:

# สูตรการคำนวณ
Score = Active Connections / Weight
เลือก server ที่มี Score ต่ำสุด

# ตัวอย่าง
Server A: 6 connections, weight=3 → Score = 6/3 = 2
Server B: 4 connections, weight=2 → Score = 4/2 = 2  
Server C: 2 connections, weight=1 → Score = 2/1 = 2
(ในกรณีนี้เท่ากันหมด อาจเลือกแบบ round robin)

ตัวอย่าง Weighted Least Connections

ข้อดี:

  • รวมประโยชน์ของ weight และ connection tracking
  • ยืดหยุ่นสำหรับ heterogeneous environments
  • ปรับตัวได้ดีกว่า Weighted Round Robin

ข้อเสีย:

  • Complexity สูง
  • Overhead มากสุดในกลุ่ม static algorithms
  • ยังคงต้องกำหนด weight manually

ประสิทธิภาพ:

เยี่ยม สำหรับ mixed environments

Use Case:

Enterprise applications, Mixed cloud-on-premise setups

IP Hash

ใช้ hash function กับ IP address ของ client

ตัวอย่าง:

# function
def ip_hash(client_ip, server_count):
    hash_value = hash(client_ip) % server_count
    return hash_value

# ตัวอย่าง
Client IP: 192.168.1.100 → hash() → Server 2
Client IP: 10.0.0.50    → hash() → Server 1
Client IP: 172.16.1.25  → hash() → Server 0

# Client เดิมจะไปยัง server เดิมเสมอ

ตัวอย่าง IP Hash

ข้อดี:

  • Session affinity โดยอัตโนมัติ
  • Consistent routing สำหรับ same client
  • ช่วย cache locality

ข้อเสีย:

  • การกระจายอาจไม่เท่ากัน (hotspot clients)
  • ยากที่จะ scale dynamically
  • ปัญหาเมื่อ client อยู่หลัง NAT

ประสิทธิภาพ:

ดีสำหรับ applications ที่ต้องการ session persistence

Use Case:

Shopping carts, User sessions, Applications ที่ต้องการ session affinity

URL Hash

ใช้ hash function กับ URL path

/api/users    → hash() → Server A
/api/products → hash() → Server B  
/api/orders   → hash() → Server C
/static/css   → hash() → Server A

# URL เดิมจะไปยัง server เดิมเสมอ (ดีสำหรับ caching)

ตัวอย่าง URL Hash

ข้อดี:

  • Cache efficiency สูงมาก
  • เหมาะกับ content-based routing
  • Predictable routing patterns

ข้อเสีย:

  • การกระจายขึ้นกับ URL patterns
  • ไม่เหมาะกับ dynamic content
  • อาจเกิด hotspots ใน popular URLs

ประสิทธิภาพ:

เยี่ยม สำหรับ static content

Use Case:

CDN, Static file serving, API caching

Random

เลือก server แบบสุ่ม ตัวนี้ไม่มีอะไรมาก สุ่มล้วนๆ

ตัวอย่าง:

Request 1 → Server B (random)
Request 2 → Server A (random)
Request 3 → Server B (random)
Request 4 → Server C (random)

ตัวอย่าง Random

Use Case:

Simple applications, Testing environments

Dynamic Load Balancing Algorithms

อัลกอริทึมที่ปรับตัวตาม real-time metrics ของ server เช่น CPU, Memory, Response Time เป็นการ Monitor server และ ปรับการกระจาย traffic แบบ real-time

ลักษณะเด่น คือ

  • ปรับตัวตาม real-time conditions
  • Optimize performance อัตโนมัติ
  • Handle varying workloads ได้ดี
  • ป้องกัน server overload
  • Better resource utilization

Least Response Time

ติดตาม response time และ เลือก server ที่เร็วที่สุด

ตัวอย่าง:

Server A: Avg 100ms, 5 connections
Server B: Avg 150ms, 3 connections  
Server C: Avg 80ms, 8 connections ← เลือกตัวนี้ (เร็วที่สุด)

ตัวอย่าง Least Response Time

ข้อดี:

  • Real-time performance optimization
  • รับรู้ได้ถึง server health และ network latency
  • Performance ดีที่สุดสำหรับ end users

ข้อเสีย:

  • Overhead สูงมากเพราะต้อง monitor continuously
  • Complexity ในการ implement
  • อาจไม่เสถียรใน high-traffic periods

ประสิทธิภาพ:

เยี่ยม แต่ต้องแลกกับ overhead

Use Case:

High-performance APIs, Real-time applications, Gaming servers

Resource-Based

ตัดสินใจตาม CPU, Memory, Disk I/O

ตัวอย่าง:

Server A: CPU 80%, Memory 60% → Load Score = 70%
Server B: CPU 45%, Memory 30% → Load Score = 37.5% ← เลือก
Server C: CPU 90%, Memory 85% → Load Score = 87.5%

ตัวอย่าง Resource-Based

ข้อดี:

  • รู้สถานะจริงของ server resources
  • ป้องกัน server overload ได้ดี
  • Optimize resource utilization

ข้อเสีย:

  • ต้องการ monitoring infrastructure
  • Network overhead สูง
  • Complexity ในการตั้งค่า thresholds

ประสิทธิภาพ:

ดีมาก สำหรับ resource-intensive applications

Use Case:

Data processing, Machine learning workloads, Database clusters

Adaptive/Machine Learning

เรียนรู้จาก pattern และ ปรับตัวอัตโนมัติ

System เรียนรู้ว่า:
- เช้า 8-10 โมง: Server A performance ดีที่สุด
- บ่าย 2-4 โมง: Server B รับภาระได้มากสุด  
- ค่ำ 6-8 โมง: กระจายเท่าๆ กันดีที่สุด

→ ปรับ algorithm อัตโนมัติตามเวลา

ข้อดี:

  • ปรับตัวอัตโนมัติตาม conditions
  • Performance optimization ต่อเนื่อง
  • รองรับ changing workloads ได้ดี

ข้อเสีย:

  • ซับซ้อนมากในการ implement
  • ต้องการ machine learning capabilities
  • อาจมี learning period ที่ performance ไม่ดี

ประสิทธิภาพ:

เยี่ยม ในระยะยาว

Use Case:

Cloud applications, Microservices, Variable workload patterns

Specialized Algorithms

อัลกอริทึมที่ออกแบบเพื่อแก้ปัญหาเฉพาะเจาะจง เช่น Geographic routing, Session affinity เป็นการ Focus ที่ requirements พิเศษ มากกว่า general load distribution

ลักษณะเด่น คือ

  • แก้ปัญหาเฉพาะเจาะจง
  • รองรับ business requirements
  • High availability focus
  • Compliance และ regulations
  • User experience optimization

Geographic

เลือกตาม location ของ client

ตัวอย่าง:

Client จาก Bangkok    → Asia-Pacific Server
Client จาก New York   → US-East Server  
Client จาก London     → Europe Server
Client จาก Sydney     → Asia-Pacific Server

ตัวอย่าง Geographic

ข้อดี:

  • Minimize latency สำหรับ global users
  • Comply กับ data residency requirements
  • Better user experience

ข้อเสีย:

  • ซับซ้อนในการ setup
  • อาจไม่สมดุลใน traffic distribution
  • ต้อง maintain geographic data

ประสิทธิภาพ:

ดี สำหรับ global applications

Use Case:

Global websites, CDN, Multi-region deployments, Compliance requirements

Health-Based

ส่งไปแค่ server ที่ "สุขภาพดี"

ตัวอย่าง:

Server A: ✅ Healthy (response < 1sec)
Server B: ❌ Unhealthy (timeout)
Server C: ✅ Healthy  

→ ส่ง traffic ไปแค่ Server A และ C

ข้อดี:

  • High availability
  • Automatic failover
  • ป้องกัน traffic ไปยัง failed servers

ข้อเสีย:

  • ต้องการ health check infrastructure
  • อาจมี false positives/negatives
  • Overhead จาก health monitoring

ประสิทธิภาพ:

สำคัญ สำหรับ mission-critical systems

Use Case:

Financial systems, Healthcare applications, E-commerce

Session Affinity (Sticky Sessions)

เป็นเทคนิคที่ทำให้ client เดิมไปยัง server เดิมเสมอ ตลอดระยะเวลา session นั้น

ข้อดี:

  • รักษา session state
  • เหมาะกับ stateful applications
  • ลด complexity ในการ sync data

ข้อเสีย:

  • ไม่สามารถ distribute อย่างเท่าเทียม
  • Single point of failure per session
  • Scaling ยาก

ประสิทธิภาพ:

ดี สำหรับ stateful apps แต่แย่สำหรับ scalability

Use Case:

Legacy applications, Session-based authentication, Stateful web apps

การเลือกใช้ในชีวิตจริง

เลือกตามลักษณะหรือขนาดของโปรเจค

เริ่มต้นโปรเจค → Static

Round Robin → Weighted Round Robin → IP Hash

Scale Up → Dynamic

Least Response Time → Resource-Based → Adaptive

Requirements พิเศษ → Specialized

Geographic → Session Affinity → Health-Based

หรือจะเลือกใช้อีกแบบ

สำหรับ beginners

Round Robin หรือ Weighted Round Robin

สำหรับ high performance

Least Response Time หรือ Adaptive

สำหรับ global scale

Geographic + Health-Based

สำหรับ legacy systems

Session Affinity + Health-Based

สำหรับ modern cloud apps

Adaptive หรือ Resource-Based