Load Balancer คืออะไร? สอนทำ High Availability และ Load Balancing สำหรับระบบองค์กร 2026

บทนำ: ทำไม Load Balancing และ High Availability ถึงสำคัญ?

ในยุคที่ธุรกิจต้องพึ่งพาระบบ IT เป็นหัวใจหลัก ไม่ว่าจะเป็นเว็บไซต์ขายของออนไลน์ ระบบ ERP ภายในองค์กร หรือแอปพลิเคชันที่ให้บริการลูกค้าตลอด 24 ชั่วโมง การที่ระบบล่มแม้เพียงไม่กี่นาทีก็สามารถสร้างความเสียหายมหาศาลได้ ทั้งในแง่รายได้ที่สูญเสียไป ชื่อเสียงที่เสียหาย และความพึงพอใจของลูกค้าที่ลดลง

High Availability (HA) คือแนวคิดในการออกแบบระบบให้สามารถทำงานได้อย่างต่อเนื่องโดยมี downtime น้อยที่สุด วัดเป็น “nines” เช่น 99.99% uptime (เรียกว่า “four nines”) หมายถึงระบบล่มได้ไม่เกิน 52.6 นาทีต่อปี ส่วน Load Balancing คือเทคนิคการกระจายภาระงาน (traffic/requests) ไปยัง server หลายตัวเพื่อให้ไม่มี server ตัวใดตัวหนึ่งรับภาระหนักเกินไป

บทความนี้จะพาคุณเรียนรู้ทุกอย่างเกี่ยวกับ Load Balancing และ High Availability ตั้งแต่หลักการพื้นฐาน อัลกอริทึมการกระจายภาระ การติดตั้ง HAProxy และ Nginx ไปจนถึงเทคโนโลยี clustering ด้วย Keepalived, Pacemaker/Corosync และ cloud load balancers บริการต่างๆ เหมาะสำหรับ System Admin, DevOps Engineer และผู้ที่ต้องการออกแบบระบบที่มีความเสถียรสูง

ส่วนที่ 1: Load Balancing คืออะไร?

Load Balancer (LB) คืออุปกรณ์หรือซอฟต์แวร์ที่ทำหน้าที่เป็นตัวกลาง รับ request จากผู้ใช้แล้วกระจายไปยัง backend server หลายตัว (เรียกว่า server pool หรือ server farm) โดยมีเป้าหมายหลักคือ:

• กระจายภาระงาน — ไม่ให้ server ตัวใดตัวหนึ่งรับ load หนักเกินไป
• เพิ่มความพร้อมใช้งาน (Availability) — หาก server ตัวหนึ่งล่ม LB จะหยุดส่ง traffic ไปยัง server นั้นและส่งไปยังตัวที่ยังทำงานอยู่แทน
• รองรับการขยายตัว (Scalability) — เพิ่ม server เข้ามาใน pool ได้ง่ายเมื่อ traffic เพิ่มขึ้น
• เพิ่มประสิทธิภาพ — ลดเวลา response และเพิ่ม throughput ของระบบโดยรวม

1.1 Load Balancing Algorithms (อัลกอริทึมการกระจายภาระ)

วิธีที่ Load Balancer เลือกส่ง request ไปยัง server ตัวไหนนั้นขึ้นอยู่กับอัลกอริทึมที่ตั้งค่าไว้ ต่อไปนี้คืออัลกอริทึมที่พบบ่อยที่สุด:

1) Round Robin

กระจาย request ไปยัง server แต่ละตัวตามลำดับวนรอบ เช่น request แรกไป server 1, request ที่สองไป server 2, request ที่สามไป server 3 แล้ววนกลับมา server 1 ใหม่ เป็นอัลกอริทึมที่ง่ายที่สุดและเป็นค่าเริ่มต้นของ load balancer ส่วนใหญ่

ข้อดี: ง่าย, ใช้ทรัพยากรน้อย | ข้อเสีย: ไม่คำนึงถึงภาระจริงของแต่ละ server

2) Weighted Round Robin

