สายนักวิ่ง นักปั่น หรือ นักกีฬา น่าจะรู้จักและใช้งาน Strava
ซึ่งแต่ละคนสามารถ update activity ต่าง ๆ
รวมทั้งสร้างหรือร่วม Club ต่าง ๆ
เพื่อบันทึก แข่งขัน หรือ ดูสถิติต่าง ๆ
หนึ่งใน feature หลักของ club คือ Leaderboard
ทำการสรุปการ scale ระบบ Leaderboardให้รองรับจำนวนการใช้งานที่สูงขึ้น
รวมทั้งจำนวนผู้ใช้งานในแต่ละ club ที่สูงมาก ๆ
จำนวนสมาชิกต่อ club ที่สูงสุดคือ 2 ล้านคน !!
มาดูกันว่า Strava ทำอย่างไร ?
เริ่มต้นในการพัฒนานั้น ทีม Strava มองว่า
จำนวนสมาชิกใน club ไม่น่าเยอะอาจจะเป็นกลุ่มเล็ก ๆ เท่านั้นเอง
แต่เมื่อเวลาผ่านมาเรื่อย ๆ จำนวนสมาชิกแต่ละ club สูงขึ้นเยอะมาก
ทำให้ระบบมีปัญหาด้าน performance
การพัฒนาจะใช้ Ruby on Rail (RoR) + Active Record
สำหรับการดึงข้อมูลจาก database มาประมวลผลใน Leaderboard
จะทำการดึงข้อมูล activity ในแต่ละชนิดของแต่ละคน
จากนั้นนำมาสรุป และจัดเรียงข้อมูลจากมากไปน้อย
มีการจัดทำ index ต่าง ๆ เรียบร้อย
แต่ก็ยังรองรับจำนวนผู้ใช้งานไม่เยอะ
ดังนั้นจึงทำ caching data โดยมีการ update ข้อมูลทุก ๆ 6 ชั่วโมง
ซึ่งทำให้ระบบรองรับได้มากขึ้นแต่ข้อมูลไม่ realtime
ทำให้ user experience ไม่ดีเลย
รวมทั้ง caching data ไม่ใช่การแก้ไขที่ต้นเหตุ !!
ยิ่งเจอ club ที่มีสมาชิกเป็นล้านคนการ query ข้อมูลมาใหม่
ต้องใช้เวลามากถึง 20 นาที !!
ผลที่ตามมาคือ เจอ error 500 เยอะและบ่อยมาก ๆ
จึงน่าจะได้เวลาแก้ไขที่ต้นเหตุกันได้แล้ว
การแก้ไขปัญหา คือ การเขียนส่วน backend ใหม่
วิธีคิดคือ
เมื่อผู้ใช้งานทำการ upload ข้อมูล activity ใหม่เข้ามายังระบบ
จะทำการ update ข้อมูลใน leaderboard ของแต่ละ club ทันที
แต่ไม่ต้องการให้ rebuid data ใหม่
ดังนั้นจึงทำการเก็บข้อมูลของ leaderboard ไว้ใน Redis แทน database หลัก
ด้วยการใช้ data structure ที่เหมาะสมคือ Sorted Set
นั่นคือ ข้อมูลจะไม่ซ้ำ และจะเรียงจากมากไปน้อยให้ทันที
ส่วนข้อมูลรายละเอียดต่าง ๆ จะเก็บข้อมูลในรูปแบบ Hash
การ Rollout ระบบใหม่ จะทำแบบค่อยเป็นค่อยไป
โดยออกแบบให้ระบบสามารถเปลี่ยนมาใช้งาน feature ใหม่รายคนได้
มีขั้นตอนดังนี้
- เริ่มจาก employee testing ก่อน
- ให้ผู้ใช้งาน 10% ลองใช้งาน
- แล้วค่อย ๆ เพิ่มไปจน 100%
แสดงดังรูป
ผลการทำงานจากระบบใหม่ ดีขึ้น
เป็นข้อมูลที่น่าสนใจ
ซึ่งเราสามารถนำมาเรียนรู้ ศึกษา และนำไปใช้งานได้
