ในบทความก่อนหน้า เราได้แนะนำการ Scale ขนาดใหญ่ด้วย MongoDB การ Scale มักมีลักษณะเป็นการตอบสนอง (Reactive) ซึ่งนำไปสู่ปัญหา เช่น ประสิทธิภาพแอปพลิเคชันลดลง หรือแย่กว่านั้นคือ Downtime ทั้งหมด ปัญหาเหล่านี้ส่งผลให้ประสบการณ์ลูกค้าแย่ลงและกระทบต่อธุรกิจโดยตรง ดังนั้น จะรู้ได้อย่างไรว่าเป็นเวลาที่เหมาะสมในการ Scale ฐานข้อมูล Mongo เพื่อไม่ให้กระทบต่อกำไรสุทธิ?
หาเกณฑ์ที่เหมาะสมสำหรับแอปของคุณ
เพื่อให้แอปพลิเคชันของคุณทนต่อการเติบโตของการใช้งานและการเพิ่มขึ้นของ Traffic อย่างกะทันหัน จำเป็นอย่างยิ่งที่จะต้อง Load Test ระบบเพื่อหาเกณฑ์ (Threshold) ที่แอปพลิเคชันรับมือได้ ก่อนที่จะนำการเปลี่ยนแปลง เช่น การ Scale ไปใช้ใน Production System บ่อยครั้งที่ขั้นตอนนี้ถูกมองข้าม ทำให้เกิด "Fire Drill" (การแก้ไขปัญหาเร่งด่วน) เมื่อเจอปัญหาจาก Traffic ที่เพิ่มขึ้น
เส้นทางสู่ Load Test MongoDB ที่สำเร็จ ควรพิจารณาปัจจัยต่อไปนี้:
- Metric ใดที่ต้อง Monitor เพื่อหาจุดคอขวด (Bottleneck)?
- ควรใช้เกณฑ์ (Threshold) อะไรในการตัดสินใจ Scale?
- ควรใช้เครื่องมืออะไรในการวิเคราะห์ Metric?
- ควร Run Load Test ที่ไหน?
ควร Monitor Metric ใดเพื่อหา Bottleneck?
ขั้นแรก คุณต้องกำหนดเกณฑ์ (Criteria) ในการหาปัจจัยจำกัดของแอปพลิเคชันเฉพาะตัว ทุกแอปพลิเคชันแตกต่างกัน การรู้ข้อกำหนดเหล่านี้จะช่วยให้คุณกำหนด Metric ที่เหมาะสมฝั่ง Database ได้
ตัวอย่างข้อกำหนดฝั่งแอปพลิเคชัน:
- แอปต้องการ X Inserts ต่อวินาที เมื่อ Traffic เพิ่มขึ้น
- ข้อมูลต้องส่งคืนให้ผู้ใช้ภายใน 100 มิลลิวินาที
- มีขีดจำกัดจำนวน Concurrent Connections
- มีขีดจำกัดทรัพยากร Server เช่น CPU สูงหรือ Load Average สูง
เมื่อกำหนด Metric ฝั่งแอปได้แล้ว คุณจึงตัดสินใจได้ว่าจะ Monitor อะไรฝั่ง Database
เช่น หากข้อกำหนดคือต้องการ Insert Request จำนวนหนึ่ง ให้เน้น Metric การเขียน (Write Metrics) เช่น:
- Server I/O
- Database Locking
- opcounters ด้าน Active Writes
- Available Write Tickets หากใช้ WiredTiger เป็น Storage Engine
เครื่องมือสำหรับวิเคราะห์ Metric
เมื่อกำหนด Metric ที่ต้อง Monitor แล้ว ต่อมาคือการรวบรวมข้อมูลจากฝั่ง Database นี่คือ Utility ที่ใช้ได้:
- mongostat - แสดง Metric แบบ Real-time เกี่ยวกับ Locking, Read/Write Queues
- db.currentOp() - ตรวจสอบ Operation ที่กำลังทำงานอยู่
- mongotop - ดู Top Active Collections
- Server Utilities เช่น top, sar, iostat - แสดง CPU Utilization, Disk Throughput
นอกจากการวิเคราะห์ Real-time แล้ว ยังสามารถขุดข้อมูลจาก MongoDB Logs เพื่อดูรายละเอียดกิจกรรม Database และ Error Conditions ได้ MongoDB Log Query ที่ใช้เวลานานกว่า 100ms โดย Default จึงเป็นเครื่องมือดีในการหา Query ที่ประสิทธิภาพต่ำ
กำหนดสถานที่ Run Load Test
เมื่อกำหนดเครื่องมือรวบรวมข้อมูลแล้ว ก็พร้อม Load Test ความคิดร่วมบอกว่า ไม่ควร Load Test ใน Production Environment แต่บางครั้งกลายเป็นอุปสรรค เพราะ Spin up Environment ทดสอบเร็วพออาจยาก หากยังไม่ได้ใช้ ObjectRocket Platform คุณสามารถ Spin up MongoDB Test Cluster ได้อย่างรวดเร็ว
ต้องการความช่วยเหลือ?
การรู้ว่าจะ Scale MongoDB เมื่อไหร่ อาจซับซ้อน ลูกค้า ObjectRocket ได้รับการสนับสนุน Scaling และ Sharding ที่ดีที่สุด DBA ของเราช่วยทุกด้านของการ Scale Cluster และความช่วยเหลือนี้รวมอยู่ในบริการแล้ว ติดต่อเราวันนี้เพื่อเริ่มต้น
ตอนนี้คุณเริ่มกำหนดได้แล้วว่าจะ Scale MongoDB Instance เมื่อไหร่ ในบล็อกต่อไป เราจะครอบคลุมวิธีการ Scale MongoDB Instance