คล้าย Round Robin แต่กำหนดน้ำหนัก (weight) ให้แต่ละ server ตามขีดความสามารถ เช่น server ที่แรงกว่ามี weight สูงกว่าจะได้รับ request มากกว่า ตัวอย่าง: server A (weight 3) จะได้ request 3 ครั้ง ก่อนที่ server B (weight 1) จะได้ 1 ครั้ง

3) Least Connections

ส่ง request ไปยัง server ที่มี active connections น้อยที่สุด ณ ขณะนั้น เหมาะกับกรณีที่แต่ละ request ใช้เวลาประมวลผลไม่เท่ากัน เช่น บาง request ใช้เวลานานในการ query database

ข้อดี: กระจายภาระได้ดีกว่า Round Robin ในกรณี request มีเวลาประมวลผลต่างกัน

4) Weighted Least Connections

รวม Least Connections กับ weight เข้าด้วยกัน พิจารณาทั้งจำนวน connections ปัจจุบันและขีดความสามารถของ server

5) IP Hash

ใช้ IP address ของ client ในการคำนวณ hash เพื่อกำหนดว่าจะส่ง request ไปยัง server ตัวไหน ทำให้ client เดิมจะถูกส่งไปยัง server ตัวเดิมเสมอ (ตราบใดที่ server นั้นยังทำงานอยู่) เหมาะกับแอปพลิเคชันที่ต้องการ session persistence โดยไม่ต้องใช้ sticky sessions

6) Least Response Time

ส่ง request ไปยัง server ที่มี response time เร็วที่สุดและมี active connections น้อยที่สุด เป็นอัลกอริทึมที่ฉลาดที่สุดแต่ต้องการการ monitor ต่อเนื่อง

7) Random

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

1.2 Layer 4 vs Layer 7 Load Balancing

Load Balancer สามารถทำงานได้ที่ 2 ระดับหลักของ OSI Model:

ตัวอย่าง Layer 7 routing: Load Balancer สามารถส่ง request ที่มี URL เริ่มต้นด้วย /api/ ไปยังกลุ่ม API servers, request ที่เป็น /images/ ไปยัง CDN, และ request อื่นๆ ไปยัง web servers ปกติ

1.3 Hardware vs Software Load Balancer

Hardware Load Balancer:

• เป็นอุปกรณ์เฉพาะทาง (appliance) เช่น F5 BIG-IP, Citrix ADC (NetScaler), A10 Networks
• ประสิทธิภาพสูงมาก สามารถรองรับ connections นับล้านต่อวินาที
• มี ASIC/FPGA สำหรับ SSL acceleration
• ราคาสูง (หลักแสนถึงหลักล้านบาท) และต้องมี license รายปี
• เหมาะสำหรับองค์กรขนาดใหญ่ที่ต้องการประสิทธิภาพสูงสุด

Software Load Balancer:

• ติดตั้งบน commodity hardware หรือ virtual machine
• เช่น HAProxy, Nginx, Envoy, Traefik, Apache httpd (mod_proxy_balancer)
• ยืดหยุ่นสูง ปรับแต่งได้ตามต้องการ
• ส่วนใหญ่เป็น open-source ฟรี
• เหมาะสำหรับ SME, startup และ cloud-native applications

ในปัจจุบัน software load balancer ได้รับความนิยมมากขึ้นเรื่อยๆ เพราะประสิทธิภาพของ CPU สมัยใหม่สูงพอที่จะรองรับ traffic ระดับสูงได้ และสามารถ scale out ด้วยการเพิ่ม VM/container ได้ง่าย

ส่วนที่ 2: HAProxy — ติดตั้งและตั้งค่า Load Balancer

HAProxy (High Availability Proxy) เป็น software load balancer ที่ได้รับความนิยมสูงสุดในโลก open-source ใช้งานในองค์กรระดับ enterprise เช่น GitHub, Reddit, Stack Overflow, Twitter รองรับทั้ง Layer 4 และ Layer 7 load balancing

2.1 ติดตั้ง HAProxy บน Linux

# ติดตั้งบน Ubuntu/Debian
sudo apt update
sudo apt install haproxy -y

# ติดตั้งบน CentOS/RHEL
sudo dnf install haproxy -y

# เปิด service
sudo systemctl enable haproxy
sudo systemctl start haproxy

