ประกอบคลัสเตอร์ WordPress ระดับองค์กรแบบที่ผมใช้จริง

WordPress ไม่ได้ช้าเพราะตัวมันเอง WordPress ช้าเพราะสแตกที่เราวางรอบ ๆ มัน — PHP ที่ไม่มีการแคช, ฐานข้อมูลเครื่องเดียว และดิสก์ที่แชร์ผ่าน NFS แบบไม่คิด

สถาปัตยกรรมด้านล่างนี้คือชุดที่ผม deploy ให้ลูกค้าองค์กรและใช้งานจริงต่อเนื่องหลายปี

ภาพรวมสแตก

กุญแจสำคัญสามดอก

หนึ่ง — shared storage ต้องเร็ว ถ้า wp-content อยู่บน NFS ที่ latency 20ms ปลั๊กอินอัปโหลดรูปจะพังทั้งคลัสเตอร์ ผมใช้ block storage ที่ mount แบบ distributed หรือ object storage + CDN offload

สอง — object cache ต้องอยู่นอก pod Redis ต้องมี persistence และ replication ไม่ใช่ container เดี่ยวที่หายไปตอน deploy

สาม — health check ต้องตรวจ PHP ไม่ใช่แค่ TCP ถ้า health check แค่ ping port 8443 โหลดบาลานเซอร์จะส่งทราฟฟิกไปยัง node ที่ PHP ตายแล้ว

# LiteSpeed ADC upstream health check
upstream wordpress_backend {
  least_conn;
  server 10.10.0.11:443 max_fails=3 fail_timeout=10s;
  server 10.10.0.12:443 max_fails=3 fail_timeout=10s;
  server 10.10.0.13:443 max_fails=3 fail_timeout=10s;
}

ค่าที่ต้องจูนใน php.ini

memory_limit = 512M
max_execution_time = 120
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
realpath_cache_size = 4096k

opcache.validate_timestamps = 0 เป็นการตัดสินใจสำคัญ: เร็วขึ้นชัดเจน แต่ต้อง reload PHP-FPM ทุกครั้งที่ deploy — ใส่ใน pipeline ให้เรียบร้อย

ผลลัพธ์ที่วัดได้

บนเว็บ e-commerce ของลูกค้า (ทราฟฟิกไทย + อาเซียน) หลังย้ายเข้า cluster:

• TTFB จาก 1.4 วินาทีเหลือ 180 มิลลิวินาที (cache hit 94%)
• รับ concurrent users ได้มากกว่าเดิม 6 เท่าในเครื่องจำนวนเท่ากัน
• Downtime ระหว่างอัปเดตปลั๊กอินลดจาก "ต้องประกาศปิดปรับปรุง" เหลือ zero-downtime rolling update

สิ่งที่คนมักลืม

• อัปเดต core ทีละ node แล้วทดสอบ checkout flow ทุกครั้ง
• ตั้งค่า Redis maxmemory-policy allkeys-lru ไม่ใช่ noeviction ซึ่งทำให้ write พังเมื่อเต็ม
• สำรองข้อมูลแบบ immutable เพราะ ransomware มองหา backup ที่ mount อยู่ตลอดเวลา
• ทดสอบ failover จริง อย่างน้อยไตรมาสละครั้ง ถ้าไม่เคยทดสอบ ก็ยังไม่รู้ว่ามันทำงาน