ก่อนแคมเปญ 11.11 ทีมรู้อยู่แล้วว่าคนจะทักพร้อมกันเป็นพัน แต่ไม่เคยทดสอบระบบรับ Traffic ขนาดนั้นมาก่อนสักครั้ง วาง Load Test ล่วงหน้าก่อนวันจริง

ทีมหนึ่งที่ผมช่วยเตรียมระบบก่อนแคมเปญ 11.11 บอกผมอย่างมั่นใจว่า ‘ระบบเราผ่าน queue กับ retry มาแล้ว ไม่น่ามีปัญหาอะไร’ ผมถามต่อว่าเคยทดสอบด้วย traffic จำลองระดับที่คาดว่าจะเกิดขึ้นจริงในวันแคมเปญหรือยัง คำตอบคือไม่เคยเลย เพราะสถาปัตยกรรม queue และ retry ที่มีอยู่เคยผ่านการใช้งานจริงในสถานการณ์ปกติมาโดยตลอด ทีมเลยสันนิษฐานว่ามันน่าจะรองรับ traffic สูงได้เหมือนกัน

ปัญหาคือการที่ระบบทำงานได้ดีในสถานการณ์ปกติไม่ได้แปลว่ามันจะทำงานได้ดีเหมือนกันเมื่อ traffic เพิ่มขึ้นสิบเท่าในเวลาไม่กี่ชั่วโมง เพราะมีจุดคอขวดหลายจุดที่ไม่ปรากฏให้เห็นเลยจนกว่า traffic จะสูงถึงระดับหนึ่ง เช่น connection pool ของฐานข้อมูลที่ตั้งค่าไว้พอสำหรับ traffic ปกติ แต่ไม่พอเมื่อมี worker พยายามเขียนข้อมูลพร้อมกันมากผิดปกติ

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

ความต่างระหว่างการรับมือพีคแบบตั้งรับกับการเตรียมพร้อมเชิงรุก

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

ความแตกต่างนี้สำคัญมากเพราะสถาปัตยกรรมที่ดูดีในกระดาษอาจมีจุดอ่อนที่ไม่มีใครคาดคิดเมื่อเจอ traffic จริง เช่น rate limit ของแพลตฟอร์มโฆษณาที่ปกติไม่เคยชนเพดานเลย แต่พอ traffic พุ่งขึ้นสิบเท่าในวันแคมเปญ อาจชนเพดานได้ทันที การรู้เรื่องนี้ล่วงหน้าผ่าน load test ดีกว่าไปรู้ตอนที่แคมเปญกำลังดำเนินอยู่จริงมาก

ประเมิน traffic ที่คาดว่าจะเกิดขึ้นจากข้อมูลที่มีอยู่

ก่อนจะทดสอบ ต้องมีตัวเลขเป้าหมายที่สมเหตุสมผลก่อนว่าควรทดสอบที่ระดับ traffic เท่าไหร่ วิธีที่ใช้ได้จริงคือดูข้อมูลย้อนหลังของแคมเปญลักษณะใกล้เคียงกันที่เคยทำมาก่อน (ถ้ามี) แล้วคูณด้วยปัจจัยความปลอดภัยเพิ่มเติม เช่น ถ้าปีที่แล้วแคมเปญคล้ายกันมี event สูงสุดที่ 500 รายการต่อนาที ควรทดสอบที่ระดับอย่างน้อย 800-1,000 รายการต่อนาที (ตัวเลขสมมติเพื่อการอธิบาย) เพื่อเผื่อการเติบโตของฐานลูกค้าและความไม่แน่นอนของพฤติกรรมผู้บริโภค

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

วิธีจำลอง traffic สำหรับทดสอบ ไม่ต้องรอวันจริงถึงจะรู้

ตัวชี้วัดที่ต้องจับตาระหว่างทดสอบ ไม่ใช่แค่ ‘ระบบล่มหรือไม่ล่ม’

• P95 และ P99 latency ของแต่ละขั้นตอนใน pipeline ไม่ใช่แค่ค่าเฉลี่ย เพราะค่าเฉลี่ยซ่อนปัญหาที่กระทบคำขอส่วนที่ช้าที่สุดได้ง่าย
• อัตราความสำเร็จของการยิง event เข้าแต่ละแพลตฟอร์มโฆษณา แยกตามปลายทาง เพื่อดูว่าปลายทางไหนเริ่มมีปัญหาก่อนที่ traffic จะสูงสุด
• ความยาวของ queue ที่ค้างอยู่ตลอดการทดสอบ เพื่อดูว่า worker ประมวลผลทันกับอัตราที่ event เข้ามาหรือไม่
• การใช้งาน CPU หน่วยความจำ และ connection pool ของฐานข้อมูล เพื่อหาจุดที่ resource เริ่มตึงก่อนที่จะถึงจุดพังจริง