# ตรวจเวอร์ชัน
haproxy -v

2.2 ตั้งค่า HAProxy

ไฟล์ตั้งค่าหลักอยู่ที่ /etc/haproxy/haproxy.cfg ประกอบด้วย 4 ส่วนหลัก:

# ======== Global Settings ========
global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # SSL tuning
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.2
    tune.ssl.default-dh-param 2048
    maxconn 50000

# ======== Default Settings ========
defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option  forwardfor
    option  http-server-close
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http

# ======== Stats Dashboard ========
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s
    stats admin if LOCALHOST
    stats auth admin:SecureP@ss!

# ======== Frontend (รับ traffic จากภายนอก) ========
frontend http_front
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/site.pem

    # Redirect HTTP to HTTPS
    http-request redirect scheme https unless { ssl_fc }

    # ACL routing
    acl is_api path_beg /api/
    acl is_static path_end .jpg .png .css .js .gif .ico

    # Route based on ACL
    use_backend api_servers if is_api
    use_backend static_servers if is_static
    default_backend web_servers

# ======== Backend (กลุ่ม server ปลายทาง) ========
backend web_servers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200

    server web1 10.0.1.41:8080 check weight 3 inter 5s fall 3 rise 2
    server web2 10.0.1.42:8080 check weight 3 inter 5s fall 3 rise 2
    server web3 10.0.1.43:8080 check weight 2 inter 5s fall 3 rise 2
    server web4 10.0.1.44:8080 check weight 1 backup  # standby server

backend api_servers
    balance leastconn
    option httpchk GET /api/health
    http-check expect status 200

    server api1 10.0.1.51:3000 check inter 3s fall 2 rise 2
    server api2 10.0.1.52:3000 check inter 3s fall 2 rise 2

backend static_servers
    balance roundrobin
    server static1 10.0.1.61:80 check
    server static2 10.0.1.62:80 check

คำอธิบาย parameter ที่สำคัญ:

• check — เปิด health check สำหรับ server นี้
• weight N — กำหนดน้ำหนัก (ค่ามากได้ traffic มาก)
• inter 5s — ตรวจ health ทุก 5 วินาที
• fall 3 — ต้อง fail ติดต่อกัน 3 ครั้งจึงจะถือว่า server ล่ม
• rise 2 — ต้อง pass ติดต่อกัน 2 ครั้งจึงจะถือว่า server กลับมาพร้อม
• backup — ใช้เป็น standby server ส่ง traffic ไปเมื่อ server อื่นล่มหมด

ตรวจสอบ syntax และ restart:

# ตรวจ syntax
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

# Restart (reload โดยไม่ drop connection)
sudo systemctl reload haproxy

# ดู status
sudo systemctl status haproxy

ส่วนที่ 3: Nginx เป็น Load Balancer

Nginx นอกจากจะเป็น web server ยอดนิยมแล้ว ยังสามารถทำหน้าที่เป็น reverse proxy และ load balancer ได้อย่างมีประสิทธิภาพ โดยเฉพาะ Nginx Plus (เวอร์ชันเชิงพาณิชย์) ที่มีฟีเจอร์ load balancing ขั้นสูง

3.1 ตั้งค่า Nginx Load Balancing

# /etc/nginx/nginx.conf หรือ /etc/nginx/conf.d/loadbalancer.conf

# กำหนด upstream (กลุ่ม backend servers)
upstream web_backend {
    # อัลกอริทึม: round-robin (default), least_conn, ip_hash, random
    least_conn;

    server 10.0.1.41:8080 weight=3;
    server 10.0.1.42:8080 weight=3;
    server 10.0.1.43:8080 weight=2;
    server 10.0.1.44:8080 backup;  # standby

    # Keepalive connections to backend
    keepalive 32;
}

upstream api_backend {
    ip_hash;  # Session persistence ด้วย IP hash
    server 10.0.1.51:3000;
    server 10.0.1.52:3000;
}

