ก่อนยิงแคมเปญใหญ่ทุกครั้ง ถามตัวเองก่อนว่าระบบรับไหว: วางแผนขีดความสามารถและทดสอบโหลดให้รู้ก่อนพัง

ร้านเสื้อผ้าแฟชั่นที่ขายผ่าน LINE เป็นหลักแห่งหนึ่ง เตรียมแคมเปญลดราคาใหญ่ประจำปีไว้อย่างดี ทั้งครีเอทีฟ งบโฆษณา และสต๊อกสินค้า แต่ไม่มีใครคิดถึงว่าระบบ tracking ที่ใช้ผูก UID กับ Click ID จะรับมือไหวไหมถ้ามีคนทักเข้ามาพร้อมกันหลายร้อยคนในเวลาไม่กี่นาทีแรกที่แคมเปญเปิดตัว ผลคือช่วงพีคของแคมเปญ ระบบประมวลผลข้อมูลไม่ทัน คิวค้าง Conversion จำนวนมากถูกบันทึกช้าหรือหายไปเลย ทั้งที่ยอดขายจริงกำลังดีที่สุดของปี

ปัญหานี้ต่างจากปัญหาระบบพังทั่วไปตรงที่มันไม่ได้เกิดจากบั๊กหรือความผิดพลาดของโค้ด แต่เกิดจากการที่ระบบไม่เคยถูกทดสอบว่ารับโหลดสูงสุดที่คาดว่าจะเกิดขึ้นได้จริงไหม ทีมส่วนใหญ่ทดสอบแค่ว่า 'ทำงานถูกต้อง' แต่ไม่เคยทดสอบว่า 'ทำงานถูกต้องได้ภายใต้ความเร็วสูงสุด'

บทความนี้จะพาดูว่าการวางแผนขีดความสามารถและทดสอบโหลดสำหรับระบบ tracking ที่เชื่อมกับ LINE ควรทำยังไง ก่อนที่แคมเปญใหญ่ครั้งต่อไปจะมาถึง

ประเมินโหลดสูงสุดที่คาดว่าจะเกิดขึ้นก่อน

จุดเริ่มต้นที่ดีที่สุดคือดูข้อมูลย้อนหลังของแคมเปญที่ผ่านมา ว่าช่วงพีคที่สุด (มักเป็นชั่วโมงแรกของการเปิดตัวโปรโมชัน) มีคนทักเข้ามากี่ข้อความต่อนาที แล้วประเมินว่าแคมเปญครั้งใหม่ที่มีงบโฆษณาสูงขึ้นหรือมีการโปรโมตแรงกว่าเดิม จะมีโหลดสูงกว่าเดิมกี่เท่า

ถ้าไม่มีข้อมูลย้อนหลังเลย (เช่นเป็นธุรกิจใหม่หรือทำแคมเปญใหญ่ครั้งแรก) ควรประเมินแบบระวังไว้ก่อน โดยคำนวณจากงบโฆษณาที่จะยิงและอัตราการทักที่คาดหวัง แล้วบวกเผื่อไว้อย่างน้อย 2-3 เท่าของค่าที่ประเมินได้ เพราะแคมเปญที่ประสบความสำเร็จเกินคาดเป็นเรื่องที่เกิดขึ้นได้เสมอ

ทดสอบโหลดยังไงโดยไม่กระทบระบบจริง

1. สร้างสภาพแวดล้อมทดสอบ (staging) ที่มีโครงสร้างเหมือนระบบจริงให้มากที่สุด รวมถึงฐานข้อมูลที่มีปริมาณข้อมูลใกล้เคียงของจริง เพราะฐานข้อมูลว่างเปล่าจะทดสอบได้เร็วกว่าความเป็นจริงมาก
2. ใช้เครื่องมือจำลอง traffic (เช่นสคริปต์ยิง webhook ปลอมจำนวนมากในเวลาสั้น ๆ) เพื่อเลียนแบบสถานการณ์คนทักพร้อมกันตามตัวเลขที่ประเมินไว้ในขั้นตอนก่อนหน้า
3. เฝ้าดูว่าระบบเริ่มมีปัญหาที่โหลดระดับไหน เช่นเวลาตอบสนองเริ่มช้าลงผิดปกติที่กี่ข้อความต่อนาที หรือคิวเริ่มค้างที่จุดไหน เพื่อรู้ 'เพดาน' จริงของระบบปัจจุบัน
4. เทียบเพดานที่ทดสอบได้กับโหลดสูงสุดที่คาดว่าจะเกิดในแคมเปญจริง ถ้าเพดานต่ำกว่าที่คาดไว้ ต้องปรับปรุงระบบก่อนวันจริง ไม่ใช่ปล่อยให้ไปเจอปัญหาหน้างาน คล้ายกับปัญหาที่เคยเกิดในแคมเปญ Flash Sale ที่ยิง event ทีละตัวจนโดน rate limit

