ระบบรับคนพร้อมกันได้กี่คน: วางแผน capacity และทดสอบโหลดก่อนวันเปิดใช้งานจริง

ระบบลงทะเบียนที่ประกาศเปิดรับเวลา 9:00 น. ของวันที่กำหนดไว้ล่วงหน้า มักใช้งานหนักที่สุดในชีวิตของมันภายในสิบนาทีแรก ไม่ได้รอถึงเดือนที่สิบสอง ช่วงนั้นเองที่คำถามซึ่งควรถูกถามตั้งแต่วันออกแบบจะย้อนกลับมา คือระบบนี้รับคนพร้อมกันได้กี่คน และมีใครเคยพิสูจน์ตัวเลขนั้นจริงหรือยัง คนที่ต้องตอบคำถามนี้ต่อผู้บริหารในเช้าวันนั้นคือทีมของคุณ ผู้ให้บริการ cloud ไม่ได้อยู่ในห้องประชุมด้วย

บทความนี้ว่าด้วยการตัดสินใจก่อนวันเปิดใช้งาน ได้แก่ ประเมินพีคจากอะไร ทดสอบอะไรถึงจะนับว่าพิสูจน์แล้ว เพดานของ cloud อยู่ตรงไหน จะยอมให้ระบบช้าแบบไหนเมื่อคนเกิน และจะเขียนตัวเลขทั้งหมดนี้ลงเกณฑ์ตรวจรับอย่างไร ส่วนการตั้ง alert หลังระบบเปิดใช้งานแล้วเป็นอีกโจทย์หนึ่ง ซึ่งเราเขียนแยกไว้ในบทความเรื่อง monitoring และ alert

พีคจริงมาจากปฏิทินงาน ไม่ได้มาจากค่าเฉลี่ย

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

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

วิธีที่เราใช้ประเมินคือเริ่มจากจำนวนคนที่มีสิทธิ์ใช้งานจริง แล้วถามฝ่ายธุรกิจสองคำถาม คือสัดส่วนเท่าไรจะเข้ามาในช่วงแรก และแต่ละคนใช้เวลาอยู่ในระบบนานเท่าไร จากนั้นใช้ความสัมพันธ์ที่เรียกว่า Little's Law (จำนวนคนในระบบพร้อมกัน เท่ากับอัตราคนเข้าคูณเวลาที่แต่ละคนอยู่ในระบบ) แปลงเป็นจำนวนผู้ใช้พร้อมกัน

ยกตัวอย่างด้วยตัวเลขสมมติ ถ้ามีผู้มีสิทธิ์ 200,000 คน และคาดว่า 20% จะเข้ามาภายใน 30 นาทีแรก เท่ากับ 40,000 คนใน 30 นาที หรือประมาณ 1,300 คนต่อนาที ถ้าแต่ละคนใช้เวลากรอกและยื่นเอกสารประมาณ 10 นาที ระบบจะมีคนอยู่พร้อมกันราว 13,000 คน

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

ตัวเลขที่ไม่มีเจ้าของ มักกลายเป็นความผิดของทีมไอที

load test ที่พิสูจน์อะไรได้ ต้องเดินเส้นทางเดียวกับผู้ใช้

load test (การทดสอบโหลด) ที่พบบ่อยคือยิงคำขอจำนวนมากไปที่หน้าแรกของเว็บ แล้วรายงานว่ารับได้หลายหมื่นคำขอต่อวินาที ผลแบบนี้มักวัดความสามารถของ CDN หรือ cache มากกว่าวัดระบบ เพราะหน้าแรกแทบไม่แตะฐานข้อมูลเลย ส่วนที่เสียในวันจริงมักอยู่หลังปุ่มยืนยัน

load test ที่มีความหมายต้องครอบคลุมอย่างน้อยสี่เรื่อง

• user journey ที่เหมือนของจริง เช่น login ขอ OTP กรอกฟอร์ม แนบไฟล์ ยืนยัน และกลับมาเช็กสถานะ ในสัดส่วนที่ใกล้เคียงวันจริง คนที่รีเฟรชหน้าเช็กสถานะซ้ำหลายรอบก็เป็นโหลดเหมือนกัน

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

• บริการภายนอกที่ระบบพึ่งพา เช่น ผู้ให้บริการส่ง SMS สำหรับ OTP ระบบชำระเงิน หรือ API ตรวจสอบข้อมูลของหน่วยงานอื่น แต่ละรายมี rate limit ของตัวเอง ซึ่งไม่ได้ขยายตามจำนวนเครื่องของคุณ

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

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

เกณฑ์ผ่านต้องตกลงกันก่อนเริ่มทดสอบ เช่น ที่ผู้ใช้พร้อมกัน 13,000 คน คำขอ 95% ต้องตอบภายในกี่วินาที และอัตรา error ต้องไม่เกินเท่าไร ถ้ากำหนดเกณฑ์หลังเห็นผล ตัวเลขมักถูกปรับให้ผ่านเสมอ หลังผ่านเป้าแล้ว เราแนะนำให้เพิ่มโหลดต่อจนระบบเริ่มเสีย เพื่อรู้ว่าเหลือระยะเผื่อเท่าไร และส่วนไหนของระบบเสียก่อน

