High Performance Web Infrastructure

วันนี้ผมมีเวลาว่าง เลยอยากจะเขียนเล่าเรื่องการออกแบบ
Web Infrastructure ให้รองรับ load สูงๆ ได้ ว่าทำแบบไหนดี
โจทย์ของผมคือเป็น web สำหรับ booking ที่จะมีคนเข้าใช้งานจำนวนมาก
ในตอนเปิดให้ใช้งาน เป้าหมายที่ตั้งไว้คือ 1000 tps/s ++
และต้องไม่ down โดยผมมี physical server อยู่ 3 node

ในการออกแบบ Infrastructure นั้น ไม่มีแบบไหนถูกแบบไหนผิด
อยู่ที่ลักษณะของงานของเรา ว่าต้องการแบบไหน อยู่ที่จินตนาการของเรา
ว่าทำแบบไหนดี การออกแบบระบบ ก็เป็นศิลปะ อย่างหนึ่ง ..

Simply The Best เป็นคำตอบ ที่ผมใช้ออกแบบระบบที่ผมจะใช้งานนี้
เท่าที่ดูลักษณะ web แล้ว จะมีการ Read/Write DB หนักพอๆ กัน ถ้าเราแยก DB
ออกไป ก็จะทำให้เกิด connections จำนวนมากเกิดขึ้นในระบบ
ต้องแยก Read/Write ที่ตัว web app อีกเกิดความยุ่งยาก มากขึ้น
ผมเลยเอา web กับ DB ไว้ในตัวเดียวกันไปเลย แล้วใช้ HAProxy
เป็น Load Balancer round robin แบบ keep-alive
มี vip เป็น Public IP ที่ eth0 และใช้ eth1 เป็น Private IP
ยิงเข้าหา แต่ละ node ที่ต้องแยก interface เพื่อเป็นการกระจาย traffic
DB ที่ใช้ผมเลือกเป็น MariaDB ที่ทำงานได้ performance ดีกว่า MySQL
และใช้ Galera Cluster เป็นตัว sync data ของ DB แต่ละ node เข้าหากัน
ทำให้ ทุก node มี data ที่เหมือนกัน node ใด node นึง down ไป
ทุก node ก็จะยังทำงานได้สมบูรณ์ ถ้าเราต้องการเพิ่ม node เข้ามา
ก็สามารถทำได้ง่าย แค่ on ขึ้นมา Galera Cluster ก็จะทำการ sync data ให้

ในส่วนของ Web Server ผมใช้ Apache 2.2.22 ที่มากับตัว Debain Wheezy
มีการ tuning ค่าต่างๆ พอสมควรให้เหมาะกับการใช้งาน ตรงนี้เดี๋ยวผมมาเล่าอีกที
ที่เลือกใช้ apache เพราะ มีความยืดหยุ่นสูง ทำงานได้ดีกับ code ทุกรูปแบบ
ส่วน code เป็น PHP กระจายไปทุก node เก็บไว้ที่ local disk ของแต่ละ node
และใช้ APC เป็น opcode cache อีกระดับนึง

ปัญหาที่เจอ มีดังนี้
– auto increment จะไม่เรียงกัน เท่าไร มีกระโดดบ้าง แต่ก็รับได้
– HAProxy 1.5.4 default จะเก็บ log ทำให้ ถ้า log ใหญ่ๆ จะหนักได้
– เวลาแก้ code ต้อง up ทุก node

ผลที่ออกมา หลังจากใช้งานจริง พบว่า รองรับการใช้งานได้ดีมาก
รับ load จำนวนมหาศาล และ users ได้จำนวนมากพร้อมๆ กัน
ส่วนรายละเอียดการ tuning ผมจะขอแยกอธิบาย ในตอนต่อไป
เพราะว่า เยอะพอสมควร ..

Web Infrastructure

Web Infrastructure

วันนี้ มีเวลานิดหน่อย ก็เลยมาเล่าถึงเรื่อง Web Infrastructure กัน ว่าแต่ละระบบ
เรียงจากขนาดเล็ก มาจนถึงขนาดใหญ่ มีวิิธีการวาง Infrastructure และแนวคิด
ในการวางระบบต่างกันอย่างไรบ้าง เพื่อที่จะให้รองรับกับจำนวนผู้ใช้งานได้ตาม
ที่ต้องการ ในที่นี้ ผมแบ่งออกเป็นย่อยๆ ประมาณ 6 ระดับครับ มาดูกันเลย  ..