ถ้าเวลาไม่พอสำหรับทดสอบเต็มรูปแบบ มีทางลัดอะไรบ้าง

• เพิ่มทรัพยากรเซิร์ฟเวอร์ชั่วคราวเฉพาะช่วงแคมเปญ (scale up) แล้วลดกลับหลังแคมเปญจบ เป็นวิธีที่ทำได้เร็วที่สุดแม้ไม่ได้แก้ปัญหาระยะยาว
• ใช้ชั้น cache สำหรับข้อมูลที่อ่านบ่อยเพื่อลดภาระฐานข้อมูลหลักในช่วงพีค ตามหลักการที่อธิบายไว้ในการวางชั้น cache ลดเวลาตอบสนอง
• เตรียมแผนสำรองไว้ล่วงหน้าเผื่อระบบรับไม่ไหวจริง เช่นมีขั้นตอนที่แอดมินเข้ามาช่วยยืนยัน Conversion ด้วยมือชั่วคราวสำหรับ event ที่ค้างอยู่ในคิว แทนที่จะปล่อยให้หายไปเงียบ ๆ และเตรียมมาตรการป้องกันแบบในการป้องกันบอทช่วง Flash Sale เผื่อโหลดที่พุ่งสูงมาจากการโจมตีไม่ใช่ลูกค้าจริง

หลังแคมเปญจบ อย่าลืมเก็บข้อมูลไว้ใช้ครั้งหน้า

ทุกครั้งที่ทำแคมเปญใหญ่ ควรบันทึกไว้ว่าโหลดสูงสุดจริงที่เกิดขึ้นคือเท่าไหร่ ระบบรับมือได้ดีแค่ไหน มีจุดไหนที่เกือบพังหรือชะลอตัว ข้อมูลเหล่านี้จะทำให้การประเมินโหลดของแคมเปญครั้งต่อไปแม่นยำขึ้นเรื่อย ๆ แทนที่จะต้องเดาใหม่ทุกครั้ง

สรุป

แคมเปญใหญ่ที่ประสบความสำเร็จเกินคาด ควรเป็นเรื่องน่ายินดี ไม่ใช่วันที่ระบบ tracking ล้มเหลวจนไม่รู้ว่าใครซื้ออะไรไปบ้าง การวางแผนขีดความสามารถล่วงหน้าคือสิ่งที่ทำให้ความสำเร็จนั้นถูกวัดผลได้ครบถ้วนจริง

การทดสอบโหลดไม่ใช่ขั้นตอนที่ทำครั้งเดียวจบ แต่เป็นสิ่งที่ควรทำก่อนทุกแคมเปญที่คาดว่าจะมีโหลดสูงกว่าปกติ เพราะระบบและปริมาณลูกค้าเปลี่ยนแปลงไปเรื่อย ๆ ตามการเติบโตของธุรกิจ

• ประเมินโหลดสูงสุดจากข้อมูลย้อนหลัง แล้วบวกเผื่อไว้เสมอสำหรับความสำเร็จที่เกินคาด
• ทดสอบโหลดบนสภาพแวดล้อมทดสอบก่อนวันจริง เพื่อรู้เพดานจริงของระบบ
• เตรียมทางลัดและแผนสำรองไว้เผื่อเวลาทดสอบไม่พอ ดีกว่าไม่เตรียมอะไรเลย

คำถามที่พบบ่อย