autoscaling มีเพดาน และบางเพดานไม่เกี่ยวกับงบ

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

เพดานแรกคือ quota ของบัญชี Google Cloud กำหนด CPU quota เป็นรายภูมิภาค คือจำนวน vCPU รวมของทุกเครื่องใน region นั้น และ managed instance group ที่ใช้ autoscaling ต้องมี quota เหลือพอสำหรับทรัพยากรทุกตัวที่กลุ่มนั้นใช้ เอกสารของ Google Cloud ยังเขียนไว้ชัดว่า quota ไม่ได้รับประกันว่าทรัพยากรจะมีให้ใช้เสมอ (อ้างอิง: Google Cloud, Allocation quotas ข้อมูล ณ 29 ก.ย. 2026)

Microsoft Azure แบ่ง vCPU quota เป็นสองชั้นในแต่ละ region คือยอดรวมทั้ง region และยอดแยกตามตระกูลเครื่อง ถ้าเกินชั้นใดชั้นหนึ่ง การสร้างเครื่องใหม่จะไม่ได้รับอนุญาต Azure ยังตรวจ quota กับ capacity แยกกัน แม้ quota พอ การสร้างเครื่องก็ล้มเหลวได้ถ้า region หรือ zone นั้นไม่มีเครื่องขนาดที่ขอเหลืออยู่ ทางที่ Azure ระบุไว้สำหรับกรณีที่ต้องการ capacity แน่นอนคือ on-demand capacity reservation (อ้างอิง: Microsoft Learn, vCPU quotas ข้อมูล ณ 29 ก.ย. 2026)

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

เพดานที่สองคือเวลา autoscaler ต้องเห็นโหลดก่อน แล้วจึงสั่งเพิ่มเครื่อง เครื่องใหม่ต้องบูตและเตรียมแอปพลิเคชันก่อนรับงานได้ Google Cloud เรียกช่วงเตรียมนี้ว่า initialization period และตั้งค่าเริ่มต้นไว้ 60 วินาที ส่วน predictive autoscaling ที่ขยายล่วงหน้าได้นั้น ทำงานได้ดีกับโหลดที่ขึ้นลงเป็นรอบรายวันหรือรายสัปดาห์ (อ้างอิง: Google Cloud, Autoscaling groups of instances ข้อมูล ณ 29 ก.ย. 2026) วันเปิดลงทะเบียนที่เกิดปีละครั้งไม่เข้ารูปแบบนั้น ทางที่ตรงกว่าคือตั้งจำนวนเครื่องขั้นต่ำให้พอรับพีคไว้ก่อนเวลาเปิด แล้วค่อยลดลงเมื่อพีคผ่านไป

เพดานที่สามอยู่ที่ฐานข้อมูล web tier เพิ่มเครื่องได้ง่าย แต่ฐานข้อมูลหลักมักขยายกลางวันงานแบบเดียวกันไม่ได้ และทุกเครื่องที่เพิ่มขึ้นจะเปิด connection ไปที่ฐานข้อมูลเพิ่มด้วย รูปแบบที่พบได้บ่อยคือ autoscaling ทำงานถูกต้องทุกอย่าง แต่ระบบล้มเพราะ connection ไปฐานข้อมูลเต็มก่อน ขนาดฐานข้อมูลและ connection pool จึงต้องตัดสินจากผล load test ก่อนวันงาน

waiting room คือการเลือกให้ช้าอย่างมีลำดับ แทนการล่มแบบสุ่ม

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

waiting room (ห้องรอคิว) คือการเลือกล่วงหน้าว่าจะให้คนส่วนหนึ่งรอก่อน เพื่อให้คนที่อยู่ในระบบทำรายการจบได้ Cloudflare Waiting Room ใช้เกณฑ์สองตัวในการตัดสินว่าจะเริ่มให้คนเข้าคิว คือจำนวนผู้ใช้ที่ active พร้อมกัน และจำนวนผู้ใช้ใหม่ต่อนาที คิวแบบที่ใช้ได้ทั่วไปคือมาก่อนได้ก่อน (FIFO) ส่วนวิธีอื่นอย่างการสุ่มลำดับเปิดให้เฉพาะบางแผนบริการ และหน้ารอจะรีเฟรชเพื่อแสดงเวลารอโดยประมาณ (อ้างอิง: Cloudflare Waiting Room ข้อมูล ณ 29 ก.ย. 2026) ก่อนนับเป็นส่วนหนึ่งของแผน ควรตรวจว่าแผนบริการ Cloudflare ที่องค์กรใช้อยู่เปิดให้ใช้ความสามารถนี้หรือไม่

