Nginx Load Balancer ต่างจาก Reverse Proxy อย่างไร

Reverse Proxy คือ Nginx รับ Request แล้วส่งต่อไปยัง Backend เพียงเครื่องเดียว ส่วน Load Balancer คือ Reverse Proxy ที่มี upstream หลายเครื่องและมีอัลกอริทึมเลือกว่าจะส่งไปเครื่องไหน ทั้งสองคือฟีเจอร์เดียวกันใน Nginx แต่ต่างที่จำนวน Backend

Nginx Load Balancing ทำบน VPS ราคาเท่าไหร่

Nginx เป็น Open Source ไม่มีค่าลิขสิทธิ์ ต้องการ VPS Linux สำหรับ Load Balancer 1 เครื่อง + Backend อีกอย่างน้อย 2 เครื่อง VPS AsiaGB เริ่มต้น 500 บาท/เดือน

IP Hash กับ Sticky Session ต่างกันอย่างไร

IP Hash คือ Nginx ใช้ IP Address ของ Client เป็น Key Hash เพื่อส่ง Request ไปยัง Backend เดิมเสมอ ผลลัพธ์คล้ายกับ Sticky Session แต่ถ้า Client เปลี่ยน IP (เช่น ใช้ Mobile Data) จะถูกส่งไป Backend ใหม่ Sticky Session ที่แม่นยำกว่าต้องใช้ Cookie-based affinity ซึ่งต้องการ Nginx Plus

Nginx Load Balancer รองรับ HTTPS ได้ไหม

ได้ Nginx สามารถ Terminate SSL/TLS ที่ Load Balancer แล้วส่งต่อเป็น HTTP ภายในไปยัง Backend (SSL Termination) หรือจะส่งเป็น HTTPS ต่อไปถึง Backend ก็ได้ (SSL Passthrough) วิธีแรกนิยมกว่าเพราะลด Overhead ที่ Backend

ตั้งค่า Nginx Load Balancer หลาย Backend บน VPS

เมื่อ Traffic เว็บเพิ่มขึ้นจนเซิร์ฟเวอร์เดียวรับไม่ไหว Load Balancer คือคำตอบ Nginx รองรับฟีเจอร์ Load Balancing แบบ Production-grade ในตัว ไม่ต้องใช้ซอฟต์แวร์เพิ่มเติม บทความนี้จะแนะนำการตั้งค่า Nginx เป็น Load Balancer บน VPS Ubuntu เพื่อกระจาย Request ไปยัง Backend Server หลายเครื่อง

Load Balancing ทำงานอย่างไร

Load Balancer รับ Request จาก Client แล้วส่งต่อไปยัง Backend Server ที่เหมาะสม ช่วยให้ระบบรับ Traffic ได้มากขึ้น ป้องกัน Single Point of Failure และทำ Zero-downtime Deploy ได้

Round-Robin

ส่ง Request สลับกันทุก Server ทีละเที่ยว เหมาะกับ Backend ที่ Spec เท่ากัน

Least Connection

ส่ง Request ไปยัง Server ที่มี Active Connection น้อยที่สุด เหมาะกับ Request ที่ใช้เวลาต่างกัน

IP Hash

ผู้ใช้ IP เดิมถูกส่งไปยัง Backend เดิมเสมอ เหมาะกับแอปที่ต้องการ Session Sticky

สถาปัตยกรรมที่จะตั้งค่า

ในตัวอย่างนี้ VPS เครื่อง Load Balancer (IP: 10.0.0.1) รับ Traffic Port 80/443 แล้วกระจายไปยัง Backend 2 เครื่อง (10.0.0.2 และ 10.0.0.3) ที่รันแอป Port 8080

ติดตั้ง Nginx บน VPS Load Balancer

sudo apt update && sudo apt install -y nginx
sudo systemctl enable nginx

ตั้งค่า upstream และ Load Balancing

สร้างไฟล์ Config ใหม่:

sudo nano /etc/nginx/sites-available/loadbalancer

ใส่ Config ต่อไปนี้ (Round-Robin):

# กำหนดกลุ่ม Backend Server
upstream backend_pool {
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
    # keepalive connections เพิ่ม Performance
    keepalive 32;
}

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

เปลี่ยนเป็น Least Connection