ทดสอบแล้วเจอจุดอ่อน ต้องทำอะไรต่อก่อนวันจริง

1. จัดลำดับความสำคัญของจุดอ่อนที่พบ ตามผลกระทบที่จะเกิดขึ้นจริงถ้าปล่อยไว้ ไม่ใช่แก้ทุกจุดพร้อมกันจนหมดเวลาก่อนวันแคมเปญ
2. ปรับ resource limit หรือ scaling configuration ตามผลการทดสอบ เช่น เพิ่มจำนวน worker หรือขยาย connection pool ของฐานข้อมูลตามจุดที่พบว่าตึงที่สุด
3. ทดสอบซ้ำอีกครั้งหลังปรับแก้ เพื่อยืนยันว่าการแก้ไขได้ผลจริง ไม่ใช่แค่คาดเดาว่าน่าจะดีขึ้น
4. เตรียมแผนสำรองสำหรับจุดอ่อนที่แก้ไม่ทันก่อนวันจริง เช่น มีทีมเฝ้าระบบใกล้ชิดเป็นพิเศษในช่วงเวลาที่คาดว่า traffic จะสูงสุด พร้อมขั้นตอนที่ชัดเจนว่าจะทำอะไรถ้าเกิดปัญหาจริง

อย่าลืมทดสอบขีดจำกัดของบริการภายนอกที่ระบบพึ่งพา ไม่ใช่แค่เซิร์ฟเวอร์ของตัวเอง

จุดที่ทีมมักมองข้ามเมื่อวางแผน load test คือ ระบบของตัวเองไม่ได้ทำงานอยู่เพียงลำพัง แต่พึ่งพาบริการภายนอกหลายจุด เช่น ฐานข้อมูลที่อาจเป็นบริการ managed service ที่มีขีดจำกัดของ connection พร้อมกัน บริการ queue ที่อาจมีเพดานการใช้งานตามแพ็กเกจที่สมัครไว้ หรือแม้แต่ DNS และ CDN ที่รับ traffic หน้าเว็บก่อนที่จะถึง backend ถ้าจุดใดจุดหนึ่งเหล่านี้มีขีดจำกัดต่ำกว่าที่ระบบหลักของตัวเองรับได้ การทดสอบเฉพาะเซิร์ฟเวอร์ของตัวเองจะไม่มีทางเจอปัญหานี้เลยจนกว่าจะถึงวันจริง

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

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

เตรียมทีมให้พร้อมในวันแคมเปญจริง ไม่ใช่แค่เตรียมระบบ

การทดสอบระบบล่วงหน้าที่ดีต้องมาพร้อมกับการเตรียมทีมให้พร้อมรับมือในวันแคมเปญจริงด้วย เพราะต่อให้ระบบผ่าน load test มาอย่างดี ก็ยังมีโอกาสที่จะเจอปัญหาที่ไม่คาดคิดในวันจริงซึ่งสภาพแวดล้อมมีตัวแปรมากกว่าการทดสอบในสภาพแวดล้อมที่ควบคุมได้ ทีมที่ดูแลระบบควรทราบล่วงหน้าว่าใครเป็นผู้เฝ้าระบบในช่วงเวลาที่คาดว่า traffic จะสูงสุด มีช่องทางสื่อสารด่วนอะไรบ้างเมื่อพบปัญหา และมีอำนาจตัดสินใจปรับ configuration ฉุกเฉิน เช่น เพิ่มจำนวน worker กลางคันได้โดยไม่ต้องรอขั้นตอนอนุมัติที่ใช้เวลานานเกินไป

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

สรุป

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

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

• แคมเปญที่กำหนดวันล่วงหน้าอย่าง 11.11 ควรทดสอบเชิงรุกก่อนวันจริง ไม่ใช่รอพึ่งแค่ queue และ retry ที่ออกแบบไว้ทฤษฎีอย่างเดียว
• ประเมิน traffic เป้าหมายจากข้อมูลแคมเปญเก่าหรือแผนงบโฆษณา แล้วทดสอบด้วย synthetic load หรือ replay ข้อมูลจริง
• จับตา P95/P99 latency, อัตราความสำเร็จแยกปลายทาง และความยาว queue ระหว่างทดสอบ ไม่ใช่ดูแค่ว่าระบบล่มหรือไม่ล่ม

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