server {
    listen 80;
    listen 443 ssl;
    server_name www.company.com;

    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    # Redirect HTTP to HTTPS
    if ($scheme = http) {
        return 301 https://$server_name$request_uri;
    }

    # Main website
    location / {
        proxy_pass http://web_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;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }

    # API routing
    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;
    }

    # Health check endpoint
    location /nginx-health {
        access_log off;
        return 200 "OK";
    }

    # Static files - serve directly
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        root /var/www/static;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

# ทดสอบ config
sudo nginx -t

# Reload
sudo systemctl reload nginx

3.2 เปรียบเทียบ HAProxy vs Nginx

ส่วนที่ 4: Health Checks และ Session Persistence

4.1 Health Checks (การตรวจสอบสุขภาพ Server)

Health Check เป็นกลไกที่ Load Balancer ใช้ตรวจสอบว่า backend server แต่ละตัวยังทำงานปกติหรือไม่ มี 3 ระดับ:

• Layer 3/4 Health Check — ตรวจว่า server ตอบ TCP connection ได้หรือไม่ (TCP SYN → SYN-ACK) เร็วที่สุดแต่ไม่รู้ว่าแอปพลิเคชันทำงานจริงหรือไม่
• Layer 7 Health Check (HTTP) — ส่ง HTTP request ไปยัง endpoint เฉพาะ (เช่น /health) แล้วตรวจ status code (200 OK) ทำให้รู้ว่า web application ทำงานจริง
• Application-Level Health Check — ตรวจละเอียดกว่า เช่น ตรวจว่า database connection ยังใช้ได้, disk space เพียงพอ, memory ไม่เต็ม ฯลฯ endpoint อาจ return JSON ที่มีรายละเอียด

# ตัวอย่าง health check endpoint (Python Flask)
@app.route('/health')
def health():
    checks = {}
    # ตรวจ database
    try:
        db.session.execute('SELECT 1')
        checks['database'] = 'ok'
    except:
        checks['database'] = 'fail'
        return jsonify(checks), 503

    # ตรวจ disk space
    disk = shutil.disk_usage('/')
    checks['disk_free_gb'] = round(disk.free / (1024**3), 1)
    if disk.free < 1024**3:  # น้อยกว่า 1 GB
        return jsonify(checks), 503

    checks['status'] = 'healthy'
    return jsonify(checks), 200

4.2 Session Persistence (Sticky Sessions)

หลาย web application เก็บข้อมูล session ไว้ในหน่วยความจำของ server (เช่น shopping cart, login state) หาก Load Balancer ส่ง request ถัดไปของ user คนเดิมไปยัง server คนละตัว session จะหาย ทำให้ต้อง login ใหม่หรือสินค้าในตะกร้าหายไป

วิธีแก้ปัญหา Session Persistence:

• 1. Source IP Affinity (IP Hash) — LB ใช้ IP ของ client เป็นตัวกำหนด server ปัจจุบัน ง่ายแต่มีปัญหาเมื่อ client อยู่หลัง NAT (IP เดียวใช้หลายคน)
• 2. Cookie-based Persistence — LB แทรก cookie พิเศษ (เช่น SERVERID=web1) ให้ client เมื่อ request กลับมาพร้อม cookie นี้ LB จะส่งไปยัง server เดิม เป็นวิธีที่นิยมมากที่สุด
• 3. URL/Parameter-based — ใช้ parameter ใน URL เช่น ?sessionid=abc123 เพื่อระบุ server
• 4. Externalized Session Storage — วิธีที่ดีที่สุด ย้าย session ไปเก็บใน shared storage เช่น Redis, Memcached หรือ database ทำให้ทุก server เข้าถึง session เดียวกันได้ ไม่ต้องพึ่ง sticky sessions

การตั้ง cookie-based sticky session ใน HAProxy:

backend web_servers
    balance roundrobin
    cookie SERVERID insert indirect nocache

    server web1 10.0.1.41:8080 check cookie web1
    server web2 10.0.1.42:8080 check cookie web2
    server web3 10.0.1.43:8080 check cookie web3

ส่วนที่ 5: SSL Termination / SSL Offloading

SSL Termination (หรือ SSL Offloading) คือการให้ Load Balancer เป็นผู้ decrypt HTTPS traffic แทน backend servers ทำให้ backend servers ไม่ต้องประมวลผล SSL/TLS ซึ่งใช้ CPU สูง

ข้อดี:

• ลดภาระ CPU ของ backend servers อย่างมาก (SSL handshake ใช้ CPU สูง)
• จัดการ SSL certificate ที่จุดเดียว ไม่ต้องติดตั้ง cert ทุก server
• Load Balancer สามารถ inspect HTTP content เพื่อทำ Layer 7 routing ได้ (ถ้า encrypt อยู่จะอ่าน content ไม่ได้)
• ใช้ SSL hardware acceleration ที่ LB ได้

ข้อเสีย:

• Traffic ระหว่าง LB กับ backend เป็น plaintext HTTP (ถ้าเป็น internal network อาจยอมรับได้)
• หากต้องการ end-to-end encryption ต้องใช้ SSL Re-encryption (LB decrypt แล้ว encrypt ใหม่ส่งไป backend)

การตั้ง SSL Termination ใน HAProxy:

frontend https_front
    bind *:443 ssl crt /etc/haproxy/certs/company.pem
    bind *:80

    # Redirect HTTP to HTTPS
    http-request redirect scheme https unless { ssl_fc }

    # Add headers for backend
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-SSL-Client-Verify %[ssl_c_verify] if { ssl_fc }

    default_backend web_servers

backend web_servers
    # Backend receives plain HTTP
    server web1 10.0.1.41:8080 check
    server web2 10.0.1.42:8080 check

ส่วนที่ 6: High Availability Architectures

6.1 Active-Passive vs Active-Active

การออกแบบ High Availability มี 2 รูปแบบหลัก:

Active-Passive (Failover):

• มี node หลัก (active) ทำงานปกติ และ node สำรอง (passive/standby) คอยเฝ้าดู
• เมื่อ active node ล่ม passive จะเข้ามาทำงานแทน (failover) โดยรับ IP address เดิม
• ง่ายในการตั้งค่า แต่ passive node ไม่ได้ถูกใช้งานจนกว่าจะ failover (เสีย resource)
• เหมาะกับ database, storage, license-limited applications

Active-Active:

• ทุก node ทำงานพร้อมกัน รับ traffic จริง
• ใช้ทรัพยากรคุ้มค่ากว่า เพราะทุก node ทำงาน
• ตั้งค่าซับซ้อนกว่า ต้องจัดการ data consistency, session sharing
• เหมาะกับ web servers, API servers, stateless applications

6.2 Keepalived + VRRP

Keepalived เป็นซอฟต์แวร์ที่ใช้สร้าง High Availability สำหรับ Load Balancer โดยใช้โปรโตคอล VRRP (Virtual Router Redundancy Protocol) ทำงานโดยสร้าง Virtual IP (VIP) ที่จะลอย (float) ระหว่าง node 2 ตัว เมื่อ master node ล่ม VIP จะย้ายไปยัง backup node โดยอัตโนมัติ

# ติดตั้ง Keepalived
sudo apt install keepalived -y

ตั้งค่า Master Node (LB1):

# /etc/keepalived/keepalived.conf (Master)
vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101           # Master มี priority สูงกว่า
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass SecretVRRP
    }

    virtual_ipaddress {
        10.0.1.100/24      # Virtual IP (VIP)
    }

    track_script {
        check_haproxy
    }

    notify_master "/usr/local/bin/notify_master.sh"
    notify_backup "/usr/local/bin/notify_backup.sh"
    notify_fault  "/usr/local/bin/notify_fault.sh"
}

