When MongoDB is growing up

"เมื่ออัพเกรดดาด้าเบสใหญ่ขึ้น กลับทำให้ประสิทธิภาพลดลง"
 
ต้นเดือนนี้เอง ดาต้าเบสของกิจการแห่งหนึ่งใกล้เต็มความจุ 5GB ทำให้ต้องอัพเกรดเพิ่มขนาดจาก M5 เป็น M10 plan เพื่อให้มีพื้นที่ 10GB ใน MongoDB Atlas
ดูแล้วก็ไม่น่ามีปัญหาอะไร แต่กลับไม่เป็นเช่นนั้น.. หลังจากอัพเกรดแล้ว ปรากฏว่าการใช้งานที่เคยราบรื่นกลับติดขัด อ่านข้อมูลช้ากว่าเดิม จนการทำงานสะดุด รายงานที่เคยดูได้สบาย กลับใช้เวลานาน จนบางครั้งเรียกดูไม่สำเร็จ
 
หลายปีก่อนเรื่องนี้เคยเกิดมาแล้ว กิจการแห่งแรก ที่เข้าสู่กระบวนการอัพเกรด จาก M0 ตอนเริ่มต้นมา M2 และ M5 ตามลำดับเป็นไปอย่างราบรื่น จนกระทั่งขยายมาเป็น M10 ก็เกิดปัญหาเช่นนี้ ตอนนั้นไม่เข้าใจและทำอะไรไม่ถูก จนต้องอัพเกรดขึ้นไปเป็น M20 จึงกลับมาใช้งานได้ตามปกติ จุดผกผันจึงอยู่ที่การเปลี่ยนผ่านจาก M5 เป็น M10 มาทำความเข้าใจสาเหตุกันก่อน แล้วหลังจากนั้นค่อยเล่าถึงกระบวนการแก้ปัญหาของเรา Atlas ที่ให้บริการ MongoDB กำหนดเงื่อนไขใช้งานต่างกัน ระหว่างมือใหม่กับมืออาขีพ
 
สำหรับดาต้าเบสที่มีขนาดต่ำกว่า 5GB มองว่าเป็นช่วงเริ่มต้นของการพัฒนาและใช้งาน จึงควรมุ่งสนใจไปที่ทำโปรแกรมให้ใช้งานได้ก่อน โดยไม่ต้องกังวลเรื่องออกแบบ schema หรือปรับปรุงประสิทธิภาพของดาต้าเบสมากเกินไป ดังนั้นจึงใช้เซิร์ฟเวอร์ที่มีขนาดใหญ่ โดยแชร์ใช้ RAM และ CPU ร่วมกับดาต้าเบสของผู้อื่น บางจังหวะที่มี query ที่กินแรงมากจึงยังพอทำงานได้ ตามธรรมชาติของข้อมูลใช้งานที่สะสมจนใหญ่เกิน 5GB ต้องผ่านเวลามาพอสมควร ถ้าเป็นคนก็ถือว่าได้เรียนรู้มีประสบการณ์โตเป็นผู้ใหญ่แล้ว รับผิดชอบตัวเองได้ ต้องมีเซิร์ฟเวอร์ที่ใช้ RAM และ CPU ของตัวเอง ถ้าหากยังมี query ที่กินแรงจนรับไม่ไหว ก็พังคนเดียว

คำอธิบายที่เป็นเหตุผลดีที่สุด เมื่อขยับขยายมาเป็น M10 น่าจะได้สเปค RAM และ CPU ต่ำกว่าเซิร์ฟเวอร์ตอนที่แชร์ใช้ M5 ดังนั้นเมื่อเจอ query ที่กินแรงเกินสเปค RAM และ CPU จึงฟ้องออกมาว่าไม่ไหว ทางเลือกจึงมีสองทาง ว่าจะเพิ่มสเปค RAM และ CPU ขึ้นไปอีก ดังเช่นกิจการแห่งแรกที่เจอมาแล้ว หรือจะพยายามปรับปรุงแก้ปัญหาที่เกิดจาก query เหล่านั้น เพราะมีดาต้าเบสของกิจการที่ต้องดูแลอยู่จำนวนมาก และในอนาคตก็จะมีการอัพเกรดอย่างนี้อีก การแก้ปัญหาโดยเพิ่มสเปค RAM และ CPU ไปเรื่อยๆ นอกจากจะทำให้เกิดค่าใช้จ่ายเซิร์ฟเวอร์สูงแล้ว สาเหตุที่แท้จริงคือ query ที่เป็นปัญหา ก็ยังอยู่เหมือนเดิมไม่ได้รับการแก้ไข
 
กระบวนการแก้ปัญหาที่ยั่งยืนจึงเลือกทางที่ยากกว่า
 