upstream backend_pool {
    least_conn;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

เปลี่ยนเป็น IP Hash (Session Sticky)

upstream backend_pool {
    ip_hash;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

ตั้งค่า Weight สำหรับ Server Spec ต่างกัน

upstream backend_pool {
    server 10.0.0.2:8080 weight=3;  # รับ Traffic 3 ส่วน
    server 10.0.0.3:8080 weight=1;  # รับ Traffic 1 ส่วน
}

เปิด Config และทดสอบ

sudo ln -s /etc/nginx/sites-available/loadbalancer /etc/nginx/sites-enabled/
sudo nginx -t          # ตรวจ syntax
sudo systemctl reload nginx

เข้าใจ Upstream Module และ Directive ที่สำคัญ

ก่อนจะตั้งค่า Load Balancer ให้ทำงานได้ดีใน Production ควรทำความเข้าใจ Directive หลักของ Nginx Upstream Module ก่อน เพื่อให้สามารถปรับแต่งพฤติกรรมให้เหมาะกับ Workload จริงของแต่ละระบบ

server — กำหนด Backend Server พร้อม Port ในกลุ่ม upstream หนึ่งกลุ่มสามารถมีได้หลาย server
weight — น้ำหนักการรับ Traffic เช่น weight=3 คือรับ 3 เท่าของ Server ที่มี weight=1 ใช้เมื่อ Backend มี Spec ไม่เท่ากัน
max_fails — จำนวนครั้งที่ Backend ตอบสนองผิดพลาดก่อนที่ Nginx จะถือว่า Backend นั้นไม่พร้อมให้บริการชั่วคราว ค่าเริ่มต้นคือ 1
fail_timeout — ระยะเวลาที่ Nginx จะหยุดส่ง Request ไปยัง Backend ที่ fail แล้ว (และเป็นช่วงเวลาที่นับ max_fails ด้วย) ค่าเริ่มต้น 10 วินาที
backup — กำหนด Server สำรอง ใช้เฉพาะเมื่อ Server หลักทุกตัวไม่พร้อมให้บริการ เหมาะสำหรับ Failover แบบ Cold Standby
down — ทำเครื่องหมายว่า Server ตัวนี้ไม่ใช้งาน ใช้ระหว่างบำรุงรักษา Nginx จะไม่ส่ง Traffic ไปเลย
keepalive — จำนวน Connection ที่ Nginx เก็บไว้ใน Pool เพื่อใช้ซ้ำกับ Backend ช่วยลด Overhead ของการสร้าง TCP Connection ใหม่ทุกครั้ง

ตัวอย่างการใช้ Directive รวมกันแบบ Production-ready สำหรับระบบที่ต้องการ Failover อัตโนมัติ:

upstream backend_pool {
    server 10.0.0.2:8080 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:8080 backup;    # ใช้เฉพาะเมื่อ 2 เครื่องหลัก down
    keepalive 32;
}

วิธีทดสอบ Load Balancing ให้มั่นใจก่อน Production

หลังตั้งค่าเสร็จควรทดสอบให้แน่ใจว่า Load Balancer กระจาย Traffic ได้จริง และ Health Check ทำงานถูกต้องก่อนจะเปิดให้ Traffic จริงเข้ามา

ทดสอบด้วย curl

ส่ง Request หลายครั้งแล้วดูว่า Response มาจาก Backend ต่างกันหรือไม่ (Backend ต้องส่งชื่อตัวเองกลับมาใน Header หรือ Body เพื่อให้ตรวจสอบได้)

# ส่ง 6 Request ดู Distribution
for i in {1..6}; do
  curl -s http://yourdomain.com/api/ping | grep '"server"'
done

ทดสอบด้วย wrk (Benchmark)

# ต้องติดตั้ง wrk ก่อน: apt install wrk
wrk -t4 -c100 -d30s http://yourdomain.com/

# ดูผลที่ได้: Requests/sec, Latency avg/max, Transfer/sec

จำลองการ Fail ของ Backend

# หยุด Backend เครื่องที่ 2 ชั่วคราว ssh [email protected] 'sudo systemctl stop myapp' # ส่ง Request มาที่ Load Balancer — ควรยัง Response ปกติ curl -v http://yourdomain.com/ # เปิด Backend กลับ ssh [email protected] 'sudo systemctl start myapp'

ถ้า Load Balancer ตั้งค่าถูกต้อง เมื่อ Backend เครื่องหนึ่ง Down ระบบยังต้องตอบสนองได้ปกติโดยส่ง Request ไปยัง Backend ที่เหลือ นี่คือการ Verify High Availability แบบพื้นฐานที่ต้องทำก่อน Go Live ทุกครั้ง

การวางแผนสถาปัตยกรรม Network สำหรับ Load Balancer

ก่อนเริ่มตั้งค่า Nginx ควรวางแผนสถาปัตยกรรม Network ให้รัดกุมก่อน เพราะการออกแบบที่ดีตั้งแต่แรกช่วยลดปัญหาด้าน Security ประสิทธิภาพ และการขยายระบบในอนาคต

รูปแบบที่แนะนำสำหรับ VPS หลายเครื่อง

Load Balancer VPS: เปิด Port 80 และ 443 ให้สาธารณะเท่านั้น ปิด Port อื่นทั้งหมดด้วย ufw หรือ iptables เพื่อลด Attack Surface
Backend VPS: ปิด Port สาธารณะทั้งหมด เปิดเฉพาะ Port แอปพลิเคชัน (เช่น 8080) ให้รับได้จาก IP ของ Load Balancer เท่านั้น ทำให้ Backend ไม่สามารถเข้าถึงได้โดยตรงจาก Internet
Private Network: ถ้า Provider รองรับ Private Network หรือ VLAN ควรใช้สำหรับ Traffic ระหว่าง Load Balancer กับ Backend เพื่อลด Latency และเพิ่มความปลอดภัย

# ตั้งค่า Firewall บน Backend VPS (อนุญาตเฉพาะ LB)
sudo ufw allow from 10.0.0.1 to any port 8080
sudo ufw deny 8080    # ปิด Public access ก่อน แล้วค่อย allow เฉพาะ LB
sudo ufw enable

การแยก Network Traffic ระหว่าง Public (Load Balancer) กับ Private (Backend) เป็นแนวปฏิบัติด้าน Security ที่ควรทำตั้งแต่วันแรก การแก้ไขภายหลังเมื่อระบบมี Traffic แล้วทำได้ยากและเสี่ยงกว่า

การติดตามประสิทธิภาพและ Logging

เมื่อ Load Balancer ทำงานบน Production ควรติดตาม Metrics เหล่านี้อย่างสม่ำเสมอเพื่อให้รู้ว่าระบบทำงานได้ดีแค่ไหนและมีปัญหาที่ไหนก่อนที่ User จะรายงาน

Metrics ที่ต้องติดตาม

Request Rate (req/s): จำนวน Request ต่อวินาทีที่ Load Balancer รับ ถ้าพุ่งขึ้นกะทันหันอาจเป็นสัญญาณของ Traffic Spike หรือการโจมตี
Error Rate (5xx): เปอร์เซ็นต์ของ Request ที่ได้รับ 500-series Error จาก Backend บ่งบอกว่า Backend มีปัญหา
Latency (ms): เวลาเฉลี่ยที่ Request ใช้ตั้งแต่ Load Balancer รับจนได้รับ Response จาก Backend ถ้าเพิ่มขึ้นอาจแปลว่า Backend ทำงานหนักเกินไป
Active Connections: จำนวน Connection ที่เปิดอยู่ในขณะนั้น ช่วยประเมินว่าต้องการ Backend เพิ่มเมื่อไหร่

ตั้งค่า Custom Log Format สำหรับ Load Balancer

# เพิ่มใน http{} block ใน nginx.conf
log_format lb_log '$remote_addr - $upstream_addr [$time_local] '
                  '"$request" $status $body_bytes_sent '
                  '"$http_referer" "$http_user_agent" '
                  'rt=$request_time uct=$upstream_connect_time '
                  'uht=$upstream_header_time urt=$upstream_response_time';

access_log /var/log/nginx/lb_access.log lb_log;
error_log  /var/log/nginx/lb_error.log warn;

ฟิลด์ $upstream_addr บอกว่า Request นั้นถูกส่งไปยัง Backend เครื่องไหน ช่วยให้ Debug ปัญหาเฉพาะ Backend ได้ง่ายขึ้นมาก และ $upstream_response_time บอก Latency จริงของ Backend นั้นๆ

เพิ่ม Timeout และ Buffer สำหรับ Production

การปรับค่า Timeout และ Buffer ช่วยให้ Load Balancer รับมือกับ Backend ที่ตอบสนองช้าหรือ Response ขนาดใหญ่ได้ดีขึ้น ควรตั้งค่าเหล่านี้ในส่วน location / หรือในบล็อก server หลัก

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeout settings
        proxy_connect_timeout 5s;
        proxy_send_timeout    60s;
        proxy_read_timeout    60s;

        # Buffer settings — ปรับตามขนาด Response
        proxy_buffering on;
        proxy_buffer_size       16k;
        proxy_buffers           8 16k;
        proxy_busy_buffers_size 32k;
    }
}

