Load Balancing Algorithms: Round Robin, Least Connections, IP Hash เลือกใช้เมื่อไหร่

Load Balancing เป็นเทคนิคสำคัญในการกระจายปริมาณงาน (traffic) ให้กับเซิร์ฟเวอร์หลายตัวในลักษณะ upstream cluster โดยจุดประสงค์คือเพิ่มประสิทธิภาพ (performance), ความพร้อมใช้งาน (availability), และการรับมือต่อปริมาณการเข้าใช้งานจำนวนมาก (scalability) ของระบบ ตัวเลือกอัลกอริทึม Load Balancing ที่ใช้งานได้แตกต่างกันไป ทำให้ความเข้าใจถึงจุดแข็งและข้อจำกัดของแต่ละวิธีมีความสำคัญอย่างยิ่ง

Nginx เป็น web server และ reverse proxy ที่ได้รับความนิยมสูงในการใช้งาน load balancing เนื่องจากมีประสิทธิภาพสูง ความเสถียร และรองรับอัลกอริทึม load balancing หลากหลายแบบ บทความนี้จะอธิบายรายละเอียดของอัลกอริทึมต่างๆ เงื่อนไขที่เหมาะสมต่อการใช้งาน และตัวอย่างการตั้งค่าทางปฏิบัติ

Nginx เป็น Load Balancer

Nginx ทำหน้าที่เป็น reverse proxy ที่รับ request จากไคลเอ็นต์และส่งต่อไปยังเซิร์ฟเวอร์ upstream หลายตัว โดยอัลกอริทึม load balancing จะตัดสินใจว่า request แต่ละตัวควรไปยังเซิร์ฟเวอร์ใด เพื่อให้การกระจายปริมาณงานเป็นไปอย่างเหมาะสม ขั้นตอนพื้นฐานในการตั้งค่า upstream คือ

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

ในตัวอย่างข้างต้น upstream ชื่อ “backend” ประกอบด้วยเซิร์ฟเวอร์ 3 ตัว Nginx จะกระจายการร้องขอไปยังเซิร์ฟเวอร์เหล่านี้ตามอัลกอริทึมที่เลือกไว้

Round Robin – อัลกอริทึมค่าเริ่มต้น

Round Robin คือวิธีการกระจายการร้องขอแบบหมุนเวียน โดยส่งการร้องขอไปยังเซิร์ฟเวอร์แต่ละตัวตามลำดับ และเมื่อถึงเซิร์ฟเวอร์สุดท้าย จะกลับไปยังเซิร์ฟเวอร์แรก

ตัวอย่างการทำงาน:

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1
Request 5 → Server 2

ข้อดี:

เรียบง่าย ใช้งานง่าย
ทำให้การกระจายปริมาณงานสม่ำเสมอ
ไม่ต้องติดตั้งเพิ่มเติม (ค่าตั้งต้น)

ข้อเสีย:

ไม่คำนึงถึง CPU load ของแต่ละเซิร์ฟเวอร์
หากมีเซิร์ฟเวอร์ที่มีประสิทธิภาพต่างกัน อาจไม่มีประสิทธิภาพสูงสุด
ถ้าเซิร์ฟเวอร์ตัวหนึ่งช้า การร้องขอก็จะติด

เมื่อใช้: เมื่อเซิร์ฟเวอร์ทั้งหมดมีความสามารถและพฤติกรรมการทำงานที่คล้ายกัน

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    # Round Robin เป็นค่าตั้งต้น ไม่ต้องระบุ
}

Weighted Round Robin – Round Robin ที่มีน้ำหนัก

Weighted Round Robin ช่วยให้สามารถกำหนดสัดส่วนของการกระจายการร้องขอให้แต่ละเซิร์ฟเวอร์ได้ เมื่อมีเซิร์ฟเวอร์ที่มีสเปค (spec) ต่างกัน

ตัวอย่างการทำงาน: หากตั้ง weight เป็น 3:2:1 จะส่งการร้องขอในอัตราส่วน 3:2:1

Request 1-3 → Server 1
Request 4-5 → Server 2
Request 6 → Server 3
Request 7-9 → Server 1

upstream backend {
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backend3.example.com weight=1;
}

เมื่อใช้: เมื่อมีเซิร์ฟเวอร์ที่มีประสิทธิภาพต่างกัน เช่น บางตัวมี CPU สูงกว่า RAM มากกว่า

Least Connections – เลือกเซิร์ฟเวอร์ที่ว่าง

Least Connections เลือกเซิร์ฟเวอร์ที่มีจำนวนการเชื่อมต่อ (connections) น้อยที่สุดในขณะนั้น วิธีนี้เหมาะกับการใช้งานที่ต้องใช้เวลาในการประมวลผลนาน