แทนที่จะรอให้ผู้ใช้แจ้งปัญหาเข้ามา เราเริ่มจากเก็บสถิติการใช้งานที่ใช้เวลาอ่านดาต้าเบสนานเกินไป เพื่อลำดับความเร่งด่วนของปัญหา ว่าจุดไหนเป็นจุดวิกฤติของการใช้งาน เช่น มีการเรียกรายงาน หรือค้นหาข้อมูลลักษณะนี้บ่อยๆ หรือมีผู้ใช้หัวข้อนี้หลายคน หากปรับปรุงจุดนี้ได้ก่อนก็จะช่วยบรรเทาได้มากกว่า เมื่อเห็นภาพรวมของสถานการณ์ การคลี่คลายจะไม่สะเปะสะปะ จากประสบการณ์ที่ผ่านมา สาเหตุของปัญหามักมีรูปแบบคล้ายกัน
 
"query ดีแล้ว แต่ขาดอินเด็กซ์"
เมื่อมีการใช้งานหัวข้อนี้มากๆ แต่ดาต้าเบสไม่ได้ปรับแต่งให้มีอินเด็กซ์ที่เหมาะสม ทำให้การเรียกใช้แต่ละครั้งต้องใช้เวลานาน กรณีนี้ผู้ดูแลดาต้าเบสต้องจัดการเพิ่มอินเด็กซ์
 
"query ยังไม่รัดกุม"
เกิดขึ้นได้ใน 2 ระดับ คือ ในระดับความผิดพลาดของตัวโปรแกรม กับระดับการสร้างรายงานเฉพาะสำหรับกิจการ
 
หากเป็นความผิดพลาดของโปรแกรม โปรแกรมเมอร์จะรับผิดชอบปรับปรุง ให้ใช้ query ที่รัดกุมกว่าเดิม เมื่อแก้ไขแล้วก็จะมีผลดีกับทุกแห่งด้วย นานวันเข้าก็จะพบเจอปัญหานี้น้อยลง
 
รายงานที่สร้างเฉพาะสำหรับกิจการ เจอบ่อยที่สุด เมื่อเจอแล้วก็ตามเก็บเป็นกรณีไป ตัวอย่างที่เพิ่งเจอเมื่อเร็วๆ นี้ เช่น รายงานสินค้าค้างส่ง เมื่อเริ่มใช้ปีแรกๆ ไม่มีปัญหาอะไร จนกระทั่ง 5 ปีผ่านไป จึงพบว่าไม่ได้กำหนดขอบเขตวันที่ใน query ทำให้ต้องหาข้อมูลตั้งแต่ปีแรกจนปีสุดท้ายทุกครั้ง เมื่อสำรวจจากข้อมูลจริงจึงพบว่า กิจการแห่งนี้มีสินค้าค้างส่งไม่เกิน 3 เดือน ดังนั้นหากเราเพิ่ม query ขอบเขตวันที่เป็น "3 เดือนล่าสุด" เอาไว้ ก็จะช่วยลดการทำงานของดาต้าเบสไปได้มาก
จะเห็นว่า ณ วันแรกที่ส่งมอบรายงานให้ใช้ ไม่มีทางรู้ว่าขอบเขตวันที่ที่เหมาะสมคือเท่าไหร่กันแน่ ดังนั้นค่า "3 เดือนล่าสุด" ต้องรอให้มีข้อมูลใช้งานไปแล้วนานพอสมควร ขณะเดียวกันก็ไม่มีทางรู้ว่าหลังจากส่งมอบไปแล้ว รายงานนั้นจะมีการเรียกใช้มากน้อยเพียงใด หนทางที่ทุ่นแรงและเชื่อถือได้มากที่สุดจึงต้องรอให้มีการเก็บสถิติออกมา เพื่อจะรู้ว่าควรกลับไปปรับปรุง query ของรายงานนั้นให้รัดกุมหรือปล่อยไป ไม่มีใครใช้
 
เรื่องเหล่านี้เป็นไปได้ยาก หากการพัฒนาโปรแกรมยังใช้วิธีจ้างเป็นโปรเจกต์ หรือซื้อโปรแกรมสำเร็จรูปมาใช้ ปัญหาไม่ได้เกิดในปีแรกที่ส่งมอบและใช้งาน เพราะในกิจการแต่ละแห่งไม่ได้หยุดนิ่ง เมื่อเติบโตขึ้นต่างต้องการระบบงานที่ตรงกับการทำงานของตน ซึ่งต้องอาศัยการทำงานร่วมกันจากผู้ดูแลดาต้าเบส โปรแกรมเมอร์ และผู้พัฒนาระบบ ที่ดูแลกันไปเรื่อยๆ หากคุณยอมรับ "ความไม่สมบูรณ์" เมื่อเริ่มต้น และเชื่อว่าระบบงานของคุณจะดีขึ้นทุกวันเมื่อเวลาผ่านไป คุณจะเข้าใจวิธีการพัฒนาและวางระบบของเรา
 


 
June 2022 / Sathit J.