ตั้งค่า Backup Node (LB2):

# /etc/keepalived/keepalived.conf (Backup)
vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100            # Backup มี priority ต่ำกว่า
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass SecretVRRP
    }

    virtual_ipaddress {
        10.0.1.100/24
    }

    track_script {
        check_haproxy
    }
}

เมื่อ HAProxy บน Master ล่ม script check_haproxy จะ fail → Keepalived ลด priority → Backup node ที่มี priority สูงกว่าจะรับ VIP ไปทำงานแทน ผู้ใช้ไม่รู้สึกถึงการเปลี่ยนแปลงเลย เพราะ IP ที่เข้าถึงยังคงเป็น VIP เดิม

6.3 Pacemaker/Corosync

Pacemaker เป็น cluster resource manager ที่ซับซ้อนกว่า Keepalived ใช้สำหรับจัดการ HA ของ resources หลากหลายประเภท ไม่เฉพาะแค่ VIP แต่รวมถึง database, file system, application services ฯลฯ ทำงานร่วมกับ Corosync ที่เป็น cluster communication layer

# ติดตั้ง Pacemaker/Corosync
sudo apt install pacemaker corosync pcs -y

# เริ่ม service
sudo systemctl enable pcsd corosync pacemaker
sudo systemctl start pcsd

