ในช่วง 1-2 วันที่ผ่านมา เจอปัญหาของระบบงานที่อยู่บน production
แน่นอนว่า ระบบล่ม เมื่อมีการใช้งานเยอะขึ้น
CPU วิ่งไป 100% แบบพุ่งปรี๊ดดด
จึงลองดูกันหน่อยว่าจะแก้ไข หรือ ทุเลาลงไปได้อย่างไร ?
การแก้ไขปัญหาเฉพาะหน้า และ หาต้นเหตุของปัญหา
การ restart เพื่อหนีปัญหา เป็นทางที่น่าสนใจ และก็ทำ
แต่ปัญหาไม่หายไป แค่ทุเลา เพื่อรอการเกิดใหม่
การ scale ด้วยการขยายเครื่อง เช่น การเพิ่ม CPU และ Memory ก็ใช้ได้ดี
แต่คือการหนีปัญหา
การ scale ด้วยการเพิ่มเครื่อง เป็นอีกทาง แต่ทำไม่ได้เลย
เนื่องจากระบบไม่ได้ออกแบบมาเพื่อสิ่งนี้ !!
เมื่อแก้ไขปัญหาเฉพาะหน้าแล้ว ก็มาหาปัญหาและแก้ไขกันหน่อย
- มีการเชื่อมต่อ database ทุก ๆ ครั้งที่เข้าระบบ ไม่ว่าจะต้องดึงข้อมูลจาก database หรือไม่ ตรงนี้โหดมากต้องแก้ไข แต่ยังทำไม่ได้ เพราะว่าต้องแก้ไข code ทั้งระบบ ความเสี่ยงสูง
- ไม่มีการใช้ caching ใด ๆ ต่อ database ตรงอย่างเดียว เช่นเดียวกันต้องแก้ทั้งระบบ ง่ายในการทำแต่เยอะเท่านั้นเอง
- ดูจาก log การใช้งานผ่าน Load balance พบว่ามีส่วนงานจำนวนมาก ที่ทำงานช้ามาก ๆ ตรงนี้คือต้นเหตุแรก !!
- ปัญหาคือใช้งาน database เป็นหลัก ดังนั้น เน้นไปตรงนี้ก่อน
เมื่อลองไปดู log ก็เจอทันทีว่า มีส่วนงานอะไรที่ช้าบ้าง
สิ่งที่เจอคือ เมื่อถึงเวลาอันเป็นมงคล CPU ใช้งานทะลุจุดเดือด
พุ่งขึ้นไม่มีอาการหรือคำเตือนใด ๆ
ระบบล่มแน่นอน !!
ก็ต้องกู้คืนให้เร็วที่สุดก่อน
เมื่อลงไปดูต้นเหตุของปัญหา พบว่า
- ไม่ทำ index ใน table ซึ่งตรงนี้จะยังไม่มีปัญหา ถ้าจำนวนข้อมูลไม่มากพอ และ traffic ไม่มากพอ
- มี operation ที่ทำงาน update ข้อมูลใน database จำนวนมาก ทั้ง ๆ ที่ใน business logic จริง ๆ ไม่ได้ต้องการแบบนั้น เมื่อข้อมูลมากขึ้นเรื่อย ๆ การ update ข้อมูลตามเงื่อนไขของนักพัฒนาก็มากขึ้น และเมื่อถึงวันโชคดีก็โดนกันไป
นี่คือ ปัญหาที่พบเจอแบบง่าย ๆ
จะเห็นได้ว่า มันคือ ระเบิดเวลาดี ๆ นี่เอง
ที่ทีมพัฒนาสร้างมันมากับมือ
เมื่อแรกเริ่มเป็นวิธีการที่ถูกต้องมั้ง เพราะว่า ทำงานได้ดี ไม่มีปัญหา
แต่เมื่อเงื่อนไขต่าง ๆ ที่จำเป็นมันมาพร้อม
ก็ทำให้ระบบล่มเฉย ๆ ได้เลย
การแก้ไขปัญหาทั้งสองข้อไม่ยาก
เพียงทำ index ไปซะ และไปเปลี่ยน condition ให้การ update น้อยลงไป
จาก update ข้อมูลครั้งละ 10,000-50,000 record ต่อ request
แน่นอนว่า ช่วง peak traffic พุ่งสูงมาก !!!
หลังจากแก้ไข เหลือ update ข้อมูลครั้งละไม่เกิน 10-20 record เท่านั้น
แน่นอนว่ายังมีปัญหาอื่น ๆ และที่ยังไม่รู้ รอระเบิดออกมา
ต้องแก้ไขกันต่อไป
ทั้งการ monitor การทำงานของทุก ๆ request ว่าช้าหรือเร็วอย่างไร
ทั้งการปรับเปลี่ยนโครงสร้างของ database server
ทั้งการปรับเปลี่ยน flow การทำงานของ code
ทั้งการนำ caching data เข้ามาช่วย เพื่อลดภาระและค่าใช้จ่ายของ database ลงไป
เพื่อช่วยให้ business ยังคงเดินหน้าต่อไปอย่างราบรื่น
จะเห็นได้ว่า การตัดสินใจใด ๆ ใน architecture ของระบบ
มันจะส่งผลต่อ business และ customer เสมอ
ถ้ามีเป้าหมายเรื่องของการ scale แล้ว
ต้องต้องออกแบบ สร้างมันขึ้นมาอย่างเหมาะสมด้วย
ที่สำคัญกว่าคือ พร้อมที่จะเปลี่ยนแปลงหรือปรับปรุงให้ดีขึ้นด้วย
อีกทั้งถ้าเรามีข้อมูลต่าง ๆ ของระบบในมือ
ก็ยิ่งช่วยให้เราง่ายต่อการตัดสินใจอีกด้วย