หากแอปส่ง Response ขนาดเล็กและต้องการ Latency ต่ำ (เช่น API) สามารถปิด Buffering ได้ด้วย proxy_buffering off; แต่จะเพิ่มภาระให้ Worker Process มากขึ้น

ตั้งค่า SSL/TLS Termination บน Load Balancer

วิธีที่นิยมที่สุดสำหรับ Production คือให้ Load Balancer รับ HTTPS จาก Client แล้วส่งต่อเป็น HTTP ภายใน (SSL Termination) — Backend ไม่ต้องจัดการ Certificate เอง ลด Overhead และทำให้ดูแลง่ายขึ้น

# ใช้ Certbot สร้าง Certificate ก่อน
sudo certbot --nginx -d yourdomain.com

# จากนั้น Config HTTPS block
server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

ตั้งค่า Rate Limiting เพื่อป้องกัน DDoS

Load Balancer เป็นจุดรับ Traffic ทั้งหมด จึงเหมาะมากสำหรับตั้งค่า Rate Limiting เพื่อกัน Request ที่มากเกินไปจาก IP เดียวกัน ป้องกัน DDoS เบื้องต้นและ Brute-force Attack

# กำหนด Zone ใน http{} block (nginx.conf)
http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;
    ...
}

# ใช้งานใน location block
location /api/ {
    limit_req zone=api_limit burst=10 nodelay;
    limit_req_status 429;
    proxy_pass http://backend_pool;
}