# ตั้งรหัสผ่าน hacluster user
sudo passwd hacluster

# สร้าง cluster
sudo pcs host auth node1 node2 -u hacluster
sudo pcs cluster setup ha-cluster node1 node2
sudo pcs cluster start --all

# ปิด STONITH สำหรับ testing (production ควรเปิด)
sudo pcs property set stonith-enabled=false

# สร้าง VIP resource
sudo pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
    ip=10.0.1.100 cidr_netmask=24 op monitor interval=10s

# สร้าง HAProxy resource
sudo pcs resource create HAProxy systemd:haproxy \
    op monitor interval=5s

# ให้ VIP และ HAProxy อยู่ด้วยกันเสมอ
sudo pcs constraint colocation add HAProxy with VirtualIP INFINITY
sudo pcs constraint order VirtualIP then HAProxy

# ดูสถานะ cluster
sudo pcs status

Pacemaker มีข้อได้เปรียบเหนือ Keepalived ในกรณีที่ต้องจัดการ HA สำหรับหลาย resources ที่มีความสัมพันธ์กัน เช่น VIP + HAProxy + shared storage ต้องอยู่บน node เดียวกันเสมอ

ส่วนที่ 7: Cloud Load Balancers

ผู้ให้บริการ cloud รายใหญ่ทุกรายมีบริการ load balancer ที่จัดการ HA ให้โดยอัตโนมัติ ไม่ต้องตั้งค่า Keepalived/Pacemaker เอง:

7.1 AWS (Amazon Web Services)

• ALB (Application Load Balancer) — Layer 7 LB เหมาะสำหรับ HTTP/HTTPS traffic, support path-based routing, host-based routing, WebSocket, gRPC
• NLB (Network Load Balancer) — Layer 4 LB ประสิทธิภาพสูงมาก รองรับ millions of requests per second เหมาะกับ TCP/UDP traffic, static IP
• CLB (Classic Load Balancer) — รุ่นเก่า AWS แนะนำให้ย้ายไป ALB/NLB
• GWLB (Gateway Load Balancer) — สำหรับ inline network appliances เช่น firewall, IDS/IPS

7.2 Microsoft Azure

• Azure Load Balancer — Layer 4 LB สำหรับ traffic ภายใน (Internal) หรือภายนอก (Public)
• Azure Application Gateway — Layer 7 LB พร้อม WAF (Web Application Firewall) ในตัว
• Azure Front Door — Global load balancer สำหรับ web applications พร้อม CDN
• Azure Traffic Manager — DNS-based load balancer สำหรับกระจาย traffic ข้ามภูมิภาค

7.3 Google Cloud Platform (GCP)

• Cloud Load Balancing — รองรับทั้ง HTTP(S), TCP/SSL, UDP, Internal มี global load balancing ที่กระจาย traffic ข้ามภูมิภาคอัตโนมัติ

ข้อได้เปรียบหลักของ cloud load balancer คือ managed service ไม่ต้องดูแล infrastructure มี auto-scaling, built-in health checks, integration กับ cloud services อื่นๆ และ SLA รับประกัน uptime 99.99%

ส่วนที่ 8: Global Server Load Balancing (GSLB)

GSLB คือการ load balance ระดับ global ที่กระจาย traffic ไปยัง data center หลายแห่งที่อยู่ในภูมิภาคต่างๆ ทั่วโลก ทำงานผ่าน DNS โดยตอบ DNS query ด้วย IP ของ data center ที่ใกล้ผู้ใช้ที่สุดหรือมี latency ต่ำที่สุด

วิธีการตัดสินใจของ GSLB:

