เดิมโปรแกรมจะมีกลไกการตรวจสอบ หากพบว่าการติดต่อกับ database เกิด error หรือใช้เวลานานเกินไป (long query) จะส่ง notify ไปที่ line bot เพื่อให้ผู้ดูแลตรวจสอบ ทำการแก้ไขหรือปรับปรุงประสิทธิภาพของโปรแกรม ไม่ต้องรอให้ user แจ้งมา
เช่น เมื่อพบว่าเกิด long query เมื่อสั่งค้นหา รายละเอียดของ notify แจ้งมาด้วยว่า ข้อความที่ user สั่งค้นหาแล้วได้คำตอบช้า คือข้อความอะไร เพื่อให้โปรแกรมเมอร์กลับมาปรับปรุงกลไกการค้นหาของโปรแกรมให้ดีขึ้น
หรือ เมื่อพบว่าเกิด long query ในรายงาน ก็จะต้องตรวจสอบจาก notify ว่ารายงานนั้น user เรียกรายงานด้วยเงื่อนไขอะไร เพื่อให้ทีมพัฒนา (Implementation Team) ที่ดูแลลูกค้าทบทวน query ที่ใช้กับรายงานให้สอดคล้องกับการใช้งานยิ่งขึ้น
เมื่อจำนวนผู้ใช้เพิ่มมากขึ้น สาเหตุของปัญหาก็ซับซ้อนมากขึ้น บางครั้งรายงานตัวเดียวกันอาจเกิด long query บ้างไม่เกิดบ้าง หลายครั้งที่มีการเกิด notify เข้ามาพร้อมๆ กันหลายรายงาน ซึ่งจุดเริ่มต้นอาจเกิดจากการเรียกรายงานตัวใดตัวหนึ่ง แล้วทำให้รายงานอื่นที่มีการเรียกใช้ในเวลาไล่เลี่ยกันพลอยมีปัญหาไปด้วย การวิเคราะห์หาสาเหตุจึงต้องการการเก็บประวัติใช้งาน และเครื่องมือที่ช่วยวิเคราะห์ได้มากกว่าการไล่ดู notify ใน line
จากรูปข้างบน รายงาน “ulogs by hour” สรุปสถิติการใช้งานเป็นรายชั่วโมง ช่วยให้เราได้เห็นภาพรวมการใช้งานจากทุก site ว่ามี user ที่กำลังใช้งานกี่คน มีการฟ้อง mongo (long query) กี่ครั้ง สามารถสืบค้นเข้าไปดูรายละเอียดต่อไปได้อีกเช่นเดียวกับ line notify
รายงาน “ulogs by site” ให้มุมมองสรุปสถิติการใช้งาน โดยเปรียบเทียบแต่ละ site ที่ใช้งาน ช่วยให้รู้จำนวน user และช่วงเวลาที่ใช้งาน
1+ million logs per month challenge
ความท้าทายของการเก็บ logs อยู่ที่ปริมาณข้อมูลที่เข้ามาตลอดเวลา เฉลี่ยอยู่ที่เดือนละกว่า 1 ล้านข้อมูล ขณะที่ต้นทุนการเก็บข้อมูลเอาไว้คือ ขนาดของพื้นที่ที่จะเพิ่มขึ้นไปเรื่อยๆ แต่การเอามาใช้ประโยชน์ในปัจจุบันยังมีอยู่จำกัด หากจะเก็บข้อมูลไว้เผื่อว่าในอนาคตอาจหาวิธีใช้ประโยชน์ได้มากกว่านี้ ก็ยังไม่รู้ว่าอีกนานเพียงใด ขณะที่ค่าใช้จ่ายในการเก็บข้อมูลเอาไว้เฉยๆ เกิดขึ้นทุกวัน
การออกแบบเวอร์ชั่นแรก เราบันทึกข้อมูลเก็บโดยใช้ Atlas MongoDB สามารถรับได้สบายๆ ปัญหาสำคัญอยู่ที่ปริมาณข้อมูลที่เพิ่มขึ้นอย่างรวดเร็ว ทำให้ต้องคอยระวัง upgrade cluster ขยายพื้นที่เก็บข้อมูล
หากมองโลกในแง่ดี ตอนนี้เรามีข้อมูลขนาดหลายล้าน สามารถใช้ทดสอบประสิทธิภาพของ Database ได้ประสบการณ์ออกแบบรายงานที่ใช้ข้อมูลขนาดใหญ่
Clearing Old Data
การล้างข้อมูลเก่า ช่วยควบคุมขนาดของข้อมูลได้ดีที่สุด ระยะเวลาที่เก็บข้อมูลที่เหมาะสมคือ 12 เดือน แต่นั่นหมายความว่าต้องใช้ cluster size ประมาณ 20GB ซึ่งเป็นต้นทุนที่เพิ่มเข้ามา ขณะที่ประวัติเก่าๆ อายุเกิน 1 เดือน แทบไม่ได้ใช้ประโยชน์
ดังนั้นระยะเวลาที่คุ้มค่าที่สุดคือ เก็บข้อมูลไว้ประมาณ 2–3 เดือน ใช้พื้นที่ไม่เกิน 5GB โดยทำการล้างข้อมูลให้เหลือแค่ 2 เดือนล่าสุด แล้วพื้นที่จะกลับมาเต็ม 5GB ทุก 2 เดือน ถึงแม้ว่าการล้างข้อมูลสม่ำเสมอเช่น ทุกสัปดาห์ จะช่วยให้ไม่ต้องเผื่อขนาดไว้มาก แต่หากทำบ่อยๆ ก็เป็นภาระที่มากเกินไป
Archive Cluster
ปี 2021 Digital Ocean เปิดบริการ MongoDB cluster ที่สามารถเลือกแบบ single node ได้ ทำให้มีราคาถูกกว่า Atlas ที่ต้องใช้ replica set 3 nodes จึงเป็นจุดเริ่มต้นของการออกแบบใหม่ ใช้ Atlas cluster ทำหน้าที่เป็น primary database เหมือนเดิม ไม่ต้องมีขนาดใหญ่ เน้นที่เร็วและไม่ล่ม ทำหน้าที่เหมือนเป็น buffer บันทึก log ใหม่ที่เข้ามาไว้ก่อน แล้ว sync ข้อมูลนั้นไปเก็บที่ Digital Ocean cluster ที่รองรับความจุได้มากกว่า หลังจากนั้นค่อยล้างข้อมูลเก่าใน Atlas cluster นั้นออกไป เพื่อรอรับ log ใหม่ได้เรื่อยๆ ไม่มีวันเต็ม
Automation
เมื่อเงื่อนไขลงตัว เวอร์ชั่นสองเป็นการออกแบบกลไกเบื้องหลังใหม่หมด พยายามทำให้เป็นอัตโนมัติ
ทำ service สำหรับ sync ข้อมูลข้าม database แล้วใช้ Job Runner ตั้งเวลาให้ sync ข้อมูลทุกชั่วโมง จาก Atlas cluster ไปเก็บไว้ที่ Digital Ocean cluster
และทุกคืน Job Runner ก็จะเรียก service ที่ทำหน้าที่ล้างข้อมูลเก่าใน Atlas cluster ให้เหลือไม่เกิน 7 วัน ทำให้ Atlas cluster ใช้พื้นที่เก็บข้อมูลไม่เกิน 2GB
ข้อดีของการออกแบบอย่างนี้ เราสามารถเอาข้อมูลจากทั้ง 2 cluster มาใช้วิเคราะห์ได้สะดวก เพราะจัดเก็บในรูปแบบของ database ที่พร้อมใช้อยู่แล้ว หากต้องการดูข้อมูลเร็วที่เป็น real time ก็อ่านจาก Atlas cluster และเมื่อใดที่ต้องดูข้อมูลย้อนหลังนานๆ ก็เปลี่ยนไปใช้ข้อมูลจาก Digital Ocean cluster ได้เช่นกัน
Comments