เกณฑ์ของห้องรอต้องมาจากตัวเลขที่ load test พิสูจน์แล้ว ถ้าระบบผ่านการทดสอบที่ 13,000 คนพร้อมกัน การตั้งเกณฑ์ไว้ที่ 20,000 คนเพราะอยากให้คนรอน้อย เท่ากับปิดประตูหลังจากระบบล้มไปแล้ว

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

เขียนเป้า capacity ลงเกณฑ์ตรวจรับ

ตัวเลขทั้งหมดข้างต้นจะมีน้ำหนักจริงเมื่ออยู่ในเอกสารตรวจรับ ถ้า TOR เขียนเพียงว่าระบบต้องรองรับผู้ใช้จำนวนมากได้ จะไม่มีใครพิสูจน์ได้ว่าผ่านหรือไม่ผ่าน เกณฑ์ที่ตรวจได้ควรระบุอย่างน้อยเรื่องต่อไปนี้

• จำนวนผู้ใช้พร้อมกันเป้าหมาย และสัดส่วน user journey ที่ใช้ทดสอบ

• เวลาตอบสนองที่เปอร์เซ็นไทล์ที่ 95 และอัตรา error สูงสุดที่ยอมรับได้ ณ โหลดเป้าหมาย

• ระยะเวลาที่ต้องรักษาโหลดนั้นไว้ เช่น 30 นาทีต่อเนื่อง

• สภาพแวดล้อมที่ใช้ทดสอบ ขนาดข้อมูล และบริการภายนอกตัวไหนเป็นของจริง ตัวไหนเป็น stub

• ผู้ร่วมสังเกตการทดสอบจากฝั่งองค์กร รายงานผลที่ต้องส่งมอบ และสคริปต์ทดสอบที่รันซ้ำได้

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

เมื่อไหร่ไม่ต้องทำขนาดนี้

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

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

ข้อโต้แย้งที่ได้ยินบ่อย: อยู่บน cloud แล้ว ระบบขยายเองได้

ข้อโต้แย้งนี้มีส่วนถูก autoscaling บน Google Cloud และ Microsoft Azure ทำงานได้จริง และช่วยให้ไม่ต้องซื้อเครื่องเผื่อพีคไว้ทั้งปีแบบ on-premises แต่ autoscaling ขยายเฉพาะส่วนที่ถูกตั้งค่าให้ขยาย ภายใน quota ที่มี และหลังจากเห็นโหลดแล้วเท่านั้น

ฐานข้อมูล lock ในตาราง และ rate limit ของบริการภายนอก ไม่ได้ขยายตาม load test จึงทำงานคู่กับ autoscaling คือบอกว่าควรตั้งค่า autoscaling อย่างไร ควรตั้งเครื่องขั้นต่ำไว้เท่าไร และส่วนไหนของระบบที่ต้องแก้ก่อนวันงาน ทีมที่ดูแลระบบอยู่ทุกวันมักรู้คำตอบบางข้ออยู่แล้ว การทดสอบช่วยเปลี่ยนความรู้นั้นเป็นตัวเลขที่ผู้บริหารใช้ตัดสินใจได้

ถ้าเหลือเวลาไม่กี่สัปดาห์ก่อนเปิดใช้งาน จะเริ่มตรงไหน

1. เขียนการประเมินพีคลงกระดาษหนึ่งหน้า พร้อมสมมติฐานทุกข้อ แล้วให้เจ้าของระบบฝั่งธุรกิจรับรอง

2. ทำรายการบริการภายนอกทุกตัวที่อยู่บนเส้นทางหลักของผู้ใช้ แล้วขอ rate limit จากแต่ละรายเป็นลายลักษณ์อักษร

3. ตรวจ quota ใน region ที่ใช้งานวันนี้ และยื่นขอเพิ่มทันทีถ้าไม่พอ

4. ทดสอบ user journey หลักหนึ่งเส้นที่โหลดเป้าหมาย บนข้อมูลขนาดจริง ก่อนขยายไปเส้นทางอื่น

5. ตัดสินเกณฑ์ของ waiting room จากผลทดสอบ และเตรียมข้อความที่ผู้ใช้จะเห็น

6. กำหนดเวลาตั้งจำนวนเครื่องขั้นต่ำก่อนเปิดรับ และเวลาลดลงหลังพีค

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

สรุป

คำถามว่าระบบรับคนพร้อมกันได้กี่คน ควรมีคำตอบเป็นตัวเลขที่ทดสอบแล้วก่อนวันเปิดใช้งาน ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้เขียนเป้า capacity พร้อมเกณฑ์ผ่านลงในเอกสารตรวจรับ เมื่อตัวเลขอยู่ในเอกสารแล้ว การประเมินพีค การทดสอบ และการเตรียม quota จะมีเจ้าของและมีกำหนดเวลาตามมาเอง

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ข้อมูลเพิ่มเติมเกี่ยวกับเราดูได้ที่ superdev.tech สำหรับองค์กรที่กำลังเตรียมเปิดใช้งานระบบ เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าระบบของคุณยังไม่จำเป็นต้องทดสอบโหลดเต็มรูปแบบ เราจะบอกตรง ๆ