• Geographic Proximity — ส่ง traffic ไปยัง data center ที่ใกล้ที่สุดทางภูมิศาสตร์ เช่น ผู้ใช้ในเอเชียไปยัง data center สิงคโปร์
• Latency-based — วัด latency จริงแล้วส่งไปยัง data center ที่เร็วที่สุด
• Health-based — ไม่ส่งไปยัง data center ที่ล่ม
• Weighted — กำหนดน้ำหนักให้แต่ละ data center
• Cost-based — ส่งไปยัง data center ที่มีค่าใช้จ่ายต่ำที่สุด

ตัวอย่างบริการ GSLB: AWS Route 53 (Geolocation/Latency routing), Cloudflare Load Balancer, F5 BIG-IP DNS (GTM), Citrix ADNS

ส่วนที่ 9: F5 BIG-IP และ Citrix ADC

สำหรับองค์กรขนาดใหญ่ที่ต้องการ enterprise-grade load balancing มักเลือกใช้ hardware/virtual appliance จากผู้ผลิตเฉพาะทาง:

9.1 F5 BIG-IP

F5 BIG-IP เป็น Application Delivery Controller (ADC) ชั้นนำที่มีฟีเจอร์ครบถ้วน:

• Local Traffic Manager (LTM) — Load balancing, SSL offloading, connection multiplexing
• Global Traffic Manager (GTM) — GSLB, DNS-based load balancing
• Application Security Manager (ASM) — Web Application Firewall
• Access Policy Manager (APM) — VPN, authentication, SSO
• iRules — scripting language สำหรับ custom traffic management ที่ทรงพลังมาก

F5 มีทั้งแบบ hardware appliance, virtual edition (VE) สำหรับ VMware/cloud และ cloud-native solution

9.2 Citrix ADC (NetScaler)

Citrix ADC (เดิมชื่อ NetScaler) เป็นคู่แข่งหลักของ F5 มีจุดแข็งในเรื่อง:

• Integration กับ Citrix Virtual Apps and Desktops
• Unified Gateway สำหรับ remote access
• Advanced SSL/TLS capabilities
• Content switching และ cache redirection
• มีทั้ง hardware (MPX), virtual (VPX) และ container (CPX)

ส่วนที่ 10: Monitoring, Metrics และ Best Practices

10.1 Metrics ที่ควรติดตาม

การ monitor ระบบ load balancer ต้องติดตาม metrics เหล่านี้:

• Request Rate — จำนวน request ต่อวินาที (RPS) ของทั้งระบบและแต่ละ backend
• Response Time — เวลาตั้งแต่รับ request จนส่ง response กลับ (p50, p95, p99)
• Error Rate — อัตราส่วน HTTP 4xx/5xx ต่อ total requests
• Active Connections — จำนวน connections ที่กำลังเปิดอยู่
• Backend Health — สถานะ up/down ของแต่ละ backend server
• Throughput — ปริมาณ data ที่ส่งผ่าน (bytes/second)
• Queue Length — จำนวน requests ที่รอใน queue (ถ้ามีแสดงว่า backend ไม่พอ)
• SSL Handshake Time — เวลาที่ใช้ในการ SSL handshake
• Session Persistence Hit Rate — อัตราที่ sticky session ทำงานถูกต้อง

10.2 เครื่องมือ Monitoring

• HAProxy Stats Page — dashboard ในตัวที่ http://lb:8404/stats
• Prometheus + Grafana — HAProxy exporter สำหรับ Prometheus แล้วแสดงผลใน Grafana dashboard
• Datadog, New Relic — SaaS monitoring platforms
• ELK Stack — Elasticsearch + Logstash + Kibana สำหรับ log analysis
• Zabbix, Nagios — traditional monitoring tools

10.3 Best Practices สำหรับ Load Balancing ในองค์กร

