Why Varnish Cache

User <-------> Varnish <-------> Web Server <--------> DB

วันนี้ ผมมีโอกาสมาพูดถึง เจ้า Varnish อีกครั้ง ว่าทำไม มันถึงน่าสนใจ มันมีอะไรดี
แล้วมันช่วยอะไรกับระบบเว็บขนาดใหญ่ ที่มีคนเข้าจำนวนมากได้ ..
โดยเฉพาะถ้าเว็บคุณเป็น content พวก static ยิ่งดีเลย เพราะว่า varnish สามารถ
caching ตรงส่วนนี้ได้หมด บน memory ทำให้ เครื่อง web server และ DB เอง
แทบไม่ต้องทำงานอะไรเลย แต่ถ้าเป็นพวก dynamic ตัว varnish เอง ก็ช่วยได้เหมือนกัน
มาดูรายละเอียดกันครับ ว่าทำไมต้อง varnish ??

– เพราะเป็น Open Source ที่มีคุณภาพ ทำไมต้องไปใช้ BlueCoat ที่มีราคาแพงด้วย
ทั้งๆ ที่ Varnish ดีกว่ามากๆๆๆๆๆๆๆๆๆ ถ้าคุณใช้มันเป็น 🙂

– Varnish Configuration Language (VCL) ซึ่งเป็นการเขียน config แบบเข้าใจได้ง่าย
เป็นโครงสร้างที่คล้ายๆ ภาษา C ทำให้เราสามารถ เขียน VCL ให้ทำงานต่างๆ ได้ละเอียด
ตามที่เราต้องการ และใช้การ compile เพียงครั้งเดียว ทำให้ การทำงานทำได้อย่างดี เร็ว
และมีประสิทธิภาพมากๆ

– Varnish เก็บ cache ต่างๆ บน memory ด้วยโครงสร้างที่ดี ทำให้ lookup ได้เร็วมาก
เวลาต้องการเรียกใช้งาน cache ที่ต้องการ โดยแทบจะไม่ทำให้ เครื่อง เกิด i/o load เลย

– Varnish สามารถทำเป็น Load Balance ได้

– Purge URL ที่ต้องการไม่ให้ cache ได้ โดยใช้คำสั่งเข้าใจง่ายๆ สามารถใช้ PHP
เขียนติดต่อ ที่ T port เพื่อทำการ purge URL ทำให้เว็บ มีประสิทธิภาพมาก เพราะว่า
ในกรณีนี้ เราจะสามารถ เขียน VCL ให้ cache URL ทั้งหมด ของระบบได้ ทำให้
Web Server และ DB Server แทบไม่ต้องทำงานเลย แต่ถ้าเวลามีการ update ต่างๆ
เราก็สามารถส่ง URL ที่ต้องการ มา purge ได้ 🙂

ที่เล่ามาก็เป็นส่วนหนึ่งที่ทำไมผมคิดว่า Varnish เหมาะที่จะมาช่วยทำให้ระบบเว็บขนาดใหญ่
สามารถทำงานได้ดีขึ้น มีประสิทธิภาพสูงขึ้น และประหยัดค่าใช้จ่ายในการซื้อ Software
และ Hardware ที่ไม่จำเป็น เป็นการช่วยลดโลกร้อน ที่เป็นปัญหาให้เกิดน้ำท่วมได้ 🙂

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

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