เจอ Bug ของระบบที่เป็นแบบระเบิดเวลา

การแก้ไขปัญหาเฉพาะหน้า และ หาต้นเหตุของปัญหา

การ 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 แล้ว ต้องต้องออกแบบ สร้างมันขึ้นมาอย่างเหมาะสมด้วย ที่สำคัญกว่าคือ พร้อมที่จะเปลี่ยนแปลงหรือปรับปรุงให้ดีขึ้นด้วย อีกทั้งถ้าเรามีข้อมูลต่าง ๆ ของระบบในมือ ก็ยิ่งช่วยให้เราง่ายต่อการตัดสินใจอีกด้วย