• ทำ Load Balancer ให้ HA เสมอ — Load Balancer เป็น single point of failure ถ้ามีตัวเดียว ใช้ Keepalived หรือ cloud managed LB
• ใช้ Layer 7 health checks — อย่าพึ่ง TCP check อย่างเดียว ให้ตรวจ application layer ด้วย
• Externalize sessions — เก็บ session ใน Redis/Memcached แทน server memory เพื่อหลีกเลี่ยงปัญหา sticky sessions
• ทำ SSL Termination ที่ LB — ลดภาระ backend servers และจัดการ cert ง่ายขึ้น
• ตั้ง connection limits — ป้องกัน backend server overload ด้วย maxconn
• ใช้ graceful shutdown — เมื่อถอด server ออกจาก pool ให้ drain connections ก่อน ไม่ใช่ตัดทันที
• ทดสอบ failover เป็นประจำ — จำลองการล่มของ server และ LB เพื่อให้มั่นใจว่า HA ทำงานจริง
• Plan for capacity — monitor และวางแผน capacity ล่วงหน้า ก่อนที่ traffic จะเกิน limit
• ใช้ Backup configuration — สำรอง config ของ LB ไว้เสมอ
• Document ทุกอย่าง — IP addresses, VIP, port mapping, backend servers, failover procedure

ส่วนที่ 11: ตัวอย่างสถาปัตยกรรม HA สำหรับองค์กร

ต่อไปนี้คือตัวอย่างสถาปัตยกรรมที่รวม load balancing และ HA เข้าด้วยกัน เหมาะสำหรับระบบ web application ขององค์กรขนาดกลาง:

                     Internet
                        |
                   [Firewall/UTM]
                        |
            +-----------+-----------+
            |                       |
      [HAProxy LB1]          [HAProxy LB2]
      (Master/VIP)            (Backup)
            |    Keepalived VRRP    |
            +-----------+-----------+
                        |
                   VIP: 10.0.1.100
                        |
         +------+------+------+------+
         |      |      |      |      |
      [Web1] [Web2] [Web3] [Web4] [Web5]
         |      |      |      |      |
         +------+------+------+------+
                        |
              [Redis Cluster - Sessions]
                        |
         +------+------+------+
         |      |      |      |
      [DB Master]  [DB Slave1]  [DB Slave2]
         |
      [Shared NAS/SAN Storage]

สถาปัตยกรรมนี้ประกอบด้วย:

• Firewall/UTM — ป้องกันภัยคุกคามจากภายนอก
• HAProxy x2 + Keepalived — load balancer HA ด้วย VRRP, failover อัตโนมัติ
• Web Servers x5 — stateless web application, scale ได้ง่ายโดยเพิ่ม server
• Redis Cluster — เก็บ session data แบบ centralized
• Database Master-Slave — write ที่ master, read ที่ slave เพื่อกระจายภาระ
• NAS/SAN Storage — shared storage สำหรับไฟล์ที่ใช้ร่วมกัน

สรุป

Load Balancing และ High Availability เป็นสองเสาหลักของระบบ IT ที่ต้องการความเสถียรและรองรับผู้ใช้จำนวนมาก Load Balancer ช่วยกระจายภาระงานไปยัง server หลายตัว ขณะที่ HA ช่วยให้ระบบทำงานต่อเนื่องแม้มี component ล่ม

สำหรับองค์กรขนาดเล็กถึงกลาง HAProxy + Keepalived เป็นทางเลือกที่คุ้มค่าที่สุด เพราะเป็น open-source ฟรี ประสิทธิภาพสูง และตั้งค่าไม่ยาก สำหรับองค์กรที่ใช้ cloud สามารถใช้ managed load balancer เช่น AWS ALB/NLB ที่จัดการ HA ให้โดยอัตโนมัติ ส่วนองค์กรขนาดใหญ่ที่ต้องการฟีเจอร์ขั้นสูง F5 BIG-IP หรือ Citrix ADC เป็นตัวเลือกที่เหมาะสม

ไม่ว่าจะเลือกโซลูชันไหน สิ่งสำคัญคือต้อง monitor อย่างต่อเนื่อง ทดสอบ failover เป็นประจำ และออกแบบสถาปัตยกรรมที่ไม่มี single point of failure หากสนใจศึกษาเพิ่มเติมเกี่ยวกับ infrastructure องค์กร สามารถอ่านบทความเรื่อง Server & Datacenter, VMware Virtualization และ Cloud AWS ที่ siamlancard.com ได้เลย