ตัวอย่างการทำงาน:

Request 1 → Server 1 (Connections: 1-0-0)
Request 2 → Server 2 (Connections: 1-1-0)
Request 3 → Server 3 (Connections: 1-1-1)
Request 4 → Server 1 (Connections: 2-1-1)
Request 5 → Server 2 (Connections: 2-2-1)
Request 6 → Server 3 (Connections: 2-2-2)

ข้อดี:

ลดเวลารอสำหรับการร้องขอที่นานกว่า
เหมาะกับการสตรีมมิ่ง, upload/download ไฟล์ขนาดใหญ่
ป้องกันการโหลดไม่สมดุล

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

เมื่อใช้: เมื่อมีการร้องขอที่ใช้เวลายาวและเวลาประมวลผลแตกต่างกัน

IP Hash – เลือกเซิร์ฟเวอร์จาก IP ของไคลเอนต์

IP Hash ใช้ IP Address ของไคลเอนต์เพื่อเลือกเซิร์ฟเวอร์ สิ่งนี้ช่วยให้ไคลเอนต์เดียวกันจะเชื่อมต่อกับเซิร์ฟเวอร์เดียวกันเสมอ

ข้อดี:

ไคลเอนต์จะเชื่อมต่อกับเซิร์ฟเวอร์เดียวกันเสมอ (persistence/sticky session)
เหมาะกับการเก็บ session บนเซิร์ฟเวอร์
ช่วยลด session replication complexity

ข้อเสีย:

หากเซิร์ฟเวอร์เสีย ไคลเอนต์ทั้งกลุ่มอาจสูญเสีย session
อาจไม่มีการกระจายปริมาณงานที่สมดุล (uneven distribution)
ไม่ใช้ได้ดีกับ mobile clients ที่อาจเปลี่ยน IP

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

เมื่อใช้: เมื่อจำเป็นต้องรักษา session บนเซิร์ฟเวอร์ หรือต้องการ sticky session

Hash – Hash ตามตัวแปร Custom

Hash ช่วยให้สามารถกำหนดตัวแปร (variable) ใดก็ได้เพื่อใช้ในการเลือกเซิร์ฟเวอร์ เช่น user ID, domain name, เป็นต้น

upstream backend {
    hash $server_name consistent;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

เมื่อใช้: เมื่อต้องการความยืดหยุ่นในการกำหนดเงื่อนไขการเลือกเซิร์ฟเวอร์

Random – สุ่มเลือก

Random เลือกเซิร์ฟเวอร์แบบสุ่ม เรียบง่ายและมีประสิทธิภาพ

upstream backend {
    random;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

ตัวอย่างการตั้งค่า Load Balancing ขั้นสูง

ตัวอย่างการตั้งค่าแบบที่พบได้ทั่วไป:

upstream web_backend {
    # Weight-based load balancing
    server backend1.example.com:8080 weight=5;
    server backend2.example.com:8080 weight=3;
    server backup.example.com:8080 backup;
    
    # Keep-alive connections
    keepalive 32;
}

upstream api_backend {
    # Least connections for long-lived requests
    least_conn;
    server api1.example.com:3000;
    server api2.example.com:3000;
    server api3.example.com:3000;
}

server {
    listen 80;
    server_name example.com;

    # API requests - use least_conn
    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Web content - use weighted round robin
    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

สรุปเปรียบเทียบอัลกอริทึม

อัลกอริทึม	เมื่อใช้	ข้อดี	ข้อเสีย
Round Robin	เซิร์ฟเวอร์เหมือนกัน	ง่าย สมดุล	ไม่สนใจ load
Weighted	เซิร์ฟเวอร์ต่างสเปค	ปรับแต่ง weight ได้	ต้องปรับแต่งเอง
Least Conn	Long-lived requests	ลดเวลารอ	ความเหมาะสมกับเวลาปฏิบัติการ
IP Hash	Session persistence	Sticky session	Risk กับ server failure

สรุป

การเลือกอัลกอริทึม Load Balancing ที่ถูกต้องจึงสำคัญอย่างยิ่งในการสร้างระบบที่มีความพร้อมใช้งานสูง พิจารณาลักษณะของแอปพลิเคชัน ลักษณะของการร้องขอ และเซิร์ฟเวอร์ที่ใช้งาน เพื่อให้ได้ประสิทธิภาพสูงสุด

แนะนำบริการ DE

หากคุณต้องการสร้าง infrastructure ที่มี load balancing และความพร้อมใช้งานสูง DE Cloud VPS เป็นตัวเลือกที่เหมาะสม ด้วยความยืดหยุ่นสูงและสนับสนุนการติดตั้ง Nginx load balancer ได้อย่างเต็มที่