1. จะมี service ทุกอย่างรวมกันอยู่ในเครื่องเดียว ทั้ง web server, DB และอื่นๆ
ใน 1 เครื่อง อาจจะมีจำนวนหลายเว็บ แบบนี้ก็ประเภท web hosting ต่างๆ

2. เมื่อมีคนเข้าเยอะขึ้น เครื่องเดียวทำงานไม่ไหว ก็ต้องมีการแยก web server กับ DB
ออกจากกัน เพื่อให้ทำงานได้มีประสิทธิภาพ รองรับจำนวนผู้ใช้งานได้มากขึ้น การแยก
web server ออกจาก DB นั้น ไม่ได้เกี่ยวกับเรื่อง security หลายๆ คนเข้าใจผิด คิดว่า
การแยกออกจากกันเพื่อเรื่องนี้ แต่จริงๆ แล้วเพื่อ performance อย่างเดียวจริงๆ

3. เมื่อระบบแบบที่ 2 รองรับไม่ไหว เราก็ต้องเพิ่มเครื่อง caching มาช่วยจัดการกับ
static file เช่นพวก jpg, gif, png, html เพื่อทำให้ web server ทำงานได้เบาลง
พวก caching ที่นิยมใช้งานก็เป็นพวก varnish, squid, nginx และพวก lighthttpd
อื่นๆ ที่เก่งในเรื่องการทำงานกับ static file แทน apache2 ที่ทำงานหนักกว่า ..

4. เมื่อเรามี caching มาช่วย web server แล้ว ปัญหาที่ตามมาอีกก็คือ ทางฝั่ง DB บ้าง
ก็จะเริ่มหนัก เราก็เลยต้องมีวิธีการแบ่ง Read/Write ออกจากกัน โดยที่ data ต้องเหมือนกัน
ในกรณีที่ใช้ MySQL เราก็จะทำ MySQL Replication แยก Read/Write ออกจากกัน
เพราะว่าส่วนใหญ่แล้ว จะเป็น Read ประมาณ 90%  Write ประมาณ  10% เท่านั้น ในกรณีนี้
ถ้าเครื่องเดียว ยังไม่เพียงพอกับการ Read เราก็สามารถเพิ่ม MySQL Slave เข้าไปได้
ให้เพียงพอกับจำนวน Read ที่เราต้องการ

5. ในเมื่อโครงสร้างเดิมๆ 1-4 ไม่สามารถรองรับกับจำนวนคนใช้งานได้แล้ว เราก็จำเป็นต้อง
มี LB (Load Balancer)  เข้ามาช่วยเป็นตัวจัดการกระจาย load ให้ระบบของเราให้เท่าๆ กัน
LB มีให้เลือกใช้งานมากมาย ทั้งที่เป็น S/W และ H/W ถ้ามีทุนมากหน่อย ก็เลือกแบบ H/W
ก็จะทำให้การจัดการทำได้ง่ายขึ้น แต่ถ้าต้องการประหยัด S/W LB หลายๆ ตัวก็ทำได้ดี
ในโครงสร้างรูปที่ 5 เราจะใช้ LB มาแบ่ง load ระหว่าง caching 2 ตัว ที่อยู่หน้า web server
เมื่อตัวใดตัวนึงมีปัญหา ระบบก็จะยังใช้งานได้ปกติ ในส่วนของ web server เองก็เช่นกัน เรามี
LB มาเป็นตัวช่วยกระจาย load โดยที่ web server ทุกตัวจะ mount file จาก NFS กลาง
ทำให้ทุกเครื่องมี data ที่เหมือนกัน เมื่อเครื่องใดเครื่องนึง มีปัญหาระบบก็ยังจะทำงานต่อไปได้
ส่วน DB ก็ใช้วิธีการแยก Read/Write เหมือนกับระบบที่ 4

6. เมื่อโครงสร้างแบบที่ 5 เริ่มรองรับไม่ไหว เราก็ต้องมีวิธีวางแผนกันใหม่ สิ่งที่ดีที่สุด ก็คือ
การแยก static กับ dynamic ออกจากกัน แล้วก็เอาเรื่องของ memory เข้ามาช่วย นอกนั้น
ส่วนอื่นๆ ก็คล้ายๆ กับโครงสร้างแบบที่ 5

เอาไว้เท่านี้ก่อนละกันครับ เดี๋ยววันหลังมาเขียนเพิ่มเติมครับ งานเข้าละ  🙂