location / {
    limit_req zone=api_limit burst=50 nodelay;
    proxy_pass http://backend_pool;
}

ค่า rate=30r/m หมายถึงอนุญาต 30 Request ต่อนาทีต่อ IP ส่วน burst=10 คือจำนวน Request ที่รับได้เกิน Rate ชั่วคราวก่อน Return 429 Too Many Requests

ค่า	เหมาะกับ	หมายเหตุ
10r/s	API ทั่วไป	เข้มงวดปานกลาง
1r/s	Login endpoint	เข้มงวด กัน Brute-force
100r/s	Static files	หลวมสำหรับไฟล์สาธารณะ

ตั้งค่า Health Check (Passive)

Nginx Open Source รองรับ Passive Health Check โดยอัตโนมัติ — ถ้า Backend ตอบสนองด้วย Error ติดต่อกัน Nginx จะ Remove ออกชั่วคราว:

upstream backend_pool {
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 max_fails=3 fail_timeout=30s;
}

Nginx Plus (Commercial): รองรับ Active Health Check (ตรวจสอบ Backend ทุก N วินาที) ถ้าต้องการ Active Health Check แบบ Open Source ให้ใช้ HAProxy หรือ Nginx + Lua Module แทน

สรุปและขั้นตอนต่อไปหลังจาก Load Balancer ทำงาน

เมื่อ Nginx Load Balancer ทำงานได้แล้วบน VPS ขั้นตอนต่อไปที่ควรทำเพื่อให้ระบบพร้อมสำหรับ Production เต็มรูปแบบมีดังนี้

ตั้งค่า SSL/TLS: ใช้ Let's Encrypt + Certbot เพื่อรับ Certificate ฟรีและ Auto-renew ทุก 90 วัน ทำให้ทุก HTTP Request ถูก Redirect เป็น HTTPS อัตโนมัติ
ตั้งค่า Monitoring: ใช้ Uptime Kuma หรือ Prometheus + Grafana ติดตาม Uptime และ Latency ของทั้ง Load Balancer และ Backend แต่ละเครื่อง
ตั้งค่า Log Rotation: ป้องกัน Access Log เต็ม Disk โดยตั้งค่า logrotate ให้หมุน Log ทุกวันและเก็บไว้ 30 วัน
ทดสอบ Failover: ปิด Backend ทีละเครื่องแล้วตรวจสอบว่า Load Balancer ยังรับ Traffic ได้ปกติ ทำทุกครั้งหลังอัพเดต Config
วาง CI/CD Pipeline: ใช้ Ansible หรือ Fabric Deploy Code ไปยัง Backend ทีละเครื่องแบบ Rolling Update โดยไม่ต้อง Downtime

Nginx Load Balancer บน VPS เป็นรากฐานสำคัญของระบบ High Availability ที่คุ้มค่ามาก เพราะซอฟต์แวร์เป็น Open Source ไม่มีค่าลิขสิทธิ์ และรองรับ Traffic ได้สูงมากด้วย Hardware ราคาไม่แพง VPS AsiaGB ที่มี Full Root Access ช่วยให้ตั้งค่า Nginx ได้เต็มรูปแบบโดยไม่มีข้อจำกัดจาก Hosting Provider

ตรวจสอบสถานะ Load Balancer

sudo nginx -t && sudo systemctl status nginx
# ดู Access Log แบบ Real-time
sudo tail -f /var/log/nginx/access.log

VPS สำหรับ High Traffic มีพร้อมที่ AsiaGB

VPS AsiaGB รองรับ Linux Ubuntu/Debian พร้อม Root Access ตั้งค่า Nginx Load Balancer ได้เต็มรูปแบบ เริ่มต้น 500 บาท/เดือน

ดูแพ็กเกจ VPS

ตั้งค่า Nginx เป็น Load Balancer หลาย Backend บน VPS